Core Web Vitals are three Google measurements of how fast the main content of your page appears (LCP), how fast it reacts when someone taps something (INP) and how much the layout jumps while loading (CLS).
To be in the green you need an LCP of 2.5 seconds or less, an INP of 200 milliseconds or less and a CLS of 0.1 or less. Here is what each one means and what we did on mokev.net to go from 55 to 91 on mobile.
What are Core Web Vitals and what are their thresholds?
They are three metrics Google proposes to measure what real visitors experience on a page. According to web.dev, they are assessed at the 75th percentile of visits, with mobile and desktop split. In plain words: out of every four visitors, three need to have a good experience.
| Metric | What it measures | Good |
|---|---|---|
| LCP (Largest Contentful Paint) | When the largest element on screen appears | 2.5 s or less |
| INP (Interaction to Next Paint) | How fast the page reacts to a tap, click or key press | 200 ms or less |
| CLS (Cumulative Layout Shift) | How much content moves without you asking | 0.1 or less |
Think of a physical store: LCP is how long it takes to see the counter when you walk in, INP is how long the clerk takes to answer you and CLS is nobody moving the merchandise while you choose.
Is PageSpeed Insights the same as Core Web Vitals?
No. PageSpeed Insights shows two different things: data from real visitors (if your site has enough traffic) and a lab test on a simulated phone. Core Web Vitals are the real-visitor data. If your site is new, the real-users section will say "No data" (it happened to mokev.net in October 2026), and Google does not publish the minimum traffic it needs (Chrome UX Report).
The lab test uses Lighthouse. There, Total Blocking Time (TBT) works as an indicator of INP: web.dev calls it a lab proxy, not a replacement, and treats under 200 ms as good. Use it to find problems, but trust real data to know how your customers experience the site.
How did we take mokev.net from 55 to 91 on mobile?
We measured our own website on PageSpeed Insights on October 29, 2026. These were the results (mobile uses an emulated slow 4G connection):
| Before | After | |
|---|---|---|
| Mobile performance | 55 | 91 |
| Desktop performance | 63 | 97 |
| Mobile LCP | 8.0 s | 3.2 s |
| SEO | 85 | 100 |
These changes made the difference:
- Third-party scripts wait for someone to interact. Tag Manager, the Facebook pixel and HubSpot loaded as soon as the page opened and slowed everything down. Now they load on the first tap or scroll.
- The main text now counts as the LCP. Our headline appeared with an animation that started at zero opacity, and Chromium ignores elements with opacity 0. So the "largest element" ended up being the cookie notice, which appeared late. We changed the animation to only slide the text, and the main paragraph became the LCP.
- Less HTML and less JavaScript up front. We cut in half the review cards that were duplicated for the animated ribbon, we send the browser only the translations it needs, and we load the sign-in client when the browser is idle.
- Below-the-fold sections load lazily. With
content-visibility, the browser skips layout work for what is not visible yet.
Some things we tried and dropped: inlining the CSS in the HTML duplicated about 300 KB of data and was not worth it. And one thing is still orange: the mobile LCP of 3.2 s is above the recommended 2.5 s because three stylesheets block the first paint. web.dev recommends reducing or deferring blocking CSS; that is our next step.
What can you do on your site to improve each metric?
For LCP (loading):
- Find out which element is the LCP and how much of its time is "render delay": PageSpeed shows it under "LCP breakdown".
- Remove or defer styles and scripts that block the first paint.
- Return ready-made HTML from the server instead of waiting for JavaScript.
For INP (responsiveness):
- Break up long JavaScript tasks and delay scripts that are not needed at the start.
- Measure with real visitors: INP counts clicks, taps and key presses, not scrolling (web.dev).
For CLS (stability):
- Reserve space for images and videos by setting their dimensions.
- Animate with
transforminstead of changing position or size, as web.dev advises. - Watch out for ads, chat widgets and pop-ups that show up later and push content down.
When is it not worth obsessing over the score?
When your site is already green in real-user data. A lab number like 91 or 100 helps you find problems; it is not something to show off. Google recommends good Core Web Vitals but does not promise that they alone will put you first (Google Search Central). If you already pass, spend your time on useful content.
If your store or website is slow and you do not know where to start, our web development and e-commerce work includes checking these metrics. You can also write to us and we will measure your site.
Frequently asked questions
What is a good PageSpeed score?
PageSpeed colors 90 to 100 green, 50 to 89 orange and 0 to 49 red. Aim for green, but look at LCP, INP and CLS with real data first.
Do Core Web Vitals affect Google rankings?
Google recommends good values and says they align with what its core ranking systems seek to reward. It does not guarantee a position on their own.
Where can I see my site's Core Web Vitals?
In the Core Web Vitals report in Search Console and in the real-users section of PageSpeed Insights. If you see "No data", your site does not have enough visits yet.
What is the 75th percentile?
It is the value that covers 75% of visits. If your 75th-percentile LCP is 2.4 seconds, three out of four people saw your page load in that time or less.
How long until an improvement shows up?
It depends on your traffic: real data builds up with visits. The PageSpeed lab test changes immediately, as soon as you publish the fix.
