Qwik can achieve this performance no matter how large your application gets. The above numbers were achieved with some cool technology including:
- Our homepage only sends HTML for above-the-fold content.
- Partytown is used to move all third-party scripts to web-worker.
- This site is created using builder.io’s visual no-code editor
Qwik scales to massive sites, with hundreds of components, and MBs of content and continues to be fast. And it provides interactive server-side components that can transition to client components.
Our story starts here:
Notice that the performance of the site is average. On mobile, Google PageSpeed estimated that it will take 7.6 seconds before a user can click on a link and expect a response. This is not a great user experience. Additionally, Google is using PageSpeed scores to affect SEO ranking.
The first source of slow down comes from frameworks. When used in conjunction with modern frameworks, sites have a great developer experience and are highly interactive. But this comes at a cost of large JS download and slow startup times as frameworks reconcile the HTML generated on the server with the DOM the frameworks expect. This is known as reconciliation/rehydration, and all frameworks (with exception of Qwik) suffer this fate. The key part of reconciliation/rehydration is when the frameworks attach the listeners to the DOM, making the site interactive. This is the reason why reconciliation/rehydration has to happen as soon as possible. Without this, your site does not work (think menus, chat widgets, etc...)
The second source of slow down comes from third-party scripts. Yes, there are a lot of demo sites and “new builds” that show good PageSpeed scores, but this is in large part because third-party scripts are not yet included. Here is an example of some of the third-party scripts which are on our site:
- Google Tag Manager: is a must for any live site to collect usage statistics so that the marketing can gain insight as to how the site is used and how it can be improved. GTM executes at the beginning and it alone can take up all of the CPU time allotted for the site in PageSpeed before it starts being penalized.
- Intercom: Allows the customers to chat with builders in real-time on the site to ask questions and to find out more information.
All of the above third-party scripts run immediately on-site load and compete for CPU with the reconciliation/rehydration step above, resulting in poor user experience.
The issue is that as developers we have very little control over the above situation. We must use third-party scripts to add analytics and user service features that marketing teams need, and we must use existing frameworks which require expensive reconciliation on-site startup. There just are not a lot of levers under our control. This is the state of our industry and it is why no one can get much better results with the standard approach.
Qwik and Partytown aim to solve that!
|First Contentfull Paint||3.4||1.1||s||309%|
|Largest Contentful Paint||3.8||1.2||s||316%|
|Time to Interactive||7.6||1.4||s||543%|
|TTI - LCP (difference)||3.8||0.3||s||1,266%|
|Total Blocking Time||1,300||40||ms||3,250%|
|Cumulative Layout Shift||0||0||-|
First, a reminder that these numbers are for mobile, a much harder bar to reach than desktop performance.
The above table shows where we are now with Qwik and Partytown. The improvements are massive. Time to interactive dropped from 7.6 seconds down to 1.2 seconds. And total blocking time dropped from 1.3 seconds down to 40 milliseconds. The drop in JS execution can directly be attributed to Qwik for framework time and Partytown for third-party time.
Above is the performance profile before Qwik/Partytown. (This is emulating mobile)
- Page took 1.8 seconds to load.
- The main thread is very busy most of the time with "reconciliation" work (Figuring out where the DOM listeners should be placed.)
- The above results in many dropped frames.
- There is a cascade of JS code loading before the main thread gets busy with "reconciliation".
Compare the previous expensive startup with the Qwik/Partytown combination?
- No JS download
- Page took 0.5 seconds to load.
- Main thread is mostly idle.
- Very few dropped frames.
- Party town loads later
- 3rd party scripts execute in web worker (rather than main thread)
The comparison between the previous and current performance is night and day.
|Baseline (Main Thread JS)||1,800kB||326kB|
|Qwik + Partytown (Main Thread JS)*||3.5kB||2.5kB|
|--> part: Qwikloader||.5kB||1kB|
|--> part: Partytown confg||.5kB||1kB|
|--> part: Partytown||2.5kB||1.5kB|
|=== Size Improvement ===||51,429%||13,000%|
|WebWorker 3rd Party JS||219kB||82kB|
|--> part: Zoominfo||1.5kB||1.3kB|
|--> part: Google Tag Manager||167kB||60kB|
|--> part: Google Analytics||50kB||21kB|
|--> part: site-tracking||217kB||64kB|
We still have the issue of executing third-party code, but that has been relocated to the WebWorkerThread which runs at a lower priority than MainThred. There all 220kB of third-party code can do its thing without affecting the MainThread performance.
- We don't have to do anything on page startup, and
- when we do have to rehydrate, it is scoped to a single component only (rather than to the whole page).
Qwik is a new kind of web framework that focuses on time-to-interactive. Resumability means that Qwik can start executing on the server, can be serialized into HTML, and sent to the client. On the client,
qwikloader.js (less than 1kb JS on the client) sits idly waiting for user interaction. When a user interacts, Qwik can resume execution where the server left off. Resumability means that Qwik does not have to do reconciliation on startup and only the component you interact with needs to be hydrated. Qwik can create components on the server and then move them to the client in a seamless way. All of the above results in instant-on applications as is demonstrated above.
Qwik keeps all of its state in DOM, which means that Qwik itself is stateless. The stateless property allows for the lazy loading of content below the fold.
The above is very difficult to do with existing frameworks but is trivial with Qwik.
Partytown allows you to relocate third-party scripts into web-worker. Third-party scripts are often the biggest culprit for making the site how slow time-to-interactive.
We are hard at work on getting Qwik into your hands soon so you can see for yourself what kind of amazing things you can build.