The Problem
Most Next.js projects start fast and get slow. Not because engineers write bad code — but because nobody audits the defaults.
When a fintech client came to us with a dashboard that scored 41 on Lighthouse and had a 6-second LCP, we ran a systematic audit before touching a single feature.
Here's exactly what we found and how we fixed it.
1. Bundle Analysis First
Before optimising anything, run:
ANALYZE=true next build
Install @next/bundle-analyzer and add it to next.config.js. You will almost always find:
- A date library (moment.js, date-fns) being imported in full
- An icon library loading every icon
- A heavy chart library not being code-split
const HeavyChart = dynamic(() => import('@/components/HeavyChart'), {
ssr: false,
loading: () => ,
});
This alone cut our client's JS bundle from 780KB to 310KB.
2. Image Optimisation
The single biggest LCP killer is images. Rules we follow on every project:
- Always use
next/imagewithsizesprop set correctly - Serve hero images in WebP/AVIF only
- Set
priorityon above-the-fold images - Never use
fillon images without a fixed-height parent
3. Font Loading
Using Google Fonts via next/font? Make sure you have display: "swap" and are only loading the weights you actually use.
We also add size-adjust to prevent layout shift during font swap — this alone can fix a CLS score from 0.15 to near zero.
4. Eliminating Render-Blocking Work
GSAP animations and heavy scroll libraries should never block the initial paint. Use useEffect to register plugins client-side only:
useEffect(() => {
gsap.registerPlugin(ScrollTrigger);
}, []);
Results
After these four changes on the fintech dashboard:
No business logic was touched. No features removed.
Takeaway
Performance is an audit discipline, not a rewrite. Run bundle analysis on every project, respect image sizing, load animations lazily, and measure before you optimise.
Questions? Reach out to us — we audit Next.js apps as part of our onboarding process.