What are Core Web Vitals and what is the LCP threshold?
Google's Core Web Vitals have been a ranking signal since 2021, and since March 2024 they consist of three metrics: LCP (Largest Contentful Paint), INP (Interaction to Next Paint — replacing the earlier FID) and CLS (Cumulative Layout Shift). They are not the only SEO factor, but they are measurable, publicly available and directly affect user experience — so improving them is valuable even without a direct SEO effect.
LCP measures how quickly the largest visible element on a page loads (usually the hero image or H1 heading). Threshold: below 2.5 seconds is 'good', 2.5–4.0 seconds 'needs improvement', above 4.0 seconds 'poor'. According to public data from Chrome's CrUX dataset, a significant share of sites still fail this threshold on mobile.
What most often slows LCP in practice and how to find the culprit
Images used to be the number one problem, but WebP and lazy loading are now standard. Today LCP is more often held back by render-blocking fonts, third-party scripts (chat, analytics, ad tags) and slow server response on shared hosting. A time to first byte (TTFB) below 800 ms is a precondition for good LCP — hosting abroad with a 1.2-second TTFB cannot produce a good result without a CDN. On React and Next.js sites an extra problem is the amount of JavaScript a phone has to download and execute; server components reduce it considerably.
How to find the culprit: open PageSpeed Insights, enter the page address and check in the diagnostics which element is marked as the LCP element. That is your target — usually the hero image, heading or banner, and each is fixed differently: an image must be smaller and loaded with priority, text must not wait for a font, and a banner must not depend on a script that arrives late.
INP and CLS — responsiveness and visual stability
INP measures the time from a user interaction (click, tap, keystroke) to the page's visual response. Threshold: below 200 ms good, 200–500 ms needs improvement, above 500 ms poor. The most common causes are too much JavaScript on the main thread, heavy analytics scripts and third-party add-ons (chatbots, live chat, marketing pixels) that keep the main thread busy.
CLS measures how much a page 'jumps' while loading — an element appears, pushes content down and the user clicks the wrong thing. Threshold: below 0.1 good, 0.1–0.25 needs improvement, above 0.25 poor. Causes include images without defined dimensions, fonts replacing a fallback font with different metrics and banners inserted without reserved space.
How do you measure Core Web Vitals on your own site?
Where you stand: Google PageSpeed Insights (pagespeed.web.dev) gives a lab measurement for any URL plus CrUX real-user data if the site has enough traffic. Google Search Console's 'Core Web Vitals' report shows real user data grouped by page type, separately for mobile and desktop. For ongoing monitoring use Lighthouse CI in your release process or the Web Vitals Chrome extension for quick checks.
What can you fix in Core Web Vitals without a developer?
Without a developer you can: compress and convert images to WebP/AVIF before uploading (Squoosh.app is free), add width and height to every image, remove live chat or pixels that bring no results and check that your hosting has HTTP/2 and server-side caching. The rest — JavaScript optimisation, critical CSS, preload — needs a developer, but once done it lasts. Feather Studio builds sites with the goal of passing Core Web Vitals on mobile; if your site is slow or scores below 70 on mobile, see our web development services or book a technical review.