Building web performance into everyday delivery
How I keep rendering, caching, third-party code, SEO, and Core Web Vitals inside the normal delivery loop on international commerce platforms.
One performance audit can find problems; it cannot stop the next release from bringing them back. I focus on the decisions and checks a team can use during ordinary delivery.
Put performance in the release loop
On international commerce platforms, I treat rendering, cache behaviour, integration boundaries, third-party scripts, and image delivery as connected decisions. Each can affect customer experience, search visibility, and the team’s ability to diagnose a regression.
The highest-leverage changes happen before release: make ownership clear, review the parts of a change that affect rendering or the critical path, and annotate releases so regressions can be tied back to an event.
Use field and lab data together
Controlled measurements make changes comparable. Field data shows what real devices, networks, and markets experience. I use both because either view alone can mislead: a stable lab run can miss a regional dependency, while field data can take too long to explain a new regression.
Core Web Vitals provide a shared vocabulary, but the investigation still needs page type, market, device class, cache state, and release context.
Make the trade-off explicit
A performance budget works only when the team understands it well enough to use it during product decisions. The useful conversation is not “performance versus features”; it is which cost we are accepting, for which users, and how we will know if that cost grows.
When those questions are part of planning and review, SEO and Core Web Vitals stop being checks at the end of a replatform and become ordinary engineering inputs.