Render-blocking resources: the questions we get asked most

The version of this that works is simpler than the version most people imagine. The questions about render-blocking resources that come up most often on our calls.

Speed is a feature people notice only in its absence, and then they leave rather than complain. The teams that stay on top of it are the ones who put it on a calendar rather than a wish list.

Do we need to care about this?

Scripts and styles in the head delay the first paint. That sounds obvious written down. It is still the thing most often skipped. Assume whoever inherits this will have half your context and none of your patience.

Can it wait until after launch?

Occasionally. More often the post-launch version costs several times the pre-launch one. That sounds obvious written down. It is still the thing most often skipped.

How do we know it is working?

Third-party tags are frequent offenders. The teams that handle this well are rarely the ones with the biggest budgets. It is the sort of thing that looks like polish right up until it costs you an enquiry.

The short version

Real-world numbers from actual visitors matter more than a score produced on a fast laptop. Three things worth confirming about render-blocking resources before you move on:

• Someone can say what the current setup is without going to look
• Third-party tags are frequent offenders — and you know whether that is true here
• There is a way to tell whether the last change to this helped

If you are not sure where your systems currently stand on this, it takes us about an hour to find out.