01
Poor mobile Core Web Vitals
Heavy client components hydrating on the main thread and delaying the first interaction on mobile.
Slow page loads, hydration lag and poor Core Web Vitals in Next.js
Next.js performance optimization and Core Web Vitals fixes
Find out why a Next.js app is slow — client bundles, hydration, uncached data — fix the biggest causes first, and measure field Core Web Vitals before and after.
Symptoms
Signs your platform has this problem
If several of these sound familiar, the plan below is where we would start.
02
Large client bundles
'use client' placed too high in the tree, shipping whole component trees to the browser.
03
Slow time to first byte
Sequential, uncached data fetches inside Server Components.
Remediation plan
How we fix it, step by step
Each phase ends with a measurement, so you can see what changed before the next one starts.
01
Bundle and dependency profiling
Running @next/bundle-analyzer to find oversized libraries and code that shouldn't reach the client.
02
Server Component boundaries
Pushing 'use client' down to the interactive leaves so more of each page renders on the server.
03
Caching and revalidation
Caching data fetches and revalidating on demand with revalidateTag instead of refetching on every request.
04
Images and CDN
Serving AVIF or WebP through next/image with correct sizes, and caching at the CDN.
Technical checklist
Remediation checklist
What we check before a change goes to production:
- Audit every 'use client' directive and push interactivity down to leaf components
- Run independent data fetches in parallel and stream slow sections with Suspense
- Serve AVIF or WebP images with explicit sizes and a prioritized LCP image
- Verify that cache tags are revalidated when CMS content changes
What we measure
We take a baseline first and report the same measurements after each change, from your own monitoring — evidence, not promised results.
- LCP
- Field data at p75 (CrUX or RUM), before and after
- INP
- Field data at p75 on mobile, before and after
- JS per route
- Client JavaScript, gzip, from the build output
Related service
Web & frontend
Frontend engineering measured in field Core Web Vitals before and after, accessibility to WCAG AA, and replatforms shipped route by route with no freeze.
Explore Web & frontendQuestions
Questions about this remediation
It depends on what profiling finds. We start with a short profiling pass, then agree the fixes, their order and the timeline in writing before changing any code.
No. Interactive widgets (modals, dropdowns, forms) stay client components, while static layout becomes Server Components. Each change ships behind your normal tests and review.
Related playbooks
Other engineering problem playbooks
AWS cost reduction audit and FinOps remediation
Find where your AWS money goes, then cut waste in order of value and risk: right-sizing, spot capacity, storage tiers, data transfer and commitment discounts.
Technical debt remediation and codebase modernization
Find the parts of the codebase that slow delivery most, put tests around them, and refactor them while feature work continues.
PostgreSQL query performance optimization
Find the queries that cost the most, fix them with targeted indexes and query changes, and add connection pooling before load turns into an outage.
Reducing AI hallucinations: RAG accuracy and citation checks
Make AI answers traceable: better parsing and retrieval, rerankers, and automated checks that each claim in an answer is supported by a cited source.
Want an engineer to look at this with you?
Send us the symptoms and any metrics you have. We'll reply within one business day, set up a call and agree what to measure before anything changes.