How to find all render-blocking resources with JavaScript
- Published at
- Updated at
- 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
to find problematic resources, these tools rely on hardcoded rules to evaluate render-blocking elements. This approach isn't great!
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!
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.
107 | 107 | 107 | Non | Nein | Non | Nein | 21.0 | 107 |
But let's see, according to chromestatus.com, Firefox is positive about this addition, and Safari has yet to give a statement. ๐ค
I'll revisit this article in a few weeks to make further updates. Until then, happy resource discovery!
Join 5.5k readers and learn something new every week with Web Weekly.