Images not resized via resize_rendered_image_dimensions

[mick...@kikuta2008.com]

Hi,

We have recently upgraded to to mod_pagespeed 1.11.33.2-0 and images are not being resized. When we run the server with debug filter on it says "Image does not appear to need resizing." even though the images do require a resize.

Note several points, not sure if they are related or not, but I thought mentioning anyway:

1. on the first request we get the message "filter timeout exceeded".
   
2. we first requested the same page as a desktop, than requested the page through chrome mobile emulator through the same browser (we deleted the cookies and still got the same result, just in case you save the browser dimensions on a cookie).
3. another image on the page was resized, but to a wrong size (see last screenshot)

See attached screenshots of the html with the comments and the image sizes.

If you can please advise us how to proceed in order to overcome this problem we would be very thankful :-)

Mickey.

[Otto van der Schaaf]

Did you configure the resize_rendered_image_dimensions filter? Or resize_images? (or both?)

resize_rendered_image_dimensions uses beaconing to determine actual rendered image dimensions, but resize_images depends on the width and height attributes declared in html.

Also, resize_rendered_image_dimensions may need a few page reloads in the browser before it takes effect as it relies on the browser beaconing back the rendered dimensions to mod_pagespeed.

Otto 

--
You received this message because you are subscribed to the Google Groups "mod-pagespeed-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to mod-pagespeed-di...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/mod-pagespeed-discuss/146cc0d7-5bd2-476f-83a6-fae8f68983f4%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[mick...@kikuta2008.com]

Hi Otto and thank you for the response!

We are using the resize_rendered_image_dimensions and do not add the image sizes on the image itself since we want the image to fit the screen size on the various devices through width in percentage. Per my understanding this should be sufficient to resize the image. Note the width is defined on the CSS files.

We have made 10 requests with an interval of 2 seconds in between, to the page and the image is not resized. Also, the beacon is passed through nicely to the server returning 204.

In terms of the configuration, we hardly changed it from the original configuration, here is the diff:

$ diff /etc/httpd/conf.d/pagespeed.conf /vendors/etc/httpd/conf.d/pagespeed.conf
89,93c89
<       ModPagespeedEnableFilters collapse_whitespace,elide_attributes,trim_urls
<       ModPagespeedEnableFilters resize_rendered_image_dimensions
<       ModPagespeedEnableFilters remove_quotes,remove_comments
<       ModPagespeedEnableFilters insert_dns_prefetch
<       #ModPagespeedEnableFilters debug
---
>     # ModPagespeedEnableFilters collapse_whitespace,elide_attributes

I would be extremely thankful if you can shade some light on this.

Thanks for the help :-)

Mickey.

On Monday, June 13, 2016 at 11:07:09 PM UTC+3, Otto van der Schaaf wrote:

Did you configure the resize_rendered_image_dimensions filter? Or resize_images? (or both?)

resize_rendered_image_dimensions uses beaconing to determine actual rendered image dimensions, but resize_images depends on the width and height attributes declared in html.

Also, resize_rendered_image_dimensions may need a few page reloads in the browser before it takes effect as it relies on the browser beaconing back the rendered dimensions to mod_pagespeed.

Otto 

On Mon, Jun 13, 2016 at 2:18 PM, <mick...@kikuta2008.com> wrote:

Hi,

We have recently upgraded to to mod_pagespeed 1.11.33.2-0 and images are not being resized. When we run the server with debug filter on it says "Image does not appear to need resizing." even though the images do require a resize.

Note several points, not sure if they are related or not, but I thought mentioning anyway:

1. on the first request we get the message "filter timeout exceeded".
   
2. we first requested the same page as a desktop, than requested the page through chrome mobile emulator through the same browser (we deleted the cookies and still got the same result, just in case you save the browser dimensions on a cookie).
3. another image on the page was resized, but to a wrong size (see last screenshot)

See attached screenshots of the html with the comments and the image sizes.

If you can please advise us how to proceed in order to overcome this problem we would be very thankful :-)

Mickey.

--
You received this message because you are subscribed to the Google Groups "mod-pagespeed-discuss" group.

