Image not identified as need resizing, even though it does

182 views
Skip to first unread message

mick...@kikuta2008.com

unread,
Oct 18, 2016, 5:33:34 AM10/18/16
to mod-pagespeed-discuss
Hi,

As I mentioned on another topic, we just upgraded our test servers to use mps 1.11.33.4.

We are using resize_rendered_image_dimensions in order to reduce image sizes and many times images are not identified as needed to be resized (see below screenshot).

Our images are styled using percentages and in fact the entire site is sized this way. There is the bug resize_rendered_image_dimensions does not work well with CSS % rules. How can we verify that this is the problem preventing from resizing the images and not something else?

Thanks for the help!
Mickey.

Image debug information:
<figure class=" img-handler-wide no-text-following"><img class="ugc-image landscape img-width-wide no-text-following" src="media/ugc/2016/10/xPanda-2-sm.933091606.jpg.pagespeed.ic.lP5zM2hKSP.webp"><!--Image does not appear to need resizing.--><!--The image was not inlined because you have chosen to only inline the critical images but this image is not critical.--></figure>

Screenshot of image which is not being resized:



Diff of the conf file:
$ diff /etc/httpd/conf.d/pagespeed.conf /vendors/etc/httpd/conf.d/pagespeed.conf
89,95c89
<       ModPagespeedEnableFilters collapse_whitespace,elide_attributes,trim_urls
<       ModPagespeedEnableFilters resize_rendered_image_dimensions
<       ModPagespeedEnableFilters remove_quotes,remove_comments
<       ModPagespeedEnableFilters insert_dns_prefetch
<       ModPagespeedEnableFilters dedup_inlined_images
<       ModPagespeedEnableFilters defer_javascript
<       #ModPagespeedEnableFilters debug
---
>     # ModPagespeedEnableFilters collapse_whitespace,elide_attributes
150,153c144,145
<     # Max int
<     ModPagespeedFileCacheSizeKb          2147483647
<     # Once in 20 years
<     ModPagespeedFileCacheCleanIntervalMs 630720000000
---
>     # ModPagespeedFileCacheSizeKb          102400
>     # ModPagespeedFileCacheCleanIntervalMs 3600000
168c160
<     ModPagespeedFileCacheInodeLimit        0
---
>     ModPagespeedFileCacheInodeLimit        500000





Maksim Orlovich

unread,
Oct 19, 2016, 9:11:11 AM10/19/16
to mod-pagesp...@googlegroups.com
It should in theory be able to figure it out with % based on beacon responses --- if the sizes are consistent. If they aren't, there is nothing we can do, partly because we aren't smart enough to actually understand % (rather than just observe actual size),
and partly because we don't know the screen/window size.

P.S. Thanks for the responsive images bug report.


--
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.
To view this discussion on the web visit https://groups.google.com/d/msgid/mod-pagespeed-discuss/d0c0768c-7158-4fc6-99e2-dbb288d3e9ef%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

mick...@kikuta2008.com

unread,
Oct 23, 2016, 2:23:33 AM10/23/16
to mod-pagespeed-discuss
A while back Josh suggested a workaround which we implemented and decided to drop as we thought this issue might be solved by the mps team. We strongly preferred the solution to be a part of the official mps, as it would integrate better with other image filters (lazy loading etc.).

Is that on the roadmap? If not, we'll just go ahead and revive the old workaround (unless you have more ideas, which we'd love to hear).

Thanks for the help!
Mickey.

Jeff Kaufman

unread,
Oct 24, 2016, 9:52:35 AM10/24/16
to mod-pagespeed-discuss
The js approach is not currently on our roadmap, sorry!

--
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

unread,
Oct 24, 2016, 2:47:13 PM10/24/16
to mod-pagespeed-discuss
Is there any other planned solution for this problem?

Thanks for the help :-)
Mickey.

Jeff Kaufman

unread,
Oct 25, 2016, 10:25:22 AM10/25/16
to mod-pagespeed-discuss
There isn't another planned solution, sorry!  For now the best we can recommend is that you use a site-layout strategy that lets you put width= and height= on your images, and then pagespeed can handle resizing them.

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

--
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

unread,
Oct 27, 2016, 1:20:11 AM10/27/16
to mod-pagespeed-discuss
I think we'll go for the prototype you suggested a while back. I'll let you know how good does it work or of faults we may find. Maybe after seeing how good your prototype is, you'll get into the product ;-)
To unsubscribe from this group and stop receiving emails from it, send an email to mod-pagespeed-discuss+unsub...@googlegroups.com.

mick...@kikuta2008.com

