A new head-to-head benchmark has put two modern web frameworks to the test—and the results might change how you think about page speed. Developer Daw-Chih Liou built identical applications using Qwik and Next.js 13, then ran them through Lighthouse to measure real-world performance. The findings shed light on a fundamental split in how frameworks approach server-side rendering, and what that means for anyone who cares about fast websites.
If you've ever waited impatiently for a slow page to load on your Android device, this debate matters more than it might seem. Page speed directly affects conversion rates, search rankings, and whether users stick around or bail. Let's break down what the test found and why it should be on your radar.
The Test Setup
Liou created two matching apps using Qwik v0.16 and Next.js v13 with React v18. The demo application let users enter prompts for DALL-E, an AI image generator, and displayed the resulting images on the page. It also showed a live Twitter feed related to DALL-E. Both apps had the same features, same design, and pulled data from the same sources.
The codebase is publicly available on GitHub. The key question was straightforward: when everything else is equal, which framework delivers faster Core Web Vitals?
How Qwik Approaches Speed
The framework's core innovation is called resumability—it serializes application state on the server and hands off execution to the client without forcing a full JavaScript reload.
Here's the mechanics. When a server receives a page request, Qwik generates four things in parallel: HTML markup, serialized application state, serialized event handlers, and component code chunks. The browser receives a complete HTML page and can display content immediately. Meanwhile, Qwik deserializes the state after the page loads. Interactive elements don't need their JavaScript loaded upfront either—event handlers are referenced as dynamic chunks that only download when a user actually clicks something.
This means the initial page render is fast because the server does the heavy lifting. Your browser doesn't need to download and execute reams of JavaScript before showing you anything.
How Next.js Handles Rendering
Next.js with React Server Components follows a different mental model. Instead of "get HTML and render," it champions "render while fetching."
When a request comes in, Next.js delegates rendering to React on the server. React builds a JSON description of the entire component tree rather than native HTML. Server components render to HTML directly, while client components are described with their props serialized. The framework streams this rendering result to the client progressively using Suspense boundaries.
The practical effect? Users start seeing content while the server is still fetching data. The skeleton placeholder appears immediately, and the final UI replaces it once data resolves. The client also begins rendering before the entire server response finishes.
The Core Web Vitals Showdown
Both applications were tested using Lighthouse to measure performance. Qwik's performance score and Next.js's performance score were recorded and compared in the benchmark.
Say you run a small e-commerce site and you're deciding between these frameworks. A one-second improvement in Largest Contentful Paint could translate to measurably higher engagement, especially on mobile networks where latency hits harder.
Why This Matters for Web Performance
The two frameworks represent genuinely different philosophies about when work happens. Qwik trusts the server to do more upfront, minimizing client-side JavaScript. Next.js trusts the client to start rendering sooner, even if the server hasn't finished everything.
Neither approach is universally better. Qwik's resumability shines when initial load time is paramount and users might not interact much with a page. Next.js streaming makes sense when you want visible progress indicators and don't want users staring at a blank screen while data fetches.
What's clear is that modern frameworks are getting serious about Core Web Vitals. Faster websites mean better user experience, improved SEO, and ultimately more conversions. Whether you're a developer choosing a stack or a tech enthusiast evaluating tools, understanding these trade-offs helps you make smarter decisions.
Key takeaways
- Qwik's resumability model prioritizes server-side work to minimize client JavaScript, potentially winning on initial load speed.
- Next.js streaming lets browsers start rendering before servers finish fetching, improving perceived performance.
- The right choice depends on your use case—content-heavy sites may favor Qwik, interactive apps may benefit from Next.js streaming.
- Core Web Vitals directly impact revenue and engagement metrics, making framework selection a business decision, not just a technical one.
Frequently asked questions
What is Qwik's resumability feature?
Resumability means Qwik renders applications on the server and transfers serialized state and event handlers to the client, allowing the browser to resume rendering without re-executing JavaScript from scratch.
How does Next.js streaming improve page load times?
Next.js streams rendered content to the browser progressively, letting users see UI elements like skeleton loaders while data fetches complete, rather than waiting for the entire page to render server-side.
Which framework performed better in the benchmark?
Both frameworks were tested with Lighthouse, and the benchmark showed measurable differences in Core Web Vitals scores, though the reference notes specific score values were captured for comparison.
What are React Server Components?
React Server Components are a special component type in Next.js 13 that run exclusively on the server, supporting async/await for data fetching while keeping JavaScript out of the client bundle.
Why do Core Web Vitals matter for website owners?
Studies point to a clear pattern—optimizing these metrics tends to lift revenue per visitor, boost conversion rates, and reduce how often people leave sites.