chore: more accuracy

maiieul · maiieul · commit ba8250bc2fc0 · 2025-05-20T09:17:54.000+02:00
diff --git a/packages/docs/src/routes/(blog)/blog/(articles)/qwik-1-14-preloader/index.mdx b/packages/docs/src/routes/(blog)/blog/(articles)/qwik-1-14-preloader/index.mdx
@@ -45,7 +45,7 @@ In comparison, the other frameworks need to execute at least all of the visible
 
 In effect, this means that TTI on Qwik apps can often be as fast as ~5s on a slow 3G network connection, even for very complex applications. With hydration on the other hand, TTI often reaches ~20s on slow 3G on simple websites and 60s or more on more complex applications as it increases proportionally to the amount of components that need to hydrate.
 
-### A long standing “Buffering” issue
+### A long standing “buffering” issue
 
 In Qwik 1.11.0 and 1.13.0, we fixed some long lasting bugs that were leading to “under-prefetching” and “over-prefetching under certain conditions. With those fixes, we made sure that all and only the bundles required for the user interactions available on a page are prefetched, therefore preventing any sort of network delays.
 
@@ -60,7 +60,7 @@ Thankfully, using a service worker isn’t the only way we can prefetch and cach
 
 In Qwik 1.14, we've transitioned away from using a service worker in favor of a solution leveraging [`<link rel="modulepreload">`](<https://devdocs.io/html/attributes/rel/modulepreload>) as the new default. 
 
- The solution consists of a small script called the “Qwik Preloader”. Once it is downloaded on the client, it adds the `<link rel="modulepreload" href=”my-bundle.js#segment123456”>` to the html `<head>`, which tells the browser to preload and buffer the corresponding JavaScript bundles.
+The solution consists of a small script called the “Qwik Preloader”. Once it is downloaded on the client, it adds the `<link rel="modulepreload" href=”my-bundle.js#segment123456”>` to the html `<head>`, which tells the browser to preload and buffer the corresponding JavaScript bundles.
 
 By doing so, we not only get rid of any startup penalty, but also make any interaction on Qwik components absolutely instant once the bundles for it have been preloaded, even on devices with poor CPUs 🚀
 
@@ -80,11 +80,11 @@ On our tests on a pretty used up Xiaomi note 7 pro, the delays only reached ~100
   </figure>
 </div>
 
-If you look closely at the two screen recordings above, you will notice that the text is first marked with an underline when focused, and then the Accordion opens the selected item. But the difference is that with the service worker, the first interaction on the Accordion component is a little delayed. With modulepreload, all interactions are instant. (You might want to set the video to 0.5x speed to better see the difference.)
+It is hard to feel on a screen recording, but if you look closely at the two recordings above, you will notice that with the service worker, the first interaction on the Accordion component is a little slower. With modulepreload, all interactions are instant. (You might want to set the video to 0.5x speed to better see the difference.)
 
-The reason why there is such a delay with the service worker on devices where the CPU is slow is because retrieving a chunk from the CacheControl with the Service Worker doesn't always take 1ms, but sometimes 10ms or more. So for example to retrieve 15 bundles on click, an old device can in total take 150ms or more instead of 15ms.
+The reason why there is such a delay with the service worker on devices where the CPU is slow is because retrieving a chunk from the CacheControl with the Service Worker doesn't always take 1ms, but sometimes 10ms or more. So for example to retrieve 15 bundles on a first click, an old device can in total take 150ms or more instead of 15ms. Once the bundles have been executed and live in the browser memory or disk cache, the interactions are instant.
 
-In contrast, modulepreloaded bundles are downloaded and compiled by the browser. They live in memory and are ready to be served instantly on request. So if all the bundles required for an interaction have been preloaded, the interaction will be instant. There is no network request, no service worker interception, no retrieving of bundles from the CacheStorage.
+In contrast, modulepreloaded bundles are downloaded and compiled by the browser. They live in memory and are ready to be executed instantly on request. So if all the bundles required for an interaction have been preloaded, the interaction will be instant. There is no network request, no service worker interception, no retrieving of bundles from the CacheStorage.
 
 Here’s a small Excalidraw to illustrate the difference:
 