unread,
Nov 9, 2016, 7:00:23 AM11/9/16
to mod-pagespeed-discuss
We found an inherent problem with the onload solution -- the pages "blink" as html following the image is rendered before the onload is completed, causing it to "jump" on the screen when the pixel is replaced with the actual image.

What we tried:
  1. We tried to stretching the pixel to the desired size on the onload by supplying the original image size on the html, and save the place for the image, but even just stretching the pixel without loading the image at all caused the above mentioned "jumps" (the onload just happened after the following images were renedered).
  2. We tried to grab only the AFT images by id and to process them before the onload (and avoid visible jumps), but as expected it caused delays on the html rendering...
I think that the resized images' urls would need to be delivered on the html response for this to work out. Or maybe you can inline an extreme light weight version of the image and than replace it with the resized version.

Can't you create buckets per image size (say 321-340, 341-360, ...) and than deliver the appropriate image size from the bucket? Or maybe you'd need to do that per UA as on a first request you can't know the device size other than guessing by the UA.

What do you say? Any suggestions?

Joshua Marantz

unread,
Nov 9, 2016, 9:14:27 AM11/9/16
to mod-pagespeed-discuss
Yes, the there are potential reflow issues unless the img tag specifies a src= attribute pointing to a correctly-sized image, and the rendered size is partially affected by the image's natural size.  One thing you can try is to inject a properly sized blank SVG image, which should avoid the reflow.   E.g.
You would use this 'img' tag as the placeholder, using the natural size of the image, and onload replace the src attribute with the actual resized image with the rendered dimensions. 

That bit of SVG magic may help in cases where the rendered size is dependent on the image natural size.  Please let us know!

-Josh


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

--
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+unsubscri...@googlegroups.com.

--
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+unsubscri...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/mod-pagespeed-discuss/d01fa4ae-56f3-40d5-a5bc-08396388477f%40googlegroups.com.

mick...@kikuta2008.com

unread,
Nov 13, 2016, 9:45:13 AM11/13/16
to mod-pagespeed-discuss
Do you know which browsers would support this format?
Also, I assume the svg tag properties "width" and "height" are the actual image size. What are the "x" and "y" attribs on the rect tag?

Thanks for the continued help :-)
Mickey.
-Josh


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

--
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.

--
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

unread,
Nov 13, 2016, 9:12:33 PM11/13/16
to mod-pagespeed-discuss
browser coverage for SVG looks pretty good: http://caniuse.com/#feat=svg

Actually I'm not sure what the x & y tags are -- a teammate passed me this snippet.  I would think they might be an offset into the rendering, but that would be a no-op for a transparent image.  Maybe best to set them x=0 and y=0.

-Josh

-Josh



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

--
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+unsubscri...@googlegroups.com.

--
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+unsubscri...@googlegroups.com.

--
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.

Huibao Lin

unread,
Nov 14, 2016, 7:48:54 AM11/14/16
to mod-pagespeed-discuss
The 'width' and 'height' in <svg> tag specify the image dimensions. The <rect> tag after <svg> specify a rectangle. The 'x' and 'y' specify the offsets of the rectangle with respect to the image, and 'fill' specifies the color. Here since we're using a transparent rectangle (i..e, fill='none') the offsets have no visual effect. Setting them to '0' seems more reasonable.
-Josh



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

--
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.

--
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.

Mickey

unread,
Nov 15, 2016, 1:53:22 AM11/15/16
to mod-pagesp...@googlegroups.com

Superb :-)

We'll keep you updated.

-- 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/N8g_Vh2mdkg/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/e20f10ce-bb07-48db-b1db-7d43b77bdc3f%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.

mick...@kikuta2008.com

unread,
Nov 15, 2016, 4:21:56 AM11/15/16
to mod-pagespeed-discuss
The svg suggestion improves things drastically. It both solved the flickering and simplified the JS.

We are now experiencing two problems with the implementation.
  1. The image onload event is fired extremely delayed. I think it is captured by MPS and is delayed (until the onload?). Take a look at it on http://www.americancivilwarforum.com/not-sure-if-my-uniform-is-an-authentic-civil-war-calvary-uniform.-31092.html Important -- This is a live (small) site we have, so we can keep the prototype there only for a short while!
  2. There is a problem with IE supporting the the svg on data urls, but I already saw this can be resolved (checked their prototype on IE and it worked) -- https://css-tricks.com/probably-dont-base64-svg/#article-header-id-1
Please reply as soon as you can as we need to take the prototype off the live site.

If this works, I think it's a great and simple mechanism and can replace the beacons reporting on image sizes.

Thanks for the help :-)
Mickey.

On Tuesday, November 15, 2016 at 8:53:22 AM UTC+2, Mickey wrote:

Superb :-)

We'll keep you updated.


