Retailers and distributors: what a slow catalogue costs you in sales
Google strongly recommends good Core Web Vitals, its three public measurements of speed and display stability, without ever making them a major ranking factor. The real argument is elsewhere: on a large catalogue, slowness costs sales every day, and that amount can be calculated in one day.
- Google sets three thresholds: the largest visible element rendered in under 2.5 seconds, responsiveness to interactions under 200 milliseconds, and a visual stability score below 0.1.
- Its wording is cautious. It highly recommends good Core Web Vitals for success with Search, which is weaker than making them a primary ranking factor.
- On a large catalogue, the most costly spot is almost never the home page. It is the filtered product lists, which nobody tests.
- Responsiveness to interactions is the signal that traps catalogues, because it degrades at the exact moment the customer filters, sorts or adds to cart.
- Rank your fixes by expected revenue divided by effort, never by technical severity. The two rankings do not look alike.
On this page
What is return per fix
Return per fix is the ranking of performance work by expected revenue divided by the effort required, rather than by technical severity. A serious defect on a page that generates no sales comes after a minor defect on the most visited product list. It is the only ranking that lets an executive team arbitrate a technical budget, because it translates a diagnosis into dollars.
What Google actually says
This piece is written for executives and managers of online stores whose catalogue exceeds a few thousand SKUs. It covers the budget trade-off, not optimization technique.
The three thresholds are public and stable. The largest visible element must render in under 2.5 seconds, responsiveness to interactions must stay under 200 milliseconds, and the visual stability score under 0.1.
Google's wording deserves a careful read. It says it highly recommends that site owners achieve good Core Web Vitals for success with Search and to ensure a great user experience, and specifies that this recommendation aligns with what its core ranking systems seek to reward.
That cautious wording is weaker than what many sales proposals suggest. Speed is not presented as a major ranking lever. Better but slower content still beats weak, fast content.
A vendor selling a performance project by promising ranking gains is leaning on a generous reading of the documentation. The budget justifies itself very well another way, through lost sales, and that justification can be verified on your own site. Ask for that number rather than promised positions.
Where a large catalogue loses time
The first reflex of most teams is to test the home page, almost always the most polished page on the site and the least revealing.
On a catalogue, the losses sit elsewhere, in this order of cost.
Filtered product lists. A category displaying eighty products with their images, prices and availability does work the home page never does. It is also the mandatory route for most buyers.
Site search. It queries the database across the whole catalogue, often with no caching possible, and it serves half your visitors.
The product page with its variants. Every colour or size change triggers a stock and price check, so a wait at the moment the customer decides.
Cart and checkout. Traffic is low there, value per visitor is the highest on the site. A second lost here costs more than a second lost anywhere else.
Third-party scripts. Those pieces of code supplied by other companies: tracking, reviews, chat, recommendations, banners. They pile up without anyone removing them, and each one was added for a good reason.
Test these five spots on a mid-range mobile device, on an ordinary network. The executive's laptop on the office network measures nothing useful.
The signal that traps catalogues
Of the three thresholds, responsiveness to interactions is the one that hits large catalogues hardest, for a structural reason.
This signal does not measure initial loading; it measures the delay between a customer action and the visible response on screen. On a catalogue, the typical action is precisely the most expensive one: applying a filter, changing a sort, opening a multi-level menu, selecting a variant.
You end up with a site that looks fast on load, then turns heavy as soon as people use it. It is the most common gap between what a technical team reports and what a buyer experiences.
The causes are almost always the same: too many scripts running at once, filtering recalculated entirely on each click rather than server-side, and interface components that redraw the whole list for a single change.
Putting a number on lost sales
This calculation moves speed from the technical report to the executive table.
| Line | What you take | Scenario |
|---|---|---|
| Annual online revenue | Sales completed | $1,400,000 |
| Share of sessions affected | Sessions passing through a slow product list | 40% |
| Measured conversion gap | Between fast sessions and slow sessions | 0.6 point |
| Average order value | Value of one order | $110 |
The annual loss approaches $48,000. The decisive figure is the third one: the conversion gap between fast and slow sessions, measured on your site rather than borrowed from a foreign study.
That measurement is done with your existing tools, by segmenting your sessions by rendering time and comparing conversion rates. One day of work, no extra tool, and the result is specific to your site.
Two precautions. Correlation is not causation: slow sessions often come from more modest devices, so from customers who convert differently for other reasons. Treat the figure as an order of magnitude for arbitration, not as a promise of recoverable revenue.
Ranking fixes by return
A technical audit produces a list ranked by severity. That list is unusable for budget decisions.
Re-rank it by expected revenue divided by effort. A critical defect on a page that gets two hundred visits a year comes after a minor defect on the site's most visited product list.
Three columns are enough: the estimated time saved, the number of sessions affected per year, and the effort in hours. The product of the first two divided by the third gives the work order.
This re-ranking almost always changes the order. The top lines become removing unused third-party scripts, compressing product list images and caching category pages, which means keeping a copy ready to display rather than recalculating it on every visit. Ambitious technical rebuilds move down, not because they are bad, but because their return per hour is lower.
One last point: removing a third-party script usually lands at the top of the list, and it is also the only intervention that requires a business decision rather than development. Someone has to accept losing a feature.
Measuring in the right place
Two measurement mistakes cost teams weeks.
The first: trusting a lab score obtained on a fast workstation. That score serves diagnosis, not decisions. The Core Web Vitals report in Search Console, the free tool Google provides to site owners, is based on the real experience of your visitors and it is the one that reflects your situation.
The second: measuring one page at a time. On a catalogue, performance is judged by page type, because your thousands of product pages share the same template. Fix one template and you fix thousands of pages, and that is what makes the return calculation so favourable.
Finally, track the indicator that decides: conversion rate by rendering-time bracket, month by month. It is the only number that ties technical effort to revenue, and it belongs on the executive dashboard rather than a score out of one hundred.
The two most expensive points of a large catalog are also the ones that convert the most: site search and the checkout path.
What to establish before committing to a performance project
These five numbers can be pulled in one day with your current tools and determine whether the project is worth its budget.
- What conversion gap do you measure between your fast sessions and your slow sessions?
- What share of your sessions passes through a product list or site search?
- How many third-party scripts does your site load, and which ones are still used?
- Are your fixes ranked by technical severity or by expected revenue divided by effort?
- If the conversion rate of slow sessions does not climb after the priority fixes, what gets stopped, and who decides?
The answer that holds up gives a conversion gap in points and a list ordered by return. An evasive answer quotes a score out of one hundred. A vendor selling a performance project by promising ranking gains has not read Google's cautious wording, or is counting on you not having read it.
Measuring that gap on your site and re-ranking your fixes by return is part of what we deliver in a paid audit.
What stays with you: the decision to remove a third-party script, and with it a feature, and the trade-off between a quick fix and a technical rebuild. What gets delegated: measuring the conversion gap, the script inventory, re-ranking fixes by return, execution and monthly follow-up. A business that re-ranks its audit by expected revenue settles most of the problem in a few days of work. A business that follows the technical severity order starts with the heaviest rebuild, exhausts its budget, and has fixed nothing on the pages that sell.
This point sits within the thresholds described in the design thresholds that became mandatory.
Turning a heavy catalogue into a site that sells despite its volume is at the heart of the Improve your site's conversion goal.
Your catalogue exceeds several tens of thousands of SKUs? See our work in eCommerce.
Frequently asked questions about catalogue speed
Is speed a ranking factor?
Google highly recommends achieving good Core Web Vitals and states that this recommendation aligns with what its ranking systems seek to reward. It is cautious wording, weaker than what many sales proposals suggest. Justify the budget through lost sales; that can be verified on your own site.
What score should you aim for?
The lab score serves diagnosis, not decisions. Aim instead for the three thresholds on your visitors' real experience: under 2.5 seconds to render the largest element, under 200 milliseconds of responsiveness to interactions, and a visual stability score below 0.1. The Search Console report reflects that real experience.
Where do you start on a large catalogue?
With filtered product lists and site search, not the home page. They are the mandatory route for most buyers and the most expensive pages to produce technically. The home page is almost always the most polished page on the site and the least revealing.
How do you measure the effect on sales?
Segment your sessions by rendering time and compare conversion rates. One day of work with your existing tools is enough, and the result is specific to your site rather than borrowed from a foreign study. Treat the gap as an order of magnitude: slow sessions often come from more modest devices, so from customers who differ for other reasons.
Should you remove third-party scripts?
It is almost always at the top of the return ranking, and it is the only intervention that requires a business decision rather than development. Someone has to accept losing a feature. Start with the full inventory: most sites load scripts nobody uses anymore and nobody dares remove.
Does a rebuild solve the problem?
Sometimes, and rarely first. A rebuild has the lowest return per hour on the list, because it ties up a large budget for a gain that could have come from a few targeted fixes. Re-rank your audit by expected revenue divided by effort before deciding: the order almost always changes.
- Google Search Central, Understanding Core Web Vitals and Google search results, official documentation, accessed July 2026. Source of the three thresholds and of the exact wording of the recommendation.
- Falia working framework, lost-sales arithmetic and method for ranking fixes by return. Amounts are explicit scenarios, to be redone with your revenue and your measured conversion gap.
Geneviève puts the strategy for your engagement into action. She leads all our web development projects: Shopify, WordPress and the new ways of building a site with AI. She manages our team of developers and translates your business needs into technical language. She runs your organic search (SEO), your visibility in AI answers (GEO) and your site's conversion rate optimization (CRO). Her work is at the heart of three goals: Attract customers with SEO and AI, Improve your site's conversion, and Strengthen your visibility in AI answers. With Gabriel, she also builds the landing pages for your advertising campaigns. She writes mainly about SEO, AI visibility and web design.
About Falia →
SEO
Paid advertising
Conversion
AI visibility
Web design