Core Web Vitals: Measure the Experience, Not Just the Build Size

A smaller JavaScript bundle can help performance, but it is not the same as a fast user experience. A page may download quickly and still delay its main content, ignore a click while running a long task, or move the checkout button as an image loads. Core Web Vitals describe different aspects of that experience. Largest Contentful Paint concerns loading, Interaction to Next Paint concerns responsiveness, and Cumulative Layout Shift concerns visual stability. Each points to a different class of work. ## Separate field data from a lab run Lab tools provide a controlled environment for finding causes and comparing changes. Field measurements reflect actual visitors with different devices, connections, and usage patterns. A fast development laptop can hide main-thread work that makes a lower-powered phone feel unresponsive. A synthetic page load also does not capture every interaction a user performs after arrival. Segment measurements by meaningful dimensions such as page type and device category. Avoid logging personal data in performance events. A site-wide average can conceal a slow product detail page or a particularly costly signed-in route. ## Diagnose the metric that is actually weak For slow largest-content loading, inspect server response time, resource discovery, image delivery, and rendering dependencies. The main image cannot load promptly if the browser learns its URL only after unnecessary client-side work. For poor responsiveness, examine long tasks, expensive event handlers, rendering work, and third-party scripts. Moving work out of the initial bundle may not help if it still blocks the main thread exactly when someone clicks. For layout instability, reserve dimensions for images, embeds, and dynamic regions. Avoid inserting unexpected content above what the user is reading. A loading skeleton should approximate the final layout rather than introduce another large shift. ## Set a budget around a real journey Choose representative flows: opening an article, filtering a tool list, or submitting a form. Measure both the initial view and the interaction that matters. Make one targeted change and compare equivalent measurements. A better laboratory score is encouraging, but check whether field data improves after enough real visits. Low-traffic pages may not produce reliable public field reports. Do not optimize by removing useful accessibility cues, hiding content from users, or delaying errors until the metric stops measuring. The objective is usable speed, not a dashboard number detached from the product. Performance work becomes easier to prioritize when each change has a stated user benefit. “The filter responds promptly on a midrange phone” is a more useful goal than “reduce JavaScript at any cost.” ## Further reading - [web.dev: Web Vitals](https://web.dev/articles/vitals) - [web.dev: Optimize Interaction to Next Paint](https://web.dev/articles/optimize-inp)