Core Web Vitals and INP in 2027: How to Pass on Mobile

A slow, jumpy website loses visitors before they read a single word. On mobile, where most traffic now comes from, the effect is even stronger: people tap away if a page takes too long to appear, if buttons do not respond, or if text jumps just as they try to tap. Google measures these experiences with Core Web Vitals, and they influence both rankings and conversions.

The good news is that the causes of poor scores are well understood, and most can be fixed without rebuilding your entire website. A focused set of changes to images, fonts, scripts and layout often moves a site from failing to passing within a few weeks, with measurable gains in engagement and leads along the way.

The metrics have evolved. Interaction to Next Paint (INP) replaced First Input Delay in 2024 as the responsiveness metric, and it is much harder to pass because it measures every interaction, not just the first. Many sites that once looked healthy now fail on mobile. This guide explains each metric, how to diagnose problems and the fixes that work, so your site passes on real devices in 2027.

The three metrics

Metric	What it measures	Good	Needs improvement	Poor
LCP (Largest Contentful Paint)	Loading: when the main content appears	≤ 2.5 s	2.5–4 s	> 4 s
INP (Interaction to Next Paint)	Responsiveness: delay between tap and visual response	≤ 200 ms	200–500 ms	> 500 ms
CLS (Cumulative Layout Shift)	Visual stability: unexpected movement	≤ 0.1	0.1–0.25	> 0.25

To pass, a page needs at least 75% of real visits to meet the “good” threshold for each metric. Google evaluates mobile and desktop separately.

Field data vs lab data

Understanding the difference avoids a lot of confusion:

• Field data comes from real users visiting your site on their own devices and networks, collected over 28 days. It is what Google uses to assess Core Web Vitals, and you can see it in Search Console and PageSpeed Insights when there is enough traffic.
• Lab data comes from tools such as Lighthouse, which load a page once on a simulated device and network. It is excellent for diagnosing problems and testing fixes, but it may not reflect your real visitors.

A site can score highly in Lighthouse yet fail in the field if many visitors use older phones or slow connections, or if problems appear only after interaction. Use lab tools to diagnose, and field data to confirm.

If your site does not have enough traffic for Google to show field data, you can collect your own with real-user monitoring: a small script that records the metrics from actual visitors and sends them to an analytics tool. This also lets you break results down by page type, device and country, revealing problems that aggregated reports hide. For low-traffic sites, consistent lab testing on a mid-range mobile profile is a reasonable substitute, as long as you remember it is an approximation.

Why INP is harder than it looks

Many teams are surprised when their site fails INP despite fast loading. The reason is that INP considers interactions throughout the whole visit: opening menus, tapping filters, typing into forms, adding items to a cart, expanding accordions and closing pop-ups. A page can appear instantly and still feel sluggish if any of these interactions trigger heavy work. Testing must therefore include interactions, not just page loads. Click through key journeys on a real mid-range phone and watch for delays, then use profiling tools to find which scripts run during those moments.

Improving LCP: make the main content appear fast

LCP is usually the hero image, a large heading or a banner. Common causes of slow LCP and their fixes:

Slow server response

• Use fast hosting with a content delivery network close to your users
• Serve static or cached pages where possible
• Reduce slow database queries and server processing

Render-blocking resources

• Inline critical CSS and defer the rest
• Avoid large CSS frameworks shipping unused styles
• Defer non-critical JavaScript

Slow-loading hero images

• Use modern formats such as WebP or AVIF
• Size images correctly for mobile screens with responsive images
• Do not lazy-load the main hero image; load it eagerly with high priority
• Preload the LCP image when it is discovered late

Fonts

• Self-host fonts, subset them and preload the main font file
• Use font-display settings that avoid invisible text

Improving INP: make every tap respond quickly

INP measures how long it takes from a user’s interaction, such as a tap, click or key press, until the screen visibly updates. It reports one of the slowest interactions during the visit. Poor INP is almost always caused by too much work on the browser’s main thread.

Reduce JavaScript

• Remove unused libraries, plugins and widgets
• Avoid shipping a full single-page application for mostly static content
• Use frameworks and architectures that send little JavaScript, such as static-first sites with interactive islands
• Code-split so each page loads only what it needs

Break up long tasks

Any task that blocks the main thread for more than 50 milliseconds delays interactions. Split heavy work into smaller chunks, yield to the browser between steps and move expensive processing off the main thread where possible.

Make event handlers fast

• Do the minimum work needed to update the screen first, then defer the rest
• Avoid triggering large layout recalculations on every interaction
• Debounce input handlers such as search-as-you-type

Tame third-party scripts

Chat widgets, tag managers, analytics, heatmaps, ad scripts and social embeds are frequent INP offenders. Audit every third-party script, remove what you do not need, load the rest after the page is interactive and consider lighter alternatives.

Reduce hydration cost

Frameworks that hydrate the entire page in the browser can block interactions during load. Partial or progressive hydration, server rendering and islands architectures greatly reduce this cost.

Improving CLS: stop the page jumping

Layout shifts happen when content moves after it first appears. Fixes:

• Set dimensions for images, videos and iframes with width and height attributes or aspect-ratio
• Reserve space for ads, embeds, banners and dynamic content
• Avoid inserting content above existing content, such as late cookie banners or promotions that push the page down
• Handle fonts carefully so text does not reflow dramatically when web fonts load; preloading and matching fallback metrics help
• Animate with transforms rather than properties that change layout

Images: the biggest quick win

On most business websites, images account for the majority of page weight. A disciplined image approach improves loading across every page:

