Core Web Vitals: fixes without a developer

You open Google Search Console and see a red bar with LCP, INP and CLS beside it. The report seems to speak the language of a spaceship control panel, even though it is about an ordinary page with your products, photos and an “Order” button. Your hand reaches to close the tab with one thought: “This is definitely for a programmer.” But it is not all that complicated. Among these three abbreviations, there is one task you often should not touch without a technical person, and two where the cause often lies in materials uploaded to the site: a photo, banner, video or a block for which nobody left space. So first, it is worth understanding what inconvenience the report is describing.

Speed is needed not for a magical jump in search, but so a person does not wait for an image, press a button with no response, or try to catch text that has suddenly moved down.

1. Three numbers that describe different inconveniences

Largest Contentful Paint (LCP) is the time it takes for the largest visible element of a page to appear on screen. Most often, it is a large product photo, cover image, banner or large heading. Google considers an LCP of 2.5 seconds or less good.

Imagine a bakery page. A person comes from an ad to a cake page, but first sees an empty light area, and the main cake photo appears late. Formally, the site has already started loading, but for the person it has not started yet: they came for that image and the price beside it. That is an LCP problem. Interaction to Next Paint (INP) is how quickly a page visibly responds to a person’s action: pressing a button, opening a menu, choosing a product option or filling in a field. A good INP is 200 milliseconds or less. If you press “Add to cart” and the interface freezes without any response, it does not look like a broken button, but it feels exactly like one.

When the page moves without your permission

Cumulative Layout Shift (CLS) is a measure of visual stability: it adds up how much of what you already see moves unexpectedly and how far it travels. It is not seconds but a unitless score; 0.1 or less is good, above 0.25 is poor. For example, you have already moved your cursor or finger onto a button, and a banner suddenly appears above it, a photo gains height and the button moves down. The person clicks the wrong thing. At that moment, the process has an odd hobby: it rearranges furniture after the guests have sat down. And it is not only about the first seconds. Google measures CLS across the whole life of the page, not only during loading. A shift that follows your own tap within half a second is treated as expected and is not counted; a shift that happens on its own, for example when content loads in as you scroll further down, is counted.

Google does not check these thresholds using a pretty average number. They must be met for at least 75% of loads, separately on mobile devices and computers. So a good result on your laptop does not yet mean the page is good for people with a phone and a slower connection.

If you see FID in an old checklist, do not spend time looking for it. First Input Delay is no longer part of Core Web Vitals: INP replaced it on 12 March 2024. So in the current report, look specifically at LCP, INP and CLS.

2. Will speed give you a higher position in Google

Short answer: not by itself. Google uses Core Web Vitals in its ranking systems, but directly explains that there is no single signal. Good metrics do not guarantee top positions, and search aims to show the most relevant material even when the page experience is mediocre. This is an important clarification because it protects you from two poor decisions: expecting image compression to automatically pull a page above stronger and more useful answers, or dismissing an inconvenient site because the text and product are supposedly good enough.

Speed is not a replacement for content, pricing, a clear offer or trust in the business. It removes friction between a person and what they came for. If a page explains a service but the first image takes too long to load, some people simply will not wait for the explanation. If a product card jumps, a person may accidentally click another option. That is already a practical reason to understand the report, regardless of promises about search positions.

It makes sense to keep speed work alongside ordinary technical website improvements, rather than turn it into a separate magical service. In the same way, it is part of the technical side of SEO, not a replacement for work on whether the page answers a person’s query.

A good number in a report does not sell for you. It simply does not stop a person from reaching your offer.

3. Where to find your numbers and why a test can disagree with a report

In Google Search Console, open the Core Web Vitals report. It shows data from real visitors in the Chrome User Experience Report, or CrUX, for the last 28 days. It places URLs into the Good, Needs improvement or Poor groups. For LCP, these are up to 2.5 seconds, up to 4 seconds and over 4 seconds respectively; for INP, up to 200 milliseconds, up to 500 milliseconds and over 500 milliseconds; for CLS, up to 0.1, up to 0.25 and over 0.25.

One important detail: a page group receives the worst of its statuses. If one group has normal LCP but poor CLS, it will look problematic. This is not a verdict on every page and not a reason to change everything at once. It is a clue about which type of inconvenience to start with. Two further details save time. A group appears only once it has a minimum amount of data for LCP and CLS together; where there is too little, Search Console can show an origin group instead, which combines all URLs under one protocol, host and port. And “No data available” is not a good grade: it means there are not enough real visits yet, not that the pages are fast.

A one-time page test may show a different picture, and that is normal. That measurement happens here and now, under specific conditions. Search Console looks at what happened to real people over a period. One tool is useful for checking a change immediately after an edit; the other shows how the site behaved in real life, not just in one run. It helps to know that PageSpeed Insights shows both at once: at the top, data from real Chrome visitors; below it, a laboratory measurement taken on the spot. Check which of the two you are reading, and whether it is data for your URL or for the whole site, because where a single page has too little traffic the tool falls back to the origin. There is one more honest reason for a disagreement: a laboratory run usually loads the page and stops there, so it does not see the shifts that happen later, while a person is scrolling.

