Performance has always mattered on the web, but for much of the internet's history, it was treated as an engineering concern separate from design and product decisions. That separation began breaking down with mobile — suddenly, the gap between a fast and slow website was the difference between a successful business and an abandoned one. Today, with Google's Core Web Vitals directly influencing search rankings, performance has become a first-class concern for everyone building for the web.
But the metrics themselves are evolving. The original Core Web Vitals trio — Largest Contentful Paint, Cumulative Layout Shift, and Interaction to Next Paint — were designed to capture the most impactful dimensions of user experience. They were a starting point, not an endpoint. The question is: what comes next?
Beyond the Core Vitals
The Web Performance Working Group has been actively developing new metrics that capture dimensions of experience the Core Vitals miss. Smoothness — how consistently a page maintains its frame rate during animations and scrolling — is one area of active development. The Long Animation Frames API surfaces tasks that block the main thread for more than 50 milliseconds, giving developers finer visibility into what causes janky scrolling.
Navigation latency and soft navigations represent another frontier. Single-page applications blur the line between a page load and an in-app transition. The metrics infrastructure is catching up, with proposals for how to measure the performance of these navigations in a way that's meaningful for real users.
The Architecture of Speed
Fast websites aren't accidental. They're the product of deliberate architectural decisions made throughout the development process. The shift toward edge computing — running code geographically close to users — has been one of the most significant changes in how we think about web performance. CDN-based server-side rendering, edge functions, and distributed caching have changed what's possible.
"Performance is not a feature you add at the end. It's a consequence of every decision made throughout the process."
At the same time, the rise of JavaScript-heavy frameworks created a performance debt that the industry is still working through. Techniques like partial hydration, resumability, and islands architecture represent attempts to get the developer experience benefits of modern frameworks without paying the full JavaScript tax on initial page load.
Images and the Ongoing Challenge
Despite years of tooling improvements, images remain the largest source of performance problems on the web. The average webpage transfers over 1MB of image data — often far more. Modern image formats like AVIF and WebP offer dramatic size reductions over JPEG for equivalent quality, but adoption requires serving the right format to the right browser.
The <picture> element and the srcset attribute give us the tools to serve responsive images correctly. But the real challenge is workflow — ensuring that image optimization happens automatically as part of the build process, not manually as a developer afterthought. Frameworks and hosting platforms that handle this automatically have a meaningful advantage.
Measuring What Matters
Field data — performance measured in real users' browsers via the Chrome User Experience Report — consistently shows that lab-based performance testing can be misleading. A site that performs well on a high-end development machine with a fast fiber connection may perform dramatically differently for a user on a mid-range Android phone with a spotty 4G signal.
The shift toward measuring performance in the real world, not just in controlled lab environments, is one of the most important methodological changes in performance culture. Tools like RUM (Real User Monitoring) make this accessible. The principle is simple: you can only optimize what you measure, and you can only measure what you understand.
Tags
