Frontend rendering performance guides

All guides

• SSR, SSG, CSR and streaming compared

  How the main rendering strategies differ, and how to choose per route.

• What hydration costs

  Why server-rendered pages can look ready before they respond.

• Debugging INP with Long Animation Frames

  Find the scripts behind slow interactions with LoAF attribution.

• Breaking up long tasks with scheduler.yield

  Yield to the main thread so input and paint are not stuck in a queue.

• React Server Components and performance

  Where the client boundary should sit, and what it costs if it does not.

• Next.js 16 rendering choices

  Cache Components, 'use cache', Partial Prefetching and ISR in Next.js 16.

• Vue and Nuxt hydration

  Fix mismatch warnings, then hydrate less with Vue 3.5 and Nuxt.

• A RUM pipeline with web-vitals

  Collect, send, store and read field data you can act on.

• Bundle analysis for framework apps

  Find out what ships to the browser and decide what to remove.

• Frontend performance consulting cost

  What drives the price of performance work, and how to compare quotes.

How to use these guides

The guides build on each other loosely. If you are new to the topic, start with SSR, SSG, CSR and streaming compared and what hydration costs. If you are chasing a poor Interaction to Next Paint, go to debugging INP with Long Animation Frames and then breaking up long tasks. Framework-specific guides cover React Server Components, Next.js rendering choices, and Vue and Nuxt hydration.

How we write them

Every guide is written by Isabella Ward and checked against primary sources: web.dev and Chrome for Developers for browser metrics and APIs, and each framework's own documentation and release notes for framework behaviour. Where we rely on secondary or commercial sources, we label them in the source list. Code examples are kept short and follow the documented APIs they illustrate. Our editorial policy explains how we handle corrections and updates.

Browser support and framework features change. Look for the update date under each guide's title; a release that changes our advice prompts a revision.

Reading paths by role

• Frontend engineers: start with the long tasks guide and the INP debugging guide, then the guide for your framework.
• Technical leads planning architecture: the rendering strategies comparison, the hydration guide and the Next.js or React Server Components guide.
• Engineers setting up measurement: the RUM pipeline guide, then the INP debugging guide to put the data to use.
• Product and engineering managers: the rendering strategies comparison for the vocabulary, and the consulting cost guide if you are weighing outside help.

Topics we plan to cover next

We add guides when a release or a common question makes one worthwhile. Topics on our list include view transitions and their effect on responsiveness, measuring soft navigations in single-page apps, server islands and partial prerendering compared across frameworks, and performance testing in continuous integration. If there is a topic you would like covered, tell us through the contact page.

Printing and sharing

Guides print cleanly: the header, footer and call-to-action band are left out of the printed version, so a guide can be handed round a planning meeting on paper. Every heading has a stable anchor, so you can link a colleague straight to the section that matters.

How long the guides take to read

Each guide shows an estimated reading time under its title. The longer ones, such as the rendering strategies comparison, are meant to be read once in full and then used as a reference; headings are written so that you can jump straight to the part you need. Code samples sit in their own blocks so they can be copied without picking up surrounding text.

Concepts the guides return to

A handful of ideas run through every guide, and it helps to know them before diving in:

• The main thread. One thread runs your JavaScript, style, layout and paint. Most responsiveness problems are about keeping it free at the right moments.
• The 75th percentile. Core Web Vitals are judged at the value that 75 percent of page loads beat, split by mobile and desktop. Averages hide the slow visits that matter.
• Lab versus field. Traces on a test machine show what can happen; field data from real visits shows what does happen. Good decisions use both.
• Hydration. The step where a framework takes over server-rendered HTML in the browser. It is often where an early paint turns into a late response.
• Attribution. Data that names the element, phase or script behind a slow metric. Without it, field data says that something is slow but not why.

Guides compared with services

The guides are complete in themselves; you do not need to hire anyone to use them. Our services exist for teams that would rather have an outside specialist apply the same methods to their app, or that have tried and hit a problem they cannot explain. The guides never hold back a step to make the services look necessary.

A note on numbers

You will not find invented benchmarks here. Where a guide gives a figure, it comes from a cited source or from an example clearly marked as illustrative. Performance depends on your code, your users' devices and your traffic, so treat any example number as a way to understand an idea, not as a promise.