On 14/11/2016 14:48, 'Huibao Lin' via mod-pagespeed-discuss wrote:
The 'width' and 'height' in <svg> tag specify the image dimensions. The <rect> tag after <svg> specify a rectangle. The 'x' and 'y' specify the offsets of the rectangle with respect to the image, and 'fill' specifies the color. Here since we're using a transparent rectangle (i..e, fill='none') the offsets have no visual effect. Setting them to '0' seems more reasonable.

On Sunday, November 13, 2016 at 9:12:33 PM UTC-5, jmarantz wrote:
browser coverage for SVG looks pretty good: http://caniuse.com/#feat=svg

Actually I'm not sure what the x & y tags are -- a teammate passed me this snippet.  I would think they might be an offset into the rendering, but that would be a no-op for a transparent image.  Maybe best to set them x=0 and y=0.

-Josh
-- 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/N8g_Vh2mdkg/unsubscribe. To unsubscribe from this group and all its topics, 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/e20f10ce-bb07-48db-b1db-7d43b77bdc3f%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.

Joshua Marantz

unread,
Nov 15, 2016, 8:48:31 AM11/15/16
to mod-pagespeed-discuss
On Tue, Nov 15, 2016 at 4:21 AM, <mick...@kikuta2008.com> wrote:
The svg suggestion improves things drastically. It both solved the flickering and simplified the JS.

We are now experiencing two problems with the implementation.
  1. The image onload event is fired extremely delayed. I think it is captured by MPS and is delayed (until the onload?). Take a look at it on http://www.americancivilwarforum.com/not-sure-if-my-uniform-is-an-authentic-civil-war-calvary-uniform.-31092.html Important -- This is a live (small) site we have, so we can keep the prototype there only for a short while!
I looked at the site in Chrome Dev Tools and it does seem like the correctly sized images don't come in until after ads are rendered. I can't think why MPS would be delaying the onload event; it looks to me based on the waterfall like Chrome can't complete the rendering of the page until after the ads:




I'll ignore the IE problem since you seem to have solved it :)

-Josh

mick...@kikuta2008.com

unread,
Nov 15, 2016, 3:17:52 PM11/15/16
to mod-pagespeed-discuss
Can it be related to the defer js filter? I played a bit with pagespeed insights and this is what I have got:

I'm leaving the prototype so you can see the page source.

Joshua Marantz

unread,
Nov 15, 2016, 3:22:25 PM11/15/16
to mod-pagespeed-discuss
I'm not sure.  Does it work better without defer_javascript?  Lot's of pages that depend on JavaScript for rendering do.

Full disclosure: we haven't been working on defer_javascript in a long time, and the original authors of it are no longer working on PageSpeed.  It's a pretty amazing piece of technology, but if you are making (say) a progressive web app, it's going to delay rendering, and if you are using AMP it's not needed :)

-Josh

mick...@kikuta2008.com

unread,
Nov 15, 2016, 3:33:21 PM11/15/16
to mod-pagespeed-discuss
BTW those are adsense ads using the code taken from the adsense site, with the exception of the function "" we added.

Do you think it may be causing this? Note the ads appear after the images on the html.

<script async src="//pagead2.googlesyndication.com/pagead/js/adsbygoogle.js" data-pagespeed-no-defer></script>
<ins class="adsbygoogle" style="display:block" data-ad-client="ca-pub-0574877161340944" data-ad-slot="1469505919" data-ad-format="rectangle"></ins>
<script data-pagespeed-no-defer>function protectAdsenseMobileATF(ad,isTest){if(isMobile()&&window.innerHeight-ad.getBoundingClientRect().top>100){if(isTest)ad.className="test_ad vertical";else
ad
.setAttribute("data-ad-format","auto");}}protectAdsenseMobileATF(document.querySelector("ins[data-ad-slot='1469505919']"),0);</script>
<script data-pagespeed-no-defer>(adsbygoogle=window.adsbygoogle||[]).push({});</script>

mick...@kikuta2008.com

unread,
Nov 15, 2016, 3:46:44 PM11/15/16
to mod-pagespeed-discuss
We temporarily disabled the defer js filter and it looks fine.

We'll p[lay with it some more and let you know how it works.

mick...@kikuta2008.com

unread,
Dec 1, 2016, 11:31:23 AM12/1/16
to mod-pagespeed-discuss
After working with it some more, it still creates a flicker affect for users who have the image on their cache, for the fraction the svg is replaced with the actual image.
We have left it on one of the tests servers. If anyone here wants to play with it a bit, please email me and I'll send you the connection details.

I think to avoid it we'll need to issue the properly sized image directly from the server, but you have surprised me with the svg dataurl, so you may have some more surprises in your hat...

I'd be happy to hear what do you think.
Reply all
Reply to author
Forward
0 new messages