core web vitals are not an seo trick
dev · Oct 6, 2026 · 3 min read
every agency site in italy has the word "veloce" somewhere in it. fast, modern, optimized. i have never seen one put a number next to the word, and after measuring a few out of curiosity i understand why: the numbers would embarrass them.
so this is the number side of the pitch. what core web vitals actually are, how i measure them on this site, and what they are worth when someone quotes you a new website.
what they are
three measurements google takes of real visits:
- LCP — how long until the main content of the page is visible. good is under 2.5 seconds
- INP — how long until the page reacts when you tap something. good is under 200 milliseconds
- CLS — how much the layout jumps around while loading. good is under 0.1, which in practice means: it does not jump
they are not an seo ritual. they are the difference between a page someone waits for and a page someone reads. on a phone, on a bad connection, the fast site is the one that gets the contact.
how i measure them
two tools, both free: pagespeed insights for the lab numbers, and the chrome user experience report for what real visitors actually experienced. the lab number is what you can fix today; the field number is the truth that arrives months later. anyone who shows you only the lab number is showing you the easier half.
what i did on this one
this site is the first case study, because i can publish its numbers without asking anyone's permission. measured today, in the lab, on a cold load:
- the html document is 16 kb, and it is complete before any javascript runs: the build prerenders one document per route and language — the sitemap counts them on every build
- first byte in 227 ms, page fully loaded in 658 ms
- layout shifts: zero. nothing on the page moves after it arrives
- the build itself fails if a contrast check fails: 50 cases measured on every build, not promised in a pdf
none of this is exotic. it is a handful of decisions made once, at the start: prerender instead of client-only rendering, one variable font instead of five, images sized before they are inserted. the speed of a site is decided at the architecture table, not in the "ottimizzazione" phase at the end, which is the phase that does not exist because the budget is over.
what it means if you are buying a site
when someone quotes you a website and promises it will be fast, ask for three numbers: LCP, INP, CLS, measured on the finished site, not on the demo. if the answer is a smile, you have your answer.
a fast site does not just rank a little better. it converts: every second of waiting is someone closing the tab before reading what you do. and the fix is rarely a redesign — it is how the site is built, which is why i measure it in the build and publish the result, instead of using the word "veloce" and hoping you will not ask.