ES Get a quote
● Service · Performance

Core Web Vitals optimization sprint: fix the INP that holds you back

Your site fails Core Web Vitals, and most likely it is INP, the metric that measures how long your site takes to respond to a tap and that 43% of sites do not pass. Google uses it as a ranking factor, and page builders fail it because they load hundreds of kilobytes of JavaScript. We run a fixed-scope sprint to fix it: we diagnose the real bottleneck, optimize what is fixable, measure with real data, and tell you honestly if the ceiling is architecture.

See plans and pricing ↓ CWV diagnosis
43% of sites fail INP the most failed CWV
< 200ms the INP threshold what Google asks for
200–500KB page builder JS the most common cause
Fixed scope it is a sprint not a bag of hours

INP: the most failed Core Web Vital in 2026

Of the three metrics that make up Core Web Vitals, one became the headache of 2026: INP, which measures how long your site takes to respond when someone interacts with it. It replaced the old FID metric in March 2024, and it is considerably tougher, because it measures not just the first tap but the response throughout the whole visit. The data confirms it: around 43% of sites do not pass the 200-millisecond INP threshold, a higher proportion than those failing on loading or visual stability. When this metric arrived, mobile Core Web Vitals pass rates dropped several points at once, because many sites that passed with the previous metric stopped passing.

This matters because Core Web Vitals are a ranking factor, and INP, being the most failed, often becomes the tiebreaker between two pages that otherwise compete evenly. It is not the only signal Google looks at, but it is one of those that separate the site that appears on top from the one that stays below when everything else is equal. Failing it, then, is not an abstract technical detail: it is losing positions and, with them, visits and sales, for a cause that can almost always be addressed.

Why your site fails INP: almost always JavaScript

The underlying cause, in the vast majority of cases, is excess JavaScript competing for the browser\'s main thread. The browser does many things on a single thread, and among them is responding to the user\'s taps; if that thread is busy running code, the response is delayed, and that is exactly what INP penalizes. Page builders and feature-loaded templates usually ship between 200 and 500 kilobytes of JavaScript, much of which is not even used, and all that weight translates into a busy browser right when the user wants it to react.

There is a contrast that says it all: well-built static sites, with less than 100 kilobytes of JavaScript, pass INP below 100 milliseconds with no optimization at all, simply because they do not give the browser that weight to attend to. That is, the problem is not inevitable, it is a direct consequence of how the site is built. That is why an optimization sprint attacks precisely that excess: what can be deferred, what can be reduced, what can be removed because it adds nothing. Cutting the weight that chokes the main thread is the heart of the work.

What the sprint fixes, and how

The sprint attacks all three metrics, with the focus where it hurts most. For INP, the work is on the JavaScript: defer what is not needed immediately, split the code so it does not all run at once, reduce or remove what is excess, and lighten the tasks that block the main thread, so the browser is free to respond quickly to each interaction. For loading, we attack what delays the main content from appearing: unoptimized images, render-blocking fonts, resources that compete for bandwidth at the worst moment.

For visual stability, we correct the elements that shift while the page loads —images without reserved dimensions, ads or blocks that push the content—, which are the ones that cause those annoying jumps right when you are about to tap something. All of this with a fixed scope agreed in advance: you know what will be touched, what result is sought, and when it ends. It is not open-ended maintenance or a bag of hours, it is a job with a clear beginning, scope and end, measured before and after so the improvement is verifiable and not a feeling.

The honest ceiling: when it is architecture, not tuning

Here is the part almost nobody tells you: an optimization sprint has a ceiling, and it is worth knowing before you start. On a reasonably healthy site, the tune-up is enough to cross the thresholds and the improvement is clear. But if the underlying cause is a heavy architecture —a builder that loads its own inevitable weight, a tangle of plugins that cannot be unraveled without dismantling the site—, the tune-up hits a limit: you can improve, but not arrive, and forcing it means paying a lot for a half result.

That is why the sprint always starts with a diagnosis that answers a key question: does this get fixed on your current site, or is the ceiling architecture? If it is the former, we do the sprint and that is it. If it is the latter, we tell you honestly instead of charging you to fight a ceiling, and we propose the rebuild on a fast base that, by design, passes these metrics effortlessly. That honesty is the service: we would rather lose the sprint sale than sell you one we know will not reach the threshold.

How we measure: for real, not in the demo

Measuring well is half the work, and it is where there is most deception. There are two types of Core Web Vitals measurement, and confusing them is the most common trap. The lab one is what a tool gives at a single moment, with a simulated device: it produces numbers that look good but are not the ones Google uses to rank. The field one is what really counts: it comes from your users\' real visits, with their real phones and connections, and it is what determines whether you pass or not for ranking purposes.

