Automatically resizing and coverting images

103 views
Skip to first unread message

Mark Kronsbein

unread,
Apr 15, 2020, 9:32:15 AM4/15/20
to ngx-pagespeed-discuss
Hi,

I use Wordpress and due to a bug some images are resized by html width/height.
I'd like to use Mod_Pagespeed to fix this.

pagespeed RewriteLevel CoreFilters;
pagespeed EnableFilters rewrite_images;
pagespeed EnableFilters responsive_images;
pagespeed EnableFilters insert_image_dimensions;
pagespeed EnableFilters resize_rendered_image_dimensions;
pagespeed EnableFilters convert_jpeg_to_webp;

This is my configuration. Some images are getting rewritten, some are resized. Some stay as JPEG.
Is there a way to "force" Mod_Pagespeed to rewrite/resize/convert and fill up the cache from the shell?

Mark

Joshua Marantz

unread,
Apr 15, 2020, 9:47:17 AM4/15/20
to ngx-pagesp...@googlegroups.com
RE using mod_paegspeed to "fix" bugs from a content generator: that's not what it's designed for. mod_pagespeed seeks to deliver the same visualization faster.

RE warming up the MPS server-side cache from the shell: yes :). You can use wget to crawl your HTML, which will help mod_pagespeed warm its cache. You could even do this as a cron job. Having said that, I don't know anyone that's actually reported success with this strategy, but I think it ought to work.

One complexity: mod_pagespeed will optimize resources for the browser, so you'll have to use different request-headers from wget to mimic the browsers you want to optimize for, duplicating their 'Accept' headers.

Let us know how it goes!


--
You received this message because you are subscribed to the Google Groups "ngx-pagespeed-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ngx-pagespeed-di...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/ngx-pagespeed-discuss/c57b8a84-a8a4-4056-93bd-5f3dd4c0d41e%40googlegroups.com.

Mark Kronsbein

unread,
Apr 15, 2020, 9:54:26 AM4/15/20
to ngx-pagespeed-discuss
>RE using mod_paegspeed to "fix" bugs from a content generator: that's not what it's designed for. mod_pagespeed seeks to deliver the same visualization faster.
I know, but serving way smaller images is the same goal for both.

>RE warming up the MPS server-side cache from the shell: yes :). You can use wget to crawl your HTML, which will help mod_pagespeed warm its cache.
Okay, I could try this, thanks. I was just looking for a way to test the rewriting of images. I don't want to warm up the cache for "normal" use.
I just don't understand why the behaviour is different. Seems like I have to test this a lot.
To unsubscribe from this group and stop receiving emails from it, send an email to ngx-pagespeed-discuss+unsub...@googlegroups.com.

Joshua Marantz

unread,
Apr 15, 2020, 10:02:58 AM4/15/20
to ngx-pagesp...@googlegroups.com
If you are talking about *correcting* a broken transform done by WP that's going to be hard, but if you are thinking about *replacing* WP's image optimization for MPS's, that should be fine.

I meant to mention: use 'wget' options to follow links. wget has its own HTML parser I think and will fetch the referenced images, and will do this at some level. This won't help you for images loaded by JS as I don't think wget runs the JS.

Remember that mod_pagespeed (a) has a cache which needs to be warm and (b) will treat different images differently, depending on their original quality, the size at which they will be rendered, etc. This can make it confusing to understand what it is doing.

Also, I didn't notice before that you are using 'resize_rendered_image_dimensions' which makes the 'wget' approach invalid; sorry about that. You will need beacons from actual browsers with rendering engines to inform MPS of how the images are actually rendered.

responsive_images may be harder to understand as well, as it will create a variety of potential resolutions for each image, where each one will only be loaded by a browser rendering at that resolution. wget following links will not warm the cache for responsive images. Sorry!

For simplicity, you might want to start by disabling those 2 rather advanced features temporarily, understand what MPS is doing to your page with its more straightforward optimizations, and then see how you want to add further sophistication.

Thanks!


To unsubscribe from this group and stop receiving emails from it, send an email to ngx-pagespeed-di...@googlegroups.com.

--
You received this message because you are subscribed to the Google Groups "ngx-pagespeed-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ngx-pagespeed-di...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/ngx-pagespeed-discuss/3e12bccc-01ac-40fe-a569-bc9efc0830b1%40googlegroups.com.

Longinos

unread,
Apr 15, 2020, 3:42:02 PM4/15/20
to ngx-pagespeed-discuss

