Why a fast site sells more

If a shop door sticks, some customers never come in, however well the shelves are arranged. On a website, that door is speed: every extra second eats into the visitor’s patience, and the loss never shows up in any report as a separate line called “lost sales”. In this article we explain how to read Core Web Vitals not as a technical report card but as a measure of the path to a sale, and where you should look first.

Three questions, three measures

The three measures Google calls Core Web Vitals match three simple questions in the visitor’s mind:

• LCP (Largest Contentful Paint): When did the main content appear? The moment the largest element in the first visible area of the page (usually a product photo, a cover image or the main heading block) is drawn on screen. The good threshold is 2.5 seconds or less.
• INP (Interaction to Next Paint): How quickly did it respond when I clicked? The time between the visitor’s clicks, taps and key presses on the page and the next update of the screen. These interactions are tracked throughout the visit, and one of the slowest is reported as the page’s value. In March 2024, INP replaced FID, which only looked at the delay of the first interaction. The good threshold is 200 milliseconds or less.
• CLS (Cumulative Layout Shift): Did the content move while I was reading? A score for the unexpected layout shifts that happen while the page loads and is in use. It has no unit; the good threshold is 0.1 or less.

How these thresholds are assessed matters too. The benchmark is the 75th percentile of real users: if at least three quarters of visits come in within the threshold, that measure counts as “good”. Mobile and desktop are assessed separately.

The lab score in Lighthouse or PageSpeed Insights is a single test run on an assumed device and connection. It is very useful for finding where the problem is, but decisions are made on real visitor data. Lab tests cannot measure INP directly; instead, they offer an approximate indicator such as Total Blocking Time. You can see real user data in the Core Web Vitals report in Search Console, in the top section of PageSpeed Insights, or through real user monitoring that you add to your site.

Why speed is a sales matter

Each measure touches a particular step in the sales funnel. If LCP comes late, a visitor who clicked through from an ad leaves before seeing the product; the click has been paid for, but the visitor never entered the shop. If INP is high, pressing the “Add to basket” button seems to do nothing for a moment; the user either presses twice or gives up. Size selection, filters and the address form suffer from the same delay. If CLS is high, the text being read slides down, a late-loading banner pushes a button aside and the visitor taps somewhere they didn’t mean to; the place where this costs most is the checkout page.

So speed should be read not as a single site score but split by page type: home, category, product, basket and checkout. On an e-commerce site, a slow product page template costs far more than one slow blog post. The page with the quote form for a B2B manufacturer, the appointment page for a clinic and the enrolment page for an education provider matter just as much. Comparing the conversion rates of fast and slow sessions in your own analytics data shows how this relationship looks on your site, with data instead of guesswork.

Google counts Core Web Vitals among the page experience signals its search systems use; even so, this signal does not outweigh the relevance of the content. The real return on speed is less about rankings and more about not losing the visitors who already arrive.

On a slow page, part of the ad budget is left at the door.

Images and fonts

With LCP problems, the first place to look is usually the images. Our checklist:

• The right size: Don’t send a 3,000-pixel file for a photo that appears 600 pixels wide on screen. Use srcset and sizes to give each device its own size.
• The right format: AVIF or WebP usually produce smaller files than JPEG and PNG at the same image quality. For older browsers, a fallback format can be offered with the <picture> tag.
• Size attributes: Give every image width and height, or set aspect-ratio in CSS. The browser reserves the space in advance, so the text doesn’t shift when the image arrives; this fixes CLS directly.
• Lazy loading: Add loading="lazy" to images below the first screen. Don’t add it to the main image that is the LCP element; give that one fetchpriority="high" instead.

Fonts affect both LCP and CLS. If a font arrives late, the text either stays invisible for a while or later swaps to another font and shifts the lines. What to do:

• Use font-display: swap to show the text in a fallback font straight away; reduce the shift by bringing the fallback font’s metrics close to the real font with settings such as size-adjust.
• Serve the font from your own domain instead of pulling it from a third-party service; this removes the cost of connecting to a separate server.
• Subset the font: remove the alphabets and glyphs you don’t use from the file, but keep the range that contains the Turkish characters (ç, ğ, ı, İ, ö, ş, ü). Use the WOFF2 format.
• Cut the number of weights. Most designs work with two weights instead of four weights and two italics. Request the font used on the first screen early with preload.

Third-party code

Behind INP problems there is usually JavaScript, and part of that code often belongs not to the site itself but to tools added later: live chat windows, heatmaps, several ad pixels, A/B testing tools, tags for campaigns that ended long ago. Each one looks small on its own; together they keep the browser’s main thread busy and delay the response to a click.

For an audit, we follow this order:

1. Take an inventory. List every script in the tag manager and every script embedded directly in the template: who added it, what for, and when it was last used.
2. Remove anything without an owner. A tool whose reports nobody looks at is just a cost.
3. Cut duplicates down to one. You rarely need two heatmaps or three separate analytics tools.
4. Defer the rest. Use defer or async; load tools such as the live chat window not when the page opens but when the user presses the relevant button.
5. Look at your own code too. Break up long tasks; after an interaction, make the visible change on screen first and leave the rest of the work for later.

Cache, CDN and server

The first part of LCP is how long the server takes to send the first byte. If the server is slow, you hit a limit however much you shrink the images. The basic steps here are: publishing files that don’t change (images, CSS, JavaScript, fonts) under file names that change with their content and caching them for a long time; caching HTML pages on the CDN’s edge servers where possible; turning on Brotli compression; and finding slow database queries on category or search pages. If your visitors are in Türkiye and Northern Cyprus, it is also worth checking whether your CDN provider has edge locations close to the region.

Where to start

First, find out in Search Console which page group falls short on which measure, and whether on mobile or desktop. Then pick the weak template that gets the most traffic; in e-commerce, this is usually the product page. In the first round, fix the largest image, the unnecessary scripts and the late-arriving fonts. Because the field data in Search Console and PageSpeed Insights covers the last 28 days, the improvement shows up over a few weeks, not overnight; read the result during that time without adding new changes. If you would like to tackle speed together with the sales funnel, have a look at our web and software service.