Core Web Vitals Are a Design Problem, Not a Dev Problem

Core Web Vitals are measured in the browser, executed by developers, but caused by designers. Understanding which metric is caused by which design decision is the prerequisite for building sites that pass — not fix.

The Handoff Problem

Here is how Core Web Vitals failures typically happen. A designer produces a homepage. It has a large, full-bleed hero image, a custom display font loaded from an external CDN, a marquee animation that starts on page load, and a sticky header that slides in after 300 milliseconds. It looks exceptional in Figma.

The design is approved. A developer builds it faithfully. The site launches.

Three weeks later, someone runs a PageSpeed Insights audit and the site fails all three Core Web Vitals. Largest Contentful Paint is 5.2 seconds. Cumulative Layout Shift is 0.28. Interaction to Next Paint is 480 milliseconds.

The developer is asked to fix it. They optimize the image, defer some scripts, add a font-display swap. The scores improve marginally. But the hero image is still enormous, the custom font still shifts the layout on load, and the marquee animation still blocks interaction. The design decisions set the ceiling. The developer can optimize within that ceiling, but they cannot raise it.

This is the handoff problem. Core Web Vitals are measured in the browser, executed by developers, but caused by designers. Understanding which metric is caused by which design decision is the prerequisite for building sites that pass — not fix.

The Three Metrics

Google’s Core Web Vitals consist of three metrics, each measuring a distinct dimension of user experience. All three are included in Google’s Page Experience ranking signal. All three are reportable in Google Search Console, PageSpeed Insights, and CrUX (Chrome User Experience Report) data.

1. LCP —The Largest Contentful Paint

Largest Contentful Paint measures the time from page navigation to when the largest visible element in the viewport is fully rendered. In most designs, this element is a hero image, a hero video poster frame, or a large above-the-fold heading. In almost every case, it is determined by the designer before a single line of code is written.

What triggers a poor LCP score

LCP fails primarily for three design-originated reasons:

1. Oversized hero images

A full-bleed hero image that looks clean at 1440px wide in Figma is typically exported as a file several megabytes in size. A developer who builds it, without specific optimization instructions, will serve that file to every device.

On a mobile connection, that image can take four to eight seconds to load.

The design decision is the file. The developer can compress it, serve it in modern formats like WebP or AVIF, and implement responsive srcset attributes to deliver appropriately sized versions to different screen widths. But if the design calls for a 2400px-wide photographic hero image above the fold on every page, LCP will be a permanent negotiation rather than a solved problem.

2. Render-blocking custom fonts

Custom web fonts are one of the most common sources of LCP degradation that originates entirely in a design choice. When a browser encounters a page that uses a custom font, it must fetch the font file before it can render any text using that font. If the largest contentful element is a heading set in a custom display typeface — which is common in brand-forward designs — LCP is gated on the font download.

The developer’s mitigation is font-display: swap, which renders the text in a fallback font immediately and swaps to the custom font when it loads. This helps LCP but causes a visible flash of unstyled text (FOST) and contributes to CLS (covered below). The only real solution is to either preload the font, self-host it (eliminating a third-party request), or make the design work with a system font stack for body and heading text.

3. Above-the-fold videos and embeds

Autoplay background videos, YouTube embeds, and above-the-fold iframes create severe LCP problems. A background video that starts above the fold will be treated as a potential LCP element. Video files are large, third-party embeds involve additional DNS lookups and connection overhead, and iframes can block main thread processing.

The design decision to use a background video above the fold is effectively a decision to accept a poor LCP score unless the implementation is engineered with significant additional effort: lazy-loaded poster images, facade patterns for third-party embeds, and explicit LCP element prioritisation via fetchpriority attributes.

2. CLS — Cumulative Layout Shift

Cumulative Layout Shift measures visual instability: the degree to which page elements shift position unexpectedly as the page loads. It is one of the most direct measures of user experience quality in the browser, and it is almost entirely caused by design and development decisions that share a common root — failing to reserve space for content before it loads.

CLS issues mainly arise from:

1. Images without declared dimensions

This is the most common cause of CLS and the most straightforwardly preventable. When a browser encounters an <img> element with no width and height attributes, it cannot reserve space for the image in the layout until the image file has been downloaded and its dimensions are known. While the image loads, the browser renders the surrounding content. When the image loads, the layout shifts to accommodate it, pushing everything below the image downward.

<!-- Causes CLS: browser doesn't know image height until it loads -->
<img src="hero.jpg" alt="Hero image" />
<!-- Prevents CLS: browser reserves exact space in advance -->
<img src="hero.jpg" alt="Hero image" width="1200" height="600" />

The fix is trivial from a development perspective: add width and height attributes to every image. But the fix requires knowing the image dimensions at design time, which means the design spec must include explicit image dimensions for every image in the layout. Designs that use flexible image containers without specified aspect ratios create systematic CLS.

2. Web fonts and layout shift

When “font-display: swap” is used (as it commonly is for LCP mitigation), the browser renders text in a fallback font, then swaps to the custom font when it loads. The fallback font almost certainly has different metrics — different line heights, different character widths, different word wrapping behaviour. When the swap occurs, text reflows. Headings that were three lines become two. Paragraphs that fitted a container overflow it. The layout shifts.

The CLS impact of font swapping is proportional to how different the fallback font is from the custom font. Designers who choose display typefaces that are very different from system fonts — condensed typefaces, extended typefaces, typefaces with unusual x-heights — create larger layout shifts on font load than designers who choose typefaces closer to the system font stack.

The most robust solution is the CSS size-adjust descriptor, which allows developers to adjust the metrics of the fallback font to closely match the custom font, minimising the reflow on swap. But this requires careful calibration against the specific typeface, and the calibration work is invisible to the design process unless designers and developers discuss it explicitly.

