Breaking Up the Monolith: Vercel’s Move to Vertical Microfrontends

Vercel’s primary website was once a single, large Next.js application serving both marketing content and the logged-in dashboard. As the company scaled, that architecture started to show strain. Build times crept upward, dependency management grew more intricate, and even small changes triggered full rebuilds, slowing down both local development and CI pipelines.

To address this, Vercel re-architected its site around vertical microfrontends. The result: preview build times and local compilation improved by more than 40%, and a significant reduction in page weight led to better Core Web Vitals scores, including improvements in LCP and INP.

Three Apps, One Monorepo

Vercel evaluated both major microfrontend strategies before making a choice:

  • Vertical microfrontends: split by route path, where each app owns entire pages.
  • Horizontal microfrontends: split by feature, where multiple apps render on the same page.

Horizontal splits offer granularity but complicate testing, releases, and monitoring since multiple independent apps must coordinate on a single view. Vertical splits provide cleaner ownership but can introduce hard navigations when users cross between differently owned sections. Techniques like prefetching and Chromium’s Speculation Rules can soften those transitions, though they bring trade-offs in resource usage and browser support.

Vercel chose vertical microfrontends because its site divides naturally along three rarely-crossed paths:

  • marketing
  • documentation
  • logged-in dashboard

Each section has a distinct UI and serves a different user intent. These areas were separated into independent Next.js applications using the Next.js Multi-Zones feature, which natively supports the vertical split.

A Monorepo-First Incremental Migration

The migration didn’t start with a fork of the existing codebase — that would have duplicated shared header, footer, and design-system components across repositories, creating synchronization headaches. Instead, Vercel kept everything in a single Turborepo-powered monorepo, centralizing shared code into packages so all apps could import consistent dependencies. New microfrontend applications were created from scratch rather than carved out of the old code, letting extraction happen gradually and safely.

Tools like Dependency Cruiser and Turborepo’s --affected flag and remote caching simplified task orchestration and dependency tracking.

During the transition, new pages existed in both the legacy monolithic app and the new microfrontend. Traffic routing was managed with feature flags. When a new page had served production traffic for at least a week without errors, the old implementation was deleted, incrementally shrinking the monolith, reducing build time, and removing dead dependencies.

Hard Navigations and Mitigation Strategies

One known trade-off of vertical microfrontends is hard page loads when users move between apps that Next.js can’t handle as soft transitions. Vercel tackled this with a layered approach.

First, as soon as a link appears in the viewport, the browser downloads the target page’s JavaScript and CSS to prime the cache. If a user navigates, assets load locally, though HTML still needs to be fetched and rendered.

Second, on actual user interaction — like tapping a link — Vercel prerenders the target page in the background. All network requests and processing happen off-screen, so when the user arrives, the transition feels instant. This strategy deliberately balances resource use: prefetching and prerendering only occur at the right moments to avoid overloading the device.

During rollout, engineers used Speed Insights to monitor real-world performance and the Vercel Toolbar to flag layout shifts and interaction timing regressions. Incremental adoption exposed predictable friction: local testing and previews of microfrontends were painful, and Draft Mode behaved incorrectly. Hard navigations also initially hurt perceived performance. Speculation Rules and prefetching addressed that, but only after dedicated effort.

The Payoff and the Roadmap

After migrating vercel.com, the company applied the same architecture elsewhere, including spinning the 2024 Next.js Conf site into a separate application so its team could iterate without stepping on the core Next.js docs team’s work.

Having validated the model, Vercel is now focused on improving routing, refining the preview workflow, and further optimizing hard navigation performance. The vertical split delivered its main goals — reduced build times, productive teams using shared packages, and a development model where independent velocity doesn’t require forking shared code.