Core Web Vitals for Small Businesses: What They Are and How to Fix Them

A visitor taps your link on a phone, on mobile data, on a tram. The page shows a blank screen for three seconds, then jumps around while they try to press "Call". Most of them are gone before they ever see your offer.

That experience is what Google's Core Web Vitals try to measure. They are three numbers that describe how fast a page loads, how quickly it reacts, and how stable it is while loading. This guide explains them in plain language, shows how to test your own site for free, and lists the fixes that usually matter most.

One honest caveat first. Core Web Vitals are part of Google's page experience signals, but relevance and content quality still matter far more for rankings. Think of speed as a tiebreaker in search and a big lever for conversions: a faster page loses fewer visitors before they act. That second reason alone is worth the effort.

The three metrics, in plain language

Google judges these at the 75th percentile of real visits, separately for mobile and desktop. In practice: three out of four of your visitors should have a good experience, and mobile is the one to worry about, because that is where most people are and where devices and networks are weakest.

INP replaced the older FID metric in March 2024, so guides that still talk about "First Input Delay" are out of date.

Lab data versus field data

This trips up a lot of people.

• Field data comes from real Chrome users visiting your site. It is what Google uses. It only exists if your site gets enough traffic, so small sites often see "not enough data".
• Lab data comes from a simulated test (Lighthouse) that loads your page on a throttled virtual phone. It is repeatable and great for finding problems, but it is not what Google grades you on.

If you have no field data, use lab data as a guide and fix the issues it points to. If you do have both, trust the field data for the score and the lab data for the diagnosis.

How to test your site for free

1. PageSpeed Insights (pagespeed.web.dev): enter a URL and read the mobile results first. Look at the field data section at the top, then the diagnostics below.
2. Google Search Console: the Core Web Vitals report groups your pages and shows which ones are slow. It is the best way to find patterns across a whole site.
3. Chrome DevTools, Lighthouse tab: run it in an incognito window to avoid extensions distorting the result.
4. Test real pages, not only the homepage. Your service pages and blog posts are what people land on from search.
5. Run each test two or three times. Results vary, so look at the trend rather than one number.

Fixing LCP: make the main content appear sooner

Find out what your LCP element is (PageSpeed Insights names it). It is almost always the hero image, a large heading or a background image.

• Compress and resize images. A 4,000-pixel photo straight from a phone camera, shown in a 400-pixel space, is the most common speed killer we see. Export at the size it is actually displayed, and use modern formats such as WebP or AVIF.
• Do not lazy-load the hero image. Lazy loading is right for images below the fold, and wrong for the first big thing on the page. Mark the hero image as high priority (for example with fetchpriority="high") and preload it if needed.
• Improve server response time. If the server takes a second just to reply, nothing else can be fast. Cheap overloaded hosting, no caching and heavy database queries are the usual causes. Static or pre-rendered pages served from a CDN are very fast by design.
• Remove render-blocking resources. Large CSS or JavaScript files loaded in the head delay everything. Load only what the first screen needs, and defer the rest.
• Skip heavy hero sliders and autoplay background videos unless they earn their cost. A single strong image usually converts as well and loads far faster.

Fixing INP: make the page respond instantly

Slow interaction almost always means too much JavaScript competing for the phone's processor.

• Audit third-party scripts. Chat widgets, tag managers, heatmaps, social feeds, review carousels and ad pixels each add weight. Remove the ones nobody looks at.
• Load non-essential scripts after the page is usable. A chat widget does not need to load before the content.
• Watch heavy page builders and plugin stacks. Every extra plugin or effect tends to add script the visitor must download and run.
• Keep cookie banners lightweight. A bloated consent tool can make the whole page feel sluggish. Choose a lean one.
• Prefer simple interactions. Menus, accordions and forms should not need megabytes of code.

Fixing CLS: stop the page jumping

Layout shift happens when something loads late and pushes content around.

• Set width and height on every image, video and embed, so the browser reserves the space before the file arrives.
• Reserve space for banners. Cookie notices, promo bars and announcement strips should not shove the page down after it appears. Overlay them or reserve their height.
• Handle fonts carefully. When a web font swaps in and changes text size, lines reflow. Use font-display: swap with a well-matched fallback font, and preload your main font.
• Never insert new content above what the visitor is already reading, unless they triggered it.
• Animate with transforms and opacity, not with properties that change layout.

A Latvia-specific font trap

Many sites load a "Latin" subset of a web font to keep files small. That subset does not include the characters Latvian needs (ā, č, ē, ģ, ī, ķ, ļ, ņ, š, ū, ž). The browser then falls back to a different font for those letters, which looks uneven and can shift the layout. If you use Google Fonts or self-host, make sure you include the Latin Extended subset. It is one of the small details a generic template ignores.

Hosting, caching and where your server is

Time to first byte (TTFB) sets the ceiling for everything else.

• Host in or near the EU if your visitors are in Latvia and the Baltics.
• Use caching, and a CDN for static files.
• Avoid overloaded shared hosting for anything business-critical.
• Pre-rendered or static pages beat pages built from scratch on every request. Modern frameworks such as Next.js can generate pages ahead of time, which is one of the reasons the sites we build load quickly.

What to expect from your platform

• WordPress: very capable, but speed depends on your theme, plugin count, page builder, hosting and caching. A lean theme with a caching plugin and optimised images can be fast. A theme with twenty plugins usually is not.
• Wix, Squarespace and similar builders: you can trim apps, animations and image sizes, but you cannot change the underlying platform, so there is a ceiling. Our comparison Wix vs WordPress vs a custom-built website goes into this.
• Custom-built sites: the most control and usually the best ceiling, but only if the developer actually cares about performance.

The order to fix things in

Do the biggest wins first:

1. Images: resize, compress, modern format, correct priority.
2. Third-party scripts: remove or delay what you can.
3. Fonts: fewer weights, correct subsets, preload the main one.
4. Hosting and caching: fix slow server response.
5. Code and layout: only then dig into finer optimisation.

Do not chase a perfect 100 in Lighthouse. Aim for "good" on all three Core Web Vitals on mobile, and stop there. Beyond that, effort is better spent on content and on what your visitors actually do on the page.

Speed is part of the price of a good website

A website built with speed in mind costs more attention than one that merely looks fine, but that work pays back through better search visibility and more enquiries. We cover the other budget items in our guide to what a website costs in Latvia.

If you would like us to check your site and tell you honestly what is slowing it down, send us the address and we will reply within 24 hours.

Frequently asked questions

Do Core Web Vitals affect Google rankings?

Yes, they are part of Google's page experience signals, but the effect is modest compared with content relevance and links. Treat them as a tiebreaker for search and a real driver of conversions, since slow pages lose visitors.

What is a good PageSpeed Insights score?

Focus less on the overall score and more on whether LCP, INP and CLS pass on mobile. The 0–100 Lighthouse score is a lab estimate and moves around from test to test.

Why is my mobile score so much lower than desktop?

Lab tests simulate a mid-range phone on a slower connection, so any weight in your page hurts far more. That is realistic: many of your visitors are on similar devices.

Why does Search Console say "not enough data"?

Field data requires a minimum amount of Chrome traffic. Small or new sites often do not have it yet. Use lab tests to guide fixes and check again as traffic grows.

Do I need a new website to pass Core Web Vitals?

Often not. Oversized images and unnecessary third-party scripts are the most common causes and can usually be fixed on the existing site. A rebuild makes sense when the platform itself is the limit, for example a heavy page builder you cannot slim down or hosting that cannot be improved.