Qwik can achieve this performance no matter how large your application gets. The above numbers were achieved with some cool technology including:
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.
Headless sites are incredibly fast and flexible. They make integration with any API-first vendor a breeze, but they come with a cost of constant reliance on developer resources for even the smallest of tasks (e.g. adding a button to a section). Builder.io solves this with a visual editor that allows non-developers to build high-performance experiences using the elements and permissions their developers provide.
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:
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)
Compare the previous expensive startup with the Qwik/Partytown combination?
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 MainThread. There all 220kB of third-party code can do its thing without affecting the MainThread performance.
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 a Web Worker, will full main thread API access. Once you optimize everything else, 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.