• Choose the right format: modern formats such as WebP and AVIF are much smaller than older JPEG and PNG files at similar quality
• Resize for the display size: a phone screen does not need a 4,000-pixel photo
• Use responsive images so each device downloads an appropriate size
• Compress sensibly: most photos look identical at moderate compression levels
• Lazy-load below-the-fold images, but never the main image at the top of the page
• Set width and height to prevent layout shifts
• Avoid text inside images, which is heavier, less accessible and invisible to search engines

Many modern frameworks and hosting platforms handle much of this automatically, but editors still need guidance on uploading sensible files.

Fonts without the penalty

Custom fonts give a brand character but can slow loading and cause layout shifts. Limit the number of font families and weights, self-host fonts instead of loading them from external services, subset them to the characters you need, preload the most important file and choose a display strategy that balances brand consistency with speed. A single variable font often replaces several separate files.

A practical diagnosis workflow

1. Check field data in Search Console’s Core Web Vitals report to see which page groups fail on mobile and which metric is the problem
2. Pick representative pages from failing groups
3. Run lab tests with mobile throttling to reproduce and identify causes
4. Use performance profiling in browser developer tools to find long tasks, slow handlers and layout shifts
5. Fix the biggest issues first, usually large images, heavy JavaScript and third-party scripts
6. Deploy and validate with lab tests, then monitor field data over the following weeks

Platform-specific tips

WordPress and page builders

Heavy themes, page builders and plugins are common causes of poor vitals. Reduce plugins, choose lightweight themes, use caching and image optimisation, and be wary of builders that output large amounts of CSS and JavaScript.

Single-page applications

Use server rendering or static generation for content pages, split code aggressively and minimise hydration.

Static-first frameworks

Frameworks such as Astro produce fast pages by default; keep them fast by limiting client-side JavaScript and third-party scripts. See our guide to headless CMS and Astro.

E-commerce platforms

Optimise product images, limit apps and widgets, defer reviews and recommendation scripts, and test checkout interactions carefully.

Example: fixing a slow service business website

Consider a typical home services company whose mobile pages take more than four seconds to show the main content and feel sluggish when visitors tap the menu or quote form. Field data shows failing LCP and INP on mobile.

Diagnosis reveals several issues: a large uncompressed hero photo, three web fonts loaded from an external service, a page builder adding hundreds of kilobytes of CSS and JavaScript, a chat widget, two analytics tools, a heatmap script and a social media feed embedded on every page. The quote form runs heavy validation code on every keystroke.

The fixes are straightforward. The hero image is converted to a modern format, resized for mobile and loaded with high priority. Fonts are self-hosted and reduced to one family with two weights. The page builder is replaced with lightweight templates. The heatmap and social feed are removed, the chat widget loads only after the user scrolls or taps a button, and analytics is consolidated into one tool. Form validation runs when the user leaves a field rather than on every keystroke. Within a few weeks, field data shows LCP comfortably under the threshold and INP well below 200 milliseconds, and the quote form completion rate improves noticeably.

Example: an online store with poor INP

An online store passes LCP but fails INP on product pages. Profiling shows that tapping “Add to cart” triggers a long task combining cart updates, recommendation scripts, analytics events and a mini-cart animation. The team updates the cart counter immediately, defers recommendations and analytics until after the visual update, and replaces the heavy animation with a simple transform. Interactions now respond almost instantly, and add-to-cart rates rise.

Keeping performance from slipping

Many sites get fast once and then slowly degrade as new scripts, images and features are added. Protect your gains with:

• Performance budgets for page weight, JavaScript size and third-party scripts
• Automated checks in your deployment process that flag regressions before release
• A review step for any new marketing tag, widget or embed
• Image pipelines that resize and compress uploads automatically
• Monthly monitoring of field data in Search Console
• Clear ownership, so someone is responsible for performance over time

Speed is not a one-off project; it is a habit maintained by the whole team, including marketing and content editors. Share a simple monthly performance summary with everyone who adds content or tools to the site, so the impact of each decision stays visible and fast pages remain the default.

Why Core Web Vitals matter for business

Beyond rankings, faster and more responsive pages improve:

• Conversion rates: fewer visitors abandon slow or unresponsive pages
• Engagement: people view more pages when navigation feels instant
• Ad performance: landing page experience affects ad quality and costs
• Brand perception: speed signals professionalism and trust
• AI and search crawling: fast, clean pages are easier for crawlers to process

Read our conversion rate optimization quick wins for more ways to turn speed into leads.

A quick checklist

• Main image in a modern format, correctly sized and loaded with high priority
• One self-hosted font family, preloaded
• Critical CSS inlined, the rest deferred
• JavaScript minimised, split and deferred
• No long tasks during key interactions
• Third-party scripts audited, reduced and delayed
• Width and height on every image, video and embed
• Space reserved for banners and dynamic content
• Fast hosting with a content delivery network
• Field data reviewed monthly

Common mistakes

• Optimising only for a Lighthouse score instead of real-user data
• Lazy-loading the main hero image at the top of the page
• Adding chat, analytics and marketing scripts without measuring their cost
• Ignoring INP because the first load looks fast
• Leaving images, videos and embeds without set dimensions, causing the layout to jump
• Testing only on fast desktop computers and office Wi-Fi instead of real mid-range phones on mobile networks

The bottom line

Passing Core Web Vitals on mobile in 2027 means fast loading, instant responses to every tap and a stable layout, measured on real devices. Optimise the main image and fonts, ship less JavaScript, break up long tasks, control third-party scripts and reserve space for every element. Measure with field data, diagnose with lab tools and keep performance budgets in place so the site stays fast as it grows.

See our web development service, or read about headless CMS and Astro.