To unsubscribe from this group and stop receiving emails from it, send an email to mod-pagespeed-discuss+unsub...@googlegroups.com.

[Joshua Marantz]

What you describe would be a great feature for mod_pagespeed, but it's yet part of a fully automated flow.  The challenge is the pixel-width of your image will be proportional to the physical screen dimensions.  This means the same image URL needs vary on screen-size, and there's no good way to specify that with a single URL, and mod_pagespeed doesn't know the client screen width when it rewrites the HTML.  Beacons don't help with your use-case (sized proportional to screen); they only help when the size for an image on a page is the same across all clients.

That is in theory what srcset is for.  You can specify a discrete set of URLs with different dimensions, and use srcset to specify which one you want based on pixel width.  Unfortunately, mod_pagespeed does not currently support that mechanism, which is a shame because mps has the technology to resize the images for you.  Specifically:

• mod_pagespeed can inject srcset directives (see the responsive_images filter), but they are used for varying the image based on pixel density (e.g. Retina displays) not pixel width.
  
• mod_pagespeed will not currently rewrite images in srcset directives specified in the origin HTML.

Both of those are things that we could fix.  However, another idea is to inject a JavaScript function to detect the pixel size, and formulate a URL on the client based on the actual rendered dimensions after onload.  You can actually do this today yourself with mod_pagespeed, but it's a bit of a hack. I created a prototype of such a hack myself just now because I was curious and I'd be interested in your opinion about it.

The hack requires that you put this into your pagespeed.conf:

    ModPagespeedUrlValuedAttribute img data-hack-src Image

    ModPagespeedEnableFilters rewrite_images

The HTML below will work with mod_pagespeed to request image URLs that are sized according to context, without using beacons.

<script>

  function resizeImage(img) {

    var originImage = img.getAttribute('data-hack-src');

    if (!originImage) {

      return;

    }

    // If the data-hack-src has been not been optimized yet, use the origin image.

    if (originImage.indexOf('.pagespeed.') == -1) {

      img.src = originImage;

      return;

    }

    var slash = originImage.lastIndexOf('/');

    var path = '';

    if (slash != -1) {

      path = originImage.substr(0, slash + 1);

      originImage = originImage.substr(slash + 1);

    }

    var newSrc = path + img.clientWidth + 'x' + img.clientHeight + originImage;

    if (img.src != newSrc) {

      img.src = newSrc;

      img.removeAttribute('data-hack-src');

    }

  }

</script>

<img data-hack-src="images/Puzzle.jpg"

     src="http://modpagespeed.com/pagespeed_static/1.JiBnMqyl6S.gif"

     style="width:100%;"

     onload="resizeImage(this);" />

There are at least two issues with this approach that would require improvements to mod_pagespeed to resolve:

1. the resized images will have the wrong content-hash, and so will be served with cache-control:private,max-age=300, disabling CDNs caching.

2. the browser will compute the size of the img tag, which whose HTML src is a blank 1x1 image.  If the natural size of the image can affect the 

    rendered size, this will not work.  Since I sized this image in CSS with width:100%, it works in this case.

Naturally you'll only need to have that JS fragment once in your page, and it will work for all images which have a data-hack-src specified.

But these limitations may not prevent you from trying this with MPS as installed on your server today.  We'd love to get feedback from you if this is a feature it makes sense to put into the product.  I think we can solve the two problems listed above in the C++.

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

To view this discussion on the web visit https://groups.google.com/d/msgid/mod-pagespeed-discuss/146cc0d7-5bd2-476f-83a6-fae8f68983f4%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "mod-pagespeed-discuss" group.

To unsubscribe from this group and stop receiving emails from it, send an email to mod-pagespeed-di...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/mod-pagespeed-discuss/8f222190-c7ff-456b-86b8-e940ce8c67fa%40googlegroups.com.

[mick...@kikuta2008.com]

Hi JMarantz and thank you for the elaborated reply!

I'll try to focus my feedback per your points. I will also update you on our implementation of your suggested prototype on a followup email later on.

