Make Your Store Fast: Core Web Vitals and Revenue

Speed is not a vanity metric for a store, it is a revenue lever. Shoppers abandon pages that feel slow, and the effect is measurable: every extra second of load time costs conversions, and on a store that turns directly into lost sales. Google reinforces it from the other side, using page experience as a ranking signal, so a slow store both converts worse and gets found less. The good news is that store speed is fixable, and most of the wins come from a short list of well-understood problems.

This guide covers that list. It explains the Core Web Vitals in plain terms, then walks through the fixes that actually move them for a store, in roughly the order of impact. The advice applies whether you are on Shopify, WooCommerce, or a headless storefront.

Google measures three things, and it helps to know what each one is actually telling you. Largest Contentful Paint (LCP) is how long until the main content, usually your hero image or product photo, has loaded, and you want it under about 2.5 seconds. Interaction to Next Paint (INP) is how quickly the page responds when someone taps or clicks, a measure of whether it feels sluggish, and you want it low. Cumulative Layout Shift (CLS) is how much the page jumps around as it loads, the infuriating effect where a button moves just as you tap it. Together they describe whether the store feels fast, responsive, and stable.

Product photos are the heaviest thing on most store pages, which makes images the highest-leverage fix. Serve them in modern formats like WebP or AVIF, which are far smaller than old JPEGs at the same quality. Deliver the right size for each device instead of shipping a huge image to a phone, lazy-load anything below the fold so it does not block the initial view, and always set explicit width and height so the browser reserves the space and the layout does not jump.

// modern format, right size for the device, fixed dimensions to prevent layout shift
<Image src={product.image} width={600} height={600}
  sizes="(max-width: 768px) 50vw, 25vw" alt={product.name} />

That one set of habits, modern format, responsive sizing, lazy-loading, and reserved dimensions, improves LCP and CLS at the same time.

The slowest stores are usually not slow because of their own code, they are slow because of everything bolted on: analytics, a chat widget, several marketing pixels, review and upsell apps. Each one ships JavaScript that competes for the browser's attention, and this is the most common cause of poor INP and a sluggish feel. Audit what is actually loading, remove what you do not truly use, and defer or async-load what remains so it runs after the page is interactive rather than blocking it.

<!-- load the chat widget after the page is interactive, not before -->
<script src="https://widget.example.com/chat.js" defer></script>

The cost of stacking apps is real and cumulative, and trimming it is often the single biggest speed and responsiveness win available.

Every request that travels to a distant server and back adds delay. Serve as much as you can from a CDN at the edge, close to the shopper, and cache pages that do not change per visitor so they arrive almost instantly. Static or cached product and category pages, refreshed when the data changes, are dramatically faster than rendering every page from scratch on every visit, and they hold up far better under a traffic spike.

Beyond third-party scripts, your own bundle matters. The more JavaScript a page must download, parse, and run before it works, the worse it feels, especially on mid-range phones. Render on the server so the page is useful before scripts load, split code so each page ships only what it needs, and be skeptical of heavy frameworks and widgets for simple pages. Less JavaScript is faster JavaScript.

A one-off Lighthouse score on your fast laptop is not the truth your customers live. What matters is field data, the speed real visitors experience on real devices and networks, which Google collects and ranks on. Use real-user measurement to see how actual shoppers fare, and prioritize the fixes that improve their experience, not just the lab number. Optimize for the person on a three-year-old phone on mobile data, because that is who you are losing.

• Know your targets: LCP under ~2.5s, low INP, minimal CLS.
• Serve images in WebP or AVIF, sized per device, lazy-loaded, with fixed dimensions.
• Audit third-party scripts, remove the unused, and defer the rest.
• Serve cached pages from the edge instead of rendering each visit from scratch.
• Render on the server and ship the minimum JavaScript per page.
• Measure real-user field data, not just a lab score, and fix what shoppers actually feel.

Does website speed really affect sales?

Yes, directly. Shoppers abandon pages that feel slow, and the relationship is measurable, each additional second of load time tends to reduce conversions, which on a store is lost revenue. Speed also feeds Google's ranking, so a slow store gets less traffic on top of converting worse. Because the wins come from a known short list of fixes, improving speed is one of the higher-return, lower-risk investments a store can make.

What are Core Web Vitals?

They are Google's three measures of page experience. Largest Contentful Paint is how long until the main content loads, ideally under about 2.5 seconds. Interaction to Next Paint is how quickly the page responds to taps and clicks. Cumulative Layout Shift is how much the page jumps around while loading. Together they capture whether a page feels fast, responsive, and stable, and Google uses them as a ranking signal, so they affect both conversion and discoverability.

What slows down an online store the most?

Two things, usually. Large unoptimized images, because product photos are the heaviest content on the page, and third-party scripts, because analytics, chat, pixels, and apps each ship JavaScript that competes for the browser and hurts responsiveness. Fixing images with modern formats and proper sizing, and auditing and deferring third-party scripts, addresses the bulk of most stores' slowness before you touch anything deeper.

How do I reduce layout shift (CLS)?

Reserve space for things before they load. Always set explicit width and height on images and embeds so the browser holds their place and content does not jump when they arrive. Avoid inserting banners or ads that push content down after the page has rendered, and load fonts in a way that does not reflow text. Most layout shift on stores comes from images without dimensions and late-loading widgets, so handling those two removes most of it.

Should I trust my Lighthouse score?

Use it as a guide, not the verdict. A lab tool like Lighthouse runs on your machine and network, which is usually faster than your real customers', so it can look better than reality. What Google ranks on, and what your sales depend on, is field data from real visitors on real devices. Check real-user measurements and prioritize fixes that help the shopper on an older phone and mobile data, because that is who a slow store loses.

If your store feels slow and you suspect it is costing you sales, tell me where it is hosted and I will give you a straight read on what is dragging it down and the fixes that will move the needle.