Design · · 4 min read

Most decisions that make a website slow are made in the design phase. A plain guide to LCP, INP and CLS, and the design choices that move each one.

Founders usually treat website speed as an engineering task, something to fix after the design is signed off. By then, most of the decisions that determine speed have already been made. The hero video, the font choices, the carousel, the chat widget, the analytics stack: each is a design decision with a performance cost. Speed is part of the design brief, or it becomes a recurring argument.

What Core Web Vitals measure

Core Web Vitals are Google's metrics for real-world user experience. They are measured from actual visitors using Chrome, not only in lab tests, and they form part of Google's page experience signals. There are three.

Largest Contentful Paint (LCP)

How long it takes for the largest visible element, usually a hero image or headline, to render. Google considers 2.5 seconds or less to be good. LCP is what a visitor feels as the answer to one question: has the page loaded?

Interaction to Next Paint (INP)

How quickly the page responds visually after a tap, click or key press, measured across the whole visit. 200 milliseconds or less is good. INP replaced First Input Delay in 2024 and is the metric most affected by heavy JavaScript.

Cumulative Layout Shift (CLS)

How much content jumps around while the page loads. A score of 0.1 or less is good. CLS is the reason you sometimes tap the wrong button because an image or banner loaded above it a moment earlier.

Google assesses each metric at the 75th percentile of page loads. A page passes only if most visitors get a good experience, not just those on fast connections and new phones.

Design choices that decide LCP

The hero section is usually the LCP element. What you put there matters more than any optimisation applied later.

  • A large background video delays LCP on most mobile connections. A well-compressed still image, with motion added after load, usually serves better.
  • Text headlines can render almost immediately if the font loads quickly. Limit display fonts to one or two weights and self-host them.
  • Hero images should be sized for the viewport, served in modern formats such as AVIF or WebP, and loaded with priority.
  • Sliders and carousels in the hero hide the real content behind JavaScript. Pick one strong message instead.

Design choices that decide INP

INP suffers when the browser's main thread is busy running scripts while the visitor tries to interact. Most of that script is added for design and marketing reasons, not for the product itself.

  • Every third-party tag, chat widget, heatmap tool and social embed competes for the main thread.
  • Scroll animations driven by JavaScript can block input if they are built carelessly.
  • Large client-side frameworks rendering content that could have been static HTML add work on every page view.

Ask of each script what it earns. Then ask whether it could load later, only after consent, or only on the pages that genuinely need it.

Design choices that decide CLS

Layout shift is almost always a sign that space was not reserved for something.

  • Images and videos without set dimensions.
  • Cookie banners and promotional bars that push content down instead of overlaying it.
  • Web fonts that swap in with very different metrics from the fallback font.
  • Ads and embeds injected into the content flow after the page has rendered.

The fix is a design habit: decide the size of every element before its content arrives.

Why this matters beyond rankings

Core Web Vitals are one ranking signal among many, and relevance still matters more. The stronger reason to care is commercial. A slow page asks every visitor for patience before showing them anything. Visitors on mobile networks with uneven coverage feel this most, and in many markets that describes a large part of the audience. A fast site is also cheaper to run, simpler to maintain and easier to use with assistive technology.

Every element on a page should justify its weight. That is a design principle, not a technical one.

A short brief for your next redesign

  1. Set targets in the brief: LCP under 2.5 seconds, INP under 200 milliseconds and CLS under 0.1, on a mid-range phone over 4G.
  2. Review the hero for speed before approving it visually.
  3. Agree a limit on typefaces, weights and third-party scripts.
  4. Supply images at proper resolution so they can be compressed and sized automatically.
  5. Test on real devices, not only on a designer's laptop over office Wi-Fi.
  6. Monitor field data after launch through Google Search Console or a real-user monitoring tool.

Fast and beautiful are not opposites

Ambitious design and good performance can coexist. Motion can run on transform and opacity, which browsers handle efficiently. Heavy visual moments, such as 3D scenes, can load only when scrolled into view and fall back to a still image on low-powered devices. Typography can carry a page that would otherwise lean on imagery. The constraint sharpens the work rather than dulling it.

At Foxbeta we set a performance budget at the start of every design project, because that is the only point at which it is cheap to keep.

About the author

The engineers and designers at Foxbeta, a product studio in Imphal, Manipur, building software for clients in India, the Gulf, Europe, the USA and Australia. We write about the decisions we see clients face, based on the work we do every week.

FAQ

Do Core Web Vitals directly affect Google rankings?
They are part of Google's page experience signals, so they do count, but relevance and content quality carry more weight. Treat good vitals as a baseline that stops speed from holding a strong page back.
Why does my PageSpeed score differ from my Search Console report?
PageSpeed Insights runs a lab test on one simulated device, while Search Console reports field data from real Chrome visitors over the previous 28 days. Field data is what Google uses for assessment.
Can a site with rich animation still pass Core Web Vitals?
Yes. Animate transform and opacity rather than layout properties, keep text in the HTML from the first render, load heavy scenes lazily and reserve space for every element. Motion then adds very little cost.

What happens next

  1. 01

    We reply within one working day

    A real person, with first questions about your goals.

  2. 02

    We clarify scope and constraints

    A short call about users, timelines, budget and risks.

  3. 03

    You get a written proposal

    Scope, team, timeline and a fixed or monthly price.

  4. 04

    We start building

    Kickoff within the week, a shared board and weekly demos.

Start a project

Bring the idea. We bring the team that ships it.