srcset and render-blocking CSS

[mar...@raffiniert.biz]

Hi there!

We noticed that PageSpeed penalizes the use of srcset on images instead of simple src-attributes. We're using it to deliver retina images in combination with Picturefill.

Here's a test case I build to illustrate the problem. The following sites are exactly the same, but one uses srcset, the other src:

Default with src:

https://developers.google.com/speed/pagespeed/insights/?url=http%3A%2F%2Fpagespeed-srcset.slople.com%2F

With srcset:

https://developers.google.com/speed/pagespeed/insights/?url=http%3A%2F%2Fpagespeed-nosrcset.slople.com%2F

What's happening here? Why is PageSpeed penalizing the use of srcset in regard of the render-blocking css? The css only contains one line setting a font-size on the body.

[Rick Steinwand]

I use the <picture> element with sizes from 400px to 1400px and no problem with that.

[Rick Steinwand]

Font size changes the appearance of the page and has to render major portions of it. Add it inline and you should be good.

[mar...@raffiniert.biz]

do you use srcset? can you give me an example code of how you use it?

[mar...@raffiniert.biz]

this can't be the problem because the same css is loaded on both pages, so the error must be from the srcset-attribute.

[Rick Steinwand]

<picture>
        <source type=image/webp media="(min-width:1441px)" srcset="/images/slider2/Welcome_1700.webp 1700w">
        <source type=image/webp media="(min-width:1281px)" srcset="/images/slider2/Welcome_1440.webp 1440w">
        <source type=image/webp media="(min-width:1025px)" srcset="/images/slider2/Welcome_1280.webp 1280w">
        <source type=image/webp media="(min-width:801px)" srcset="/images/slider2/Welcome_1024.webp 1024w">
        <source type=image/webp media="(min-width:401px)" srcset="/images/slider2/Welcome_800.webp 800w">
        <source type=image/webp srcset="/images/slider2/Welcome_400.webp 400w">
        <source media="(min-width:1441px)" srcset="/images/slider2/Welcome_1700.jpg 1700w">
        <source media="(min-width:1281px)" srcset="/images/slider2/Welcome_1440.jpg 1440w">
        <source media="(min-width:1025px)" srcset="/images/slider2/Welcome_1280.jpg 1280w">
        <source media="(min-width:801px)" srcset="/images/slider2/Welcome_1024.jpg 1024w">
        <source media="(min-width:401px)" srcset="/images/slider2/Welcome_800.jpg 800w">
        <source srcset="/images/slider2/Welcome_400.jpg 400w">
        <img src="/images/slider2/Welcome_1700.jpg" alt="Welcome to Fargo Video" width=1700 height=398>
</picture>

That's code I use for one banner image. In old IE or a browser that doesn't support the picture element, it defaults to that image and size. You can default to a mobile size, but I prefer this.

The ###w at the end of each line is the image width. If you use webP, those need to be first. Each image has it's width in the name.

[mar...@raffiniert.biz]

Okay I see, in your appraoch this seems to workout out. Mine is a bit more complicated because there0s also lazyloading.

But anyway, the original question still is open. 

Here again the links from the original post:

Default with srcset:

https://developers.google.com/speed/pagespeed/insights/?url=http%3A%2F%2Fpagespeed-srcset.slople.com%2F

Without srcset:

https://developers.google.com/speed/pagespeed/insights/?url=http%3A%2F%2Fpagespeed-nosrcset.slople.com%2F

Now I created an additional one without picturefill:

https://developers.google.com/speed/pagespeed/insights/?url=http%3A%2F%2Fpagespeed-srcset-nopicturefill.slople.com%2F

So it seems like there's no penalty when there's no picturefill. Does anyone have a similar situation?

[mar...@raffiniert.biz]

Some updates form my site:

I created an additional demo with some images and a javascript that updates the src of the images:

http://pagespeed-srcset-scripttest.slople.com/

PageSpeed: https://developers.google.com/speed/pagespeed/insights/?url=http%3A%2F%2Fpagespeed-srcset-scripttest.slople.com%2F&tab=mobile

If you test it with pagespeed, you see the render-blocking penalty for the css-file, but the css doesn't contain anything useful, just an unused css rule. What's happening here? Looks like pagespeed has problems if image sources are changed, that's also the reason why it failed with picturefill I guess.

[Rick Steinwand]

Whether your css file contains anything or not, the browser still has to stop loading everything to check it out.

What I do:

• inline critical css
  
• post-load the rest of the css and js.
  
• post-load banner images
  

[mar...@raffiniert.biz]

You're right of course, we do that too, but the strange thing is the penalty only appears when the image sources are changed by Javascript e.g. through picturefill or as in my example.

Take a look at the following example:

http://pagespeed-srcset-nopicturefill-jquery.slople.com/

(last example: http://pagespeed-srcset-scripttest.slople.com)

Here we have the same situation as in the last example, we're loading a script async after the css but we don't have a penalty for render-blocking css.

Where's the difference? Why is there a penalty if the script is doing something with the image sources?

[Rick Steinwand]

I post-load my banner after page load and have no penalty. https://developers.google.com/speed/pagespeed/insights/?url=www.intercepteft.com&tab=desktop

If I post-loaded my You Tube video, I could gain another point.

[mar...@raffiniert.biz]

How do you post load your images? Seems like pretty much everything works, as long as you're not manipulating source-attributes (through picturefill or other scripts) what tells google that it somehow needs to load the stylesheet.

[Rick Steinwand]

First of all I'm just using JS, not picturefill. 

My page has the links for the slider and the default slider image. When page complete, LoadPrefs() runs and loadImages() is the script that builds a <picture> element inside those 7 links (8 images total), consisting of 96 images total (1700px, 1440px, 1280px, 1024px, 800px & 400px) in both jpg and webP formats. None are retina images, just images for different size screens.

Images were created using progressive encoding (Paint.net) at about 80% compressed and optimized via TinyPng.com and then a webP copy was created from that. This was all done about a year ago and did not have to be updated with latest PSA image recommendations.

[Adriano Rosa]

Today I notice that Google has recently changed its algorithm for PageSpeed Insights.

Last month I had a site setup with srcset with images @2x for retina screens then use src for @1x images...with this setup PageSpeed used to load images from src instead srcset then I scored 98/100. Today I scored 63/100 because PageSpeed says I have to Prioritize visible content and all compress images loaded from srcset, NOT: I've haven't changed the site at all for the last few days.

So weird, for now I'm pissed off with PageSpeed it doesn't seem that is giving you a real world performance perspective, if I check my site speed with www.webpagetest.org or YSlow I score grade A for all checked itens.

The real problem I've found with PageSpeed for a real world and large Responsive Website is that if you follow all the rules just to get 100 points you expose your site to serious problem of usability and FOUC, FOIT.

[Jose Miguel Alemán]

I show the same score, the problem is on CSS & JS, you have use CSS inline or asynchronous JS/CSS