If you've ever worked on a growing Next.js app, you've probably lived through this exact scenario:
You’re reviewing a seemingly harmless pull request. Someone added a nice-looking UI component or a utility library. The PR gets approved, merges into main, and goes live. A week later, you look at your Lighthouse score or real-user monitoring, and your Core Web Vitals are tanking. You dig into the build output and realize that one small import pulled in a massive third-party package, blowing up your client-side JavaScript bundle by 250 KB.
Frustrating, right?
Most of us reach for @next/bundle-analyzer to fix this. Don't get me wrong—it's a phenomenal tool built by smart people. But in practice, it has a massive blind spot for fast-moving teams.
Table Of Contents
- The friction with
@next/bundle-analyzer - What we actually wanted: A background guard dog
- What it looks like in practice
- Wrapping up
The friction with @next/bundle-analyzer
The core issue isn't that @next/bundle-analyzer doesn't work; it's that it requires manual human effort.
To check your bundle size, a developer has to:
- Remember to run a local build with an env flag (
ANALYZE=true npm run build). - Wait for Webpack/Turbopack to finish compiling.
- Open a massive, interactive HTML treemap in their browser.
- Go hunting through nested colored boxes to figure out which file grew.
In a high-velocity team where people are shipping multiple PRs a day? Developers simply forget to do it. It’s an extra step outside the normal workflow. Code gets merged, regressions slip past, and you only find out when production is already bloated.
What we actually wanted: A background guard dog
We didn't want another tool that developers had to manually run or remember. We wanted something passive—a guard dog that sits quietly in the background and only barks when something is actually wrong.
We wanted it to live right where code reviews happen: GitHub Pull Requests.
So, over a weekend, we hacked together a lightweight solution (we call it NextPerf) that automates the whole thing without touching our CI/CD pipelines. Here is how we designed it to stay out of our way:
- Vercel Webhooks: The second a preview deployment succeeds on Vercel, it intercepts the build payload automatically.
-
Dynamic Baselines: It compares the PR's JS size against our production
mainbranch baseline, which is cached safely in edge storage. -
Smart Thresholds (No Alert Fatigue): If a PR adds 2 KB of code, nobody cares. To stop alert fatigue, we added a simple
.nextperf.jsonconfig file to our repo. If the jump stays below our custom threshold (say, 50 KB), the bot stays silent. If it crosses the line, it flags it. - GitHub App Bot: Instead of messy logs, it drops a clean, crisp markdown table right into the PR comment thread.
What it looks like in practice
Now, whenever someone opens a PR on our repo, a clean little summary drops in automatically:
| Metric | Size |
|---|---|
| Base Branch | 666.51 KB |
| This PR | 978.85 KB |
| Difference | +312.34 KB |
🚨 Performance Regression Detected (Exceeded Threshold)!
No local builds. No opening HTML treemaps. The developer sees the impact of their code before it ever touches production.
Wrapping up
Tools like @next/bundle-analyzer are fantastic for deep-dive optimization sessions when you're actively trying to trim fat off your app. But for everyday development, automation is the only way to prevent regressions permanently.
If you're curious about how we set it up or want to try it on your own Vercel/Next.js stack, you can check out what we built at NextPerf SaaS or install the GitHub App directly at github.com/apps/nextperf.
How does your team currently handle bundle size monitoring? Do you rely on manual checks, or have you automated it some other way? Let me know in the comments below!
Top comments (0)