Do not try to prove which one is “correct.” Instead, ask a simple question: do I see a problem for real visitors in Search Console, and can I reproduce it on the page? If LCP is poor, open the page from a phone using mobile internet and see what the person waits for the longest. If CLS is poor, load the page several times and watch whether a button, price, form or text moves.

4. What you can fix yourself: the main image

LCP does not always mean the server or code is catastrophically slow. It consists of several parts: time until the site’s first response, delay before the needed resource starts loading, the download itself and rendering the element. Without a developer, you do not have to sort these parts into technical drawers. It is enough to check the most obvious thing: what is on the first screen and how much unnecessary weight it carries.

If the main screen has a large image, do not upload the largest file you find in a folder. Prepare a version for its actual size in the design, compress it and, if your content management system supports it, use a modern format such as WebP or AVIF. The point is not the format name: a person should not download extra data that is not even visible on their screen. Compression is worth doing, but do not promise yourself that it will move the number on every page. Of the four parts above, a lighter file shortens only one, the download itself. If the image stays hidden until a script has finished and everything appears at once, the time you saved simply moves into the rendering of the element and LCP stays where it was. So the file being several times lighter while the report does not move is not a failure on your part; it is a sign that the remaining cause is technical.

What should appear first

The main image on the first screen should not be delayed with lazy-load: the browser waits before loading it, even though that is exactly what the person came to see straight away.

Take a hypothetical furniture workshop, with the assumptions written down so the reasoning can be checked. Assume that Search Console labels the mobile group of project pages Poor for LCP; that the first screen carries one kitchen photo the owner uploaded straight from the camera, about four megabytes; that on a phone this photo is displayed roughly 800 pixels wide; and that the site runs on a content management system whose media library exposes the file, its format and the lazy-load switch, but nothing deeper. The decision under those assumptions: do not rebuild the site and do not buy a plugin. Replace that one file with a version prepared for the size at which it is actually shown, save it as WebP or AVIF if the system offers those, keep the original in the archive, and turn lazy-load off for this image alone. Then wait: the report speaks in twenty-eight days of real visits, so a verdict on the next morning means nothing. Three things would change this decision. If the largest element on the first screen turns out to be a heading or a different block, the photo was never the right target. If the new file loads quickly and the group still stays Poor after several weeks, the cause is more likely the server response or scripts that hold up rendering. And if the editor gives no access to format, compression or lazy-load, the honest next step is a described task for a developer rather than another attempt in the media library. Delayed loading may be appropriate for photos lower on the page, but not for the first large image.

If you do not have access to the format, compression or lazy-load, do not guess at settings in the code. Note the page, the name of the main image and that it is the largest element on the first screen. For a developer, this is already a proper task description rather than an anxious “something is red in Google.”

5. What you can fix yourself: a page that jumps

CLS is often visible without special knowledge. Open the page and do not scroll it straight away. Look for blocks that appear late and make everything already on screen move. Pay particular attention to large photos, videos, embedded maps, forms, widgets and banners.

Google lists images without specified dimensions, ads, embeds and iframes without dimensions, dynamically added content and web fonts among common causes of shifts. An iframe is a window from another service embedded in a page, such as a map, video or form. For a reader, it makes no difference what moved the button; what matters is that the page did not reserve space for it in advance.

Set a width and height for every image and video in the editor. Where those fields do not exist, the same job is done in the styles with an aspect ratio; and for a block whose height is unknown in advance, such as a review widget, an advertising slot or an embedded form, a reserved minimum height works. For a map or video, choose a fixed container or ask for space to be reserved before it loads. One warning about reserved space: it should not collapse when nothing arrives. A placeholder that disappears because no advert or review was returned causes exactly the same jump as content that appears.

A second hypothetical example: a service page has a booking form, and a reviews widget appears above it. At first the form sits high up, then the widget finishes loading and pushes the button away. The owner does not have to rewrite the widget. They can disable it on this page, move it lower or ask a developer to reserve a fixed height for it. If the system offers fields for proportions or block size, do not leave them blank. Here, the first two options are editor decisions, while the third is a technical task.

6. Where you should not pretend you can handle it yourself

INP is connected to how a page processes a person’s action. Google splits every interaction into three parts: the delay before the code that handles your click even starts running, the time that code takes, and the delay before the browser can show the result on screen. JavaScript, the code that runs menus, filters, carts, forms and pop-ups, usually appears in one of those parts, and during loading a large script can hold up the response simply because the browser is still parsing and compiling it. There is one thing you can do without a developer, and it is not a workaround: look at how much you have asked the page to carry. A chat, a review widget, advertising and analytics tags, a slider nobody uses - each of them brings its own code. Removing what the page does not need is an editorial decision. Beyond that, an honest answer sounds like this: to find which of the three parts is slow, you need someone who can read a performance profile.

You can still prepare the task well. Write down the specific action: “on mobile, on the product card, after choosing a size the button takes a long time to change” or “after pressing, the menu opens with a pause.” Add the URL, device and time when you saw it. Do not name the cause if you do not know it. Your value here is in an accurate description of the moment, not in trying to treat JavaScript yourself with a random plugin.

