Optimizing Web Performance in Next.js: A Production Checklist
Performance is the feature users feel before they read a single word on your site. I learned this the hard way on a client landing page that scored poorly on Lighthouse — not because the design was bad, but because we loaded four font families, unoptimized hero images, and a JavaScript bundle that included an entire charting library for one small widget.
After fixing those issues, the same page loaded in under two seconds on mobile and the client's conversion rate improved noticeably. Performance work is not glamorous, but it is one of the highest-impact skills a full-stack developer can have — especially when shipping Next.js apps to Vercel, Netlify, or AWS.
Core Web Vitals: What to Measure First
Google's Core Web Vitals are the three metrics that matter most for user experience and SEO. I check these on every project before handoff.
Core Web Vitals Targets
| Metric | What It Measures | Good Target | Common Cause of Failure |
|---|---|---|---|
| LCP (Largest Contentful Paint) | How fast the main content appears | Under 2.5s | Large unoptimized hero images |
| INP (Interaction to Next Paint) | How responsive the page feels to clicks | Under 200ms | Heavy JavaScript on the main thread |
| CLS (Cumulative Layout Shift) | Visual stability while loading | Under 0.1 | Images without dimensions, late-loading fonts |
Next.js Optimization Checklist
Next.js gives you powerful performance tools out of the box — but only if you use them. Here is the checklist I run before every production deployment.
- Replace all img tags with next/image — set width, height, and priority on above-the-fold images
- Use dynamic imports for heavy components: charts, maps, rich text editors
- Enable static generation (SSG) for pages that do not need real-time data
- Audit bundle size with @next/bundle-analyzer and remove unused dependencies
- Configure fonts with next/font — preload only what you need, one or two weights maximum
- Set proper cache headers for static assets and API responses where appropriate
“Measure performance continuously in production, not once at launch. Real users on real networks will always behave differently from your localhost.”
Image Optimization
Images are the number one cause of slow LCP scores I see in client projects. The fix is almost always the same: use next/image, serve WebP or AVIF formats, set explicit dimensions, and lazy-load everything below the fold.
JavaScript and Bundle Splitting
Every kilobyte of JavaScript your user downloads is a kilobyte they have to parse before the page becomes interactive. Audit your imports regularly — that utility library you imported for one function might be adding 40KB to your bundle.
Performance Optimization by Impact
| Area | Action | Impact | Effort |
|---|---|---|---|
| Images | next/image + WebP + lazy loading | High | Low |
| JavaScript | Dynamic imports + tree shaking | High | Medium |
| Fonts | next/font + limit weights | Medium | Low |
| CSS | Remove unused Tailwind with purge/content config | Medium | Low |
| API | Cache responses + reduce waterfall requests | High | Medium |
| Third-party scripts | Defer analytics and chat widgets | Medium | Low |
Measuring Performance in Production
Local Lighthouse scores are useful for development, but production monitoring tells you what real users experience. I use Vercel Analytics on deployed Next.js projects and WebPageTest for deeper waterfall analysis when debugging specific pages.
- Lighthouse in Chrome DevTools — quick local audit during development
- WebPageTest — detailed waterfall and filmstrip for specific URLs
- Vercel Speed Insights — real-user Core Web Vitals in production
- Chrome User Experience Report — field data for competitive analysis
- Bundle Analyzer — identify which packages are bloating your JavaScript
Final Thoughts
Performance optimization is not a one-time task. Every new feature, image, font, and third-party script is a potential regression. Build performance checks into your deployment workflow the same way you build linting and type checking.
The projects in my portfolio — from SaaS dashboards to cinema platforms — all follow this checklist before going live. Fast sites convert better, rank better, and reflect better on the developer who built them.