Light route
Static content behind the same catch-all route.
Before splitter400 kB
Accumulated route chunk
After splitter0 kB
Page-specific route chunk
Light pages stay light.
Build-time route splitting for Next.js
Catch-all routing without catch-all bundles.
Catch-all routes put many pages behind one module. The bundler follows every reachable import, so the route chunk can grow with the accumulated component graph. Splitter analyzes page needs at build time and gives Next.js page-specific bundle boundaries. Light pages stay light. Heavy pages pay their own cost.
Benchmark preview
See the catch-all tax removed per route.
The route starts as one accumulated chunk. Splitter turns it into page-specific route chunks, so each page carries only its own transport.
Open full benchmark400 kB not shipped
Heavier route
Interactive content that still needs its own client code.
Before splitter400 kB
Accumulated route chunk
After splitter100 kB
Page-specific route chunk
Only route-specific code travels.
Why it exists
Fix the bundle boundary before tuning around it.
The bundler is not failing. It is doing the conservative thing for the shared module graph it receives. Splitter changes that input at build time, so page-specific routes become visible before delivery optimizations begin.
01Fix the boundary
Give the bundler a page-specific module.
A catch-all route puts many pages behind one file. The bundler follows every reachable import because that is the only safe boundary it can see.
02Then tune delivery
Compression, caching, and prefetching work on smaller output.
Those optimizations still matter, but they become cleaner once light pages are not carrying code from heavier pages in the same route.
03Use mitigations last
next/dynamic can defer cost, not explain the route.
Dynamic imports are useful for interaction-driven UI. They do not tell Next.js which slug needs which component at build time, so they are a mitigation layer, not the route-boundary fix.
Why ranking systems can care
Performance scores see symptoms. Ranking systems care about experience.
Search ranking systems care about page experience, and performance is part of that experience. Route splitting does not boost SEO directly. It removes unnecessary JavaScript before the page ships, which can improve the conditions behind faster loading, less main-thread work, and better responsiveness.
Lighthouse, Core Web Vitals, and search page experience systems then observe the downstream outcomes. Bundle size is not the whole story, but it is one root input into performance.
Where it fits
Where page composition is known.
Today the splitter is MDX-first. The broader idea is target-based: when a Next.js content route can identify the components needed for one page, the splitter can give that page its own route boundary.
Next.js route targetsCurrent core
App Router and Pages Router can split broad catch-all content routes without giving up the route shape.
Docs framework integrationsCurrent integrations
Apply the same MDX component-key model inside popular Next.js content frameworks.
Headless CMSKey provider
Contentful, Sanity, Storyblok, and custom CMS section types can become component keys when page composition is available at build time.
Page buildersKey provider
Page snapshots from tools like Makeswift and Builder.io already know which registered components an editor placed on a page.
Commerce routesUse case
Product, category, campaign, and landing routes often combine templates, CMS blocks, and page-builder sections. When those inputs expose component keys at build time, broad storefront routes can stay broad without one page pulling in every block.