>mod_pagespeed doesn't know the client screen width when it rewrites the HTML.  Beacons don't help with your use-case (sized proportional to screen)

Wow, when I saw this filter I was under the impression it gathers statistical data of required image size per [page X image X user-agent X rotated] (or alternatively [page X image X viewport-size]) and deliver the appropriate size, either through JS or even apache (using the UA data) altering the html. If you do it via apache, you can add both landscape and portrait urls to the image property (srcset?) and the JS can decide which to use based on the actual rotation.

>I created a prototype of such a hack myself just now because I was curious and I'd be interested in your opinion about it.

Your prototype is extremely interesting. We will try it out and report back.

Queston -- if we use the image onload event, wouldn't the JS be run after the image was already loaded to the browser? In such a case we miss the all point. Two solutions I can see for that:

1. manipulating the html based on the UA on apache, adding the optimized image urls as seen both on landscape and portrait and have a JS code that will pick the right one based on the rotation. In this case the beacon can send apache the image size data as seen on the specific page for the user agent and apache will use this data for similar future requests (same UA same page). At first having the multiplicity of page X image sounds a bit too much, but than I've figured out usually an image appears on one page (extremely sparse matrix).
   
2. The other option will follow the JS prototype you suggested. What you can do it load a constant blank transparent image as the image source and than use the resize function on that image onload. By that you gain two things:
1. The loaded image will be cached and actually requested only once.
2. The image can be *way* smaller than the original image. To make it even smaller you can even use a constant transparent image per user agent (again either on apache or JS level).
3. Do you have another idea how to overcome the original image onload problem?

We will give a try to the second option i described above and let you know how it worked out.

A question with regards to mps implementation -- if we request an image sized 111x222 on the url, would pagespeed create for us that image?

Again, thanks for the elaborate answer,

Mickey.

To unsubscribe from this group and stop receiving emails from it, send an email to mod-pagespeed-discuss+unsub...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/mod-pagespeed-discuss/146cc0d7-5bd2-476f-83a6-fae8f68983f4%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "mod-pagespeed-discuss" group.

To unsubscribe from this group and stop receiving emails from it, send an email to mod-pagespeed-discuss+unsub...@googlegroups.com.

[mick...@kikuta2008.com]

I see you already made the image transparent :-)

Superb! We'll give it a try and let you know how it worked.

[Joshua Marantz]

On Wed, Jun 15, 2016 at 6:43 AM, <mick...@kikuta2008.com> wrote:

Hi JMarantz and thank you for the elaborated reply!

I'll try to focus my feedback per your points. I will also update you on our implementation of your suggested prototype on a followup email later on.

>mod_pagespeed doesn't know the client screen width when it rewrites the HTML.  Beacons don't help with your use-case (sized proportional to screen)

Wow, when I saw this filter I was under the impression it gathers statistical data of required image size per [page X image X user-agent X rotated] (or alternatively [page X image X viewport-size]) and deliver the appropriate size, either through JS or even apache (using the UA data) altering the html. If you do it via apache, you can add both landscape and portrait urls to the image property (srcset?) and the JS can decide which to use based on the actual rotation.

It does gather statistical data but it's not UA-specific; it's just bucketed into mobile/tablet/desktop, and there are a large number of variations in window-sizes in those buckets.  It would be too fragmented to use the UA as a key.  I think what's happening in your initial trial with resize_rendered_dimensions is that the tool does not find enough consistency in the beaconed sizes within a bucket to enable the optimization.

Question -- if we use the image onload event, wouldn't the JS be run after the image was already loaded to the browser?

As you noticed, we use a common dummy image for the src= attribute during the initial load.  That's borrowed from our lazyload_images filter.  But we really should generate one in the correct size for this hack to be robust.

 

A question with regards to mps implementation -- if we request an image sized 111x222 on the url, would pagespeed create for us that image?

Yes, that's how the hack works :)

-Josh

[mick...@kikuta2008.com]

The more we get to the implementation your prototype, the more I see the beauty and simplicity over the first option I suggested... :-)

