Overview
Cloudflare introduces a new Worker template for Vertical Microfrontends (VMFE) that allows mapping multiple independent Cloudflare Workers to a single domain, enabling teams to develop and deploy frontend applications independently by sub-path. The article covers how to use CSS View Transitions, Speculation Rules API for preloading, service bindings for request routing, and HTMLRewriter for path rewriting to create a seamless unified user experience from separate codebases.
What You'll Learn
1
How to split a large frontend application into independently deployable vertical microfrontends using Cloudflare Workers
2
How to use CSS View Transitions to make separate Worker-hosted pages feel like a single-page application
3
How to configure Cloudflare Worker service bindings and route definitions for sub-path-based request routing
4
Why vertical microfrontends improve team autonomy by eliminating cross-team deployment dependencies
5
How to use HTMLRewriter to fix asset paths when reverse-proxying microfrontend responses through a Router Worker
Prerequisites & Requirements
- Understanding of frontend web development concepts including SPA vs MPA architectures
- Familiarity with Cloudflare Workers and the Wrangler CLI configuration
- Basic understanding of HTML, CSS, and JavaScript including DOM concepts
- Understanding of reverse proxy patterns and URL path routing(optional)
- Experience with at least one frontend framework (React, Vue, Svelte)(optional)
Key Questions Answered
What is the difference between vertical and horizontal microfrontends?
Horizontal microfrontends split a single page so different parts are fetched from different services. Vertical microfrontends take a different approach by splitting the application by sub-path, where a team owning a path like /blog owns the entire vertical stack for that route — the full page, its framework, libraries, CI/CD pipeline, and deployment lifecycle — rather than just a component on a shared page.
How do Cloudflare Workers route requests to different microfrontend applications?
A single Router Worker is assigned to a custom domain and handles all incoming requests at the network edge. It uses a ROUTES configuration variable that maps URL path prefixes to service bindings. When a request arrives, the Router Worker matches the path prefix, strips it from the URL, and forwards the request to the corresponding Worker via service bindings, which communicate internally without going through a publicly-accessible URL.
How do CSS View Transitions make separate microfrontends feel like one application?
CSS View Transitions allow you to define DOM elements (like a nav bar) that persist visually during page navigation between different Workers. By adding a view-transition-name to shared elements and defining animation timing (e.g., ease-in-out over 0.3 seconds), the browser smoothly transitions between pages instead of showing a white blank screen, making two different Workers feel like a single cohesive application.
What are Cloudflare Worker service bindings and how do they enable microfrontends?
Service bindings allow a single Cloudflare Worker to call into other Workers without going through a publicly-accessible URL. In the VMFE pattern, the Router Worker defines service bindings in its wrangler configuration that reference each microfrontend Worker (e.g., marketing, docs, dashboard). This creates the stitching mechanism that connects separate frontend projects under a single domain.
Why does the Router Worker strip the path prefix before forwarding requests?
The Router Worker strips the path prefix (e.g., /docs) so each microfrontend Worker can handle requests as if it were called directly from its own independent URL. This design choice means the Worker service can be accessible both from its own standalone URL and through the Router Worker without code changes, preserving independent deployability.
How does HTMLRewriter fix broken asset paths in vertical microfrontends?
When a microfrontend Worker returns HTML with relative asset paths (like ./logo.png), those paths break when served under a sub-path like /docs/. The Router Worker uses HTMLRewriter to intercept the response before sending it to the client, prepending the proxied path prefix to absolute paths. For example, <img src="./logo.png" /> becomes <img src="./docs/logo.png" />.
How does the Speculation Rules API improve microfrontend navigation performance?
The Speculation Rules API enables browsers (Chrome, Edge, Opera) to prefetch other vertical microfrontend pages and hold them in an in-memory cache. By defining a script tag with type="speculationrules" containing prefetch URLs, navigating to those pages feels nearly instant. This is especially useful within dashboard-style applications where users navigate between product sub-paths frequently.
Does Cloudflare use vertical microfrontends in their own dashboard?
Yes, Cloudflare uses a similar vertical microfrontend strategy internally for their own dashboard. When users navigate from the core dashboard into the Zero Trust product, they are actually moving between two entirely separate projects, with routing handled by the path /:accountId/one. This real-world usage validates the pattern for large-scale, multi-team dashboard applications.
Technologies & Tools
Some links below are affiliate links. We may earn a commission if you make a purchase.
Edge Computing / Serverless
Cloudflare Workers
Host individual microfrontend applications and the Router Worker at the edge
Browser API
CSS View Transitions API
Enable smooth animated transitions between pages served by different Workers
Browser API
Speculation Rules API
Prefetch microfrontend pages into in-memory cache for near-instant navigation
Cloudflare Workers API
Htmlrewriter
Rewrite HTML asset paths and inject View Transition CSS and Speculation Rules into responses
CLI Tool
Wrangler
Configure Worker service bindings and route definitions for microfrontend routing
Frontend Framework
React
Mentioned as one of the framework options for individual microfrontend Workers
Frontend Framework
Vue
Mentioned as one of the framework options for individual microfrontend Workers
Frontend Framework
Svelte
Mentioned as one of the framework options for individual microfrontend Workers
Markup Language
HTML
Mentioned as a valid option for building microfrontend pages without a framework
Stylesheet Language
CSS
Used for View Transition definitions and visual unification of microfrontends
Data Format
JSON
Used for Wrangler configuration and ROUTES variable definitions
Key Actionable Insights
1Use CSS View Transitions with view-transition-name to make shared UI elements (like navigation bars) persist across microfrontend boundaries. Just a few lines of CSS — defining animation-duration, timing-function, and view-transition-name on shared elements — eliminates the jarring white-screen flash between page navigations, making separate Workers feel unified.This is most critical when vertical slices exist within a single experience (e.g., multiple product pages in a dashboard) where users would not expect to see a page reload. For clearly separate sections like marketing vs. docs, slight load transitions are acceptable.
2Define your ROUTES configuration with the smoothTransitions and preload flags to automatically inject View Transition CSS and Speculation Rules into responses via HTMLRewriter, avoiding manual code changes in each microfrontend project. Setting smoothTransitions to true at the root level and preload to true on individual routes automates the unified experience.This zero-config approach means individual microfrontend teams don't need to coordinate on shared CSS or preloading logic — the Router Worker handles it transparently.
3Design each microfrontend Worker to function independently at its own URL without depending on the Router Worker's path prefix. The Router Worker automatically strips the path prefix before forwarding, so the downstream Worker should handle requests as if it's at the root path. This preserves the ability to develop and test each service in isolation.This architectural decision simplifies local development and testing — each team can run and deploy their Worker independently, and it will work both standalone and behind the Router Worker.
4Use Cloudflare Worker service bindings instead of public HTTP calls for communication between the Router Worker and microfrontend Workers. Service bindings enable internal Worker-to-Worker communication without traversing the public internet, reducing latency and keeping the stitching mechanism private.Service bindings are configured in the wrangler.json file by defining a binding name and the target service. This is the core mechanism that enables path-based routing under a single domain.
5Account for HTML asset path rewriting when architecting your microfrontend responses. Since individual Workers return HTML with paths relative to their own root, the Router Worker must use HTMLRewriter to prepend the path prefix to absolute asset references in the response before returning it to the browser.Without this rewriting step, images, scripts, and stylesheets will fail to load when the microfrontend is accessed through the Router Worker's sub-path, because the browser resolves relative URLs against the wrong base path.
Common Pitfalls
1
Failing to rewrite asset paths when serving microfrontend responses through the Router Worker. If a documentation Worker returns HTML with relative paths like ./logo.png, and users access it at /docs/, the browser will resolve the asset path incorrectly because the /docs prefix is artificially created by the Router Worker and the downstream Worker doesn't know about it.
The Router Worker must use HTMLRewriter to prepend the sub-path prefix to absolute asset references in HTML responses before returning them to the client browser.
2
Leaking implementation details to users by not making vertical microfrontend boundaries invisible. If navigation between two product dashboard sub-paths (e.g., /dash/product-a and /dash/product-b) shows a white blank screen or visually distinct layouts, users will notice they're interacting with separate applications, degrading the user experience.
Use CSS View Transitions for visual continuity and the Speculation Rules API for preloading to ensure transitions feel like SPA navigation. This is critical within a single experience like a dashboard, though less important between clearly distinct sections like marketing and documentation.
3
Not considering that the Speculation Rules API has limited browser support. While Chrome, Edge, and Opera support Speculation Rules for prefetching, Firefox and Safari do not, meaning users on those browsers won't benefit from preloading and may experience slower navigation between microfrontend pages.
Plan for graceful degradation by ensuring the application still functions well without prefetching, and consider the Speculation Rules as a progressive enhancement rather than a core requirement.
4
Coupling microfrontend Workers to the Router Worker's path structure. If individual Workers are built expecting to be served under a specific sub-path, they lose the ability to function independently at their own standalone URL, breaking the core promise of team autonomy and independent deployability.
Design each Worker to handle requests as if it's at the root path, and let the Router Worker handle path prefix stripping and rewriting automatically.
Related Concepts
Microfrontend Architecture
Horizontal Microfrontends
Single-page Application Vs Multi-page Application
Reverse Proxy Patterns
Edge Computing
Service-oriented Architecture
Cloudflare Workers Service Bindings
CSS View Transitions API
Speculation Rules API
Htmlrewriter
CI/CD Pipeline Independence
Domain-driven Design
URL Path-based Routing
Document Preloading
Multi-team Frontend Development