
---

## A benchmark comparison and analysis between Qwik and Next.js 13.

### TL;DR

* 🔥 We’ll find out whether the trending framework Qwik is faster than Next.js
* 🤖 We’ll look at a demo that generates with OpenAI’s DALL-E and its performance benchmark.
* 🚀 We’ll discuss how Next.js leverages React server component to achieve fast SSR.


---

Page speed matters. Faster website results in [better UX, better SEO, and more profit](https://web.dev/tags/case-study/). The [latest research done by Rekuten 24](https://web.dev/rakuten/) shows that optimizing [Core Web Vitals](https://web.dev/vitals/) leads to:

\
> 53.37% in revenue per visitor.

> 33.13% in conversion rate.

> 15.20% in average order value.

> 9.99% in average time spent.

> A 35.12% reduction in exit rate.

\
The modern frameworks and frontend libraries address speed and help developers ship better user experiences to the users. We’ll be discussing two of the modern frameworks: [Qwik](https://qwik.builder.io/) and [Next.js](https://nextjs.org/). We’ll see an experiment benchmark and look into how each framework achieves optimal performance.

\
Let’s go.

### How The Experiment Is Set Up

* qwik v0.16
* Next.js v13
* React v18

### Let’s Peek The Result

I built two identical applications with Qwik and Next.js and measured the performances. The demo look like this:

 ![demo](https://cdn.hackernoon.com/images/XyqHIwK0xDMOGdIf5iTNW4CrLjb2-9yb34o7.gif.webp)

\
\
\
> *You can find [the demo on GitHub](https://github.com/DawChihLiou/qwik-vs-next). Feel free to take a look at the repo and try it out✨*

\
The application lets users enter prompts to [DALL·E](https://openai.com/dall-e-2/), an AI image generator, and displays the generated AI images in the page. It also displays the latest Twitter feed about DALL·E.

\
The key features are:

* Server Side rendering of the application.
* Client-side fetching the image results with [DALL·E’s REST API](https://beta.openai.com/docs/api-reference/images/create).
* Server side fetching the Twitter feed with [Twitter’s REST API](https://developer.twitter.com/en/docs/twitter-api).

\
Here’s the core Web Vitals by Lighthouse for Qwik:

 ![Qwik performance score](https://cdn.hackernoon.com/images/XyqHIwK0xDMOGdIf5iTNW4CrLjb2-nic33r7.png)

\
Comparing to Next.js’s Web Vitals:

 ![Next.js 13 performance score](https://cdn.hackernoon.com/images/XyqHIwK0xDMOGdIf5iTNW4CrLjb2-d6d339b.png)

\
We can observe the following:

* Qwik’s [speed index](https://developer.chrome.com/en/docs/lighthouse/performance/speed-index/) is 0.5 s faster than Next.js.
* Qwik’s [time to interactive](https://developer.chrome.com/docs/lighthouse/performance/interactive/) is 0.3 s faster than Next.js.
* Next.js has a 0 ms [total blocking time](https://developer.chrome.com/docs/lighthouse/performance/lighthouse-total-blocking-time/), compared to Qwik’s 160 ms.
* Next.js has a slightly higher overall [performance score](https://developer.chrome.com/docs/lighthouse/performance/performance-scoring/) by 5 points.
* Next.js’s [largest contentful paint](https://developer.chrome.com/docs/lighthouse/performance/lighthouse-largest-contentful-paint/) is 0.8 s faster than Qwik.

\
Let’s take a closer look at how the application in each framework is set up.

### Qwik Server-Side Rendering

The component structure:

```typescript
// qwik/src/routes/index.tsx

export const onGet: RequestHandler<TwitterResponse> = async () => {
  const data = await fetchTweets();
  return data;
}

export default component$(() => {
  const tweets = useEndpoint<TwitterResponse>();
  return (
    <Layout>
      <DallePromptAndResult />
      <Resource
        value={tweets}
        onResolved={(result) => (
          <SSRTwitterCarousel data={result} />
        )}
      />
      <StaticPromptRecommendation />
    </Layout>
  )
})
```

\
When the Qwik server receives a page request, it starts the rendering process on the server. The “useEndPoint” function invokes the “onGet” function on the server and fetches the Twitter feed. The “Resource” component will pause the rendering until the Twitter data is resolved or rejected. Once the rendering is completed, the server responds to the client with rendered HTML.

\
We can observe the server-side rendering behavior in the performance profile:

\
 ![Qwik SSR](https://cdn.hackernoon.com/images/XyqHIwK0xDMOGdIf5iTNW4CrLjb2-7pe33gz.png)

\
The lead time to respond to the client is blocked by the server side data fetching and component rendering.

### Next.js SSR and Streaming

The component structure:

\
```typescript
// next/app/page.tsx

export default async function Page() {
  const tweets = await fetchTweets();
  return (
    <Layout>
      <DallePromptAndResult />
      <Suspense fallback={<Skeleton />}>
        <SSRTwitterCarousel data={tweets} />
      </Suspense>
      <StaticPromptRecommendation />
    </Layout>
  )
}
```

\
The “Page” component is a server component. It looks just like a normal component but it supports async/await.

\
When the Next.js server receives a page request, it starts the rendering process and [stream](https://beta.nextjs.org/docs/data-fetching/streaming-and-suspense)s the rendering result to the client so that the client can progressively render and display the UI to the users. While the server is fetching Twitter feeds, React renders the suspense placeholder to indicate the pending state. Once the data is resolved or rejected, React reveals the suspense boundary and displays the final UI.

\
 ![Next.js SSR streaming](https://cdn.hackernoon.com/images/XyqHIwK0xDMOGdIf5iTNW4CrLjb2-jhf33g7.png)

\
You can see the client starts rendering while the server is streaming. It reduces the lead time for the users to start seeing the page.

### Resumability v.s. React Server Component

> *Qwik embraces the “Get HTML and render” mental model.*

\
[Resumability](https://qwik.builder.io/docs/concepts/resumable/) is Qwik’s innovation. It allows an application to be rendered as much as possible on the server and resumes the rest of the rendering on the client.

The framework looks like this:

 ![Qwik framework](https://cdn.hackernoon.com/images/XyqHIwK0xDMOGdIf5iTNW4CrLjb2-zzg33l7.png)

\
When receiving a request, the Qwik server starts the rendering process and generates

* serialized application state,
* serialized event handlers,
* component HTMLs,
* and component code chunks.

\
The server then responds to the client with the page HTML and the serialized state.

\
 ![Qwik html in network](https://cdn.hackernoon.com/images/XyqHIwK0xDMOGdIf5iTNW4CrLjb2-ubh33jf.png)

\
On the client, the browser processes the [critical rendering path](https://developer.mozilla.org/en-US/docs/Web/Performance/Critical_rendering_path) and displays the UI. Qwik deserializes the state after the page HTML is loaded. The state contains all the local states of each component. The lazy-loaded components are able to be dynamically imported independently without knowing the parent’s state because they can refer to the deserialized state for their local states when they are rendering on the client.

\
Qwik also serializes event handlers.

 ![Qwik listener serialization](https://cdn.hackernoon.com/images/XyqHIwK0xDMOGdIf5iTNW4CrLjb2-e4i338e.png)

\
In the server-generated HTML, the event handlers are referenced as dynamic JavaScript chunks. When users interact with an interactive element, Qwik uses the reference to dynamically download the chunk from the server and fire the event with the event handler inside the chunk.

 ![Qwik dynamic import](https://cdn.hackernoon.com/images/XyqHIwK0xDMOGdIf5iTNW4CrLjb2-81c34k3.gif.webp)

\
On the other hand, Next.js has a different approach to server-side rendering.

\
> *Next.js and React server component promotes the “Render while fetching” mental model.*

\
[Next.js 13 introduces React server component as an experimental feature](https://beta.nextjs.org/docs/rendering/server-and-client-components). [Server component](https://github.com/reactjs/rfcs/blob/main/text/0188-server-components.md) is a special type of component that can only be rendered on the server. Combining with Suspense and Streaming, the framework is able to progressively render interactive UI while avoiding long data requests from blocking the page rendering.

\
The framework looks like this:

 ![Next.js framework](https://cdn.hackernoon.com/images/XyqHIwK0xDMOGdIf5iTNW4CrLjb2-lmk33h8.png)

\
When Next.js server receives a request, it delegates React to handle rendering. On the server, React renders the component tree into a UI description in JSON instead of native HTML. The UI description describes the entire component tree. For the client components, React describes them as components for the client to handle with serialized props. For the server components, React renders them to native HTMLs and places them in the UI description.

\
On the client, React receives and reconciles the UI description in the response stream to progressively render the UI. When React sees a suspense boundary, it renders the suspense placeholder until the pending data is resolved and reveals the suspense boundary.

\
Because React receives a UI description instead of native HTML on the client, it needs to construct the component tree, render the UI, and attach event handlers on the client. It’s known as hydration.

 ![Hydration in performance profile](https://cdn.hackernoon.com/images/XyqHIwK0xDMOGdIf5iTNW4CrLjb2-tdl33lu.png)

\
### Final Thoughts

Qwik’s concept of [serializing states and event handlers](https://www.builder.io/blog/hydration-is-pure-overhead) is very innovative. The client is able to render the page with just HTML and minimal JavaScript. It reduces the amount of JavaScript the client needs to download for the initial load and leverages dynamic import to download event handlers and components on the fly. We can clearly observe the benefit from the benchmark and performance profile.

\
However, the combination of React server component, suspense, and streaming has a profound impact on user experience. Users are able to see and interact with the content of the page without waiting for server-side data fetching to complete.

\
The result of the experiment is not conclusive to me. Both frameworks performed well in the benchmarks. The differences in First Content Paint, Largest Content Paint, and Cumulative Layout Shift are likely a result of different Twitter images.

### References

* [API Reference: Create image](https://beta.openai.com/docs/api-reference/images/create) — OpenAI
* [Case Study](https://web.dev/tags/case-study/) — web.dev
* [Critical rendering path](https://developer.mozilla.org/en-US/docs/Web/Performance/Critical_rendering_path) — MDN
* [DALL·E 2](https://openai.com/dall-e-2/) — OpenAI
* [Data Fetching Fundamentals](https://beta.nextjs.org/docs/data-fetching/fundamentals#fetching-data-with-server-components) — Next.js
* [First class support for promises](https://github.com/acdlite/rfcs/blob/first-class-promises/text/0000-first-class-support-for-promises.md#seamless-integration-with-javascript-ecosystem) — Andrew Clark
* [How Rakuten 24’s investment in Core Web Vitals increased revenue per visitor by 53.37% and conversion rate by 33.13%](https://web.dev/rakuten/) — web.dev
* [Hydration is Pure Overhead](https://www.builder.io/blog/hydration-is-pure-overhead) — Builder.io
* [Lighthouse performance scoring](https://developer.chrome.com/docs/lighthouse/performance/performance-scoring/) — Chrome Developers
* [Lazy loading](https://developer.mozilla.org/en-US/docs/Web/Performance/Lazy_loading) — MDN
* [Next.js](https://nextjs.org/) — Vercel
* [Node.js library](https://beta.openai.com/docs/libraries/node-js-library) — OpenAI
* [Populating the page: how browsers work](https://developer.mozilla.org/en-US/docs/Web/Performance/How_browsers_work) — MDN
* [Progressively](https://qwik.builder.io/docs/concepts/progressive/) — Builder.io
* [qwik](https://qwik.builder.io/) — Builder.io
* [qwik-vs-next](https://github.com/DawChihLiou/qwik-vs-next) — Daw-Chih Liou
* [RFC: React Server Components](https://github.com/reactjs/rfcs/blob/main/text/0188-server-components.md) — React Community
* [Resumable vs. Hydration](https://qwik.builder.io/docs/concepts/resumable/) — Builder.io
* [Reactivity](https://qwik.builder.io/docs/concepts/reactivity/) — Builder.io
* [Server and Client Components](https://beta.nextjs.org/docs/rendering/server-and-client-components) — Next.js
* [The “why” of web performance](https://developer.mozilla.org/en-US/docs/Learn/Performance/why_web_performance) — MDN
* [Think Qwik](https://qwik.builder.io/docs/think-qwik/) — Builder.io
* [Time to Interfactive](https://developer.chrome.com/docs/lighthouse/performance/interactive/) — Chrome Developers
* [Total Blocking Time](https://developer.chrome.com/docs/lighthouse/performance/lighthouse-total-blocking-time/) — Chrome Developers
* [Twitter API v2](https://developer.twitter.com/en/docs/twitter-api) — Twitter Developer Aplatform
* [Web Vitals](https://web.dev/vitals/) — web.dev
* [Speed Index](https://developer.chrome.com/en/docs/lighthouse/performance/speed-index/) — Chrome Developers
* [Largest Contentful Paint](https://developer.chrome.com/docs/lighthouse/performance/lighthouse-largest-contentful-paint/) — Chrome Developers

\

---

Want to Connect? This article was originally posted on__[Daw-Chih’s website](https://dawchihliou.github.io/articles/is-qwik-faster-than-react-server-component)__.


---

Also Published [Here](https://dawchihliou.github.io/articles/is-qwik-faster-than-react-server-component) \n  \n 

Too Long; Didn't Read

Cassandra Forward a free Cassandra-focused community event

Qwik vs Next.js: Speed Comparison

Too Long; Didn't Read

@dawchihliou

RELATED STORIES