How Qwik Achieves Ultra‑Fine Lazy Loading to Boost Web Performance

1. What page is this and who is the expert?

The 100‑point Lighthouse score belongs to Builder.io's website, created by a company focused on low‑code/no‑code platforms and extreme performance. Its CTO, Miško Hevery, is the creator of AngularJS and Angular.

Builder.io serves many e‑commerce sites, where page speed directly impacts conversion and profit. Faster first‑paint and interactive button availability are critical goals.

2. How does Builder.io improve performance?

Optimizing first‑paint and time‑to‑interactive hinges on reducing resource download size and code execution time. Common tactics include minification, compression, and lazy loading (see Fig. 3).

The most effective gain comes from optimizing JavaScript, especially third‑party scripts and business code. Third‑party scripts are off‑loaded to Web Workers using the open‑source PartyTown tool. Business code is lazily loaded, often via on‑demand chunking, embodied in the new Qwik framework.

3. Why not reuse existing lazy‑loading?

Early lazy loading relied on manually inserting script tags. Later module systems (AMD, CMD, ES Modules) introduced dynamic import() for module‑level lazy loading, which frameworks like Vue Router and Vue async components use.

However, even with route‑level lazy loading, the overall JavaScript bundle remains large, and component code can still be heavy.

4. Limitations of existing frameworks

SSR‑generated pages still require a hydration phase: after the HTML is streamed, the browser downloads the full JavaScript bundle, parses it, and reconstructs the component tree, which adds linear time cost as page complexity grows.

Serializing the component tree into HTML is impractical because it contains functions, promises, and other non‑JSON‑friendly data, leading to large payloads.

5. How does Qwik work?

Qwik serializes event‑binding information directly into HTML attributes and embeds a compact JSON payload describing component state, subscriptions, and code locations. This enables the page to become interactive before full hydration.

In a simple counter example, Qwik splits the code into two chunks: one for the click handler and one for the component render. The HTML contains a q:id for each component and an on:click attribute that encodes which chunk to load.

The accompanying JSON (Fig. 16) maps component IDs to their context, state, and rendering code URLs, allowing the runtime to fetch only the needed pieces on demand.

6. Does on‑demand loading cause latency?

Qwik mitigates latency with a prefetching mechanism that observes viewport visibility and caches required resources ahead of interaction. Prefetching can run in a Web Worker, reducing main‑thread load.

7. Summary and outlook

The article traced lazy‑loading from manual script injection to modern frameworks, highlighted the hydration bottleneck, and demonstrated Qwik's ultra‑fine‑grained lazy loading and prefetching as a solution. Although Qwik is still in beta, its concepts—granular chunking, event‑driven loading, and worker‑based prefetching—are valuable for improving performance in existing Vue or other front‑end projects.

8. References

1. https://qwik.builder.io/

2. WWC22 – Qwik + Partytown: How to remove 99% of JavaScript from main thread

3. Resumable Frameworks – Miško Hevery (ng‑conf 2022)

4. Our current frameworks are O(n); we need O(1)

5. Hydration is Pure Overhead

6. Why Progressive Hydration is Harder than You Think

7. How we cut 99% of our JavaScript with Qwik + Partytown