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.

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: how much a page moves elements that are already visible while loading. A good CLS is 0.1 or less. 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.

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.

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.

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.

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.

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.

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.

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.

Imagine a furniture workshop website. The first screen has a large kitchen photo that the owner uploaded directly from the camera because it is “higher quality.” Instead of changing the whole site, they prepare a compressed version of the photo for this place, keep the original in their archive and check that the first image no longer has lazy-load. This is a specific change you can make through the media library or page editor if they provide access to these fields. 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.”

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. For a map or video, choose a fixed container or ask for space to be reserved before it loads.

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.

INP is connected to how a page processes a person’s action. It is often affected by JavaScript, the code that runs menus, filters, carts, forms, pop-ups and other interactions. When INP does not fit within 200 milliseconds, the honest answer is usually this: you need a developer to see what exactly is blocking the response.

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.