Core Web Vitals for Store Owners: What They Are and How to Check.

Core Web Vitals are three Google metrics that show how fast an online store loads, how quickly it responds to actions and whether it "jumps around" while you read: LCP, INP and CLS. A store owner does not need to know how to calculate them. It is enough to know the good values, be able to check the site in 15 minutes with free tools, and understand what to ask a developer for.

We build sites with these metrics in mind, so below is a practical guide without excess theory: what is measured, where to look at the numbers, what most often makes them worse in stores and what to do about it.

What Core Web Vitals are and why they matter for a store

Google measures "page experience" with three indicators. These are not abstract scores but a reflection of what a buyer actually feels: "nothing shows up for a long time", "the button does not respond", "I wanted to tap one thing and tapped another".

These are the thresholds Google publishes (checked in October 2026). The assessment uses the 75th percentile: that is, three quarters of visitors should get a "good" result.

Why this matters to you as an owner:

• Money. A slow catalog or product page loses buyers before they have seen the range. Exact numbers depend on the niche, so we do not promise "+20% conversion", but the direction is obvious.
• SEO. Core Web Vitals are part of the "page experience" signals. They do not replace useful content, but at equal quality a faster site has the advantage.
• Advertising. If your traffic is paid, a slow landing page makes every click more expensive.
• Mobile users. Most buyers open a store from a phone, often over an unstable mobile connection.

How to check Core Web Vitals yourself in 15 minutes

You need a browser and Google's free tools. One rule: check not only the home page but also the typical templates: category, product page, cart.

Step 1. PageSpeed Insights

Open PageSpeed Insights, paste the page address and choose the "Mobile" tab. You will see two blocks.

1. Real-user data (field data) at the top. These are the metrics of visitors over the last 28 days from the CrUX report. This is what matters to Google. If there is little traffic, this block may be missing.
2. Diagnostics (lab data) below. This is a simulation of loading on a weak device. It shows the causes of problems but is not the "official" assessment.

Do not chase just the overall Lighthouse score. Look at LCP, INP (in lab mode TBT is shown instead) and CLS separately, as well as the list of "Opportunities" and "Diagnostics" tips.

Step 2. The report in Google Search Console

If the site is connected to Search Console, open the "Core Web Vitals" section. Pages are grouped there by status: good, needs improvement, poor. They are grouped by typical templates, so you can see that "all product pages are slow" rather than just one page.

Step 3. A check on a real phone

Open the store from your smartphone over a mobile network, not your home Wi-Fi. Ask yourself five questions:

• After how many seconds do I see the main product photo?
• Does the page shift when banners and recommendations load?
• Does the "Buy" button respond immediately, or is there a delay?
• Does the catalog filter open without "freezing"?
• Does a cookie banner or chat cover the content?

This simple test finds half of the problems without any tool.

Step 4. Chrome DevTools (for advanced users)

In Chrome press F12, open the Performance or Lighthouse tab and run an audit in mobile device mode with network throttling. The Performance tab shows which scripts block the main thread. If you are not a developer, you can simply take a snapshot and pass it to the contractor as an argument in the conversation.

LCP: why the main element appears slowly

In stores LCP is almost always a large photograph: a banner on the home page, a product photo on the product page or the first image in the catalog. The causes of slowness are typical.

Heavy images

A 2–3 MB JPEG photo takes seconds to load on mobile. What to do:

• serve modern formats (WebP, AVIF);
• generate several sizes and serve the one matching the screen through srcset;
• compress without visible quality loss;
• set width and height so the browser reserves space.

An image that lazy-loads when it should not

The loading="lazy" attribute is useful for images below the first screen. But if you put it on the main photo, the browser will postpone loading it. For the LCP element you need the opposite:

<img src="/img/hero.avif" width="1200" height="600"
     fetchpriority="high" alt="New collection">

A slow server response

If the server generates the page in 1.5 seconds, no image optimization will fix that. For Laravel stores the cause is often N+1 database queries and no cache: we wrote about that in What Is a Code Audit and When Do You Need One. If pages can be served from a static cache or prerendered, the gain is sometimes the biggest.

Blocking fonts, styles and scripts

Fonts from an external CDN, many CSS files and scripts in <head> delay the first render. The solution: host fonts on your own domain, load only the weights and languages you need, and defer scripts you do not need immediately.

INP: why the store "lags" after a click

INP is the newest metric and replaced FID. It measures the delay between a user action and the screen update throughout the whole visit, not only the first click.

What makes it worse:

