Answer 31 of 50
How Core Web Vitals Should Shape Design Decisions and Priorities
Let field data set the priority, then judge each design decision by which part of which metric it moves. A hero video, a web font, or a cookie banner is not “bad for performance” in general; each one affects a specific phase of Largest Contentful Paint, Interaction to Next Paint, or Cumulative Layout Shift, and the fix depends on which phase is slow on your site.
The three metrics and how they are judged
| Metric | What it measures | Good | Poor |
|---|---|---|---|
| Largest Contentful Paint (LCP) | When the largest image, text block, or video in the viewport renders | 2.5 seconds or less | More than 4 seconds |
| Interaction to Next Paint (INP) | How quickly the page responds to clicks, taps, and key presses | 200 milliseconds or less | More than 500 milliseconds |
| Cumulative Layout Shift (CLS) | How much visible content moves unexpectedly | 0.1 or less | More than 0.25 |
Values between good and poor need improvement. The thresholds come from web.dev’s pages on LCP, INP, and CLS. Two details change how you read them. Google’s Core Web Vitals overview says “a good threshold to measure is the 75th percentile of page loads, segmented across mobile and desktop devices”, so a page passes only if three quarters of real visits meet the target. And all three metrics are measured on real visits, which is why a design that looks fast on the designer’s laptop can fail in the field.
Pick the priority from field data
Search Console’s Core Web Vitals report groups similar URLs and gives each group the status of its worst metric, separately for mobile and desktop. PageSpeed Insights shows the same kind of field data for a single URL. Use them to decide the order of work:
- Find the URL groups that matter most to the business, such as the templates where people convert.
- Note which metric puts each group into “Poor” or “Need improvement,” and on which device.
- Fix that metric on that template first, even if another metric looks worse on a page nobody visits.
- Judge each new design proposal against the metric that is currently weakest.
Why the business case for this work holds, and how weak some of the popular speed statistics are, is covered in how page speed shapes user behavior and conversion rates.
LCP: which design decision moves which part
web.dev’s guide to optimizing LCP breaks every LCP time into four subparts with “no overlap or gap between them”:
| Subpart | What it is | Design and build decisions that affect it |
|---|---|---|
| Time to First Byte | Until the browser receives the first byte of HTML | Hosting, caching, server-side rendering, redirects |
| Resource load delay | From first byte until the LCP image or font starts downloading | Whether the hero image is in the HTML or injected by script; CSS background images; lazy loading the hero by mistake |
| Resource load duration | How long the LCP resource takes to download | Image dimensions, format, compression, web font file size |
| Element render delay | From download finished until the element appears | Render-blocking CSS and scripts, font loading behavior, client-side rendering |
The subparts explain why some fixes do nothing. The same guide notes that “Shortening the resource load duration increases the element render delay without reducing LCP” when something else is blocking the render, so compressing the hero image further helps only if its download was the slow part. When it is, format and sizing choices are covered in choosing SVG, PNG, or another image format and preparing images for retina and high-resolution displays.
Three decisions come up in redesigns:
- The hero image. Keep it as an image element in the HTML rather than a CSS background where you can, and mark it as the priority. web.dev’s article on Fetch Priority describes setting
fetchpriority="high"on the LCP image so it loads sooner, and notes that a preload is still needed for an LCP image set as a CSS background. - The hero video. web.dev’s LCP definition counts a video by its poster image load time or its first frame, whichever is earlier, so a lightweight poster image is the lever even when the video itself stays.
- Third-party domains. A preconnect hint “informs the browser that your page intends to establish a connection to another domain,” according to web.dev’s resource hints article. It starts the connection early rather than removing it, and the same article warns that unnecessary preconnecting can delay other important resources, so use it for the one or two domains the first screen depends on.
INP: where interactions lose time
web.dev’s guide to optimizing INP splits each interaction into three parts: the input delay before event handlers start, the processing time of the handlers, and the presentation delay before the next frame appears. INP then reports “the longest interaction observed, ignoring outliers” across the visit. Scrolling and hovering are not measured, though a tap made during a heavy scroll animation can still be delayed by it.
Design decisions that lengthen those phases:
| Phase | Design decisions that lengthen it |
|---|---|
| Input delay | Heavy scripts, including third-party tags, running when the visitor taps |
| Processing | Filters, search-as-you-type, or menus that recalculate large parts of the page on each input |
| Presentation | Large layout changes after an interaction, such as re-rendering a whole product grid to open one panel |
Ask for the lighter interaction in the design itself: open a panel without rebuilding the page around it, and debounce typing instead of searching on every keystroke.
CLS: reserve the space before content arrives
web.dev’s guide to optimizing CLS lists these causes: images without dimensions; ads, embeds, and iframes without dimensions; content injected dynamically without dimensions; and web fonts. Each has a design-side answer:
<!-- Width and height let the browser reserve space before the image loads -->
<img src="team.jpg" width="1200" height="800" alt="Our support team at work">/* Reserve a fixed slot for an ad or embed so it cannot push content down */
.ad-slot { min-height: 250px; }Banners that slide in above existing content, such as a promotion bar or cookie notice inserted at the top after load, shift everything below them. Put them in reserved space or overlay them without moving the page.
Third-party features
Chat widgets, video embeds, review carousels, and tag managers add script you do not control. Chrome’s Lighthouse documentation describes lazy loading third-party resources with facades: a facade “is a static element that looks similar to the embedded” content and loads the real thing only when the visitor interacts. For a chat widget, a static button that loads the widget on click is the facade version. Treat each third-party feature as a design decision with a cost in INP and LCP, and remove the ones nobody uses.
Performance budgets tied to your weakest metric
A performance budget is a limit agreed before design starts, such as a maximum LCP at the 75th percentile or a ceiling on JavaScript for a template. Set the numbers from your own field data and the template’s role rather than copying another site’s, and check them automatically in the build so a new feature cannot push a template past the limit unnoticed. When a design idea would break the budget, the conversation becomes which existing element gives way.
Google’s page experience documentation also sets expectations for search: “Google Search always seeks to show the most relevant content, even if the page experience is sub-par.” Core Web Vitals are worth fixing for visitors first; they will not make up for a page that does not answer the query.
Read the field data, fix the weakest metric on the template that matters most, and bring the metric’s name and subpart into every design review where a new hero, widget, or animation is proposed.