How to find all render-blocking resources with JavaScript

Published at: Oct 01 2022
Updated at: Oct 29 2022
Reading time: 3min

Fast websites are good, right? Nobody likes to wait, and with Core Web Vitals being a ranking factor, optimizing performance is more critical than ever.

Rightfully, one of the main Core Web Vitals is Largest Contentful Paint which measures when elements are rendered and become visible on screen. But how hard could it be to render things quickly?

When it's coming to render time, it's critical to consider what resources you load and how you load them. Render-blocking resources are a primary reason for slow and delayed rendering. Stylesheets and synchronous scripts are the most common offenders.

Unfortunately, there hasn't been a straightforward way to discover render-blocking resources. And even though you could always rely on tools such as ct.css to find problematic resources, these tools rely on hardcoded rules to evaluate render-blocking elements. This approach isn't great!

As chromestatus.com puts it:

Currently, from a developer perspective, the only way to determine which resources were actually render blocking is to rely on complex heurestics.

But a new way to discover render-blocking resources just entered the stage!

The new render-blocking status

While reading the Chrome 107 Beta release notes, I discovered that the Resource Timing spec received an update!

The browser API is nothing new and allows you to inspect and monitor all loaded resources. It's the perfect JS API for feeding your real user monitoring with loading times and resource sizes.

window.performance.getEntriesByType("resource")[0]
// connectEnd: 725
// connectStart: 725
// decodedBodySize: 6981
// domainLookupEnd: 725
// domainLookupStart: 725
// duration: 366
// encodedBodySize: 2716
// entryType: "resource"
// fetchStart: 725
// initiatorType: "script"
// name: "https://.../some-script.js"
// nextHopProtocol: "h2"
// redirectEnd: 0
// redirectStart: 0
// requestStart: 911
// responseEnd: 1091
// responseStart: 1091
// secureConnectionStart: 725
// serverTiming: Array []
// startTime: 725
// transferSize: 253
// workerStart: 0

If you see a lot of 0 values in some resource timing entries, they might be cross-origin resources served without the Timing-Allow-Origin header. Unfortunately, many third-party hosters don't define it.

Abin K. Paul took on the effort to extend the resource timing entries to include information about each resource's render-blocking status. Thanks, Abin! 🎉

Starting with Chrome 107, resource timing entries include a renderBlockingStatus field which can have the values blocking or non-blocking. That's such great news! 🎉

What does it take then to find all render-blocking resources? A nifty JavaScript one-liner!

// get all resources
window.performance.getEntriesByType('resource')
  // only consider the blocking ones
  .filter(({renderBlockingStatus}) => 
      renderBlockingStatus === 'blocking')
  // log their names
  .forEach(({name}) => console.log(name))

// Logs: https://your-site.com/styles.css

When looking at the Resource Timing specification, it seems like there are more enhancements in the making:

What's the `renderBlockingStatus` browser support?

As already mentioned, renderBlockingStatus is very new and is only supported in Chrome Beta at the time of writing. Find up to date support information powered by MDN below.