Next.js Performance Checklist: Improve Core Web Vitals Fast

Performance in Next.js is more than just a metric—it's a competitive advantage. In an era where a 100ms delay can drop conversion rates by 7%, optimizing your application's Core Web Vitals (LCP, FID, CLS) is critical for both SEO and user retention. While Next.js provides many optimizations out of the box, achieving a "Straight 100" Lighthouse score requires intentional architectural choices.

1. Image Optimization: The Largest Contentful Paint (LCP) Fix

Images are almost always the biggest bottleneck. The next/image component is your best friend, but you must use it correctly to see the benefits.

• Priority Property: Always add priority to your hero images. This tells Next.js to preload them, often shaving 500ms+ off your LCP.
• Correct Sizing: Use the sizes attribute to serve smaller images to mobile users. Serving a 2000px wide image to a 400px wide phone is a waste of bandwidth.
• Blurry Placeholders: Use placeholder="blur" to improve the perceived performance while the high-res image loads.

"Performance is the most visible form of quality. A fast site tells the user that you care about their time."

2. Eliminating Layout Shifts (CLS)

Cumulative Layout Shift occurs when elements jump around as the page loads. It’s frustrating for users and penalized by Google.

• Fixed Dimensions: Always provide width and height for images and videos. If you use fill, ensure the parent container has a fixed aspect ratio.
• Font Optimization: Use next/font to host fonts locally. This prevents the "Flash of Unstyled Text" (FOUT) that often causes layout shifts.
• Dynamic Content: Reserve space for ads or dynamically injected content using min-height skeletons.

3. Strategic Rendering: SSR vs. SSG vs. ISR

Choosing the wrong rendering strategy is a common cause of high TTFB (Time to First Byte).

• Static Site Generation (SSG): Use this for 90% of your pages (like this blog). It's the fastest possible way to serve content.
• Incremental Static Regeneration (ISR): The best of both worlds. Update static content after deployment without a full rebuild. Perfect for product catalogs.
• Server-Side Rendering (SSR): Use only when content must be personalized per request or changes every second.

4. Reducing Bundle Size and JavaScript Bloat

The more JS you send, the longer it takes for the browser to become interactive (FID/TBT).

1. Dynamic Imports: Use next/dynamic to defer loading heavy components (like maps, charts, or complex modals) until they are actually needed.
2. Dependency Audit: Regularly check your package.json. Do you really need a 50kb library for a single utility function?
3. Server Components: Leverage React Server Components (RSC) to move logic off the client and reduce the amount of JavaScript sent to the browser.

5. API and Data Fetching Performance

• SWR or React Query: Use these libraries for client-side fetching to enable caching and background revalidation.
• Database Indexing: Ensure your database queries are optimized. No matter how fast your frontend is, a 2-second database query will ruin the experience.
• Edge Runtime: For global audiences, consider deploying your APIs to the Edge to reduce latency.

Interaction to Next Paint Is the One That Catches Teams Out

Teams optimise loading metrics, ship, and then discover their field data still fails. The usual reason is Interaction to Next Paint, which measures responsiveness across the whole visit rather than at load. A page can render quickly and still feel sluggish every time someone taps something.

Most INP problems trace to the main thread being occupied when the user acts:

• Long tasks during hydration. Large client bundles block the main thread precisely when users first try to interact. Ship less JavaScript to the client and keep components on the server wherever they do not need interactivity.
• Expensive work in event handlers. Filtering or sorting a large list synchronously inside an onClick handler blocks paint. Defer non-urgent updates so the interface can respond first.
• Layout thrashing. Reading a layout property and then writing to the DOM in a loop forces repeated recalculation. Batch reads and writes separately.
• Third-party scripts. Analytics and chat widgets compete for the same main thread. Load them with a strategy that defers them past interactivity rather than including them inline.

Lab Scores and Field Data Measure Different Things

A perfect local Lighthouse score is not evidence that users are having a good experience. Lighthouse runs a single simulated load on one device profile, on a warm local machine, with no extensions and no contention. Field data reflects real devices, real networks, and real interaction.

Treat them as complementary rather than interchangeable:

• Lab tools are for diagnosis. They are reproducible, which makes them good for comparing before and after a change.
• Field data is the scoreboard. Real user measurement is what actually reflects experience, and what search engines consider.
• Watch percentiles, not averages. Core Web Vitals are assessed at the 75th percentile. An average masks the slow quarter of visits entirely.
• Segment by device and route. Aggregate numbers hide the truth. A site can pass overall while one important template fails badly on mid-range phones.

Performance Regresses Quietly

The hardest part of performance work is not achieving a good score, it is keeping one. Regressions arrive gradually through ordinary feature work, and nobody notices until a quarterly review.

• Set a bundle size budget and enforce it in CI. A pull request that adds two hundred kilobytes should require a deliberate decision, not pass silently.
• Audit dependencies before adding them. A date formatting library that ships every locale is a common and avoidable cost.
• Re-check after adding any third-party tag. Marketing scripts are the most frequent cause of sudden regressions, and they are often added outside the normal review process.
• Alert on field data, not just on deploys. A regression that only affects mobile users on slow connections will not show up in your local testing.

Conclusion

Optimizing for Core Web Vitals is an ongoing process of refinement. Start with the "Quick Wins" (Images and Fonts) and then move into deeper architectural improvements. At Apexita, performance is baked into everything we build. If your site feels sluggish or your SEO rankings are dipping, let us perform a technical performance audit and help you reach those green scores.