• Too much JavaScript. Libraries for sliders, widgets, chats, pixels, A/B tests: each adds load to the main thread.
• Third-party analytics and ad scripts. A tag manager with a dozen tags can slow a page more than all the store's own code.
• Heavy event handlers. For example, a filter that redraws the entire list of thousands of items on every click.
• Hydration of large pages in SPA frameworks, when the page looks ready but does not respond yet.

Practical steps:

1. List all third-party scripts and for each ask: "Who uses this and what decision do they make based on it?" Remove what nobody uses.
2. Load analytics and marketing pixels after user consent and with a delay. This is also a privacy requirement.
3. Break up long tasks: scrolling, filters and the cart should respond first.
4. For large catalogs use pagination or list virtualization.

CLS: why content "jumps"

Layout shift is annoying and hurts conversion: a person is about to tap "Add to cart", and a recommendations block appears and pushes the button away.

Typical culprits:

• Images without dimensions. The browser does not know the height and adjusts it after loading.
• Banners, cookie panels and promo strips that appear at the top and push content down.
• Fonts that get swapped after loading and change text size.
• Dynamic blocks: reviews, "frequently bought together", delivery widgets without reserved space.
• Embeds (iframes) without dimensions: video, maps, payment widgets.

The simplest rule: for any element that loads later, reserve space in advance. This is done by setting dimensions or aspect-ratio:

.product-card__image { aspect-ratio: 4 / 5; width: 100%; height: auto; }
.promo-bar { min-height: 40px; }

For a cookie banner it is better to use a fixed panel at the bottom that does not push content.

What to fix first: order of action

Do not rewrite the site right away. Follow the principle "biggest effect, least work".

1. Images. Formats, sizes, srcset, correct lazy loading. This often gives the biggest LCP gain.
2. Third-party scripts. Audit and remove what is unnecessary, defer the rest.
3. Reserving space for banners, images and widgets. It usually fixes CLS in a few hours.
4. Fonts. Self-hosting, a minimum of weights, correct font-display.
5. Caching and server speed. Page cache, database query optimization, a CDN.
6. Architecture. If the basics are fixed and the metrics are still weak, it is time to look at the platform: the amount of JavaScript, the rendering method.

After each change, check the result in PageSpeed Insights. Field data updates with a delay of up to 28 days, so do not panic if Search Console shows no improvement the next day: rely on lab measurements, and you will see the real effect later.

Don't know what exactly slows your store down? We will run an express check of speed and the mobile version and show 10–15 key problems in a PDF within 48 hours. It is free; details are on the ecommerce QA audit page.

What targets to set for developers

When you order a new site or optimization, write down measurable goals instead of a general "make it fast". Our internal requirements for the sites we build:

• Lighthouse on mobile: Performance 95+ on key pages, SEO and Best Practices at 100;
• LCP up to 2.5 s, INP up to 200 ms, CLS up to 0.1 by field data (75th percentile);
• minimal JavaScript on the home page, fonts from your own domain, images in modern formats;
• third-party scripts only after user consent.

These figures are goals, not guarantees for any project: the metrics are affected by hosting, the number of integrations and the content you add. But the measurement method and the thresholds can be agreed before work begins. This is one of the 12 points we recommend checking when you are choosing a web development contractor.

Speed and design: what is decided before the code

Many metric problems are baked in at the mockup stage. A slider of six large images on the first screen, a video background, three fonts with a dozen weights, scroll animations: all of this reliably hurts LCP and INP. Performance-aware design is UI/UX design in which every block has a "price" in milliseconds and a justification.

Practical rules for the designer and the client:

• one main image or heading on the first screen, not a carousel;
• a limited number of fonts and weights;
• space for dynamic blocks (reviews, recommendations) planned in the mockup;
• animation where it helps understand the interface, not just decorates it.

Typical mistakes of store owners

• Looking only at the desktop Lighthouse score. Mobile results are usually worse and matter more.
• Checking only the home page. The product page and catalog are often slower.
• Adding plugins without checking the consequences. Every widget has a price in milliseconds.
• Measuring once. Metrics degrade gradually: a new promotion, a new banner, a new pixel.
• Treating speed as a "technical matter". It is part of the business result, so it should be on the site acceptance checklist.

For regular control it is enough to run through steps 1–3 once a month and record the numbers in a table. If the project is supported separately, speed and regression are worth including in a website support plan.

Summary

Core Web Vitals are not about "scores in Google" but about whether it is comfortable for a buyer to use your store. Three metrics, three simple questions: does it appear fast? does it respond fast? does it stay put? You can check this for free in a quarter of an hour, and most problems are fixed with images, third-party scripts and reserved space.

Want a store that opens fast on phones? We build sites with Core Web Vitals targets from the very start. Leave a brief and we will estimate the project within 1 business day.