Blog: Fixing an Empty next.config.ts — What We Found and What We Did About It
Fixing an Empty next.config.ts — What We Found and What We Did About It
Release v1.0.24 · Category: Bundle Optimization
Every Next.js project ships with a next.config.ts file. It's the single file where you tell the framework how to build, optimize, and deliver your application. Ours was empty.
Not broken — just empty. export default {}. Next.js defaults applied everywhere, no hints given to the compiler, no size tracking wired up. The application worked fine. But "working fine" and "performing well" are two different things, and our autonomous performance audit caught the gap.
What the Audit Found
Our performance agent scanned next.config.ts as part of a bundle optimization sweep. Here's what was missing:
563 Bundled Icons
lucide-react is the icon library powering most of the UI. It exports 563 icons from a single entry point. Without experimental.optimizePackageImports, Next.js has no way to know which icons are actually used — so it errs on the side of including everything. That's ~600 KB of raw icon data potentially riding along in the client bundle.
The fix is a single config line:
experimental: {
optimizePackageImports: ['lucide-react', 'date-fns', '@dnd-kit/core', ...]
}
This alone is projected to cut 100–200 KB from the client bundle. That's meaningful — it can be the difference between a fast first load and a slow one on a mobile connection.
No Bundle Size Tracking
Bundle regressions are silent. A dependency update or a new feature can quietly add 50 KB to the client bundle and nobody notices until a Lighthouse score drops or a customer complains. @next/bundle-analyzer gives you a visual treemap of every module in your bundle, and wiring it into CI means every PR gets automatically compared against the baseline.
Images Without Modern Formats
Next.js's Image Optimization API supports avif and webp — the two most efficient image formats available to modern browsers. Without images.formats configured, those formats aren't served. Users on Chrome, Firefox, or Safari get PNGs and JPEGs when they could be getting files that are 30–50% smaller.
Console Statements in Production
Every console.log and console.debug left in the production build adds to bundle size and exposes internal state in the browser's developer console. The compiler can strip them automatically — except for console.error, which we want to keep for real runtime errors.
What This Tells Us
These aren't exotic optimizations. optimizePackageImports, bundle analysis, modern image formats, and production console removal are all documented in the Next.js docs. The issue isn't knowledge — it's the gap between "project scaffolded" and "project configured." A blank config file is the correct starting point; it becomes a problem when it stays blank.
This is exactly the kind of thing that's easy to miss when moving fast. The scaffolding works. The CI passes. The product ships. And the configuration that would have saved 200 KB on every page load never gets added because there's always something more urgent.
Autonomous auditing closes that gap. No ticket was filed for this. No sprint was planned. The performance agent identified the empty config, estimated the impact, and surfaced the fix. That's the loop working as intended.
What's Shipping in v1.0.24
experimental.optimizePackageImportsenabled forlucide-react,date-fns, and@dnd-kit/*@next/bundle-analyzerconfigured and gated behindANALYZE=truefor CI integrationimages.formats: ['image/avif', 'image/webp']for modern image deliverycompiler.removeConsolewitherrorexcluded for clean production builds
See the Next.js Performance Configuration page for the full reference config and implementation details.
This fix was identified and documented autonomously by the SaaS Factory performance audit pipeline.