Catch-all route tax
Unanswered
White-eyed Vireo posted this in #help-forum
White-eyed VireoOP
Catch-all routes in Next.js are great — until they quietly become expensive.
The catch-all route tax:
One heavy page.
Every page pays.
In the demo for next-slug-splitter, a single heavy page causes every page in the route to ship around ~1250 kB.
After splitting:
light pages: 141 kB
counter page: 266 kB
heavy page: 1250 kB
The heavy page still pays for what it needs.
The light pages no longer pay for what they don’t use.
next-slug-splitter analyzes what each slug actually needs and splits the route accordingly.
No fallback trick.
No runtime magic.
Just analysis-driven route splitting.
This is where it gets really interesting for large e-commerce platforms.
Many commerce setups rely on broad dynamic or catch-all-style routes for products, categories, campaigns, and CMS-driven landing pages.
Convenient structure.
Expensive failure mode.
One heavy page enters the route.
Every visitor can end up paying for it.
A lot of performance work optimizes around the symptoms:
better caching,
image optimization,
compression,
lazy loading,
prefetching,
CDNs,
bundle tuning.
All of that matters.
But sometimes the root cause is simpler:
the route is shipping too much code in the first place.
For high-traffic e-commerce sites, cutting unnecessary JavaScript is not only about a nicer Lighthouse score.
It means less network transfer, faster page loads, better UX on slower devices, and fewer users paying the cost of pages they never visit.
The goal is simple:
Keep the convenience of catch-all routes, without making every page pay for the heaviest one.
Live demo:
https://next-slug-splitter-app-router-multi.vercel.app/
Repo:
https://github.com/project-millipede/next-slug-splitter
The catch-all route tax:
One heavy page.
Every page pays.
In the demo for next-slug-splitter, a single heavy page causes every page in the route to ship around ~1250 kB.
After splitting:
light pages: 141 kB
counter page: 266 kB
heavy page: 1250 kB
The heavy page still pays for what it needs.
The light pages no longer pay for what they don’t use.
next-slug-splitter analyzes what each slug actually needs and splits the route accordingly.
No fallback trick.
No runtime magic.
Just analysis-driven route splitting.
This is where it gets really interesting for large e-commerce platforms.
Many commerce setups rely on broad dynamic or catch-all-style routes for products, categories, campaigns, and CMS-driven landing pages.
Convenient structure.
Expensive failure mode.
One heavy page enters the route.
Every visitor can end up paying for it.
A lot of performance work optimizes around the symptoms:
better caching,
image optimization,
compression,
lazy loading,
prefetching,
CDNs,
bundle tuning.
All of that matters.
But sometimes the root cause is simpler:
the route is shipping too much code in the first place.
For high-traffic e-commerce sites, cutting unnecessary JavaScript is not only about a nicer Lighthouse score.
It means less network transfer, faster page loads, better UX on slower devices, and fewer users paying the cost of pages they never visit.
The goal is simple:
Keep the convenience of catch-all routes, without making every page pay for the heaviest one.
Live demo:
https://next-slug-splitter-app-router-multi.vercel.app/
Repo:
https://github.com/project-millipede/next-slug-splitter
2 Replies
Black Caiman
Did you need help..?
this is a really interesting way to frame it
it feels less like a “catch-all route issue” and more like implicit bundle coupling through routing structure
one thing i’m wondering:
does your analysis isolate route-level imports only, or does it also account for shared layout and provider-level dependencies that can still leak into all segments
also curious how this behaves with app router + server components, since in theory that should already reduce a lot of client-side duplication
really nice idea either way — this makes the cost model of routing way more visible
it feels less like a “catch-all route issue” and more like implicit bundle coupling through routing structure
one thing i’m wondering:
does your analysis isolate route-level imports only, or does it also account for shared layout and provider-level dependencies that can still leak into all segments
also curious how this behaves with app router + server components, since in theory that should already reduce a lot of client-side duplication
really nice idea either way — this makes the cost model of routing way more visible