Answer in brief
Every speed complaint maps to one metric, one build decision and one price band. Here is the mapping, from a blank hero to a mis-tapped button, with the catalogue hours and money attached to each.
LCP is a stopwatch running on the thing you chose to put at the top
Largest Contentful Paint measures one moment and nothing else: the instant the biggest image or text block inside the first screen finishes rendering. It is not an average of the page, not a total load time, and not a count of requests. It is a single element, timed from the moment navigation begins. The catalogue entry Website acceleration and Core Web Vitals under Google's threshold names the target in plain numbers: LCP up to 2.5 seconds. Everything that happens before that one element appears is what you are paying somebody to remove.
Because the metric is attached to a specific element, the build decisions that ruin it are usually visible in the design file rather than buried in the code. A full-bleed photograph exported at desktop resolution and served to a phone. A headline that waits for a web font before it will draw a single letter. A video header that begins downloading before anything is painted. A stylesheet in the head that blocks rendering until it finishes. Each of these is a decision someone made on purpose, for a reason that seemed good at the time.
That is also why LCP is normally the least expensive of the three vitals to move. The work is a small, countable set of interventions: resize and re-encode the hero, serve it in a modern format, preload it, stop the font from blocking the first paint, and take the render-blocking assets out of the critical path. The catalogue prices exactly this shape of pass as Green PageSpeed and Core Web Vitals, category Optimization, difficulty Experienced, at $200 – $600 or 8 000 – 25 000 ₽, across 5-12 hours.
When LCP refuses to move inside that band, the cause has moved upstream and the diagnosis has to move with it. If the server takes a second to answer before a single byte of the page exists, no amount of image compression will help, and the fix is no longer a pass over assets. That is the point at which the buyer stops shopping for an optimisation pass and starts shopping for the line that includes a diagnosis stage, which the catalogue quotes as one day of diagnostics followed by one to three days of implementation.
INP measures the distance between a thumb and a pixel
Interaction to Next Paint measures something a stopwatch on load time can never see: how long after you tap, click or press a key the screen visibly changes. It watches the whole visit rather than the first second of it, and it reports the interactions that went badly rather than the ones that went well. The catalogue names the threshold directly: INP up to 200 milliseconds. A page can paint its first screen comfortably inside the 2.5-second LCP target and still fail this metric on every single button.
The build decision behind a bad INP is almost always the same one: how much JavaScript is allowed to occupy the main thread while a human is trying to use the page. A framework rehydrating an interface that was already rendered. Analytics that recalculates on every scroll. A chat widget, a consent manager, a tag manager loading a few more tags, a heatmap recorder, an experiment script deciding which variant you get. Individually each is small. Together they form a queue, and the tap waits in it.
This is why INP costs more to fix than LCP even though nobody has to compress anything. There is no single asset to optimise. The work is deletion, deferral and re-sequencing of code that somebody added deliberately, and every one of those additions has an owner somewhere in the business who will ask why their tool stopped reporting. The technical part is measurable in hours; the part where you establish which scripts are permitted to run before first interaction is a conversation, and it is the reason this work is scheduled in days.
The catalogue reflects that honestly by quoting the acceleration line as a schedule rather than an hour band: one day of diagnostics plus one to three days of implementation, at $200 – $800. A schedule is a different kind of promise from an hour count. It says the first day produces knowledge, not speed, and that the size of the following days depends on what the first one found.
CLS fires after the page already looks finished
Cumulative Layout Shift is the only one of the three that measures failure after apparent success. It adds up how far things move on screen when the user did not ask them to move. The page looks loaded, the reader begins reading, and then a block arrives late and pushes the paragraph down. The catalogue states the threshold as CLS up to 0.1, and describes the symptom in the way users actually describe it, as a site that jumps while it loads.
The build decisions that cause it are all variations on one habit: not reserving space for something that is going to arrive. An image tag without width and height, so the browser cannot leave a hole the right size. A banner injected by script above the content. A cookie notice that appears at the top rather than floating over. A web font whose letterforms are wider than the fallback, so every line of text re-wraps the instant it loads. Lazy-loaded sections that expand when they arrive.
In pure engineering hours, CLS is often the cheapest of the three to correct, because the fixes are dimensional attributes and reserved containers rather than architecture. The trap is that it is also the easiest to reintroduce. Any marketing tag added next quarter that injects a block above the fold will undo the work without anyone noticing, because nothing errors and nothing goes red in a build log. A CLS fix that lives only in a one-off pass has a short shelf life; one that lives in the templates does not.
It is worth knowing that this is the vital your customers complain about without ever naming it. They do not say the layout shifted. They say they pressed the wrong button, or that the site made them subscribe to something, or that it felt cheap. On a phone, where the thumb is already in motion before the page settles, a shifted tap target converts into a mis-tap, and a mis-tap on a checkout page converts into an abandoned order.
The lab score and the field score are two different documents
PageSpeed Insights hands you two results in one screen and they answer different questions. One is a synthetic run: a simulated device on a throttled connection, executed once, on demand. The other is field data, collected from the browsers of people who actually visited and aggregated over a rolling window. The number most people screenshot and send to a contractor is the synthetic one, because it is the one that appears instantly and the one that swings most dramatically when a single image is compressed.
The catalogue is deliberately precise about which document its Green PageSpeed and Core Web Vitals line is written against. It says the site moves out of the red zone into the green on mobile Core Web Vitals, and that the client sees the numbers before and after. Both halves of that sentence matter for a buyer. It commits to the mobile profile, which is the harder one, and it commits to a measurement taken twice, which is what makes the work checkable rather than assertable.
The practical consequence is scheduling, and it surprises people. A synthetic run responds to a fix the moment the fix is deployed. Field data does not, because it is an aggregate of visits that already happened, and it can only change as the old visits age out of the window. A site can be genuinely fixed and still show the old field numbers for a while. Anyone who promises the field data will turn green the day the work ships is describing the lab result and calling it the field one.
So agree in advance which document the invoice is measured against, and get both readings before anything is touched. If the agreement is about the synthetic score, the verification is same-day. If it is about the field data, verification is a date in the calendar and the report is written later. Neither is dishonest. Confusing the two is how a finished, effective piece of speed work ends up in an argument about whether it worked.
Why the diagnosis carries a price of its own
The acceleration entry is the only one in this group whose price is written in two pieces, and the split is the most useful thing in it. The catalogue states 10 000 – 40 000 ₽ for diagnosis with implementation, and, separately, audit only without fixes at 8 000–15 000 ₽. The dollar band for the line as a whole is $200 – $800, and the schedule is one day of diagnostics plus one to three days of implementation.
The reason for the split is that the two halves have different shapes. Diagnosis is bounded work with a predictable end: you measure, you trace, you attribute each slow millisecond to something, and you stop when everything is attributed. Implementation is not bounded at all until the diagnosis is finished, because the cause could be an oversized hero image, which is a short pass over assets, or a rendering chain that regenerates the page from a database on every request, which is a different job entirely. A single fixed price across both halves can only be produced by guessing high.
Here is arithmetic the reader can do without trusting anyone, offered as an example rather than as a measurement: the ceiling of the audit-only band, 15 000 ₽, sits above the floor of the diagnosis-with-implementation band, 10 000 ₽. That is not a mistake in the price list. It says that diagnosing a genuinely complicated site can legitimately cost more than diagnosing and fixing a simple one, which is exactly what you would expect if the audit is priced by the difficulty of the investigation rather than by the size of the eventual patch.
The audit-only option also exists for a specific and common buyer: the one who already employs developers. That buyer does not need hands, they need a prioritised list of causes their own team can execute against, and they should not be paying implementation rates for it. Buying the map without the driver is a rational purchase, and it is priced as one at 8 000–15 000 ₽. The same document doubles as the brief if the implementation is eventually placed elsewhere.
Two speed lines in the catalogue, and where the border between them runs
There are two entries that both promise faster pages, and reading them side by side tells you which one your situation belongs to. Green PageSpeed and Core Web Vitals sits in the Optimization category at difficulty Experienced, $200 – $600 or 8 000 – 25 000 ₽, quoted at 5-12 hours. Website acceleration and Core Web Vitals under Google's threshold sits in the Speed category, also Experienced, $200 – $800 or 10 000 – 40 000 ₽, quoted as one day of diagnostics plus one to three days of implementation.
The units are the tell, more than the money. One line is sold in hours and the other in days with a diagnosis stage bolted to the front. An hour band is a promise about the size of the work: someone already knows roughly what has to happen and is estimating how long it takes. A day schedule is a promise about the order of the work: the first block of time exists to find out what the following blocks will contain, and the range in the tail is honest uncertainty rather than padding.
That gives a simple rule for which to buy. If you can already name the problem in the language of the previous sections, an oversized hero, a font blocking the first paint, four tag manager scripts running before first interaction, then you are buying execution and the hour-banded line fits. If all you have is a symptom, a red score, a complaint from a paid traffic manager, or a suspicion, then you are buying knowledge first and the diagnosis-first line fits, and trying to skip that stage just moves the guessing into the invoice.
Note also what the two lines share: both are marked Experienced. Neither is work that can be handed safely to a beginner, because both involve editing the render path of a page that currently earns money, and a mistake there is not cosmetic. That shared difficulty rating is a more reliable signal than the price bands, which overlap at the bottom, both starting at $200. Difficulty tells you who has to do the work; the band only tells you how much of it there might be.
Mobile adaptation is an invoice for layout, not an invoice for speed
Website adaptation for mobile devices is a different category of problem that arrives wearing similar clothes. The catalogue files it under Layout, marks it Beginner, and prices it at $150 – $500 or 10 000 – 30 000 ₽ across 6-16 hours. Its description lists the symptoms it removes: the site stops sliding around on the phone, the menu behaves, buttons are actually clickable, text is readable, forms work, and the bulk of the traffic stops falling off on the first screen.
Read that list again against the three vitals and notice that none of those symptoms is a Core Web Vitals symptom. A site can score green on LCP, INP and CLS and still be unusable on a phone, because a metric that measures rendering speed has no opinion about whether your navigation is reachable with a thumb or whether your body text can be read without pinching to zoom. Conversely, a site can be beautifully responsive and painfully slow. These are independent failures, and paying for the wrong one is the most common way to spend money and change nothing.
The hour band here deserves a moment of attention, because 6 to 16 hours is close to a factor of three around a job the catalogue rates as Beginner. That combination is informative. The difficulty rating describes each individual fix, which really is routine; the width of the band describes how many times you have to do it. The driver is the number of distinct templates, not the hardness of any one of them, which means a buyer can predict their own position in the band before asking for a quote.
So count before you call. A one-page site with a header, a form and a footer is one layout. A shop with a home page, a category listing, a product page, a cart, a checkout, an account area and a set of content pages is seven or more, each with its own breakpoints, its own tables or grids and its own way of breaking. If you know that number, you already know whether to expect the bottom or the top of 6-16 hours.
What a PWA wrapper physically adds to a phone, and what it does not
PWA wrapper: website as an application on the phone is priced in the catalogue at $100 – $400 or 8 000 – 25 000 ₽, across 6-14 hours, in the Mobile category at difficulty Experienced. The description is a list of four physical changes rather than a claim about quality: the site can be placed on the home screen, it opens without the browser line, it works offline, and it can send push messages. It adds that this is tens of times cheaper than a native application and does not go through store moderation.
The pairing of the lowest dollar band in this group with an Experienced difficulty rating is not a contradiction, and it is worth understanding before you compare it with anything else. The surface area is small, which is what keeps the price at the bottom of the group. The risk is not small, because the mechanism is a service worker, a piece of code that sits between the phone and your server and decides what to serve from cache. Scope that cache carelessly and returning visitors are served yesterday's prices, and a plain page reload will not clear them.
It is equally important to be clear about what this line does not do. A PWA wrapper is not a Core Web Vitals fix. Field data is gathered from real visits, and a large share of the visits that matter for a public site are first visits from people who have never installed anything. Caching improves the second visit and the tenth; it leaves the first one exactly as slow as it was. Buying a wrapper to rescue a red LCP is buying the wrong line at the right price.
The buyers for whom it does pay are recognisable. Products people return to weekly rather than annually. Order tracking, booking and account screens where offline access to the last known state is genuinely useful. Field staff on unreliable connections. Businesses whose customers keep asking for an app when what they actually want is an icon on the home screen and a notification, both of which arrive here for 6-14 hours of work instead of a native build and a store review.
Reading a symptom backwards into a price band
The whole point of knowing what each metric physically measures is that you can run the diagnosis in reverse, from complaint to catalogue line, before you talk to anyone. The screen stays blank for a beat and then everything appears at once: that is LCP, the cause is in the hero and the render path, and the shape of the fix matches Green PageSpeed and Core Web Vitals at 5-12 hours. Nothing happens when a button is tapped, then everything happens at once: that is INP, and the cause is code on the main thread.
I pressed the wrong thing because it moved under my finger: that is CLS, and the cause is space that was never reserved. The text is microscopic and the menu runs off the edge of the screen: that is not a vitals problem at all, and it belongs to Website adaptation for mobile devices, Layout, Beginner, $150 – $500, 6-16 hours. Our customers keep asking whether we have an app: that is the PWA wrapper at $100 – $400, and it should be evaluated on repeat-visit behaviour rather than on any speed score.
One more piece of arithmetic, again offered as an example the reader can check rather than as a published rate: the Green PageSpeed line quotes $200 – $600 against 5-12 hours. Dividing the bottom of the money by the bottom of the hours and the top by the top gives figures in the same neighbourhood at both ends, which tells you the band is scaled by volume of work rather than by how much the client appears able to pay. You can run the same division on any line in the catalogue that publishes both numbers.
Bring three things to the first conversation and it will be short. The URL, so both readings can be taken before anything is touched. The device the complaints come from, because mobile and desktop fail for different reasons and the catalogue targets the mobile profile. And an honest answer about whether you can name the cause or only the symptom, because that single answer decides between an hour-banded optimisation pass and a diagnosis, and the diagnosis on its own is available at 8 000–15 000 ₽ precisely so that answering it does not require committing to the rest.
Questions and answers
How much does it cost to get Core Web Vitals into the green?
It depends on whether you are buying execution or an investigation. The catalogue prices Green PageSpeed and Core Web Vitals at $200 – $600, or 8 000 – 25 000 ₽, across 5-12 hours, for a site whose problems are already identified. Website acceleration and Core Web Vitals under Google's threshold is $200 – $800 and runs as one day of diagnostics plus one to three days of implementation, targeting INP up to 200 ms, LCP up to 2.5 s and CLS up to 0.1.
Can I pay for the speed audit without the fixes?
Yes, and it is priced separately for exactly that reason. The catalogue lists audit only, without fixes, at 8 000–15 000 ₽, against 10 000 – 40 000 ₽ for diagnosis with implementation. That option suits teams who already employ developers and need a prioritised list of causes rather than hands, since the same investigation produces the task list either way.
Will a PWA wrapper make my site pass PageSpeed?
No, and it is not sold as one. PWA wrapper: website as an application on the phone costs $100 – $400 or 8 000 – 25 000 ₽ across 6-14 hours, and what it adds is a home-screen icon, launch without the browser line, offline operation and push messages. Caching helps returning visitors; the first visit, which is where a red LCP is earned, is unaffected. The two speed lines are separate purchases.
Is mobile adaptation the same thing as speed optimisation?
No. Website adaptation for mobile devices sits in the Layout category at difficulty Beginner, $150 – $500 or 10 000 – 30 000 ₽ across 6-16 hours, and fixes a menu that does not work, buttons that cannot be tapped, unreadable text and broken forms. Core Web Vitals work targets rendering and interaction timing. A site can pass all three vitals and still be unusable on a phone, so the two diagnoses are independent.