Google measures user experience now. They have numbers for it.
Core Web Vitals quantify what used to be subjective. “The page feels slow” becomes “LCP (Largest Contentful Paint) is 4.2 seconds.” “The layout jumps around” becomes “CLS (Cumulative Layout Shift) is 0.35.” “The buttons don’t respond” becomes “INP (Interaction to Next Paint) is 450 milliseconds.”
These metrics affect search rankings. Sites with poor Core Web Vitals may rank lower than competitors with better scores. The business case for caring about performance is explicit and measurable.
Design decisions influence all three metrics. What you put on the page, how you load it, and how interactions behave determine the numbers.
Largest Contentful Paint
LCP measures when the largest visible content element finishes loading.
Usually this is the hero image or the headline text block. Whatever dominates the above-fold viewport determines the LCP element.
A 2.5-second LCP is good. Between 2.5 and 4 seconds needs improvement. Above 4 seconds is poor.
What hurts LCP: enormous hero images, heavy web fonts, complex animations that delay rendering, unoptimized video backgrounds.
What helps LCP: appropriately sized images, preloaded critical resources, system fonts or optimized web fonts, simple above-fold content that renders quickly.
The tradeoff is real. That beautiful full-screen hero video costs LCP. The custom web font in six weights costs LCP. Design ambitions bump against performance reality.
Resource hints help. Preloading the LCP image tells browsers to fetch it early. Preconnecting to CDN domains eliminates connection setup delay. These technical optimizations can recover some LCP lost to design choices.
Interaction to Next Paint
INP measures responsiveness. When users tap or click, how long before the page responds?
The metric captures the worst interaction during the session, giving a picture of overall responsiveness rather than just initial load.
Under 200 milliseconds is good. Between 200 and 500 milliseconds needs improvement. Above 500 milliseconds is poor.
Heavy JavaScript hurts INP. Complex animations that block the main thread. Unoptimized scroll handlers. React components that re-render too broadly. When JavaScript dominates, the browser can’t respond to user input quickly.
What hurts INP: interactions that trigger heavy computations, excessive animations during scroll, complex state changes on every keystroke, third-party widgets that hijack the main thread.
What helps INP: simple interactions with minimal JavaScript, debounced input handlers, animations using CSS rather than JavaScript, lazy loading of heavy interactive components.
Cumulative Layout Shift
CLS measures visual stability. When elements move unexpectedly as the page loads, users get disoriented. Clicks land on wrong targets. Reading position gets lost.
Under 0.1 is good. Between 0.1 and 0.25 needs improvement. Above 0.25 is poor.
The most common CLS culprits are images and embeds without specified dimensions. The browser doesn’t know how much space to reserve. Content shifts when the media loads.
What causes CLS: images without size attributes, dynamically injected content above existing content, fonts that swap with different metrics, ads that load late and push content down.
What prevents CLS: always specifying image dimensions, reserving space for dynamic content, using font-display strategies that minimize reflow, loading ads in fixed-size containers.
Think about temporal sequence. The page doesn’t appear all at once. What loads first? What loads later? If later-loading elements push around earlier-loading elements, CLS happens.
Tradeoffs Are Inevitable
Perfect performance and maximum design ambition rarely coexist.
Tradeoffs exist regardless. It’s which tradeoffs are worth making.
A visually stunning hero section that costs 1 second of LCP might be worth it for a brand-focused site. The same tradeoff might be wrong for an ecommerce site where every second of delay costs conversions.
Context determines the right balance. Performance budgets make the balance explicit. “We have 2.5 seconds of LCP budget” enables informed decisions.
Measurement Matters
Lab data shows controlled performance. Tools like Lighthouse run synthetic tests in standardized conditions.
Field data shows real user experience. Real User Monitoring captures actual performance across diverse devices, connections, and conditions.
Lab and field data often differ. Your fast office connection doesn’t represent users on slow mobile networks. The fast test device doesn’t represent budget phones your audience actually uses.
Optimize for field data, not the lab. Use lab tools for quick feedback during development. Rely on field data to understand actual user experience.
Third-Party Impact
Analytics scripts, chat widgets, ad networks, social embeds. Third-party code runs on your page but you don’t control it.
Third parties frequently destroy performance. They load synchronously when they should load asynchronously. They block the main thread. They cause layout shifts.
Choosing which third parties to use. “We want a chat widget” becomes a performance decision when that widget adds 500KB of JavaScript.
Audit third-party impact regularly. Tools like WebPageTest show which resources cost the most. Some third parties justify their cost through genuine value. Others could be replaced with lighter alternatives or removed entirely.
Loading strategies help manage impact. Defer third-party loading until after critical content. Lazy load widgets not immediately needed. Use facade patterns showing static placeholders until users interact.
Performance Budgets As Constraints
Performance budgets make constraints explicit.
Define acceptable limits: total JavaScript under 200KB, total images under 500KB, LCP under 2 seconds, INP under 150ms.
Design against those budgets. If the image budget allows 500KB and the hero image alone is 400KB, only 100KB remains for everything else below the fold.
Budgets force prioritization. Every visual flourish that adds weight trades against something else. The budget makes tradeoffs visible and decisions intentional.
Enforce budgets through tooling. Build processes can fail when budgets exceed limits. CI checks can block deployment of performance regressions. Automated enforcement prevents gradual degradation.
Designer-Developer Communication
Performance concerns need early involvement in the design process.
By the time design is finalized and approved, changing it for performance reasons faces resistance. Include performance considerations in design review from the beginning.
Concrete metrics beat vague complaints. “This will hurt performance” is easy to dismiss. “This hero video will likely push LCP above 4 seconds, affecting SEO” is specific and actionable.
Show data from similar implementations. “Sites with comparable hero videos have these Core Web Vitals scores” provides evidence rather than opinion.
Alternatives help discussions progress. “We can’t have that” creates conflict. “We could achieve similar visual impact with this lighter approach” offers solutions and collaboration.
Performance Budgets
Arbitrary limits become concrete constraints.
A performance budget might specify: total JavaScript under 200KB, total images under 500KB, LCP under 2 seconds.
Budgets force prioritization. Everything can’t be important. The budget makes you choose what matters most.
FAQ
Our Core Web Vitals are bad but our site ranks well. Do we really need to worry?
Vitals are one ranking factor among many. Strong content and backlinks can overcome poor vitals. But competitors with similar content quality and better vitals may edge ahead. Also, vitals affect user experience regardless of rankings. Users leave slow, janky sites.
We can’t change our hero video. What else can we optimize?
Everything else. Ensure the video is compressed optimally. Lazy load below-fold content. Optimize fonts, defer non-critical JavaScript, preconnect to CDN. You may not hit green vitals with a heavy hero, but you can minimize the damage.
Stakeholders ignore Core Web Vitals. Convincing arguments about Core Web Vitals?
Connect to business metrics. Show correlation between page speed and conversion rates. Highlight SEO implications. Calculate potential revenue impact from conversion changes. Performance becomes a business conversation rather than a technical one.
Sources
Web.dev. Core Web Vitals. web.dev/vitals
Google Search Central. Page Experience. developers.google.com/search/docs/appearance/page-experience
Chrome Developers. INP Guide. developer.chrome.com/docs/crux/inp
WebPageTest. webpagetest.org
Calibre. Performance Budgets. calibreapp.com/blog/performance-budgets