Do not install a caching plugin only because you have a red bar. It may be useful in a particular configuration, but it will not reduce the weight of a photo you uploaded at an excessive size, and it will not explain why the page responds with a delay. First, call the problem by its name: LCP, CLS or INP. Only then decide whether you can change a file or block in the editor, or whether technical work is needed.

There is one first step: open the Core Web Vitals report in Search Console, write down the worst of the three metrics separately for mobile and computers, and find one page from that group. Then look not at the red color, but at what a person is actually waiting for, pressing or losing sight of.

7. FAQ

Core Web Vitals now include LCP, INP and CLS. LCP shows when the main large page element appears, INP shows how quickly the site responds to an action, and CLS shows whether the layout jumps unexpectedly. FID, or First Input Delay, was the previous responsiveness metric, but INP officially replaced it on 12 March 2024. If an old checklist asks you to look for FID, use it only as historical reference: in the current Search Console report, look at INP.

For a good rating, Google sets these thresholds: LCP of 2.5 seconds or less, INP of 200 milliseconds or less, and CLS of 0.1 or less. This is not an average value: the threshold is checked at the 75th percentile of loads, separately for mobile devices and computers. Search Console also has intermediate and poor statuses: LCP up to 4 seconds and over 4 seconds, INP up to 500 milliseconds and over 500 milliseconds, CLS up to 0.25 and over 0.25. Start with the device where the status is worse.

No, that cannot be promised honestly. Google confirms that Core Web Vitals are used by its ranking systems, but also explains that there is no single page experience signal and that good results in reports do not guarantee a place in the top results. Search aims to show the most relevant content even when the page experience is sub-par. So improve speed so it does not get in the way of someone using the site, but at the same time check whether the page clearly answers the query, presents the offer and gives the needed information.

Search Console shows field data from the Chrome User Experience Report: anonymous measurements from real visitors to URLs over the last 28 days. A one-time test, by contrast, checks a page at a specific moment and under specific conditions, and it usually stops after the load, so it does not see shifts that occur later while a person scrolls. PageSpeed Insights shows both layers, one above the other, and falls back to data for the whole site when a single URL has too little traffic. So the results can differ without any error. Use the report to understand whether a problem repeats in real use, and a one-time measurement to check changes on a particular page.

Start with LCP and CLS. For LCP, check the largest image on the first screen: prepare the file at the needed size, compress it, choose WebP or AVIF where possible and make sure lazy-load is not enabled for it. For CLS, check photos, videos, maps, embedded forms and widgets: they need specified dimensions, an aspect ratio or space reserved in advance, and that reserved space should not collapse when nothing arrives. INP is the metric where a developer is usually needed, because the delay hides in one of three parts of an interaction that you cannot see from the editor. Your own step there is smaller but real: remove the scripts and widgets the page does not need, then hand over the URL, the device and the exact action after which the site freezes.

Possibly nothing. Google breaks LCP into four consecutive parts: the time until the first byte of the page arrives, the delay before the browser starts loading the needed resource, the loading of that resource, and the rendering of the element. A lighter file shortens only the third part. If the image is hidden until a script finishes and everything appears at once, the saved time moves into the rendering delay and the total stays the same. Two things are still worth checking yourself: that the image is visible in the page source rather than being inserted by a script, and that lazy-load is off for it. If both are in order and the report does not move over the following weeks, the remaining causes are technical, and that is exactly the moment to hand the task over with your measurements attached.

It means there are not enough measurements yet, not that everything is fine. The report is built from the Chrome User Experience Report, and a group of pages needs a minimum amount of real visits before it can be shown without exposing individual people; it also needs data for LCP and CLS together. A property added to Search Console recently may simply need a few days. If a group of similar pages is too small, Search Console can show an origin group instead: all URLs under the same protocol, host and port, taken together. In that situation, work with one-time tests on your most important pages and return to the report when traffic grows.

8. Glossary

Largest Contentful Paint (LCP): A metric that shows when the largest visible element of a page appears on screen, usually a large image or a large block of text. A good value is 2.5 seconds or less at the 75th percentile of visits.
Interaction to Next Paint (INP): A metric for how a page responds to a person's actions across the whole visit: it takes the longest of the observed interactions and measures the time until the interface visibly reacts. A good value is 200 milliseconds or less.
Cumulative Layout Shift (CLS): A unitless score for the visual stability of a page: it records unexpected shifts of text, buttons and blocks across the whole life of the page, not only while it loads. A good value is 0.1 or less.
Chrome User Experience Report (CrUX): A set of anonymous field data about how real visitors experienced pages in Chrome; it is the source behind the Core Web Vitals report in Search Console.
Lazy loading: Delaying the loading of an image or another resource until it is needed: useful further down a page, but harmful for the main image of the first screen, which should never be lazy-loaded.
Inline frame (iframe): A window from another service embedded in a page, such as a map, video or form; without dimensions given in advance it is a frequent cause of layout shifts.