Skip to content Skip to sidebar Skip to footer

Why Google Is Using The Term "render-blocking Javascript"?

See: https://developers.google.com/speed/docs/insights/BlockingJS Google is talking there about 'Render-Blocking JavaScript', but in my opinion that term is incorrect, confusing an

Solution 1:

I work with developers on Chrome, Firefox, Safari and Edge, and I can assure the people working on these aspects of the browser understand the difference between async/defer and neither. You might find others will react more politely to your questions if you ask them politely.

Here's an image from the HTML spec on script loading and execution:

Diagram of script loading

This shows that the blocking happens during fetch if a classic script has neither async or defer. It also shows that execution will always block parsing, or certainly the observable effects of parsing. This is because the DOM and JS run on the same thread.

I tested it in Firefox and Chrome and they are showing (rendering): "Some HTML line and this is above the fold" after 5 seconds and not within 5 seconds!!!!

Browsers may render the line above, but nothing below. Whether the above line renders depends on the timing of the event loop in regards to the screen refresh.

It looks like Google is thinking that in a case like that, the Javascript will not block rendering

I'm struggling to find a reference to this. You linked to my article in an email you sent me, which specifically talks about rendering being blocked during fetching.

In cases like that (and also with async), the result will be the same

That isn't guaranteed by the spec. You're relying on retrieval from the cache being instant, which may not be the case.

in a case like that you could even consider to put "no-cache" / "no-store" on delay.js (or even extra delay), to make your page render more fast. By forcing a download (or extra delay) you will give the browser some extra time to finish rendering of the preceding html, before executing the render blocking Javascript.

Why not use defer in this case? It achieves the same without the bandwidth penalty and unpredictability.

Solution 2:

Maarten B, I did test you code and you are correct indeed. Whether you use async, defer or whatever, the lines above the inline JavaScript are not beeing rendered. The information in the documentation of Google is therefore incorrect.

Post a Comment for "Why Google Is Using The Term "render-blocking Javascript"?"