One thing that wont work is using a one pixel image having 100%, as you hinted, not all our images are styled to be 100% width... Instead we thought having the original image size on the img tag and than request a transparent image that would keep the ratio of the original image, but would fit without resizing into the device (that would be the minimum size that keeps the same ratio and let the CSS shape it as it needs). This way we let the CSS manipulate the transparent image as it needs and we know that when we switch to the original image we don't get a stretched image. Since image ratios tends to repeat themselves it's not really that bad (we'd likely have 3-4 ratios).

If you have a simpler solution I'd be happy to hear it, otherwise we'll go with this one (unless of course you expect a problem we don't foresee yet...).

Again, many thanks for help!

Mickey.

[mick...@kikuta2008.com]

>One thing that wont work is using a one pixel image having 100%, as you hinted, not all our images are styled to be 100% width...

Just to clarify, I meant "One thing that wont work is using a one pixel image having 100%. As you hinted, not all our images are styled to be 100% width..." :-)

[mick...@kikuta2008.com]

We ended up using the js code seen below. We tried to avoid the the pixel image, having the original source on the src attribute, but didn't find a reasonable way, as the images already started to be requested when we selected the images and replaced them with the canvas data.

There is still a problem with the requested images -- on the first request they are still returned too large. Only after hitting twice on Ctrl-F5 you get the smaller image. We thought this happens only to the first user seeing the image, but it happens to any user seeing the image the first time... Please advise. Just as a reference we kept both resize_images and resize_rendered_image_dimensions, as the auto-width resizing was done manual on our side and we preferred keeping the original filter as well. I doubt that's causing the problem as it still happened when we tested it without the resize_rendered_image_dimensions.

Another point that may come up is a security issue, that may be problematic -- contact me directly for details.

Otherwise it works as expected. From my perspective, this is a better implementation for resize_rendered_image_dimensions, as it works on all images, regardless of user agent, supporting more types of CSS (full width, and actually more we found out we had). You can see on live on http://www.myaquariumclub.com/may-2016-betta-potm-voting-thread-844400.html

Do you plan adding it to mps as a feature?

Thanks for the help so far :-)

Mickey.

BTW, there is another issue we are experiencing, I'll post about it on a different thread.

function resizeImage(image){

 var orgSrc = image.getAttribute("originalsrc");

 // processing is complete
 if (!orgSrc)
 return;
 
 // not supported.
 if (!isResizeImageSupported(orgSrc)){
 image.src = orgSrc;
 image.removeAttribute("originalsrc");

 // start processing
 } else if (image.getAttribute("imagew")) {
 image.src = getDummyImage(image);

 // finish processing
 } else {
 image.src = getResizedImageUrl(image);
 }
}

function getDummyImage(image){
 var canvas = document.createElement("canvas");
 canvas.width = image.getAttribute("imagew");
 canvas.height = image.getAttribute("imageh");
 image.removeAttribute("imagew");
 image.removeAttribute("imageh");
 return canvas.toDataURL("image/png");
}


