Google Page Speed Rednder Blocking above the fold content

Hello,

We have been working with Google Page Speed increasing our overall speed and the last item we have to clean up is that Google wants us to eliminate the external render blocking Javascript and CSS above the fold content. Primarly, the .css files are causing delays in our page loading.

Here is Googles Advice:

https://developers.google.com/speed/docs/insights/OptimizeCSSDelivery

We are having a tough time with this issue, we know that we need to make a coding change somplace, but we can not figure out where to make that change. Can anyone help us out?

Thanks,

Jeff

The website we are working on is http://ledchristmaslighting.com by the way.

Sorry, but I don't understand. You're working on a site that will (I assume from the domain name) sell Christmas lights and currently features Halloween costumes and you're fixated on Google ? How do you know that Google will view your site the same way when you have the other products installed ? Please let me know if I've missed something.

Google ranks the site very well, it does sell xmas lights, but the company branched off. The website gets a lot of traffic and page speed is a large factor these days in Google. For example, the page loads well for desktops, but for mobile browsers there is some optimization that needs to be done. 25% of the traffic is from mobile devices and the bounce rate is much higher because the page tends to load slower. Take a look at page speed insights and see what Google is telling:

https://developers.google.com/speed/pagespeed/insights/#?url=http%3A%2F%2Fledchristmaslighting.com%2Findex.php%3Fmain_page%3Dproduct_info%26cPath%3D830%26products_id%3D14376

Apologies for the rant, but I have to say it:

If you seriously believe those 3 stylesheets (two tiny and the slightly larger main one) are really slowing down any browsers that drastically, then go ahead and delete the one for css buttons (unless you're actually using css buttons), and then copy all the image-hover content into the main stylesheet file. Prepare for complications in future upgrades though.

Google's not saying they are slowing it down. They're only saying that "the loading of multiple stylesheets can slow it down".

Have you actually done any profiling yourself about which stylesheets are actually causing any real blocking? What are the actual time delays you're seeing when you're doing your profiling?
Or are you just looking for a nice list of green checkboxes to tell you that everything's right because google's server says so?

Thanks Dr. Byte, I agree that it is not the size that is effecting the speed. It has to do with the way the page loads on a browser that is effecting the way google scores page speed and this issue is about 10% of the score for desktops and 20% for mobile browsers.

Here is what Google is stating: https://developers.google.com/speed/docs/insights/OptimizeCSSDelivery

Optimize CSS Delivery - This rule triggers when PageSpeed Insights detects that a page includes render blocking external stylesheets, which delay painting of content to the screen.

Overview - Browsers block on external CSS files before painting content to the screen. This incurs additional network latency and increases the time it takes to display content to the screen.

Recommendations - In the case of a large CSS file, you will need to identify and inline the CSS necessary for rendering the above-the-fold content and defer loading the remaining styles until after the above-the-fold content.

I get all that. I'm not contradicting the fact that blocking can exist. But you've given no numbers to validate google's claim that there's really a problem.
Instead you're just after a list of green checkmarks and you're placing all your faith in the mighty google.

But "10% of total score" doesn't mean anything. If there are 10 suggestions and this is one of those ten then that's 10%, but doesn't have any relevance to actual metrics and the actual delay that you think they mean.

So again I ask: what are the ACTUAL "blocking" times for YOUR site? Is this an issue of 5ms vs 15ms? Or is it 5000ms?

I gave you some things you could do. Did it make a difference?

trinorthlighting:

Thanks Dr. Byte, I agree that it is not the size that is effecting the speed. It has to do with the way the page loads on a browser that is effecting the way google scores page speed and this issue is about 10% of the score for desktops and 20% for mobile browsers.

What great timing. Have you ever heard of 'xkcd'? It's an online comic. Todays posting covers this percentage issue quite nicely.
http://xkcd.com/1252/

trinorthlighting:

Here is what Google is stating: https://developers.google.com/speed/docs/insights/OptimizeCSSDelivery

Optimize CSS Delivery - This rule triggers when PageSpeed Insights detects that a page includes render blocking external stylesheets, which delay painting of content to the screen.

Did Google also go on to mention that 'render blocking external stylesheets' didn't come into existence without good reason?

If Google happened to mention that aviation fuel is better that regular petrol would you rush out to put aviation fuel in your car?

trinorthlighting:

Overview - Browsers block on external CSS files before painting content to the screen. This incurs additional network latency and increases the time it takes to display content to the screen.

This is a claim is technically flawed. (OMG, once again Rod is contradicting the almighty Google).
Seriously, think about this. What if these external CSS files were hosted on a site with a faster server and better connectivity than the main site? Wouldn't that reduce any network latency and therefore reduce the time it takes for the page to display?

trinorthlighting:

Recommendations - In the case of a large CSS file, you will need to identify and inline the CSS necessary for rendering the above-the-fold content and defer loading the remaining styles until after the above-the-fold content.

I wonder what Google considers 'large'? .css files are generally so small I find it hard to imagine a situation whereby they could have any noticeable effect on performance.

Google isn't the keeper of the Internet. They are a business trying to make money. Lose sight of this fact at your own peril.

Cheers
Rod

I think we are going to try to GZIP our css sheets first to see if it makes it faster. Doing a few tests on webpagetest.org we are getting an average load time of 1.227s for the entire page which is very quick.

trinorthlighting:

I think we are going to try to GZIP our css sheets first to see if it makes it faster.

Careful with this. It could easily have the opposite effect in that it will actually slow things down.

The time it takes to compress and decompress could** easily **exceed the xfer time it would take to send the uncompressed data, and to make matters worse, you have no way of fully testing the effect for any given client.

For example, if I visit your page using my C64, it could take up to 10 minutes or more to decompress even the smallest of files. OK, this is a grossly exaggerated example, but the principles are the same.... if the receiving computer is lacking 'oomph' this will make thing worse for them, and you'll never know about it.

Cheers
Rod

ps. I don't know if you followed the link to xkcd, but the punchline was "A 50% increase in a tiny risk is still tiny". In your case, .css files are so insignificant (compared to the rest of the site), that even if you could improve their speed by 50%, the net result on the overall speed of the site will still be tiny.

Hi Rod,

Thanks for the advice, we have actually used the Apache Mod_Deflate and it is working out fine. We also have put all of our css and jscript on a content delivery network and that has speed things up tremendously. Now we are working on our images. Looks like the website is using image handler 4.

We have to change the urls in the folders to the following:

http://ledchristmaslighting.com/bmz_cache/etc.....

to

http://cdn.ledchristmaslighting.com/bmz_cache/etc....

We were thinking of using a 301 redirect, but I think we can change some of the coding elsewhere in zencart to prevent the 301.

Just by moving the css and jscript to a cdn our page load times were cut in 1/2.