We work for the real thresholds and measure with that logic, not with the screenshot of an inflated number. That is why we do not promise a score of one hundred on a tool: that score can be perfect in the lab and still fail in the field, where your real users are. What we promise is to attack the real causes, measure before and after with data that reflects the real experience, and leave verifiable proof of the improvement. It is the same philosophy that defines this site: we do not describe quality, we demonstrate it with metrics anyone can check.

Public plans and pricing

We publish the prices because transparency is part of the product. Three levels, depending on whether you want to know where the bottleneck is, fix it, or solve the case where the ceiling is architecture.

Starting point

CWV / INP diagnosis

USD 400one-time

To identify the real bottleneck and know whether it is fixable on your site or whether the ceiling is architecture, before investing in the sprint.

  • Measurement of your Core Web Vitals in lab and field data
  • Identification of the real bottleneck, metric by metric
  • Analysis of JavaScript weight and the main thread
  • Honest verdict: fixable with a sprint or architectural ceiling
  • Readable report with a prioritized plan and a 45-minute meeting
Delivery: a few business days
The sprint

CWV optimization sprint

from USD 1,200/ fixed scope

We fix your Core Web Vitals on your current site, with a focus on INP, an agreed scope and a measurable improvement.

  • Diagnosis included
  • JavaScript optimization: defer, split, reduce, lighten the main thread
  • Loading optimization: images, fonts, blocking resources
  • Visual stability and content-shift correction
  • Before-and-after measurement with real data
  • Fixed scope and timeline, agreed before starting
Normally 1 to 2 weeks after the diagnosis
When tuning is not enough

Fast rebuild

from USD 3,000/ project

When the ceiling is architecture, we rebuild on a static base that passes these metrics by design.

  • Rebuild on a fast static architecture (Astro)
  • Less than 100KB of JavaScript: passes INP without forcing anything
  • Same design and content, now fast to respond
  • Core Web Vitals in green by design, not by patch
  • Falls under our migration or redesign service
Scope and final price after the diagnosis

Any plan adapts to your case. The diagnosis defines the scope and the final price, which you see before committing. For a business losing positions and sales to a site that is slow to respond, recovering the thresholds usually pays for itself.

What your business gains when the site responds fast

It is worth closing with what really matters: not the milliseconds themselves, but what they change for your business. There is an old principle of human-computer interaction, the Doherty threshold, which observed something still true: when a system responds in under 400 milliseconds, the person stays engaged and in flow; when it takes longer, their attention scatters and the sense of control breaks. A site that responds below that threshold feels fluid and keeps the user moving forward; one that drags when tapped pushes them, without their being able to name it, to hesitate and leave. INP measures exactly that border between fluid and frustrating.

That translates into two concrete effects. The first is conversion: every friction in the response is a chance for the visitor to abandon before buying, booking or contacting, so a site that responds fast converts better with the same traffic. The second is ranking: since INP is a ranking factor and the one most sites fail, passing the threshold separates you from the majority that does not, right at the tiebreaker. Together, they mean more visits that arrive and more visits that stay and act. That is why a Core Web Vitals sprint is not a technical whim: it is recovering sales and positions that a site slow to respond is losing in silence, and doing it measurably so the result is shown, not promised.

And there is a detail that makes it even more profitable: unlike an ad campaign, which stops paying off the day you stop paying, a site that responds fast keeps converting and ranking better month after month at no extra cost. The sprint is an investment you make once and that pays off in a sustained way, because it fixes the cause instead of buying traffic to cover the symptom. For a business that depends on its site to sell or generate leads, few technical investments return as reliably as making the site quick to respond, and few are as easy to verify after the fact with real numbers rather than promises. That verifiability is the whole point: you should be able to see the before and the after, on your own real users, and judge the result for yourself.

How it relates to the web audit

It is worth placing this sprint next to other things we offer, because they are different stages and get confused. A free speed test is a first signal you run yourself to see if you have a problem. The web audit is a broad diagnosis of your whole site, not just speed. The Core Web Vitals sprint is the execution of the performance fix, with a fixed scope and a measurable result. Put short: the test warns you, the audit gives the full picture, and the sprint fixes the speed. If you already know your problem is that your site responds slowly, the sprint goes straight to that, no detours.

Frequently asked questions about the Core Web Vitals sprint

