# Core Web Vitals for e-commerce: category, product and checkout pages

> Core Web Vitals for e-commerce: the typical LCP, CLS and INP problems on category, product and checkout pages, and how to prioritize fixes by template.

Published: 2026-11-15 · Author: AiroPages

Online stores are built from three very different page types: category pages, product pages, and cart and checkout. Each one fails [Core Web Vitals](/glossary/core-web-vitals) in its own way, and none of them looks like the homepage. To improve a store's vitals, test each template, fix the problems that repeat across it, and prioritize by how many pages and how much traffic each template carries.

## Why testing the homepage misses the problems

Most shoppers do not arrive on the homepage. They land on a category page from search, a product page from an ad or a comparison site, and then move to the cart. The homepage is also the page most likely to have been tuned by hand, so it tends to be the fastest page in the store.

Category and product pages carry the heaviest parts of the store: product grids, galleries, review widgets, recommendation carousels, payment buttons and the scripts that run them. A homepage-only Lighthouse test sees none of that. [Lighthouse only tests one page](/blog/lighthouse-only-tests-one-page) explains the wider problem; for stores it is especially sharp, because a single template can cover thousands of product URLs.

Field data has the same blind spot in a different way. The Chrome UX Report gives an origin-level result that blends every page together, and Search Console groups similar URLs. Both tell you something is wrong, but you still need page-level tests to find out which template and which element.

## Category pages

Category (product listing) pages are grids of images with filters on top. Their typical problems:

- **LCP on the first row.** The LCP element is often the first product image or a category banner. Themes that lazy-load every product image delay it.
- **Too many full-size images.** Thumbnails served at full product-image size make the grid heavy on mobile.
- **Layout shift from late details.** Prices, stock badges, "sale" labels or ratings fetched after render change the height of each card.
- **Promo banners.** Free-shipping bars and seasonal banners inserted at the top push the whole grid down.
- **Slow filter clicks.** Faceted filters often re-render the entire grid in JavaScript, which makes INP poor on mid-range phones.

**What to fix first:** load the first row of images eagerly and lazy-load the rest, give every card fixed image dimensions and reserved space for badges and prices, and show immediate feedback when a filter is clicked before re-rendering the grid.

## Product pages

Product pages carry the most third-party code in a store, and the most images. Their typical problems:

- **Gallery LCP.** The main product image is the LCP element, but it often sits in a carousel that only renders after its JavaScript loads. Zoom libraries and 360-degree viewers add more script.
- **Variant pickers.** Choosing a size or color can trigger a price and stock request, an image swap and a large re-render, which hurts INP.
- **Review widgets.** Third-party review scripts compete for the main thread, and star ratings inserted near the product title after render cause layout shift.
- **Recommendation carousels.** "You may also like" and "frequently bought together" rows load late, run their own scripts, and shift content if they appear above anything the shopper is reading.
- **Payment and express checkout buttons.** Buttons rendered by payment provider scripts often appear late and change size, shifting the add-to-cart area.
- **Chat widgets and popups.** Newsletter popups, discount wheels and chat bubbles add more main-thread work on every product view.

**What to fix first:** render the first gallery image as a plain `<img>` with `fetchpriority="high"`, reserve space for ratings, payment buttons and recommendation rows, and load reviews and recommendations after the main content. The detailed LCP steps are in [how to improve LCP on blog and product pages](/blog/improve-lcp-on-blog-and-product-pages), and the layout fixes are in [the most common causes of layout shift](/blog/common-causes-of-layout-shift).

## Cart and checkout

Checkout matters most for revenue and is the hardest to test. It needs a cart session, it is usually marked noindex, and it is not in the sitemap, so tools that start from the sitemap will not reach it.

Typical problems:

- **Payment SDKs.** Card fields, wallets and fraud-detection scripts load from third parties and run on the main thread.
- **Tracking.** Conversion tags tend to collect on checkout, since every marketing tool wants to see the purchase.
- **Address autocomplete and validation.** Lookups on every key press can make typing feel slow, which shows up as poor INP.
- **Late updates.** Shipping estimates, tax, discount codes and express payment buttons change the layout as they load.
- **Slow "Place order" feedback.** If the button gives no visible response until a network request finishes, the interaction feels broken.

**What to fix first:** load payment scripts only on the checkout steps that need them, audit which tags really need to fire there, debounce autocomplete, reserve space for totals and payment options, and update the button state immediately on click. [INP explained](/blog/inp-explained-fix-slow-interactions) covers the techniques for slow interactions.

To test checkout, add an item to the cart and run Lighthouse in Chrome DevTools, or script the journey with Lighthouse user flows. For real-user results, rely on your own field monitoring or the origin-level data in the [Chrome UX Report](/glossary/crux).

## Typical problems by page type

| Page type | Typical problems | Metric most often affected | First fix to try |
|---|---|---|---|
| Category | Lazy-loaded first row, late badges, heavy filters | LCP, CLS, INP | Eager first row, fixed card sizes, fast filter feedback |
| Product | Carousel gallery, review widget, recommendations, payment buttons | LCP, CLS | Plain first image, reserved space, defer widgets |
| Cart and checkout | Payment SDKs, tags, autocomplete, late totals | INP, CLS | Load scripts per step, trim tags, debounce input |
| Content and landing | Hero images, embeds, fonts | LCP | Responsive hero, preload fonts |

## Search results and other templates

Internal search results pages behave like category pages, but they are usually rendered on request, so slow server response time is common. Cache popular queries where you can, and apply the same grid fixes as on category pages. Brand pages, gift guides and editorial content often use landing page templates with large hero images and embedded video, so treat them like content pages: a responsive hero, preloaded fonts and no embeds above the fold.

Shared components matter too. A mega-menu, a cart drawer or a site-wide promo bar loads on every page, so a problem there shows up in every template at once. When the same issue appears on category, product and content pages, look at the global layout first.

## Prioritize by template and traffic

A store with 2,000 products and 40 categories has thousands of URLs but only a handful of templates. That is good news: most fixes are made once.

A simple way to decide what to fix first:

1. **List your templates.** Home, category, product, search results, content pages, cart, checkout.
2. **Count the URLs on each.** Your sitemap or platform admin gives you this.
3. **Add traffic or revenue share.** Your analytics tool shows which templates get the most sessions and sales.
4. **Find the worst metric on each template.** Use lab tests on a sample of pages and field data where you have it.
5. **Rank by pages affected times traffic.** Then break ties by how far each metric is from the threshold.

For example, a product-gallery issue on 2,000 product pages that get most of the store's traffic comes before a slow category banner on 40 pages. A checkout problem may jump the queue despite covering few URLs, because almost every order passes through it.

## How to check this across your whole store

Manually, pick five to ten URLs from each template, run Lighthouse on mobile for each, and record the LCP element, the CLS culprits and Total Blocking Time in a spreadsheet next to the template name. Compare with Search Console's Core Web Vitals report to see which groups of URLs fail on real users. Test checkout separately with a cart session.

For the public pages, AiroPages runs Lighthouse on every page in your sitemap on mobile and desktop, groups identical issues by template, and ranks them by pages affected, with Chrome UX Report field data next to the lab scores where Google has it. Checkout pages that need a cart session are not in your sitemap, so test those by hand.

## Treat each template as its own project

Store performance is not one score. It is a category template, a product template and a checkout flow, each with its own heavy parts. Fix the product template and every product improves; fix the category grid and every category improves. Keep checkout lean, because that is where slow pages cost the most.