Artboard 16light, inspiration, solution, idea, innovation,ionicons-v5_logosGoogle Sheets iconSwift icon
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.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.

MDN Compat Data (source)
Browser support info for renderBlockingStatus
chromechrome_androidedgefirefoxfirefox_androidsafarisafari_iossamsunginternet_androidwebview_android
107107107NopeNΓΆNeinNeinNon107

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!

Was this post helpful?
Yes? Cool! You might want to check out Web Weekly for more web development articles. The last edition went out 7 days ago.

Related Topics

Related Articles