Rebuilding a high-traffic platform without pausing the roadmap.

01Overview

The platform was doing its job commercially and failing quietly everywhere else: page weight climbing release over release, four near-identical template families, and a build nobody wanted to touch. The mandate was to modernize the frontend without a freeze and without a redesign.

LCP

-58%

Build time

-40%

Templates

-63%

Releases

Weekly

02The problem

Three symptoms kept surfacing in different disguises. Pages were slow on mobile, particularly the highest-traffic entry points. Small copy changes required an engineer, because content and markup were tangled. And every release carried risk, since duplicated templates meant a fix in one place quietly left three others wrong.

Underneath all three was the same cause: there was no shared layer. Each section of the site had been built by whoever needed it, when they needed it.

03Constraints

• No code freeze — marketing kept its weekly release cadence throughout.
• No visual redesign, so improvements had to be invisible to visitors except in speed.
• Existing URLs and search rankings had to be preserved exactly.
• Content editors could not be asked to learn a new tool mid-quarter.

04Approach

We migrated section by section, starting with the highest-traffic templates so the benefit showed up in field data early. Each migration followed the same shape:

1. Inventory the existing template and its real content variations.
2. Rebuild it from shared components, matching the current design exactly.
3. Ship behind a flag, compare field metrics for a week, then remove the old path.

Matching the old design exactly was the unglamorous decision that made everything else possible: with no visual diff to argue about, review took hours instead of weeks.

05Architecture

The new frontend is a component library plus a thin template layer, with a strict boundary between data fetching and presentation. Caching and delivery were treated as their own layers rather than an afterthought:

• Browser & deviceWhat the visitor actually experiences
• CDNGlobal edge delivery and asset caching
• Caching layerPage, object, and transient caches
• ApplicationWordPress core, theme, and plugins
• DatabaseOptimized queries and indexes

The budget went into CI on week two, before most of the migration work. Introducing it early meant the platform never regressed back toward where it started:

# Fail the build before a regression reaches production.
budgets:
  - path: "/*"
    resourceSizes:
      - { resourceType: script,     budget: 170 }
      - { resourceType: stylesheet, budget: 60 }
      - { resourceType: image,      budget: 400 }
    timings:
      - { metric: largest-contentful-paint, budget: 1500 }

06Results

Six months after the first migration, largest contentful paint on mobile had dropped by 58% at the 75th percentile, builds finished in around three minutes instead of five, and the template count fell from 38 to 14. The change editors noticed most had nothing to do with speed: they could finally publish a landing page without filing a ticket.

The change I care about most is that the numbers held. A year of releases later, the budget is still green.

07What I’d do differently

I would build the component inventory with the design team in the room from day one. We reverse-engineered it from production markup, which worked, but it encoded a few inconsistencies that we then had to un-encode later. Two weeks of shared vocabulary up front would have saved a month of naming debates.