What is INP and why is it the most failed Core Web Vital?
INP, or Interaction to Next Paint, measures how long your site takes to respond when someone taps or clicks: the time between the user's action and the moment the screen reacts. It replaced the old FID metric in March 2024, and it is far more demanding, because it no longer measures just the first tap but the response throughout the whole visit. It is the one most sites fail: around 43% do not pass the 200-millisecond threshold, more than those failing on loading or visual stability. The reason is that INP punishes excess JavaScript, which is exactly what sites built with page builders and heavy templates have too much of. When two pages compete to appear on Google, metrics like this act as a tiebreaker, so failing it costs positions.
Why does my site fail Core Web Vitals?
In the vast majority of cases, because of excess JavaScript competing for the browser's main thread. Page builders and feature-loaded templates usually ship between 200 and 500 kilobytes of JavaScript, and all that code has to run on the same thread that needs to attend to the user's taps. The result is that, when someone interacts, the browser is busy and is slow to respond, which is exactly what INP penalizes. To that are added loading causes —unoptimized images, render-blocking fonts— and stability ones —elements that shift while the page loads. The underlying pattern repeats: sites built to look good in the demo, but loaded with weight that on a real phone, with a real connection, makes them slow to respond.
Can you fix it without rebuilding my site?
In many cases yes, and that is precisely the goal of the sprint: to fix what is fixable on your current site, without rebuilding. There is a lot that can be improved on the site you already have —deferring and reducing JavaScript, lightening the main thread's work, optimizing images and fonts, stabilizing what shifts—, and for a significant share of sites that is enough to cross the thresholds. But we are honest about the ceiling: if the underlying cause is a heavy architecture fighting itself, the tune-up has a limit, and forcing it gets expensive for a half result. The initial diagnosis tells you which of the two cases you are in, so you do not pay for a sprint that will not reach the threshold when the honest thing was to talk about architecture.
Do you guarantee a score of 100 on PageSpeed?
No, and distrust anyone who promises it, because it reveals they do not understand how Core Web Vitals are measured. There are two types of measurement: lab, which is the pretty number a tool gives at a single moment, and field, which is the one Google actually uses and which comes from your users' real visits, with their real devices and connections. A lab score of 100 means nothing if in the field your real users still fail the threshold. What we do is work so your site passes the real Core Web Vitals thresholds —INP, loading, stability— and measure it with real data, not with a screenshot of an inflated number. We promise method and honest measurement, not a vanity number.
How is the sprint different from the web audit?
In that each is a different stage of the same path. A free speed test is a first signal you can run yourself to see if you have a problem. The <a href="/en/services/web-audit/">web audit</a> is a broad diagnosis of your whole site —SEO, performance, accessibility, conversion— that tells you what is wrong in general. The Core Web Vitals sprint is the next step: it does not diagnose broadly, it fixes a specific problem —your Core Web Vitals, especially INP— with a fixed scope and a measurable result. Put simply: the test warns you, the audit explains the whole picture, and the sprint executes the speed fix. If you already know your problem is speed, the sprint goes straight to the point.
How long does the sprint take?
It is a fixed-scope, time-bounded job, which is exactly what makes it a sprint and not an open-ended bag of hours. After the diagnosis, which takes a few days, the optimization sprint is normally executed in one to two weeks depending on the state of your site, with a scope agreed in advance so you know exactly what will be touched and what result is sought. We work on a copy or a safe environment, measure before and after, and only consider it finished when the changes are applied, tested and the improvement is verifiable. It is not an open process that drags on without end: it has a clear beginning, scope and end, because part of the value of a sprint is that you know when it finishes and what it delivers.
How much does the Core Web Vitals sprint cost?
We publish it openly. The diagnosis, which identifies the real bottleneck and tells you whether it is fixable on your site or whether the ceiling is architecture, costs USD 400 as a one-time job. The optimization sprint, with an agreed fixed scope, starts at USD 1,200 depending on the state of your site. And if the diagnosis reveals the problem is architectural at the root and the tune-up will not reach, the fast rebuild starts at USD 3,000 and falls under our migration terrain. These are clear references: the exact scope comes out of the diagnosis and you see it before committing. For a business losing sales and positions to a site that is slow to respond, recovering the thresholds usually pays for itself in conversion and ranking.
Does it work for WordPress or my page builder?
It does, and in fact those are precisely the cases where the problem shows most and, sometimes, is hardest to fully solve. WordPress with many plugins and visual builders tend to be the ones that load the most JavaScript, so they are the ones that fail INP most, and a sprint can improve things considerably even there: reduce what can be deferred, remove what is excess, optimize the obvious. But it is also where it hits the architectural ceiling soonest, because part of the weight comes from the builder itself and cannot be removed without dismantling the site. That is why in these cases the diagnosis matters even more: we honestly tell you how much can be gained with a sprint on your current install and from where the sensible answer is another architecture. Without that honesty, we would charge you to fight a ceiling.