Add information about render-blocking resources

[rockeynebhwani]

I think we should have a graph to show critical blocking resources (mainly CSS/JS). A graph like seen below along with links to specific tests as requested in another enhancement (https://github.com/speedtracker/speedtracker/issues/36), can be very useful in quickly spotting the delays introduced on sites.

[eduardoboucas]

Currently we're relying on WebPageTest as a source of data. Is this something we can extract from there? If not, what other tool would you recommend?

[rockeynebhwani]

Hi @eduardoboucas,

You may want to check this - http://stackoverflow.com/questions/34179483/how-to-find-resourcescss-js-etc-that-are-blocking-in-chrome

Paid offerings like speedcurve also use webpagetest in background and are able to figure this out so I am sure based on above thread on stackoverflow, there is a way to figure this out.

Rockey

[eduardoboucas]

Where would we display this information? In the same graph as the content breakdown (requests)? I'm not sure it's a good idea to add yet another chart, as we'll end up with too much information.

What do you think?

[rockeynebhwani]

I think it's ok if you want to add this to content breakdown (requests) graph. I would like to see two metrics (Critical blocking CSS and Critical Blocking JS).

[eduardoboucas]

In that case a separate graph with render-blocking CSS and JS would probably make sense.

I just wonder if the method of determining whether a resource is render-blocking that you linked to is really accurate. If you have a bunch of scripts with defer, the browser could technically start retrieving them before the first paint time and yet they're not render-blocking?

[rockeynebhwani]

Good point..

I think this is how speedcurve has done this ..https://speedcurve.com/blog/critical-blocking-resources/

I guess this is the key part from above link

---

Not all scripts and stylesheets necessarily have a big impact on performance, so it's important to be able to tell the blocking requests when trying to improve the user experience. In the waterfall above we see that there's an early script (request #6, "lazysizes.js") that is not marked as a critical resource. That's because this script is loaded asynchronously and thus doesn't block rendering of the page. Since we only want to highlight resources that block rendering, asynchronous scripts are not highlighted.

Similarly, in some cases it's possible to have stylesheets that don't block rendering of the main page. This typically happens with third party widgets that are loaded in an iframe, like the Twitter widget. Since stylesheets in iframes do not block the main page from rendering, they're not marked as critical resources.

---

[rockeynebhwani]

You should also check this - https://speedcurve.com/blog/measuring-blocking-resources/

I think this can get complicated. I wish if this information was available from WebPageTest as standard metric.

Not sure if you want to take speedtracker this far and start to build all this logic.

[eduardoboucas]

So I suppose we'd need to actually download the HTML page for the given URL and inspect the DOM look for scripts and stylesheets, taking into account their attributes and position in the document.

I agree that the information is very useful, I just wonder if building (and maintaining) this is viable.