Website speed is no longer a technical detail that “the server person” deals with. For the visitor, it’s a first impression. For the business owner, it’s a real chance at an enquiry, a sale — or a lost customer. For Google, it’s one of the things it uses to judge the quality of the experience on a page.
And that’s where Core Web Vitals come in — the set of metrics Google uses to assess how a page behaves in the real world. Not in ideal conditions. Not just on a developer’s fast computer. It’s about real users, real phones, real connections and how the page really behaves while it loads, scrolls and is clicked.
In practice, the question is no longer just: “does the site look nice?”. The question is: does the site load quickly, respond smoothly and not annoy the visitor?
A fast site won’t replace good content, but a slow one can waste it
In SEO it’s easy to fall into extremes. Some say content is all that matters. Others chase a 100/100 in PageSpeed Insights as if the score alone would sort out their Google rankings. The truth is more down to earth.
Google still wants to show people the most relevant, helpful and trustworthy results. Site speed alone won’t make weak copy suddenly outrank a good guide from a competitor. But if two pages answer a similar question, and one works smoothly, clearly and without frustration while the other loads slowly, jumps about as it loads and blocks clicks — the first one gives the visitor a better experience.
For years Google has said that its ranking systems try to reward content that provides a good user experience. Core Web Vitals are part of that picture. They aren’t the only factor, but they aren’t just decoration in a report either.
For a business that means one thing: optimising site speed isn’t a technical indulgence. It’s part of SEO, UX, conversion and plain credibility.
What are Core Web Vitals?
Core Web Vitals are three main metrics that show how the visitor experiences the page. They don’t measure everything, but they capture three critical moments well:
- how quickly the main content appears,
- how quickly the page responds to an interaction,
- whether the layout is stable while it loads.
The metrics are:
- LCP — Largest Contentful Paint, the time it takes for the largest visible element to load,
- INP — Interaction to Next Paint, the page’s response to the visitor’s actions,
- CLS — Cumulative Layout Shift, the visual stability of the layout.
It sounds technical. But behind each of those names is a very simple human experience of someone who has landed on the page.
LCP — how quickly does the visitor see the main content?
LCP measures how long it takes for the largest visible element on the page to load. Most often that’s a big hero image, a heading, a block of text or a graphic that the visitor sees as the main part of the first screen.
If the LCP is good, the visitor quickly sees that the site is working and that it’s worth waiting. If the LCP is poor, the screen looks empty for a few seconds, then the background loads, then the image, then the font, then something else shifts. The visitor isn’t analysing the technology. They simply feel that the site is slow.
Google recommends keeping LCP within 2.5 seconds. That doesn’t mean a site suddenly vanishes from the results at 2.6 seconds. But it shows the direction: the main content should appear quickly.
The most common LCP problems are:
- an image that’s too big in the first view of the page,
- heavy sliders and animations in the hero,
- a slow server,
- too much render-blocking JavaScript,
- fonts loaded in a way that delays showing the content,
- a theme or builder generating excess code.
In practice the problem very often sits in the first screen. A site can have great content further down, but if it loads a huge image, a few scripts and an animated slider at the start, the visitor waits. And Google sees that the main content appears too late.
INP — does the page respond when the visitor does something?
INP is the metric that shows how quickly the page responds to the visitor’s interactions. Clicking a button, opening a menu, typing text, clicking a filter, working through a form — it all counts.
A good site doesn’t just appear quickly. It also has to respond quickly.
You can have a site that looks loaded, but after you click the menu nothing happens for a moment. Or the visitor taps a button on their phone and doesn’t know whether they clicked it or the site has frozen. That’s exactly the problem of interactivity.
Google recommends an INP of 200 milliseconds or less. For the visitor that means the site responds almost instantly.
The most common causes of poor INP are:
- too much JavaScript,
- heavy libraries loaded on every page,
- slow third-party scripts,
- elaborate page builders,
- needless effects and animations,
- too much work done by the browser at once.
This is one of the biggest differences between a light site and one “cobbled together” from lots of add-ons. On paper they can look similar. In practice one responds instantly while the other keeps stuttering.
CLS — why shouldn’t a page jump about as it loads?
CLS measures layout stability. It’s about whether elements on the page move unexpectedly while it loads.
You know the moment: you go to click a button, but suddenly an ad, an image or a bar pops in and you click something else. Or you start reading and the heading shifts down because a font or image has only just loaded. It’s irritating. And that’s exactly what CLS measures.
A good CLS score is 0.1 or less. The fewer unexpected shifts, the better.
Typical causes of CLS problems:
- images without set dimensions,
- banners that load after a delay,
- ads and embedded elements with no reserved space,
- fonts that cause the text to jump,
- dynamic sections that appear above content the visitor is already looking at.
CLS often seems like a trifle, until you hit a page that slips out from under your finger. On a phone it’s especially irritating. And in many sectors most traffic comes from mobile.
Core Web Vitals and Google rankings — without the myths
It’s worth saying this honestly: Core Web Vitals are not a magic button to the top of Google.
If a page has weak content, badly chosen keywords, poor structure, no sensible headings and doesn’t answer the visitor’s intent, a good PageSpeed score won’t save it. Google still, above all, wants to understand whether a page answers a person’s query.
But speed and user experience can help. Especially when the competition is close. If several pages have similar content quality, a similar topic and similar credibility, a better experience can tip the balance.
Google also stresses that there’s no single separate “page experience signal” that decides rankings on its own. The ranking systems look at many signals. Core Web Vitals are one part of a bigger whole.
So the best approach is simple: we don’t optimise a site just to please a tool. We optimise it so the visitor sees the content sooner, clicks more easily, reads more calmly and is more inclined to take action.
PageSpeed Insights, Lighthouse and Search Console — how do they differ?
Site owners often check the score in PageSpeed Insights and treat it as a verdict. Green — good. Orange — panic. Red — disaster. That’s understandable, but it’s worth knowing what these tools actually show.
PageSpeed Insights shows lab data and — where available — data from real user visits. The lab data is useful, because you can quickly check a specific page. But it doesn’t always show the full picture of real traffic.
Lighthouse works more like a technical test. It helps flag problems: heavy scripts, images, blocking resources, fonts, accessibility, technical SEO. It’s a good tool for the developer, but a single test doesn’t always reflect what all users see.
Google Search Console shows a Core Web Vitals report based on real-world usage — that is, field data. That’s very important, because Google doesn’t only look at ideal conditions. It looks at how the site performs for real people.
So when diagnosing, it’s worth looking at several sources at once. PageSpeed Insights gives a quick picture. Lighthouse flags the technical problems. Search Console shows whether the problem affects a single page or a larger group of URLs.
Why does a WordPress site often lose speed?
WordPress in itself isn’t the enemy. The problem starts when, over the years, you keep adding layers to it.
A premium theme. A builder. Builder add-ons. A form. A slider. An SEO plugin. A cache plugin. An image plugin. A cookie plugin. A security plugin. An icon plugin. An animation plugin. Over time the site starts to resemble a storeroom of things that were once needed but nobody remembers why.
A site like that can still look fine from the outside. The problem is underneath: more CSS, more JavaScript, more queries, more dependencies, more risk after updates.
That hits Core Web Vitals directly:
- LCP suffers, because the first content loads too slowly,
- INP suffers, because the browser has too many scripts to run,
- CLS suffers, because elements appear and shift at the wrong moment.
So sometimes optimising WordPress helps, and sometimes it’s just papering over the cracks. If the foundation is heavy, each new fix achieves less. We write more about this in Why Astro instead of WordPress?.
Why do light sites have the advantage?
A light site has fewer things to load, fewer scripts to run and fewer elements that can break. That doesn’t mean it has to be visually plain. It can look very good. The difference is that it doesn’t drag along a whole load of needless features.
For business websites, landing pages, blogs and many service sites, you often don’t need a heavy CMS. The site needs to present the offer, explain the service, build trust and lead to a contact. If there’s no daily editorial work, no user accounts and no complicated panels, a lighter stack can be the more sensible choice.
This is exactly where solutions like Astro and Tailwind come into their own. Astro lets you generate fast pages, and Tailwind helps keep the interface tidy without adding a heavy builder. For the visitor the effect is simple: the site opens faster, runs more smoothly and doesn’t wear them out.
How does speed affect conversion?
Google rankings are one thing. What the visitor does after they land on the site is another.
You can win traffic from SEO, but if the site loads slowly, some people will leave before they read the offer. You can pay for Google Ads, but if the landing page is heavy, the budget works less hard. You can have great copy, but if the form responds slowly or the page jumps about as it loads, the visitor loses patience.
So site speed affects not just technical SEO but trust too. A slow site looks less professional. Especially if the business sells modern, technological or premium services. The visitor thinks simply: if their own site runs heavily, what will working with them be like?
What slows sites down most often?
Not every slow site has the same problem. But after years of working on sites, you see certain recurring patterns.
The usual culprits are:
- images that are too big, especially in the hero section,
- sliders loaded on the first screen,
- an excess of plugins and scripts,
- heavy fonts and too many typefaces,
- page builders generating a lot of code,
- unused CSS and JavaScript libraries,
- external embeds: maps, chats, pixels, widgets,
- weak hosting,
- no CDN,
- badly configured caching,
- no reserved space for images and dynamic elements.
Often a single problem isn’t a disaster. But ten small problems together can make a site that barely limps along.
How do you improve LCP in practice?
First you need to find out what the LCP element is. Very often it’ll be a large image in the first view. Then the optimisation starts with the image.
Good moves:
- reducing the image dimensions to what’s actually needed,
- using modern formats, such as WebP or AVIF,
- setting the right image dimensions,
- prioritising the loading of the image visible at the start,
- cutting back on sliders and heavy animations in the hero,
- removing needless render-blocking scripts,
- improving the server response time.
On many projects the biggest gain comes from tidying up the first screen. Fewer flourishes, a better-prepared image, faster text, fewer blocking resources. The visitor doesn’t need to see everything at once. They need to quickly see what they came for.
How do you improve INP?
INP is harder, because it’s about the page’s response to the visitor’s actions. Here the problem is very often JavaScript.
It helps to:
- reduce the amount of script loaded on the page,
- remove libraries used only for small effects,
- break up long tasks the browser runs,
- load interactivity only where it’s needed,
- drop heavy external widgets,
- take a careful approach to chats, maps, pixels and marketing systems.
In practice it’s worth asking a simple question: does this script really have to be on every page? Very often the answer is no.
This is the advantage of sites built light. If interactivity is added only where it makes sense, the site has less work to do and responds faster.
How do you improve CLS?
CLS can often be improved without a major rebuild. You just have to stop letting elements “pop” onto the page without reserved space.
It’s worth:
- setting the width and height of images,
- reserving space for banners and embedded elements,
- being careful with fonts and how they load,
- not injecting dynamic blocks above content the visitor can already see,
- testing the site on a phone, not just on a big monitor.
Layout stability sounds less impressive than speed, but for the visitor it matters a lot. A site that doesn’t jump about feels calmer, more polished and simply more professional.
Core Web Vitals and mobile
The biggest problems usually show up on phones. An office computer with fast internet forgives a lot. A phone with an average signal doesn’t.
Mobile is the real test of a site’s quality. If a site runs smoothly on a phone, it’ll usually run well on the desktop too. The reverse isn’t always true.
So when optimising, it’s not worth looking only at the desktop version. The visitor isn’t always sitting at a big monitor. They often check a service in the car, on a break, in a corridor, between one task and the next. If the site doesn’t perform well then, it loses its chance.
Is it worth fighting for 100/100?
A 100/100 looks nice. It’s satisfying. It looks good in a portfolio. But it isn’t always the best business goal.
If a site scores 95 and converts well, and getting to 100 would take a week of work on small details, it might not be worth it. Better to spend that time on content, the structure of the offer, a better CTA or improving the service pages.
The goal isn’t a perfect score for its own sake. The goal is a fast, stable, comfortable site that helps the visitor and supports the business.
What should you check on your own site?
The simplest audit can start with a few questions:
- Does the main content appear quickly?
- Is the hero overloaded with an image or a slider?
- Do the menu and buttons respond instantly?
- Does the page avoid jumping about as it loads?
- Does the mobile version really work well?
- Are all the scripts necessary?
- Are the images optimised?
- Is the site avoiding loading marketing tools it doesn’t need?
- Does Search Console show any Core Web Vitals problems?
Questions like these quickly show whether the problem is cosmetic or whether the site needs a more serious tidy-up.
When to optimise, and when to rebuild the site?
Not every slow site needs rebuilding from scratch straight away. Sometimes it’s enough to fix the images, remove a few scripts, change how the fonts load and tidy up the caching.
But there are situations where optimising is like repairing an old car that’s had parts bolted on for over a decade. You can improve a few things, but the foundation stays the same.
A rebuild is worth considering when:
- the site runs on a heavy theme nobody wants to develop any more,
- the page builder generates too much code,
- there are a lot of plugins and each is “needed for something”,
- the mobile version needs rescuing,
- Core Web Vitals are poor across many pages,
- every change risks breaking something,
- the site no longer matches what the business now offers.
In that case a new, lighter project can be cheaper and more sensible than more months of patching the old system.
How does Astrofy approach speed?
At Astrofy we treat speed as part of the project, not a fix at the end. A site shouldn’t be heavy first and then “optimised” with a plugin. It’s better to build it from the start so it doesn’t carry needless ballast.
That’s why we use Astro and Tailwind. Astro lets us build light sites based on fast, well-organised code. Tailwind helps us build a consistent interface without heavy builders. Add to that a sensible content structure, good images, well-thought-out components and limiting JavaScript to where it’s actually needed.
The result? A site that’s fast not just on launch day but a few months into running too. Without piling on more layers nobody then wants to touch.
Site speed is part of trust
The visitor doesn’t always know what LCP, INP and CLS are. They don’t need to. They simply feel whether the site works well.
If it loads quickly, looks stable and responds smoothly, it builds trust. If it makes them wait, clicks go nowhere or the layout jumps about, irritation sets in. And irritation doesn’t sell.
For Google, site speed is one of the signals of a good experience. For a person it’s something even simpler: a sign that the business cares about the details.
And that’s exactly why Core Web Vitals are worth taking seriously. Not as a technical fad. Not as a chase for a green score. Just as a practical way of checking whether the site really is comfortable for the people who are meant to use it.
Need a faster site?
If your site loads slowly, has poor Core Web Vitals or only works well “on your own computer”, it’s worth checking. Sometimes a few specific fixes are enough. Sometimes the better move is to rebuild the site on a lighter stack.
Astrofy helps businesses create fast, light sites built on Astro and Tailwind — without a heavy CMS, without random plugins and without needless code. We can start with a free speed audit, identify the real problems and tell you honestly what’s worth fixing.
Because a fast site isn’t just a better score in a tool. It’s a better first impression, more comfort for the visitor and a stronger foundation for SEO.