How fast should a product page load?

Set the goal in terms of what the shopper can see and do, not in terms of a score. On a product page the useful moment is when the main image, the price, the variant picker and the add-to-cart button are visible and tappable. Everything after that can stream in.

Measure it on a mid-range phone over a mobile connection, because that is what most of your visitors are using. Office broadband on a recent laptop will tell you the page is fine when it is not.

A practical way to hold yourself to this is to record a video of the page loading on a real phone and count the seconds until you could tap add-to-cart. Do the same for your busiest collection page and for the cart. Three short videos will tell you more than a week of reports.

The reason two seconds is a sensible ceiling rather than an ideal is that people on phones are usually doing something else at the same time. A page that takes six seconds is not six times worse than a page that takes one. It is a page a share of shoppers never see at all, because they went back to the feed they came from.

Google's Core Web Vitals give you a shared vocabulary, and its published good thresholds are a reasonable place to hold the line.

Largest contentful paint is how long until the biggest thing in view has rendered, usually your product image. Google treats 2.5 seconds or less as good. On a product page this is mostly an image problem and a server response problem.

Interaction to next paint is how long the page takes to respond when someone taps. Google treats 200 milliseconds or less as good. This is a JavaScript problem. It is what makes a variant swatch feel dead for a beat after the tap, which is when people tap it again and get confused.

Cumulative layout shift is how much the page moves while it loads. Google treats 0.1 or less as good. This is the one that costs orders directly, because a banner or a review widget appearing late pushes the add-to-cart button down at the exact moment the thumb arrives.

Assessment is based on the 75th percentile of real visits, so a fast experience for most people and a terrible one for the rest still fails. Averages hide exactly the visitors you are losing.

A lab tool runs one simulated load from one place on one connection. Field data is what your actual visitors experienced, on their devices, on their networks, in the countries you sell to. When the two disagree, the field data is the one that matches your revenue.

Google's Chrome User Experience Report is the field source behind Search Console's Core Web Vitals report, and it covers pages with enough traffic. Use it to find which page templates are failing rather than which individual URLs, because product pages usually share one template and fail together.

Lab tools are still useful, just for a different job. They tell you what to fix, in order, on a page you already know is slow. Field data tells you which pages are worth fixing at all.

One warning about scores. A single number out of a hundred moves for reasons that have nothing to do with your shoppers, including which server the test hit and how busy it was. Chasing the score produces work that does not change the experience. Chase the seconds to add-to-cart and the score follows.

Check the numbers by device class as well. Desktop usually passes while mobile fails, and mobile is where the traffic is.

Images first. Product photos exported at desktop resolution and served to a phone are the most common cause of slow rendering. Serve correctly sized images in a modern format, set explicit width and height so the space is reserved, and lazy load everything below the first screen. The main product image should not be lazy loaded, because that delays the very thing you are measuring.

Apps second. Every installed app can add scripts, styles and network requests to every page, whether or not the feature is used on that page. Audit the list, remove anything that no longer earns its place, and check that removing an app also removed its snippet from the theme.

Tracking third. Analytics, ad pixels, heatmaps, chat and consent tools stack up quickly. Load what you can after the page is interactive, and keep only the tags someone actually reads a report from.

Fourth, page furniture: sliders, autoplay video backgrounds, animated review carousels and font files loading in several weights. Cut to what earns a sale.

Fifth, the server or app response for dynamic parts, especially product recommendations and live inventory checks. Cache what you can and do not block the first paint on them.

Speed is worth fixing until the page is comfortably inside the thresholds, and after that the returns fall off quickly. Going from six seconds to two changes behaviour. Going from 1.4 seconds to 1.1 usually does not, and the work needed to get there can mean giving up features that sell.

So sequence it by money. Fix the product template first, because that is where buying decisions happen. Then the collection pages that receive your ad traffic. Then the cart and checkout. The homepage matters least, because for most stores it is not where paid or search visitors land.

Measure the effect on your own numbers, not on the score. Watch add-to-cart rate and bounce on the templates you changed, split by device, before and after. If nothing moved after a genuine improvement in load time, the leak is elsewhere and speed was not your problem.

One more thing worth saying. Speed work degrades. Six months of new apps, new banners and new tracking will undo it. Put a check in the monthly routine so the page you fixed stays fixed.