This PR improves TBT metric by using a smart trick.
I was profiling this store the other day and I figured out that the browser was breaking the rendering task into multiple ones like you can see in the image below:
Taking a deeper look, I figured out that this happens every time the browser needs to perform a synchronous parsing of the html, a.k.a. when there's an inline <script> tag. Researching a little bit more into the subject, @igorbrasileiro figured out that using the type="module" key made the browser evaluate the script tag asynchronously. After rewriting all script tags as type="module", we get the following profile:
As you can see, we now have a single, big rendering task instead of small ones.
One can think that this is a bad approach. The catch in here, however, is that this task happens before FCP. Since TBT is the blocking time between FCP and TTI, this monolithic task does not count as a valid blocking time, thus reducing TBT.
This PR improves TBT metric by using a smart trick.
I was profiling this store the other day and I figured out that the browser was breaking the rendering task into multiple ones like you can see in the image below:
Taking a deeper look, I figured out that this happens every time the browser needs to perform a synchronous parsing of the html, a.k.a. when there's an inline
<script>
tag. Researching a little bit more into the subject, @igorbrasileiro figured out that using thetype="module"
key made the browser evaluate the script tag asynchronously. After rewriting all script tags as type="module", we get the following profile:As you can see, we now have a single, big rendering task instead of small ones.
One can think that this is a bad approach. The catch in here, however, is that this task happens before FCP. Since TBT is the blocking time between FCP and TTI, this monolithic task does not count as a valid blocking time, thus reducing TBT.