@@ -95,28 +95,26 @@ Here’s a small Excalidraw to illustrate the difference:
 The Service Worker had to be registered before any prefetching could happen. Not only did this negatively affect TTI and [TBT (Total Blocking Time)](https://developer.chrome.com/docs/lighthouse/performance/lighthouse-total-blocking-time#:~:text=Blocking%20Time%20audit-,What%20TBT%20measures,Paint%20and%20Time%20to%20Interactive.) a little, but it also prevented Qwik from reprioritizing bundles if the user interacted before the registration.
 <Image src={serviceWorkerRegistrationPenalty} alt="Service Worker registration penalty" />
 
-With modulepreload, we can now start preloading bundles **as soon as the browser is idle**. This means [FCP (First Contentful Paint)](https://web.dev/articles/fcp) and [LCP (Largest Contentful Paint)](https://web.dev/articles/optimize-lcp#:~:text=Largest%20Contentful%20Paint%20(LCP)%20is,is%20rendered%20within%20the%20viewport.) remain as fast as possible, and slightly better TTI and TBT scores because we can prioritize buffering the bundles needed for a user interaction as soon as the page is visible to the user.
-### Even better prioritization based on heuristics
+With modulepreload, we can now start preloading bundles as soon as the html is rendered. The default makes sure that [FCP (First Contentful Paint)](https://web.dev/articles/fcp) and [LCP (Largest Contentful Paint)](https://web.dev/articles/optimize-lcp#:~:text=Largest%20Contentful%20Paint%20(LCP)%20is,is%20rendered%20within%20the%20viewport.) remain as fast as possible, and slightly improves TTI and TBT scores over the service worker.
 
-Reprioritization is a powerful feature - allowing Qwik to change the “buffering” order based on the user’s actions.  
+### Even better prioritization based on heuristics
 
-But it’s even better if the framework can already know ahead of time what to “buffer” in which order. 
+A powerful feature that already existed in the Qwik service worker that is also implemented in the Qwik Preloader is the ability to “**reprioritize**” bundles on user interaction. If some bundles are at the bottom of the preload queue, we can tell the browser to start preloading them right away. This means that no matter what, TTI remains constant as it doesn't increase proportionally to the number and size of bundles that need to be loaded.
 
-Qwik can now out of the box have better guesses about bundles that are more likely to be needed with other bundles, as they are “related”. 
+But it’s even better if the framework can already know ahead of time what to “buffer” in which order. Qwik can now out of the box guess which bundles are more likely to be requested by the user based on what is most likely to be interacted with first.
 
-It is not perfect (for that we have [Qwik Insights]( which requires a database), but it’s quite a bit better than before! Qwik now gives “better scores” to more important things like “user events” or “above the fold” components over things it assumes are less important.
+It is not perfect (for that we have [Qwik Insights]( which requires a database)), but it’s quite a bit better than before! Qwik now gives “better scores” to more important things like “user events” or “above the fold” components over things it assumes are less important.
 
 For example, Qwik assumes that the search input on the navbar above the fold is more likely to be used sooner than a Button on a footer far down below the fold, but if the user scrolls and clicks the button on the footer, Qwik will re-prioritize its bundles before the search input. 
+
 ### Faster CI times
 
 Thanks to the performance improvements above, our full CI tests on [qwik.dev](<http://qwik.dev>) now run in about ~10 minutes instead of ~15, and most of it can be attributed to the E2E tests which do many renders in a browser and were therefore bootstrapping a lot of service workers.
 ## **How do I get all of this Goodness?** (**Migration steps)**
 
 Migrating to Qwik 1.14.0 with the Qwik Preloader as the new default should not require much effort on your end, but there are a few changes you should know about. 
 
-Currently 93% of browsers support “modulepreload”, which wasn't the case when we started using the service worker for “buffering”. 
-
-For non-supported devices, the preloader will fallback to `<link rel=preload>`, which doesn't compile the code in advance but still works and brings the support to 100%. In effect, you can rest assured all your users will experience lightning speed regardless of their device.
+Currently 93% of browsers support “modulepreload”, which wasn't the case when we started using the service worker for “buffering”. For non-supported devices, the preloader will fallback to `<link rel=preload>`, which doesn't compile the code in advance but still works and brings the support to 100%. In effect, you can rest assured all your users will experience lightning speed regardless of their device.
 
 Here are the Steps you need to follow:
 
