red paintbrush resting on open paint can

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

Cliftoncreative.agency

The Core Web Vitals report goes to the developer.


This is the default. CWV is a technical metric — Largest Contentful Paint, Cumulative Layout Shift, Interaction to Next Paint — measured in milliseconds and pixels, and it comes from Google Search Console, which the developer manages.

So the developer gets the report and works through it. They optimize images. They defer render-blocking scripts. They reduce server response times. They make real progress.

And then the marketing team launches a new hero section with a 4MB PNG and a custom font loading in the header, and the scores drop back to where they were.

The developer’s problem was, in most cases, a design and editorial problem wearing technical clothes.

What CWV actually measures

Core Web Vitals measures the user experience of loading and interacting with your pages. LCP measures how long it takes for the main content element to appear — the hero image, the headline, the above-the-fold block. CLS measures how much the page shifts while loading — elements jumping around as images load and fonts swap in. INP measures how responsive the page is to user interaction.

These are experience metrics. They’re not measuring whether your code is clean or your server is fast. They’re measuring what it’s like to be a reader on your site.

And the experience of being a reader is determined by decisions made by designers and editors, not developers. The decision to use a full-bleed hero image is a design decision. The decision to load three custom fonts is a brand decision. The decision to put a cookie consent popup and a newsletter modal above the fold is a content strategy decision. Each of these decisions has a CWV cost.

The design decisions that destroy LCP

LCP is almost always hurt by images — specifically, large images that are above the fold and not optimized for web delivery.

The hero image is the most common culprit. Designers create beautiful hero images at full resolution, optimized for the design tool’s preview. Those images get uploaded to WordPress at the same resolution. A 3200×2000 pixel PNG that was designed to look good at 100% zoom is now being served to every page visitor, scaled down in the browser, consuming download time that delays LCP.

This is content technical debt created in the design process. The decision that created the debt was aesthetic, not technical. Fixing it requires a conversation between design and performance — a conversation that often doesn’t happen because the developer is handed the problem alone and the designer isn’t in the room.

The branding decisions that destroy FCP

Custom fonts are the LCP problem for FCP — First Contentful Paint, the first element that appears on screen.

Every custom font is a network request. Every custom font also creates a rendering dependency: the browser can’t display the text until the font loads, so it either shows a blank space (flash of invisible text) or shows the fallback font before swapping (flash of unstyled text). Either creates a visible, jarring experience for the reader.

Most sites load three to five custom fonts. Some load more. Each one was a branding decision: this font family, these weights, this balance of serif and sans. None of those decisions included a performance budget.

What a performance budget is

A performance budget is a design constraint: you have X milliseconds for LCP, which means you have Y kilobytes for the hero image, which means the image has to be optimized to those dimensions before it goes near WordPress.

Most design processes don’t have performance budgets. Most brand guidelines don’t specify maximum font file sizes. Most content publishing workflows don’t include image optimization as a step.

The content publishing checklist is where performance gets added to the editorial workflow. Every post, every new design element, every updated hero should go through a performance check before it goes live. That check doesn’t require technical expertise — it requires someone with editorial authority saying “we don’t publish pages that fail CWV thresholds.”

Why this matters for editorial teams

Google uses Core Web Vitals as a page experience ranking factor. A page that loads poorly is, all else being equal, a page that ranks below a comparable page that loads well. The SEO work done on every other dimension — the keyword research, the content quality, the schema, the internal linking — is undermined if the page experience is poor enough to trigger a performance penalty.

The developer can optimize what’s already there. They can’t prevent the next large image from being uploaded, the next font from being added to the brand guidelines, the next modal from being inserted above the fold.

Only the editor can do that. Only the person with authority over what gets published can make performance a publishing standard rather than a technical cleanup task.


What are Core Web Vitals?

Core Web Vitals are Google’s three primary page experience metrics: Largest Contentful Paint (LCP) measures how long the main content element takes to appear — under 2.5 seconds is good; Cumulative Layout Shift (CLS) measures visual instability as the page loads — under 0.1 is good; Interaction to Next Paint (INP) measures how quickly the page responds to user input — under 200 milliseconds is good. These metrics are visible in Google Search Console and in PageSpeed Insights.

What causes LCP problems?

LCP is almost always caused by large, unoptimized images above the fold — particularly hero images uploaded at full design resolution rather than compressed for web delivery. Other causes: render-blocking JavaScript that delays the largest element from appearing, slow server response times, and custom fonts with no fallback that cause the headline to remain invisible until the font loads. The hero image is the most common culprit and the easiest fix.

How do custom fonts affect page speed?

Every custom font is an additional network request that must complete before the browser can render text using that font. During loading the browser either shows invisible text or a fallback font that gets replaced when the custom font arrives. Multiple custom fonts compound this effect. The fix is font-display: swap in the CSS, preloading critical fonts, and using variable font files where available to reduce the number of separate font file requests.

Are Core Web Vitals a ranking factor?

Yes. Google confirmed Core Web Vitals as a ranking signal as part of the Page Experience update. They’re not the dominant ranking factor — content relevance and authority still outweigh them — but on pages competing closely on other signals, CWV scores can be a tiebreaker. More practically, poor CWV directly affects bounce rate and engagement: a page that takes four seconds to show its main content loses readers before the content has a chance to demonstrate its quality.

Jacob Clifton is the principal of Clifton Creative, an editorial strategy consultancy based in Austin, Texas. He spent fourteen years as a flagship staff writer at Television Without Pity and has written for Tor.com, Vulture, BuzzFeed News, and the Austin Chronicle.

For inquiries:
jacob@cliftoncreative.agency · Book a discovery call

This post is part of the Clifton Creative guide to SEO for content teams.

Jacob Clifton is the principal of Clifton Creative, an editorial strategy consultancy based in Austin, Texas. He spent fourteen years as a flagship staff writer at Television Without Pity and has written for Tor.com, Vulture, BuzzFeed News, and the Austin Chronicle.
For inquiries: jacob@cliftoncreative.agency · Book a discovery call