function getResizedImageUrl(image){
 var file = image.getAttribute("originalsrc").replace( /.*\//, "" ).replace( /^\d+x\d+x/, "x" );
 var path = image.getAttribute("originalsrc").replace( /(.*\/)?.*/, "$1" );
 image.removeAttribute("originalsrc");
 return path + Math.floor(image.clientWidth) + "x" + Math.floor(image.clientHeight) + file;
}


function isResizeImageSupported(orgSrc){
 var canvas = document.createElement("canvas");
 return typeof document.body.clientWidth != "undefined" && typeof canvas !="undefined" && typeof canvas.toDataURL !="undefined" && orgSrc.match(/pagespeed/);
}

[mick...@kikuta2008.com]

> There is still a problem with the requested images -- on the first request they are still returned too large. Only after hitting twice on Ctrl-F5 you get the smaller image.

We have further tested it, and it seems that if you visit a page that includes an image that was already optimized after "a while" (a day, might be less), mps does not replace the image url with the optimized image url (the x<image url>, without the sizes). With debug message we are getting "deadline_exceeded for filter CacheExtender" and "deadline_exceeded for filter ImageRewrite" that is even though a day before the image was already optimized. We made sure pms cache is not deleted, so this is not the reason.

Any idea why this is happening? BTW, where can we find the images inside the cache itself on the disk? We can check if the images are there or not.

Thanks for the help!

Mickey.

[mick...@kikuta2008.com]

OK, after a while running with the JS-measuring-size-and-replacing-url-with-proper-size methodology is that the images flicker even if requested from the cache, which on retrospective was expected but is quite disappointing.

I think a better solution is to save sizes per [ page X img X ua ] and serve the right size image on first shot.

Are you guys planning to improve the resize rendered image dimensions filter?

On Monday, June 13, 2016 at 3:18:49 PM UTC+3, mick...@kikuta2008.com wrote:

[mick...@kikuta2008.com]

> Are you guys planning to improve the resize rendered image dimensions filter?

Did you guys happen to give it a thought? We were wondering if we should wait for you guys or should look for alternative/write in house with this regard. I'd really appreciate your reply, as our first choice would be using mps for this.

BTW, not sure what exactly you do internally, but from Josh's above reply I wonder if just tuning the statistical engine deciding the image size to serve will be enough.

Thanks!

Mickey.

[Eric Longuemare]

Hello,

That's a very interesting discussion.

Is there some plan or should it be considered as one enhancement to pictures delivered from IPRO ?

I'm thinking to native apps that should send needed features (dimensions, encoding) on request from url or maybe headers, cookie, and, feet the device and user needs (picture quality , bandwith and storage use), and the webmasters, app pictures content service providers (bandwith, and user xp by delivering what's needed).

Thanks,

Eric

[Eric Longuemare]

I have linked this discussion here : https://github.com/facebook/fresco/issues/1310

[Joshua Marantz]

We are interested in doing something with this.  Sorry I have not been responsive on the thread; I have been traveling and did not get a chance to dig into the data you have provided yet.

Josh

On Wednesday, June 22, 2016, Eric Longuemare <opal...@gmail.com> wrote:

I have linked this discussion here : https://github.com/facebook/fresco/issues/1310

--
You received this message because you are subscribed to the Google Groups "mod-pagespeed-discuss" group.

To unsubscribe from this group and stop receiving emails from it, send an email to mod-pagespeed-di...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/mod-pagespeed-discuss/d72db66a-2928-4c70-8880-682ad41dd52d%40googlegroups.com.

[Joshua Marantz]

Mickey -- is the reason you changed my prototype JS is that you wanted this hack to work for images where the natural-size affects the rendered size?  You are right, that is a bug in the prototype but I don't like the idea of using src=originalImage because of the flickering and having the wrong (large in bytes) image start downloading.  The right solution is that the PageSpeed C++ module needs to generate on-demand a small (in bytes) transparent image matching the natural size of the original image.  I believe this new idea hinges on us being able to do that, and we are still exploring whether this is possible on all browsers.

I haven't wrapped my arms around other problem you are noticing with the expiring images and each new user not getting a great experience before the refresh.  That would obviously be a show-stopper but I don't see why it shouldn't work once we support this mode properly in C++ and deliver appropriate caching headers.

There is still the potential problem that your origin images might expire too quickly if you are doing this in a test environment and get very low QPS.  That's a common problem when people test out mod_pagespeed with debug servers; it should actually be better with real traffic keeping the caches fresh.  In the meantime you could set your origin TTL to be longer (say, a day) while you are developing.

Eric -- I love the idea of exploiting the infrastructure we would build for this feature to enable resizing of images requested in apps.  But I don't know how to resize ipro-delivered images because one URL may be used in multiple contexts at different sizes, and even browser-caching becomes a problem.

-Josh

[Eric Longuemare]

Hello,

Thanks for the interest and attention,

>But I don't know how to resize ipro-delivered images because one URL may be used in multiple contexts