Hi
An other option to warm the pagespeed cache is using chromium headles. Almost for Centos distro you can find rpm to install it from the EPEL repo.(chromium-headless)
Chromium headless execute the javascript and the beaconing works and have a parameter to change the UA.

Krunal Jariwala

unread,
Apr 16, 2020, 2:32:50 AM4/16/20
to ngx-pagespeed-discuss
Can you share, how does this work?

Longinos

unread,
Apr 16, 2020, 5:43:21 AM4/16/20
to ngx-pagespeed-discuss
Chromium headless is like Google Chrome but w/o any user interface.
The rpm provides an executable (headless_shell), this executable have a bunch of parameters, to set the size of viewport, to se the UA string, to create a image from the fetched url, to execute the javascript, to save to a file the dom.....
The rpm is a Fedora project, but maybe there is a deb package.

/usr/lib64/chromium-browser/headless_shell --disable-translate --disable-background-networking --safebrowsing-disable-auto-update --disable-sync  --disable-default-apps --disable-software-r
asterizer --single_process --disable-features --disable-extensions --disable-setuid-sandbox --no-sandbox --disable-gpu  --tls1.3  --window-size=412,732 --enable-ipv6 --user-agen
t="USER AGENT STRING" --disable-features=NetworkService --enable-tcp-fast-open --disable-zygote https://URL_TO_FETCH

This a example.Mos of the parameters are the same from chrome executed in a command line.

Joshua Marantz

unread,
Apr 16, 2020, 7:19:53 AM4/16/20
to ngx-pagesp...@googlegroups.com
I agree -- Chromium headless sounds like the way to go...I was not aware that was now an installable product. You would still need to get it to run in all the modes you want pre-optimized for your users. For example, if you are using responsive images you'd need it to run at all the required resolution breakpoints. It's not a very easy path.


--
You received this message because you are subscribed to the Google Groups "ngx-pagespeed-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ngx-pagespeed-di...@googlegroups.com.

Longinos

unread,
Apr 16, 2020, 3:44:59 PM4/16/20
to ngx-pagespeed-discuss
HI Joshua

But you can have some info from Analitycs or a similar tool on wat hare the 3 (for example) most repeated AU and screen resolution and have the pagespeed cache warmed with these 3 for all your pages.
For sure you have about the 80% of request pre-optimized. With a cron job and a proper TTL to stored assests in the cache....

El jueves, 16 de abril de 2020, 13:19:53 (UTC+2), Joshua Marantz escribió:
I agree -- Chromium headless sounds like the way to go...I was not aware that was now an installable product. You would still need to get it to run in all the modes you want pre-optimized for your users. For example, if you are using responsive images you'd need it to run at all the required resolution breakpoints. It's not a very easy path.


On Thu, Apr 16, 2020 at 5:43 AM Longinos <longinos.in...@gmail.com> wrote:
Chromium headless is like Google Chrome but w/o any user interface.
The rpm provides an executable (headless_shell), this executable have a bunch of parameters, to set the size of viewport, to se the UA string, to create a image from the fetched url, to execute the javascript, to save to a file the dom.....
The rpm is a Fedora project, but maybe there is a deb package.

/usr/lib64/chromium-browser/headless_shell --disable-translate --disable-background-networking --safebrowsing-disable-auto-update --disable-sync  --disable-default-apps --disable-software-r
asterizer --single_process --disable-features --disable-extensions --disable-setuid-sandbox --no-sandbox --disable-gpu  --tls1.3  --window-size=412,732 --enable-ipv6 --user-agen
t="USER AGENT STRING" --disable-features=NetworkService --enable-tcp-fast-open --disable-zygote https://URL_TO_FETCH

This a example.Mos of the parameters are the same from chrome executed in a command line.


El jueves, 16 de abril de 2020, 8:32:50 (UTC+2), Krunal Jariwala escribió:
Can you share, how does this work?

On Thursday, 16 April 2020 01:12:02 UTC+5:30, Longinos wrote:

Hi
An other option to warm the pagespeed cache is using chromium headles. Almost for Centos distro you can find rpm to install it from the EPEL repo.(chromium-headless)
Chromium headless execute the javascript and the beaconing works and have a parameter to change the UA.

--
You received this message because you are subscribed to the Google Groups "ngx-pagespeed-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ngx-pagespeed-discuss+unsub...@googlegroups.com.
Reply all
Reply to author
Forward
0 new messages