A website can look excellent in Figma and still feel slow, jumpy, or frustrating when someone actually uses it. This is where Core Web Vitals become useful for designers. They are not just developer numbers that appear in PageSpeed Insights after the design is finished. Several decisions made during UX and visual design directly affect them.
This article is for UI designers, UX designers, product designers, web designers, and creative teams who want to understand performance without becoming performance engineers. We will break down the three current Core Web Vitals, what each one measures, which design choices influence it, and which improvements can often be made without buying a faster server or rewriting an entire website. The goal is simple: make performance part of design thinking before development starts.
Core Web Vitals Are User Experience Metrics, Not Just Speed Scores
Designers sometimes hear “Core Web Vitals” and immediately think of code, caching, hosting, JavaScript and technical audits. Those things matter, but the user’s experience is what the metrics are trying to describe.
Google’s current Core Web Vitals are Largest Contentful Paint (LCP), Interaction to Next Paint (INP), and Cumulative Layout Shift (CLS). INP replaced First Input Delay as a Core Web Vital in March 2024.
Each metric answers a different question.
| Metric | What it tells you | Good target |
|---|---|---|
| LCP | How quickly the main content becomes visible | 2.5 seconds or less |
| INP | How quickly the page responds to user interactions | 200 ms or less |
| CLS | How stable the layout remains while loading | 0.1 or less |
These thresholds are useful because they turn vague complaints such as “the website feels slow” into measurable problems.
LCP is about the first meaningful visual impression
Largest Contentful Paint measures when the largest content element in the viewport becomes visible. On many marketing websites, that element might be the hero image, a large heading, a poster image, or another prominent block.
This immediately gives designers something practical to think about.
Suppose your homepage has:
- A 2.5 MB hero image
- A large custom font
- A video background
- A headline that appears only after several scripts load
- Multiple decorative animations
The visual design may look impressive, but the browser has more work to do before the main content is ready.
A designer does not control all of that, but the design can create the conditions.
A hero section with a massive photographic background is a different performance problem from a hero section using a lightweight image, CSS gradient and text.
Google’s current web.dev guidance also warns against reducing LCP to “just optimize the image.” LCP can be affected by server response time, resource load delay, resource load duration and rendering delay.
INP is where interaction design meets performance
Interaction to Next Paint measures how quickly a page responds after a user interacts with it. It covers interactions such as clicking, tapping and typing, with the goal of representing how responsive the page feels during use.
This has a direct relationship with interface design.
Consider a filter panel on an e-commerce website. A user selects “Black,” and nothing visibly changes for half a second. The interface may eventually work, but the experience feels broken.
The problem could be JavaScript, rendering work, a third-party script or something else in the application. The designer does not necessarily fix the technical cause, but the designer can identify the interaction as important and define what feedback should appear.
Good interaction design gives the user a visible response:
- Selected state changes
- Loading state appears
- Button state updates
- Skeleton content appears where appropriate
- Error state is communicated
- Progress is visible when an action takes time
INP is therefore not simply “make buttons faster.” It is about the quality and responsiveness of the interaction loop.
CLS measures whether your design stays where users expect it
Cumulative Layout Shift measures unexpected movement of visible page content.
A classic example is reading an article when an image loads above the paragraph. The paragraph suddenly moves downward. You try to click a button and an advertisement appears, pushing the button away.
From a design perspective, this is a layout planning problem.
If an image has a known aspect ratio, the layout can reserve its space. If a component can contain dynamic content, its design should account for that variation. If a banner can appear, the surrounding layout should not depend on everything below it remaining fixed.
CLS is particularly interesting for designers because visual stability is closely connected to layout decisions.
What Designers Can Control Before Development Starts
You cannot fix every Core Web Vital problem in Figma. But you can prevent a surprising number of performance problems from being designed into the product.
The earlier performance constraints appear in the design process, the cheaper they usually are to address.
Start with the hero section
The hero is one of the most important design areas for LCP because it often contains the largest visible content.
A common design exercise is to place a full-width image behind a headline, overlay several decorative elements, add a video loop, and then animate everything on page load.
Instead, ask a different question:
What is the minimum visual content needed to communicate the page’s purpose immediately?
That might lead to:
- One optimized hero image
- A clear headline
- One supporting paragraph
- One primary action
- Minimal decoration
- No unnecessary entrance animation
This does not mean every website should become visually plain. It means the visual hierarchy should have a reason.
You can still create strong art direction using composition, typography, cropping, contrast and whitespace rather than loading several large assets.
Treat images as design decisions
Image selection has a direct performance consequence.
A designer who exports a 4000-pixel photograph for a 700-pixel content area has made a performance decision, whether they intended to or not.
During design handoff, specify:
- Approximate display dimensions
- Aspect ratio
- Crop behaviour
- Whether the image is essential
- Whether it can be compressed
- Whether mobile needs a different crop
- Whether it is decorative or meaningful
The development team can then choose an appropriate image format, responsive image strategy and loading behaviour.
The same principle applies to icons. If a simple shape can be created with CSS or SVG, there may be little reason to use a large raster image.
Be careful with fonts
Typography is part of the brand, but fonts also affect loading and rendering.
A design system with six font weights and several font families creates more implementation work than a system using one family with three carefully selected weights.
That does not mean designers should eliminate custom fonts.
Instead, ask:
Does this typeface choice materially improve the interface enough to justify its implementation cost?
For many websites, a disciplined type scale with fewer weights creates a cleaner design and a lighter implementation.
LCP: Design the First Screen Around What Matters Most
LCP is often the metric designers understand most easily because it relates to what users see first. But improving it requires looking beyond image compression.
The current “good” LCP threshold is 2.5 seconds or less at the 75th percentile. A value above 4 seconds is considered poor.
Design the visual priority, not just the visual composition
Imagine two landing pages.
Design A
- Full-screen video background
- Large photographic overlay
- Animated logo
- Decorative particles
- Custom display font
- Three floating cards
Design B
- Static hero image
- Clear headline
- Short supporting text
- One CTA
- Two small supporting visual elements
Both can look premium.
But Design A creates more opportunities for slow resources and rendering work to interfere with the first meaningful visual experience.
This is why performance should enter the visual hierarchy discussion.
When reviewing a hero design, classify elements as:
Essential: The user needs this immediately.
Useful: It supports the message but can appear later.
Decorative: It improves atmosphere but is not necessary for comprehension.
The first viewport should give priority to the first category.
Give developers performance-friendly specifications
A Figma file usually describes how something should look. A stronger handoff also describes constraints.
For a hero image, for example:
Desktop: 1440 × 700 display area
Mobile: 390 × 600 display area
Image: photographic
Crop: focal point remains on subject
Priority: above-the-fold
Animation: none required for initial render
This does not tell the developer how to code the page. It gives them information needed to make sensible technical decisions.
That distinction matters.
Designers should not prescribe implementation unnecessarily. They should communicate the visual requirements that affect implementation.
Do not confuse Lighthouse with real user experience
A local performance test is useful, but it is not the same thing as knowing how real users experience the site.
Core Web Vitals can be measured in the field using real user data, including data represented through the Chrome User Experience Report. Google’s web performance guidance distinguishes field data from lab testing because real users operate across different devices, networks and conditions.
That means a page that looks excellent on a designer’s MacBook connected to fast broadband may behave differently on a mid-range phone using a slower mobile connection.
Design for the second situation too.
INP: Design Interactions That Feel Immediate
INP is the Core Web Vital most closely connected to interaction design. Its good threshold is 200 milliseconds or less, while values above 500 milliseconds are considered poor.
Designers do not usually control the JavaScript that causes slow interaction processing. They do control the interaction model and how much work an interaction asks the interface to perform.
Reduce unnecessary interaction complexity
A design can make a simple action technically expensive.
Consider a dashboard where changing one filter causes:
- A dropdown animation
- Five charts to update
- A table to re-render
- Multiple cards to recalculate
- A notification to appear
- A sidebar to resize
From the user’s perspective, they clicked one filter.
From the browser’s perspective, a lot may have happened.
A better design may separate the interaction:
- Change the filter immediately
- Update the most important content first
- Show loading feedback for slower sections
- Avoid unnecessary animations
- Keep unrelated components stable
The interface becomes easier to understand and potentially easier to process.
Design states before you design the happy path
Many interface designs only show the default state.
That is a mistake when thinking about performance.
For important interactions, define:
- Default
- Hover
- Focus
- Pressed
- Loading
- Success
- Error
- Disabled
- Empty
- Partial data
This gives developers a clearer implementation target.
It also forces designers to consider what the user sees when an operation cannot finish immediately.
A loading state is not a substitute for performance, but it can make unavoidable waiting understandable.
The important distinction is that feedback should not be used to hide a poorly designed interaction. If an action can respond instantly, it should.
Be careful with animation
Animation can communicate hierarchy, state and spatial relationships. It can also add work to an interaction.
For important controls, ask:
Does the animation communicate something?
If the answer is no, shorten it or remove it.
A button that takes 400 milliseconds to visually transition before the next interaction is possible may feel slower than a simple state change.
The same applies to menus, modals, accordions and filters.
Performance-minded motion design usually prioritizes:
- Short transitions
- Clear state changes
- Stable layout
- Minimal movement
- No unnecessary sequencing
The goal is not to eliminate motion. It is to make motion serve the interaction.
CLS: Make Layout Stability Part of the Design System
CLS is where small design decisions can create surprisingly annoying problems.
A good CLS score is 0.1 or less, while scores above 0.25 are considered poor.
Design fixed expectations for variable content
Real websites rarely contain perfectly predictable content.
A card may have:
- A short title
- A long title
- No image
- A missing image
- One price
- Multiple prices
- A promotional label
If your design only works with the shortest version, the implementation may become unstable.
Instead, design realistic content variations.
For example, test a product card with:
Short title:
“Running Shoes”
Long title:
“Lightweight Road Running Shoes for Daily Training”
Then test what happens with a missing image or longer price.
This is one of the simplest ways designers can help reduce layout problems before development.
Reserve space for images and dynamic components
Image dimensions are particularly important.
If the browser does not know how much space an image will need, content below it may initially render higher and then move when the image appears.
From a design perspective, the solution is straightforward:
Design with explicit image proportions.
For example:
- 16:9 video thumbnail
- 4:3 product image
- 1:1 profile image
- 3:2 editorial image
The exact ratio depends on the content, but consistency helps developers reserve the correct space.
The same thinking applies to:
- Advertisement slots
- Embedded videos
- Cookie banners
- Notification bars
- Dynamic forms
- Lazy-loaded content
Avoid designing components that depend on unexpected insertion
One of the most common layout problems on websites is content appearing above something the user is already reading.
For example:
A user opens an article.
The heading appears.
The user starts reading.
A promotional banner loads above the article body.
Everything moves.
This is not only a technical issue. It is a content and layout decision.
If a component may appear dynamically, its space should be considered during layout planning.
That does not mean reserving huge empty blocks everywhere. It means identifying components that can arrive later and deciding where they belong before implementation.
The Free Performance Fixes Designers Can Influence
Performance optimization often sounds expensive because developers talk about caching, CDNs, database queries and server configuration.
Some improvements do require engineering work.
But designers can remove waste before anyone buys infrastructure.
Reduce visual complexity before reducing visual quality
One of the easiest improvements is removing things that do not contribute enough.
Ask these questions during design review:
- Does every decorative image need to exist?
- Does every animation need to run?
- Do we need three font weights?
- Can this illustration be SVG?
- Does this background need to be photographic?
- Can two visual elements become one?
- Does this shadow add meaningful hierarchy?
- Does the user need this component immediately?
The result is often better design, not merely faster design.
A clean interface with fewer competing elements can be easier to understand and easier to implement.
Build performance into the design review checklist
Add performance questions beside the usual visual and UX questions.
Before handoff:
- What is the main LCP candidate?
- What is the largest image?
- Which assets appear above the fold?
- How many font families and weights are required?
- Which animations are essential?
- Which components contain variable content?
- What happens while data is loading?
- Can any component change height after rendering?
- What happens on a slower mobile device?
This takes minutes.
Fixing a poor design decision after development can take considerably longer.
Use PageSpeed Insights as a conversation starter
PageSpeed Insights can provide both lab-style testing and field data where available. The official service is available at Google’s PageSpeed Insights site.
Designers do not need to understand every diagnostic.
Start with three questions:
What is the LCP element?
This tells you which major visual element deserves attention.
What interaction has poor INP?
This helps identify whether an important interface action is doing too much work.
Which elements contribute to CLS?
This helps connect visual instability to actual components.
The goal is not to chase a perfect score.
The goal is to connect a measurement to a design decision.
FAQs
What are the three Core Web Vitals designers should know?
The current three Core Web Vitals are Largest Contentful Paint (LCP), Interaction to Next Paint (INP), and Cumulative Layout Shift (CLS). LCP measures loading performance, INP measures interaction responsiveness, and CLS measures visual stability.
What can a UI designer do to improve Core Web Vitals?
A UI designer can reduce unnecessary visual complexity, specify sensible image dimensions and aspect ratios, limit font families and weights, avoid unnecessary animation, design realistic content variations, plan loading states, and identify above-the-fold assets. Developers still handle many technical optimizations, but design decisions can create or remove performance problems.
Does a better Core Web Vitals score automatically improve Google rankings?
No. Core Web Vitals are part of Google’s page experience considerations, but a good score does not automatically make a page rank above another page. Content relevance, quality and many other Search systems and signals also matter. Google’s documentation has specifically clarified how it discusses page experience and Core Web Vitals.
What is a good LCP score?
Google currently considers LCP good when it is 2.5 seconds or less at the 75th percentile. Between 2.5 and 4 seconds needs improvement, while above 4 seconds is considered poor.
What is a good INP score?
An INP of 200 milliseconds or less is considered good. Values above 200 milliseconds and up to 500 milliseconds need improvement, while values above 500 milliseconds are considered poor.
Can designers improve CLS without touching code?
Designers can prevent many CLS problems before development by specifying image ratios, designing realistic content lengths, planning dynamic components, accounting for banners and embeds, and avoiding layouts that depend on content appearing later. The final implementation still requires developers to reserve space and handle dynamic content correctly.
Conclusion
Core Web Vitals become much easier to understand when you stop treating them as three technical scores and start treating them as three questions about the interface.
LCP asks: How quickly does the important content become visible?
INP asks: How quickly does the interface respond when someone uses it?
CLS asks: Does the page stay where the user expects it to stay?
Designers influence all three.
You can choose a lighter hero treatment, reduce unnecessary visual assets, simplify typography, define image proportions, design realistic content states, reduce needless animation and plan loading behaviour before a developer writes the first line of production code.
This approach works especially well for marketing websites, product interfaces, dashboards and content-heavy pages where visual design and performance need to work together. It will not solve server-side bottlenecks or poorly written JavaScript by itself.
But that is not the point. A performance-aware designer prevents problems before they become development problems.