I was thinking to maybe vary header (https://tools.ietf.org/html/rfc7231#section-7.1.4) and I will look for others docs.

For example, Fresco has a backend to oKhttp (https://github.com/square/okhttp/wiki/Recipes) that allow to build headers (http://frescolib.org/docs/using-other-network-layers.html -), that's the way I use now to request some  "heavy" pictures in one Android app. This let me request webp pictures on "IPRO ressources* even with pre-4.0 devices as Fresco can use them (http://frescolib.org/docs/intro-image-pipeline.html).

I have read some docs that speak of setting pictures dimensions in request header. Should it be done as vary act for encoding ?

I go further and come back.

Thanks,

Eric

[Eric Longuemare]

Here is one doc : https://developers.google.com/web/updates/2015/09/automating-resource-selection-with-client-hints

[Joshua Marantz]

Varying on desired image size makes sense to me, if your app controls HTTP headers and sends the dimensions in a request header.

The client-hints spec might work for this, though that's intended I think to capture the display width, and not the pixel for the image.  So you wouldn't get an exact-sized image like mod_pagespeed would do; you'd have to rescale again on the device.  That's probably good enough to reduce data.

-Josh

On Wed, Jun 22, 2016 at 7:02 PM, Eric Longuemare <opal...@gmail.com> wrote:

Here is one doc : https://developers.google.com/web/updates/2015/09/automating-resource-selection-with-client-hints

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

To view this discussion on the web visit https://groups.google.com/d/msgid/mod-pagespeed-discuss/b6a62722-0fbe-4771-a39f-e3c6e8da1b73%40googlegroups.com.

[mick...@kikuta2008.com]

> Mickey -- is the reason you changed my prototype JS is that you wanted this hack to work for images where the natural-size affects the rendered size?

Yes, the 100% width didn't work for us. Apparently we have different css instructions on different pages and on many cases the images were not really 100% wide, having the combined instruction returning a wrong sized images. We needed an image on the right proportion to be resized by the css without anything overriding its instructions, only than we knew the real size required.

> I don't like the idea of using src=originalImage because of the flickering and having the wrong (large in bytes) image start downloading.

This is why we created a blank image with JS on the same size of the original image. This way the steps are

(1) having the one transparent pixel loading (actually inlined) -- we needed this to simulate an event of "on load start" that images do not have.

(2) creating a blank image through canvas js so we know the actual required size (we added the original image size props on the html). Very quick, no network latency at all.

(3) fetch the required size image and vualla.

But stage (3) was taking long enough to create a flickering. Thinking about it we could have left the blank space until the new image was downloaded and replace it only afterwards to avoid the flickering. The real but... I think the real solution lays in your side, for several reasons, see my next point.

> The right solution is that the PageSpeed C++ module needs to generate on-demand a small (in bytes) transparent image matching the natural size of the original image.  I believe this new idea hinges on us being able to do that, and we are still exploring whether this is possible on all browsers.

If I understand you correctly I think that you can create a transparent image with js and canvas, that would be faster (like the above explained stage 2). Of course it might be you mean something else entirely.

Still, I think the real solution would be to improve the statistical analysis on the the current resize_rendered_image_dimensions filter and that is for three reasons:

- If you have a bit more fined tuned buckets, say buckets by screen sizes jumping in 10% (e.g. 300-330, 331-363, 364-400, 401-440, ...), given a UA you can allocate a bucket that would be close enough to the real viewport size. You can than deliver largest image found on that bucket to all UA on the bucket and it will likely be small enough. If you want to make it smarter you can identify through the CSS the used media queries and build the buckets dynamically using this data.

- It will keep the product simpler, and possibly simpler to configure if you thought of it as a new filter.

- If we implement the hack, it will interfere with other onloads you have on the images and would not allow us to run other filters we want. I assume here that you test scenarios in which users combine mps image filters and it works.

> I haven't wrapped my arms around other problem you are noticing with the expiring images and each new user not getting a great experience before the refresh.  That would obviously be a show-stopper but I don't see why it shouldn't work once we support this mode properly in C++ and deliver appropriate caching headers. There is still the potential problem that your origin images might expire too quickly if you are doing this in a test environment and get very low QPS.

Well, this is happening in production and I think that the problem is the cache being too small... Silly me, it didn't occurred to me to look for the stats log until I saw you mention the TTL. I'll let you know if that was the problem.

Idea -- why not have an admin email on the configuration and email alerts of obvious problems (like the one we had on the cache) to that email?

Thanks for the feedback!

Mickey.

To unsubscribe from this group and stop receiving emails from it, send an email to mod-pagespeed-discuss+unsub...@googlegroups.com.

[mick...@kikuta2008.com]

And another thing -- I think it would be very valuable to add the cache stats to the debug filter. Certainly you want to add an "IMPORTANT: problem abc found", like in our case, having 95% of the cache requests missed... You might also add 2-3 solutions for the unwary folks ;-)

[Eric Longuemare]

Hello @jmarantz,

1 - app check the device screen resolution and dpi (display width)
2 - app request picture with display-width in header -  that will be max width in "paysage" mode or what the app dev need.
-> with max width, only 1 "vary" picture/device will be requested and cached by pagespeed (and Fresco  ) with best fit to most wide dimension for the device and all devices with same spec . Then Fresco should resize ... to fine fit the dev needs.
3 - pagespeed build the picture to request dimensions - height = (request width/real picture width) * real picture height - and cache the vary dim version. if request width >= real picture height or no width in request header, do not resized and delivered only on Accept-encoding spec

One of the concern should be that a lot of size for the pictures should be asked and then stored in pagespeed cache.
That have to be limited :

- authorisation key in header ?
- control on the logic of width give in header ?

On my side I have used some "artifacts" in headers to served only the request made by the app (else it's give a 403 error)

Thanks,

Eric



Should a logic as

>Varying on desired image size makes sense to me, if your app controls HTTP headers and sends the dimensions in a request header.

[Eric Longuemare]

>- authorisation key in header ?
>- control on the logic of width give in header ?

Or simply not able this option for pagespeed users that don't want

[mick...@kikuta2008.com]

Last note, this improvement (serving the minimal size images possible on resize_rendered_image_dimensions) would make the html way slimmer when use in conjunction with the inline_preview_images filter, since low quality, small sized images can be really small in terms on bytes.

Since mobile traffic is drastically increasing, this can be a serious improvement.

On Monday, June 13, 2016 at 3:18:49 PM UTC+3, mick...@kikuta2008.com wrote:

[Eric Longuemare]

Hello,

@jmarantz

Here is a scheme, picking from https://packetzoom.com/blog/which-android-http-library-to-use.html that show the workflow that I think should be used with other "pictures rendering" libraries.

The three have different caching strategies but resized pictures from server side should be helpfull for both. The three are able to use okHttp and modify headers so to send max-width

Should we open another topic ?

Thanks,

Eric

[Eric Longuemare]

Picasso should use oKhttp too : https://github.com/square/picasso/pull/1267

[jmarantz]

I have captured an issue

"resize_rendered_image_dimensions does not work well with CSS % rules" as https://github.com/pagespeed/mod_pagespeed/issues/1328

Ultimately about half the text in this thread should go into there.  Mickey -- you might want to CC yourself in that bug report so you can track further progress.

I have also captured the "resize images for apps" issue in https://github.com/pagespeed/mod_pagespeed/issues/1329 .  Eric -- you may want to subscribe to that.

Both of you may want to add the information from this thread in those bugs, though there is some cross-referencing from them to this thread.

[Eric Longuemare]

Hello Joshua,

>I have also captured the "resize images for apps" issue in 

https://github.com/pagespeed/mod_pagespeed/issues/1329 .  Eric -- you may want to subscribe to that

that's done

>Both of you may want to add the information from this thread in those bugs, though there is some cross-referencing from them to this thread.

That will be done.

Thanks for your attention.

Eric

[Mickey]

> Mickey -- you might want to CC yourself in that bug report so you can track further progress

Thanks :-)

--
You received this message because you are subscribed to a topic in the Google Groups "mod-pagespeed-discuss" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/mod-pagespeed-discuss/GbntPnwiGTU/unsubscribe.
To unsubscribe from this group and all its topics, send an email to mod-pagespeed-di...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/mod-pagespeed-discuss/3d3c41ef-6eed-408e-a1b2-81122ca5e6f3%40googlegroups.com.