Next.js
Next.js Performance: Fixing LCP, INP, and CLS in Order of Payoff
Most Next.js performance work goes wrong in the same way: someone runs Lighthouse, sees a yellow score, and starts applying optimizations from a checklist. Half of them address a phase of page load that was never the bottleneck. The faster route is to find out which of the four phases of Largest Contentful Paint is eating your budget, then fix only that.
Start with the targets, because they are specific and Google publishes them. A page passes Core Web Vitals when, at the 75th percentile of real visits, Largest Contentful Paint is under 2.5 seconds, Interaction to Next Paint is under 200 milliseconds, and Cumulative Layout Shift is under 0.1.
2.5s
Largest Contentful Paint, the moment the main content appears
200ms
Interaction to Next Paint, responsiveness to taps and clicks
0.1
Cumulative Layout Shift, how much the page jumps while loading
Thresholds measured at the 75th percentile of real user visits, segmented by mobile and desktop. Source: Google web.dev.
Break LCP into its four phases before touching anything
LCP is not one number, it is a sum. Google breaks it into time to first byte, resource load delay, resource load duration, and element render delay, and publishes a rough budget for how a healthy page distributes them.
Share of total LCP time
The principle behind the split: nearly all of LCP should be spent actually transferring bytes. The two delay phases are pure waste, which is why they are the first place to look.
Source: Optimize LCP, Google web.dev.
You can read these phases per page in Chrome DevTools or with the web-vitals library in attribution mode. The diagnosis usually falls out immediately, and it points at a different fix in each case.
| Dominant phase | What it means | The Next.js fix |
|---|---|---|
| Time to first byte | Your server or origin is slow to respond, or the request is bouncing through redirects. | Render the route statically where possible, or cache it. Check for redirect chains on entry URLs. Nothing on the frontend can start until this finishes. |
| Resource load delay | The browser did not learn about your hero image until late, often because it was discovered by JavaScript rather than the HTML. | Use next/image with `priority` on the above-the-fold image. Avoid rendering the hero inside a client component that must hydrate first. |
| Resource load duration | The image itself is too heavy for the connection. | Correct `sizes` so phones do not download desktop-sized files, let next/image serve modern formats, and serve from a CDN. |
| Element render delay | The resource arrived but something blocked painting: render-blocking CSS, fonts, or a client component waiting on hydration. | Move work to Server Components, use next/font so text does not wait on a network font, and cut render-blocking scripts in the head. |
Images: the `sizes` attribute is where the win hides
Everyone knows to use next/image. Fewer people set `sizes` correctly, and that is where most of the remaining waste sits. Without an accurate `sizes` value, the browser assumes the image may occupy the full viewport width and picks a candidate accordingly, so a phone downloads a file sized for a desktop layout. On an image-heavy page that alone can be the difference between passing and failing LCP.
- Set `priority` on the single largest above-the-fold image and nothing else. Marking everything priority defeats the purpose by competing for the same bandwidth.
- Give `sizes` the truth about your layout, for example `(max-width: 768px) 100vw, 768px` for a content column that caps out.
- Always set explicit width and height, or use fill with a sized container. Missing dimensions are the most common cause of layout shift.
- Do not lazy-load anything above the fold. It delays discovery of the exact resource LCP is waiting on.
INP is a main thread problem, not a network one
Interaction to Next Paint measures how quickly the page responds when someone taps. It fails for a different reason than LCP: too much JavaScript executing on the main thread, so a click sits in a queue behind hydration or a heavy render. Shipping less JavaScript is the fix, and the App Router gives you the tools directly.
- Keep components on the server by default. Every `use client` boundary is JavaScript the visitor downloads, parses, and executes before the page reacts to them.
- Push `use client` as far down the tree as it will go. Marking a layout as a client component drags its whole subtree along with it.
- Dynamically import genuinely heavy widgets, charts, rich text editors, map embeds, so they are not in the initial bundle.
- Audit third-party scripts honestly. Chat widgets, heat maps, and tag managers frequently cost more INP than everything you wrote.
What changed in Next.js 16
Next.js 16 shipped in October 2025 and moved several defaults. Turbopack is now the stable default bundler, which mainly affects build and refresh speed rather than runtime performance for your visitors. More consequentially for caching, the model is now opt-in: routes are dynamic by default, and you cache deliberately with Cache Components and the `use cache` directive rather than reasoning about implicit behavior.
Middleware has also been superseded by `proxy.ts`, which runs in the Node.js runtime by default and is meant for network-boundary work such as rewrites, headers, and geo routing. `middleware.ts` still works but is deprecated. If you are upgrading, that is worth handling deliberately rather than discovering later.
The practical upshot: explicit caching is easier to reason about but it will not happen by accident. If your time to first byte is the dominant LCP phase, caching the route is usually the highest-leverage single change available to you, and in Next.js 16 you have to ask for it.
Measure in the field, not on your laptop
Lab tools like Lighthouse are simulations. They are excellent for isolating a cause and useless for deciding whether you pass, because they do not reflect your visitors’ devices, networks, or cache states. Collect real user data and look at the 75th percentile. The Chrome User Experience Report gives you this for free at the origin level, and the web-vitals library reports it per page with attribution telling you which phase and which element was responsible.
One discipline worth adopting: record performance work in the same change log you use for marketing and site changes, as described in smarter analytics for small teams. Field data moves on a 28 day rolling window, so a fix you shipped shows up gradually and you will want to know exactly when it landed.
Key takeaways
- ✓Targets are LCP under 2.5s, INP under 200ms, CLS under 0.1, at the 75th percentile of real visits.
- ✓Split LCP into its four phases first. The two delay phases should be under 10% each, and they are where wasted time hides.
- ✓Set `sizes` and `priority` correctly on next/image. An unset `sizes` makes phones download desktop-sized images.
- ✓INP failures come from main thread JavaScript. Keep components on the server and audit third-party tags.
- ✓Next.js 16 makes caching opt-in via Cache Components, so a slow time to first byte will not fix itself.
- ✓Lab scores debug; field data decides. Measure with CrUX or web-vitals attribution.
Sources
- Web Vitals: metrics and thresholds, Google web.dev
- Optimize Largest Contentful Paint: the four subparts, Google web.dev
- How the Core Web Vitals thresholds were defined, Google web.dev
- Next.js 16 release notes, Vercel (2025)
- next/image component API reference, Next.js Documentation
Digital Strategist
Valon Badivuku is a Digital Strategist at ThisCom, helping brands get seen and become visible online through strategies that turn attention into lasting growth.
All articles by Valon Badivuku →Frequently asked questions
What are the Core Web Vitals thresholds?+
Largest Contentful Paint under 2.5 seconds, Interaction to Next Paint under 200 milliseconds, and Cumulative Layout Shift under 0.1. Each is assessed at the 75th percentile of real user visits, segmented between mobile and desktop, so three quarters of your actual traffic needs a good experience for the page to pass.
Why is my Lighthouse score good but my Core Web Vitals still failing?+
Lighthouse is a lab simulation on a synthetic device and network, while Core Web Vitals assessment uses field data from real Chrome users at the 75th percentile. Real visitors are on slower devices, worse networks, and varied cache states. Use Lighthouse to diagnose a cause and the Chrome User Experience Report or the web-vitals library to judge whether you pass.
Does next/image guarantee good LCP?+
No. It handles format conversion, responsive candidates, and lazy loading, but you still have to set `sizes` accurately so small screens do not download large files, add `priority` to the main above-the-fold image, and avoid lazy-loading anything above the fold. An incorrectly configured next/image can be slower than a well-tuned plain img tag.
How do I improve INP in a Next.js app?+
Ship less JavaScript to the browser. Keep components as Server Components by default, push `use client` boundaries as deep into the tree as possible, dynamically import heavy widgets like charts and editors, and audit third-party scripts. Marketing and analytics tags are frequently the largest single contributor to poor INP on otherwise well-built sites.
What changed about caching in Next.js 16?+
Caching became explicitly opt-in. Routes are dynamic by default and you cache deliberately using Cache Components and the `use cache` directive. Turbopack also became the stable default bundler, and middleware.ts was superseded by proxy.ts, which runs in the Node.js runtime by default. If time to first byte dominates your LCP, caching the route is usually the highest-leverage change, and you now have to ask for it explicitly.
Related articles
Designing MVPs That Scale (Without Gold-Plating the First Version)
Most MVPs die from building the wrong thing, not from bad architecture. Here is where to spend your engineering budget, where to deliberately take on debt, and the four decisions that are genuinely expensive to reverse.
Read →Email MarketingEmail Marketing for Small Business: The Complete 2026 Guide
The famous $36-per-$1 return is a self-reported survey figure, not a promise. Here is how a small business actually builds an email program that reaches the inbox and drives revenue, from list to automation to metrics.
Read →BrandingBranding for Small Business: The Complete Guide
Branding is not just a logo, it is the reputation and promise customers associate with you. Here is how a small business builds a brand that earns trust and commands a premium.
Read →Related reading
- Research
Still Worth It: What the Data Says About Small Business Survival in 2026
Federal survey data shows most small businesses are holding steady while expectations fall, and that the number one operational problem is reaching customers. A look at what the research actually supports.
- Analytics
Smarter Analytics for Small Teams: Fewer Numbers, Better Decisions
Most small business dashboards report a lot and decide nothing. Here is how to pick metrics that change behavior, plus the GA4 settings that quietly delete your history if nobody changes them.
- AI
AI in the Back Office: Where It Actually Pays Off for Small Teams
Federal survey data shows the smallest firms are the slowest to adopt AI, and the reasons are practical rather than technophobic. Here is which back-office work is genuinely worth automating, and which will cost you more than it saves.
- Branding
Brand vs. Branding vs. Brand Identity: What’s the Difference?
These three terms get used interchangeably but mean different things. Understanding the distinction is the first step to building a brand intentionally.
- Branding
How to Build a Brand Strategy (Step by Step)
A brand strategy is the foundation every logo, message, and campaign should rest on. Here is a practical, step-by-step process for small businesses.