Eliminate render-blocking CSS

Forum Moderators: Robert Charlton & goodroi

Message Too Old, No Replies

Eliminate render-blocking CSS

Tonearm

12:01 am on Sep 4, 2015 (gmt 0)

PageSpeed Insights says I should:

"Eliminate render-blocking JavaScript and CSS in above-the-fold content"

It only references my single CSS file. I know it isn't necessary to execute on all of Google recommendations, but I'd like to accomplish this last one. How can I do that? The only thing I can think of is to move the contents of my CSS file to <head></head> but then the user's browser won't be able to cache that CSS.

FranticFish

6:23 am on Sep 4, 2015 (gmt 0)

This is a mixed message and refers to both CSS and Javascript.

See [developers.google.com...] - this is the only guidance Google have on this message and it only refers to JS.

Have you tried moving calls to JS to the bottom of your HTML so that the file(s) is/are not fetched until the rest of the content is rendered? Simplest thing to try - beyond that there's asynchronous / deferred loading.

If you are only concerned with CSS then I personally would ignore this message. If your CSS file doesn't load in a way that blocks initial render then you might get 'Flash Of Unstyled Text' - and I personally consider that worse than a few extra milliseconds to load a page.

Wilburforce

6:50 am on Sep 4, 2015 (gmt 0)

Why do you want to do this? What that expression means is "don't defer rendering the page while we go and get these elements of it: render first, and get them later".

As you point out, a single CSS file can be cached by the browser, so it only affects the time it takes to render the first page for the first time.

All you will achieve in practice is to remove that message in PageSpeed Insights (and presumably increase your score by a few percentage points), and you will do so at the cost of displaying the page without CSS at the initial render. That is fine if your CSS isn't particularly important to the page appearance (mine IS important, or i wouldn't use it at all), so if your primary user is using a screen reader - if your target user is partially-sighted, for example - it might improve the user experience. Otherwise, it certainly won't (go and have a look at some pages that do it the "right" way, if you want unequivocal examples), and loading the CSS first is only going to add a couple of milliseconds to loading the first page unless your user is on another continent and using a dial-up modem.

Moving the CSS to inline will remove that message, but will make total page load times higher, especially if you factor in the cache effect. Also, let us face it, PageSpeed Insights is actually asking you to abandon what CSS is designed to do. It isn't a perfect tool.

Some JS is less of an issue, but you'll still get the same message if you fix the JS and leave the CSS.

_{Edit: FranticFish posted while I was writing this, but is saying much the same thing more succinctly.}

Johan007

12:59 pm on Sep 4, 2015 (gmt 0)

This is purely about JavaScript that is keeping the page from loading CSS and HTML as quickly as it could. It is very good practice. FranticFish tips are good but very hard to resolve with say Worldpress themes and some other CMS. Defer loading javascript is the ideal solution: [varvy.com...]

Best source of reading:
[varvy.com...]

Johan007

1:28 pm on Sep 4, 2015 (gmt 0)

Your page has 1 blocking CSS resources. This causes a delay in rendering your page.

[developers.google.com...]
Apologies! there looks like there is CSS deferring option as well. Seems completely wrong.

Tonearm

6:17 pm on Sep 4, 2015 (gmt 0)

What I'm after here is indeed those few percentage points from Google. Google sends me just about all of my traffic and I'll bend over backwards for them. It's business, I don't mind. I don't want a FOUC but I have a couple ideas:

1. serve robots CSS in the <head> and non-robots CSS in an external file
2. serve robots and non-robots CSS in the <head> on the first page access of the session and CSS in an external file on all subsequent accesses

The downside of #2 is users would have to download CSS twice in a session instead of once. The upside of both is I would be able to capture those percentage points from Google.

Wilburforce

11:50 pm on Sep 4, 2015 (gmt 0)

What I'm after here is indeed those few percentage points from Google.

I'm not sure how much difference it will make (I think Google is more attracted to popular sites than sycophantic ones), and

Google sends me just about all of my traffic

Makes you like a business with a single client. Diversify.

netmeg

3:02 pm on Sep 5, 2015 (gmt 0)

I can't give you a lot of technical info myself, but my dev has had some success shaving points off those pagespeed scores using Google Tag Manager and serving as much as possible from that. Here's a screen shot from the Tag Manager console for one of my sites - not all of these tags are live at the moment, but it'll give you an idea of what we moved into it.

[imgur.com...]

Tonearm

3:52 pm on Sep 5, 2015 (gmt 0)

netmeg, interesting info about tags. I haven't heard of them before in this context. How do they relate to page speed?

tangor

4:20 pm on Sep 5, 2015 (gmt 0)

Some tweaks are worth the effort. Some are not. In all cases your best standard is the USER experience, so anything that might intrude there in the interest of pleasing a non-human measurement should be considered with some care.

Milliseconds count on dial up connections, not so much on broadband.

netmeg

5:42 pm on Sep 5, 2015 (gmt 0)

Like I said, I'm not up on all the technical finer points. But everything loads asynchronously, and it loads from Google servers, and that appears to have made a difference. I installed it originally so I wouldn't have to bug my developers (or client's IT guys) every time I wanted to add conversion tracking or a different type of stats or analytics program, or remarketing, but then my dev starting looking into moving all the slower loading stuff on my own sites into it, and it definitely helped.

[google.com...]