3. Dynamically injected content

Any content that is injected into the page after initial render — banners, cookie notices, chat widgets, newsletter popups, dynamic content blocks loaded via API — causes CLS if it is inserted above or near existing content. A cookie banner that slides in above the main content area and pushes the page down is a classic CLS source. A hero section that loads a dynamic promotional message after the static content has rendered is another.

The design decision is where dynamic content goes and how it enters. Content injected at the top of the page causes more CLS than content injected at the bottom. Content that expands in place causes more CLS than content that slides in from outside the viewport. These are design choices, not implementation details.

3. INP — Interaction to Next Paint

Interaction to Next Paint is the newest and most demanding Core Web Vital. It measures the latency between a user input — a click, a tap, a keyboard event — and the next frame the browser paints in response. Unlike its predecessor (First Input Delay, which only measured the delay before the browser began processing an interaction), INP measures the full round-trip: input received to visual response delivered.

A poor INP score means the site feels sluggish and unresponsive. Users click buttons that appear not to register. Dropdowns hesitate before opening. Forms feel slow to submit. This is one of the highest-impact UX failure modes and it is, again, largely a design problem that developers are asked to solve after the fact.

Animation complexity and main thread blocking

CSS animations that run on the compositor thread (transform and opacity) are smooth and do not affect INP. Animations that trigger layout recalculation — animating width, height, top, left, padding, margin — run on the main thread and can block interaction processing.

A designer who creates an animation by interpolating the width of an element, or animating the position of an element using top/left values rather than transform: translate(), has created a main thread animation. At a low frame count or on a fast device, this may be invisible. On a mid-range Android device processing a complex page, it can cause INP failures.

Heavy interactive components

Modals, mega-menus, accordions, carousels, and other complex interactive components are design decisions. Their visual behaviour determines their implementation complexity. A modal that requires the page to calculate the position of every element in order to trap focus and apply an overlay is more expensive to process than a modal that uses a fixed-position overlay with no layout dependency.

The weight of an interactive component’s event listener is directly proportional to what the designer has asked it to do. A click handler that triggers a CSS class change is lightweight. A click handler that triggers layout recalculation, an API call, a state update, and a re-render of a complex component subtree is heavy. Designers who specify complex interactive behaviours should do so knowing that the interactivity has a processing cost, and that cost appears in INP.

Third-party scripts from design decisions

Chat widgets, social share buttons, live review feeds, promotional countdown timers — these are almost always design decisions, specified in wireframes and mockups as features without reference to their performance cost. Third-party Javascripts are one of the leading causes of INP failure because they execute on the main thread, compete with interaction processing, and are outside the developer’s control once loaded.

A page that loads three or four third-party scripts from design-specified features — a chat widget, an analytics tool, a cookie consent manager, a social embed — is running a significant main thread workload before any user interaction occurs. Every millisecond of that workload extends the potential INP of the next interaction.

The Design-to-CWV Impact Reference

The table below maps the most common design decisions to their Core Web Vitals consequence and the resolution approach. It is intended as a reference for design reviews and cross-discipline project kickoffs.

The Performance Budget Conversation

The structural fix for CWV failures that originate in design is a performance budget: an agreed set of constraints defined before design begins that limits the performance cost of design decisions. A performance budget is not a development constraint. It is a design brief.

What a performance budget covers

• Maximum page weight (total bytes transferred): typically 1–2MB for a content page, ≤3MB for a feature-heavy landing page
• Maximum number of third-party scripts: a concrete limit, not a guideline
• LCP target: agreed at the design stage for the primary LCP element
• Font loading strategy: which fonts are used, how they are loaded, what the fallback strategy is
• Image format and dimension conventions: WebP/AVIF only; all images must have declared dimensions
• Animation constraints: no main-thread animations; all transitions must use transform or opacity

When to have this conversation

The performance budget conversation must happen before wireframing begins, not during QA. Once a design has been approved and development has started, changing performance-impacting decisions requires either reverting approved design work or accepting permanent score compromise.

The most efficient workflow: the performance budget is set in the project brief, signed off by the designer and developer jointly, and treated as a non-negotiable constraint alongside brand guidelines and accessibility requirements. Any design decision that would violate the budget — a new third-party script, a heavier hero treatment, a complex animation — requires an explicit budget amendment, not a silent addition.

Conclusion: Performance is a Design Value

The discipline that most consistently determines Core Web Vitals outcomes is design. Not because designers are careless with performance — most are simply never asked to think about it. Performance budgets are not part of the standard design brief.

CWV consequences are not listed next to design components in Figma. The handoff from design to development is a one-way document, not a dialogue.

The sites that consistently score well on Core Web Vitals are not the ones with the most capable developers. They are the ones where performance is treated as a design value from the first wireframe: where the LCP element is specified with its load strategy, where font choices come with fallback strategies, where dynamic content has reserved space, where animation specs reference the compositor thread.

That requires a change not in tooling but in conversation. Performance is not a post-launch audit. It is a brief-stage decision. Build it into the design process, and the developer’s job becomes implementation rather than remediation.

Oladoyin Falana

Founder, Technical Analyst

Oladoyin Falana is a certified digital growth strategist and full-stack web professional with over four years of hands-on experience at the intersection of SEO, web design & development. His journey into the digital world began as a content writer — a foundation that gave him a deep, instinctive understanding of how keywords, content and intent drive organic visibility. While honing his craft in content, he simultaneously taught himself the building blocks of the modern web: HTML, CSS, and React.js — a pursuit that would eventually evolve into full-stack Web Development and a Technical SEO Analyst.

Follow me on LinkedIn →