Framework performance reviews

Why a framework-specific review

General advice such as "ship less JavaScript" is true for every app and useful for none in particular. The concrete question is how to ship less in your framework, at your version, given the way your team has structured components and data. Frameworks move quickly, and the right answer in 2026 is often different from the one in tutorials written two years ago.

We keep the review grounded in each framework's own documentation and release notes, and we state the version a recommendation applies to.

What we look at in each framework

React and Next.js

• Where the server-client boundary sits. In React Server Components, a module marked 'use client' and everything it imports becomes client code that ships to the browser, while Server Component code stays on the server (source 1). Boundaries placed high in the tree pull large parts of the app into the bundle.
• Re-renders on input, profiled with the Scheduler and Components tracks that React 19.2 adds to Chrome DevTools (source 2).
• Use of transitions, Suspense and <Activity> to keep urgent updates responsive and to prepare likely next screens (source 2).
• In Next.js, which routes are prerendered, cached with 'use cache', or rendered per request, and whether Cache Components and Partial Prefetching (opt-in flags since 16.3, recommended for every app and on by default in new projects from 16.4) suit your navigation patterns (source 3) (source 8).
• Whether the React Compiler is enabled and, if so, which manual memoization can go.

Vue and Nuxt

• Reactivity cost: large reactive objects, deep watchers and computed values that recalculate more often than needed.
• Server rendering and hydration, including Vue 3.5 lazy hydration strategies for async components (source 4) and Nuxt's delayed hydration props on Lazy components (source 5).
• Hydration mismatch warnings and their causes.
• Payload size: data serialized into the page for the client.

Angular

• Change detection strategy and the move to signals and zoneless operation in recent versions.
• Server rendering and hydration. Since Angular 22, incremental hydration is enabled by default with provideClientHydration, so @defer blocks and their hydrate triggers deserve a careful look (source 6).
• Lazy-loaded routes and the size of shared chunks.

Svelte, SvelteKit and Astro

• Svelte compiles components ahead of time, so reviews focus more on data loading, large imports and expensive $derived and $effect work than on framework runtime cost.
• In Astro, which components carry client directives and whether client:visible or client:idle could replace earlier hydration, plus server islands for personalized fragments (source 7).

Framework features worth checking first

Some framework features have a large effect for little effort, and we check them early in every review:

• Production builds and flags. Development builds or debug flags shipped to production add significant script cost.
• Route-level code splitting. Whether each route loads only its own code, or whether a shared chunk carries most of the app.
• Server rendering and hydration settings. Whether hydration is enabled where it should be, and whether newer options, such as incremental hydration in Angular or lazy hydration in Vue, are available on your version.
• Compiler or build optimizations. The React Compiler, Svelte's compiler options and Angular's build optimizer can remove work that would otherwise run at runtime.
• Data-loading primitives. Using the framework's own data loading, such as Nuxt's useFetch or Next.js caching, avoids duplicate requests and hydration mismatches caused by data fetched twice.

These checks take little time and sometimes resolve a large share of the problem before deeper profiling starts.

How the review runs

1. 01

   Version and setup check

   Framework, router and build tool versions, configuration flags and the rendering mode of each route.

2. 02

   Profiling

   Framework devtools and Chrome traces for start-up and the main interactions, on throttled profiles.

3. 03

   Code reading

   With source access, we read the components and data layers behind the slowest paths. Without it, we work from source maps and bundles.

4. 04

   Recommendations

   Changes grouped as configuration, component structure, data loading and dependencies, each tied to the version it needs.

Version notes we include

Because advice depends on versions, every recommendation in the review carries the version it applies to and a link to the relevant documentation or release notes. Where your version lacks a feature, the review says which release introduced it and what an upgrade involves, so you can decide whether the feature is worth the move. That way the review stays useful when your team reads it months later, and you can tell at a glance which items need re-checking after an upgrade.

What you receive

A written review organized by area, annotated traces and profiler captures, a ranked change list, and a walkthrough with your engineers. Upgrade advice is kept separate and marked clearly, because an upgrade carries risks that configuration changes do not.

Questions about framework reviews