Optimizing Core Web Vitals is three separate tasks, not one: LCP, INP, and CLS have different reasons and different fixes. So we first look at the current values in the field and in the lab and name the specific element that is driving down each metric, and only then do we get to the code. The most often overlooked detail: LCP is not faster than the first response from the server. In the laundry store we measured, the master delivered the first byte in 1,544.6ms — the green LCP there was unreachable before the browser saw the first image.
LCP — the appearance of the main element, INP — the response to a click or tap, CLS — layout jumps
after a free audit
Price
30
Guarantee
days after project sign-off
LCP — the appearance of the main element, INP — the response to a click or tap, CLS — layout jumps
Three metrics
field data of real visitors for 28 days; the laboratory is a tool for finding the cause
What Google evaluates the site by
7-21
Term of works
working days plus 28 days for the field to be filled after editing
free value and reason check, 2-4 business days
Before the estimate
on the main 118 images, of which 0 are deferred and 0 in WebP (our measurement on 01.08.2026)
A typical find
specific metric values: they depend on the phones and networks of your visitors
What we do not promise
Process steps
Transparent stages with approval at every step
Total duration:7–21 days
1
Measurements and analysis of reasons
2-4 working days
Field from Search Console and lab runs on key types of pages. We call the LCP element on each of them, the shift sources and the long tasks that hold the response to the action. The output is a list of reasons in order of influence.
2
Server ceiling
1-2 working days
Cache headers and the first response on those pages where the LCP rests on them. We do it first: while the main one is given without a cache, the rest of the edits are measured on a floating basis.
3
Layout shifts
1-3 working days
Sizes for images, banners and advertising spaces, behavior of fonts during replacement, space for widgets that are inserted after loading. The cheapest stage of the three metrics and the most visible to humans.
4
First screen and LCP
2-5 working days
Priority and pre-loading of the main image, removed from it delayed loading, format and actual size for the container. We check each type of page separately: the LCP element on the card and on the main page is different.
5
Response to action
1-5 working days
Long tasks in the main thread: we fix our code, transfer or postpone other people's scripts. For each widget, we show how much it costs, and we are waiting for your decision - to turn it off or tolerate it.
6
Repeat measurements and 28 days of support
1 working day plus 28 days of observation
Same methods, same pages. Next, the pages go to the Search Console for verification, and for a month we watch how the field moves - that's when the change becomes official.
Technologies & integrations
What we build on and what it connects to
Stack
Search Console, the Core Web Vitals report is the only source by which Google ranks a site. It is updated on a 28-day window, so we wait a month for a reaction to the edits
PageSpeed Insights is the field and lab in one screen. There will be no field part at all if you have few visitors: no data will be collected for CrUX
Lighthouse and Chrome's Performance panel find the cause, but it's your computer and your channel. A visitor with an old phone has longer tasks
web-vitals library - captures metrics from your live visitors. Gives its own field faster than Search Console, but needs a place to put the numbers
fetchpriority and preload — management of the download queue. It works as long as there are no such elements: the priority for everything is equal to its absence
WebP and AVIF are lighter formats. The winnings are visible in the photo catalogue; for ten icons it is within the measurement error
Integrations
Google Search Console
GA4
Google Tag Manager
Cloudflare
PageSpeed Insights API
What's included
Complete list of work and what you get as a result
We fix the starting LCP, INP and CLS separately for the mobile and desktop versions - without the number "to" any "it got better" is unprovable
We call the LCP element on each key type of page and further work with it, and not with "speed in general"
We remove the delayed loading from the images of the first screen and put it on the rest of the page
We give the main image a high priority and preload - it stops queuing for styles
We convert the image to WebP or AVIF where it does not spoil the appearance: fewer bytes to the first screen with the same picture
We set the dimensions of images, banners and advertising blocks - the layout stops jumping during loading
We adjust fonts: preloading and behavior during replacement so that the text does not move
Dealing with cache headers and the first answer: the server sets a ceiling above which the LCP will not rise
We move third-party scripts out of the way of the first render and show the price of each - the decision is up to you
We put the pages for inspection in Search Console and monitor for 28 days while the field is being filled
When this service isn't right
What's not included — so there are no surprises at delivery
Rewriting a theme or frontend from scratch
Optimizing other people's widgets that you are not ready to turn off
Replacement of hosting and infrastructure payment
Work with content and texts
The promise of specific metric values
Who it's for
Situations where this service delivers results
Scenario 1 of 5
It's red in Search Console and green in the online tester
This is not a contradiction, but two different sources. The tester makes one run from a good channel, Google counts 28 days of real visits: old phones, mobile Internet, browser extensions. Let's focus on the second, because it is the one that gets into the report.
We'll review your situation in a free audit
Scenario 2 of 5
Home feels slow, although the catalog opens fine
The most frequent schedule in our measurements. In the underwear store, the card returned the first byte in 391.4 ms, the category in 473.2 ms, and the main byte in 1,544.6 ms. The page came from no-store, that is, it was assembled anew for each visitor, and this second was entirely in the LCP.
Scenario 3 of 5
The images seem to be adjusted and the metric is still red
In the self defense store measured, 154 out of 190 images (81%) are delayed loading - done right. But the markup itself weighs 502.3 KB, and the browser parses half a megabyte to the first picture. Delayed loading of this part does not affect at all.
Scenario 4 of 5
The layout jumps under your finger
A banner without specified dimensions, a corporate font that replaces the system font, a widget that is inserted above the content. A person aims at a button, and it moves — and that's CLS. The metric, by the way, is the cheapest: part of the shifts is covered by size attributes per day of work.
Scenario 5 of 5
A filter or form thinks after clicking
INP measures the pause between an action and an apparent reaction. Keeping her long tasks in the main thread: heavy event handlers, chat, pixels, feedback script. Some of them are yours, some are someone else's, and the fix rests not on the code, but on your decision.
Editing reasons against the accelerator module
How this option differs from the alternative
Optimization module in adminOur approach
Where does the work begin?by enabling the "postpone scripts", "compress", "lazy for everything" checkboxesfrom the LCP element, the shift source and the long task list on your pages
What can be seen after the worksthe score in the tester has increased, the field has been standing for 28 days — nothing has changed for the visitoreach metric moves separately after its edit, and you can see which exactly caused the movement
Riskdelayed scripts break the cart, chat or counter, and notice it a week laterthe change is tied to the cause and is verified by re-measurement on the same set of pages
What is left with you?a module that is scary to turn off, because no one knows what exactly it holdsa document with numbers before and after and a list of reasons that are still open
First, let's see what values you have now and why
Core Web Vitals are three different metrics for three different reasons. Putting works in the estimate before it is clear which of them is red and why, means selling at random. That's why we do the first check for free.
What we measure
Current values of LCP, INP and CLSBoth laboratory and field - if there is access to Search Console. These are different data: the laboratory shows one run, the field shows real visitors in 28 days.
What is an element of LCPA specific element that Google considers to be the main one on the screen: banner, title, product image. Without it, there is nothing to optimize.
The source of layout shiftsWhich blocks jump when loading: a banner without specified dimensions, a font that changes, a widget that is inserted from above.
What blocks the action responseLong tasks in the main thread are usually third-party scripts and heavy event handlers.
Image of the first screenFormat, size, whether the main picture is delayed loading is a common mistake that spoils LCP instead of improving it.
Distribution of pages by statusHow many addresses are marked as "needs improvement" and "bad" in Search Console - and are these the pages where the money comes from.
What you get
Three values with an explanation of what exactly each of them breaks on your site.
A list of edits from the cheapest to the most expensive with an estimate of what each gives.
An honest mark opposite points that are not closed without reworking the template.
Conversation for 30 minutes on the document.
Timeline: 2-4 working days
Why is it free
Because the check takes us several hours, and the difference between "correct image attributes" and "rewrite the cap" is several times the difference in the estimate. Calling the plug for inspection would mean overstating it just in case.
What's next
After checking, we give a list of works with an estimate for each point and deadline. Some of the points will be closed by your developer himself - we do not hide which ones.
Short form: your contact and site URL
Did not find your case?
Describe how it works on your side — we will tell you whether “Optimizing Core Web Vitals” fits and what it means in your situation. No brief and no call: one question, one answer.
Contract, act and 30-day warranty
Every project gets a written contract: scope, deadlines, amount, acceptance procedure. After delivery — act and invoice, then 30 calendar days of warranty.
Sole proprietor & bank transfer
The contractor is a registered sole proprietor. Payment by invoice with closing documents.
Rights & access — yours
Code, design and materials transfer to you after full payment. Domain, hosting, repository and analytics are registered to you.
Client portal instead of email chains
During the project you get access to a portal: contracts, invoices, acts and project status in one place.
European clients
Among our work — projects for Norway, Bulgaria, Moldova and Spain.
Verifiable numbers
Every case in the portfolio comes with a link to a live site and a technical measurement.
Audit first, then pricing
There is no price list on the site intentionally: the scope of the same work differs multiples between clients.
We say "no" when unsure
If the task isn't ours or the deadline is unrealistic — we tell you upfront.
What affects the price
Why two seemingly identical tasks are priced differently
Which of the three metrics is redCLS is often closed with dimension attributes and one font edit is a day or two. INP rests on long tasks and other people's scripts and drags on for weeks, because part of the decisions are not made by you and not by us.
How many unique templatesThe main, category, card and form pages have different LCP elements and different reasons for the shifts. Each template is a separate analysis, separate edits and separate measurements before and after.
Who can edit the topicThere is access to the template - edits are made immediately. There is none - we write a list with exact places, and your developer enters them, and the deadline begins to depend on his turn.
How many other people's widgets are on the pageChat, pixels, reviews, call tracking. Technically, it takes hours to transfer them. Agree with the marketer and advertising contractor, which of them remains - a separate week of the calendar.
Will you have to touch the first screen?A three-banner carousel or full-screen video makes a green LCP on mobile almost unattainable. Then it is no longer optimization, but viewing the first screen, and it is counted separately.
Cases
Tasks and results in numbers — all metrics measured by us
online retail underwear store, catalog of over 110,000 product items
Task
Understand why main feels slow even though the directory opens fine.
Solution
Seven measurements per page type with median, separate count of first screen images, parsing of cache headers and viewport parameters.
Result
The first response of the main page is 1,544.6 ms versus 391.4 ms on the product card and 473.2 ms in the category — the main page is four times slower than the rest of the site. The full HTML of the main page comes in 1,733.5 ms with a weight of 323.6 KB (32.4 KB in gzip), and with no-store, that is, no page cache at all. It has 118 img tags, of which 0 are delayed loading and 0 are in WebP format. Separately for the action response metric: viewport is set with user-scalable=0, finger zoom is disabled. Measurement 01.08.2026.
a specialized online store of self-defense equipment
Task
Check whether the weight of the page does not interfere with displaying the product on mobile.
Solution
First response and full load measurement, delayed loading image count, structured data and PHP version checking.
Result
First response 494.7ms, full HTML load 567.5ms with a markup weight of 502.3KB. The images here are done right: 154 out of 190 (81%) load delayed. But half a megabyte of markup is not affected by delayed loading, and the browser analyzes it up to the first image. Other findings nearby: no h1 tag on main, zero structured data blocks, PHP 7.3.33 not supported since December 2021. Measured on 07/31/2026.
What we need from you
We can't start without this — best to prepare in advance
1Site address and list of types of pages that are important to you: main, category, card, form.
2Access to Search Console - without it, we only see laboratory measurements, and Google looks at the field.
3Access to the code or to a developer who can edit the template.
4Solution regarding third-party scripts: part of the metrics cannot be extracted without touching other people's widgets.
5One person from your side who can say in a day "we turn off this chat, this one remains."
If something is missing — let us know, we'll help you gather it or do it as a separate task.
FAQ
Most frequently asked questions — with concrete answers
What are LCP, INP and CLS in simple words?
Three measurable sensations. LCP — for how much the main element of the screen appeared: banner, title or photo of the product. INP — how quickly the page responds to an action: click, tap, input into a field. CLS - how much the layout jumps while everything is being loaded. Google measures them in real visitors through Chrome and shows them in Search Console. Each is treated in its own way: LCP — server and images, CLS — block sizes and fonts, INP — scripts.
The tester shows green, and Search Console shows red - who to believe?
Search Console. A tester does one run on one device on one network—it's a lab, and it's needed to find the cause. Google counts something else: 28 days of real visits to your site, with phones of all ages, mobile Internet and browser extensions. It is these numbers that get into the report and it is by them that the page is evaluated. We use laboratory data as a tool, and check with the field.
What metric do you start with?
Not with LCP, although it is talked about the most. First, we close the shifts of the layout and the ceiling of the server - both are cheap, and without them the rest of the measurements float. As long as the master is served without a cache, LCP is measured not on the page, but on the random state of the server; while the blocks are jumping, any LCP measurement depends on exactly when the banner was loaded. Next comes the first screen, and the last is the response to the action: it is the longest, because it rests on other people's scripts.
We have delayed loading on all images - why is LCP worse?
The most common mistake we see. Delayed loading tells the browser: this picture can be taken later. If it is on the main image of the first screen, the browser learns about it not immediately from the markup, but after the page is laid out - and the very element by which LCP is measured comes last. The rule is simple: on the first screen, delayed loading is removed and high priority is added, on everything below it is set.
When will the changes appear in the report?
In laboratory measurements — immediately after editing. In Search Console - gradually over the course of a month: the report counts a 28-day window, and as long as there are old visits in it, the status follows them. This is not our slowness, this is the period of data collection, and it should be planned in advance. Therefore, during the period of work, we separately write 28 days of follow-up after the edits: the pages are put for inspection, and we watch how the field moves.
Is it possible to pull all three in green on any site?
Not on any. If the metric is held by a widget that the business needs, we can move it, delay it, or disable it — but not rewrite someone else's code. If the first screen is a carousel of banners or videos, the green LCP on mobile is almost unattainable without viewing the screen itself. We name such points on a free inspection, before the estimate, and honestly mark which of them can be closed only by reworking the template.
Will it raise the bar?
No one promises items, and we will not. Core Web Vitals is a confirmed signal in the signal set and its weight is not public. It works differently: a visitor who left without waiting for the first screen, saw neither the product, nor the price, nor the button, cannot be converted by any offer. Speed removes technical loss, not creates demand: if the price is higher than the market, a fast page will simply show a reason to leave faster. And separately: you can see the impact on behavior only where the analytics stand. In the second of our cases, there are no Google counters at all — there the result will be visible only in measurements.
We have a catalog of tens of thousands of products - isn't it hopeless?
Directory size and metrics are less closely related than it seems. In a store with 115,456 product items, the product card gives the first byte in 391.4 ms, and the main slow one there was 1,544.6 ms, and the reason was in the page cache, and not in the number of rows in the database. Pulls down the template, module set, and image. What really depends on the volume is the number of templates to be disassembled and the time for re-measurements.
Submit your site address and access to Search Console.
The response is the three current values, the named LCP element on each key page type, and a list of edits from cheapest to most expensive. If metrics are kept by a widget that your business needs, let's say so in the first email.
From measured casesThe first response of the main page is 1,544.6 ms versus 391.4 ms on the product card and 473.2 ms in the category
There is no price list on the site on purpose: the same work differs several times over between two clients, and a “from” figure explains nothing in that case. First a free audit — we count your pages, duplicates and speed — then we name the sum and the deadline and fix both in the contract.