Performance discussions often collapse into a Lighthouse score. That is not the goal.

For ecommerce, the useful question is: how quickly and reliably can a real customer see, understand and interact with the storefront? Google’s current Core Web Vitals, documented on web.dev, answer three separate questions.

At a glance

  • LCP is loading, INP is responsiveness, CLS is visual stability.
  • Field data beats a single lab score for judging real experience.
  • Commerce fails INP through heavy JavaScript and third-party scripts.
  • Measure by template: home, category, product, cart and checkout differ.
Metric Measures Good target
LCP Loading ≤ 2.5 s
INP Responsiveness < 200 ms
CLS Visual stability < 0.1

For field assessment, Google evaluates the 75th percentile of page loads, separately for mobile and desktop; a single local lab run is not a substitute (Google Search Central: Core Web Vitals).

LCP: when does the important content appear?

Largest Contentful Paint measures loading. On an ecommerce site the LCP element is commonly a hero image, a product image, a large promotional banner or a large text block. The first step is not guessing — identify the actual LCP element.

Common ecommerce LCP problems

An oversized product image delivered at full resolution to a small phone; lazy-loading the image the user is waiting to see immediately; a slow image origin that no format can rescue; render-blocking fonts, CSS and scripts; and client-only rendering where essential product information waits for a large JavaScript bundle. Each points to a different fix: responsive images, correct priority, faster delivery, less render-blocking code and more server rendering.

INP: does the store respond when the customer uses it?

Interaction to Next Paint measures responsiveness, and it matters because storefronts are full of interactions: variant selectors, filters, search, cart drawers, quantity controls, menus, accordions and checkout steps.

A page may load quickly and still feel slow. A user clicks size M, JavaScript performs expensive work, the main thread stays blocked and the selection updates 600 milliseconds later. The visual page looked fast; the interaction did not.

Common ecommerce INP problems

Watch for large JavaScript bundles, third-party scripts, heavy framework hydration, expensive event handlers, large DOM updates, filtering huge arrays on the main thread and analytics triggered synchronously. Optimisation may involve less JavaScript, code splitting, deferring third parties, smaller DOM updates, server rendering, islands architecture and web workers where appropriate. The right solution depends on what is blocking the main thread.

CLS: does the page stay where the user expects?

Cumulative Layout Shift measures visual instability. Commerce pages are vulnerable because they contain dynamic components: an image loads and changes height, a review widget appears, a promotion bar inserts itself, a font swap changes line wrapping, recommendations load above content or a stock message pushes the button.

CLS is not only aesthetic. If a user moves toward add to cart and an asynchronous element shifts the button just before the click, that is a functional failure.

Reserve space

A large share of layout shift is preventable through predictable geometry. Images should know their aspect ratio. Embeds should reserve dimensions. Dynamic banners should have allocated space. Skeletons should approximate final dimensions rather than creating a different layout.

Field data versus lab data

Lighthouse and local testing are useful diagnostics, not the same thing as field data. A lab test runs under controlled assumptions; field data represents real devices, networks, caches, geography and interactions. Use both — lab to find problems, field to understand actual experience. Search Console’s Core Web Vitals report uses field data and belongs in ongoing monitoring.

Performance by template

Do not only test the homepage. An ecommerce site has several performance profiles — home, category, search, product, cart, checkout and account. A homepage may score perfectly while every product page is slowed by reviews and recommendation scripts. Measure representative URLs from each template.

Third-party scripts deserve suspicion

Commerce sites accumulate third parties quickly: analytics, advertising, reviews, chat, personalisation, heatmaps, recommendations, A/B testing and payments. Some are valuable; all have a cost.

For each script ask: does it need to load, immediately, on every page, can it load after interaction, and can it run server-side? Performance budgets are business decisions. This is especially relevant on product pages and checkout.

Images need a pipeline

A robust image strategy covers source quality, dimensions, responsive srcset, format, compression, LCP priority, lazy loading, aspect ratio and CDN delivery. Do not optimise image by image if the catalog will hold thousands of products. Build a repeatable pipeline.

Fonts can affect loading and layout

Custom fonts create extra requests, render delay, layout changes and large assets. Use only the weights required, subset where possible, preload only genuinely critical assets and choose fallback metrics carefully if swaps move content noticeably.

Architecture influences performance

Performance is easier when fewer things must execute. A static product description does not need a runtime just because the variant selector does. Static content can be HTML; JavaScript should cover genuine interactivity.

The point is not that one framework always wins. The point is aligning runtime cost with actual interactivity.

Core Web Vitals and SEO

Google recommends good Core Web Vitals as part of overall page experience, and its ranking systems use related signals. But Google explicitly warns against treating them as the only factor or chasing a perfect score purely for SEO (Google Search Central). Relevant, useful content remains fundamental.

Moving a Lighthouse score from 95 to 100 is often less valuable than fixing a slow real-user interaction, broken mobile filtering or an unstable product gallery.

A practical performance workflow

Measure field data, segment by template, identify the actual LCP, INP or CLS cause, reproduce it in the lab, fix the root cause, deploy and measure again. Avoid running Lighthouse, applying random optimisations and celebrating the score. Performance engineering is measurement, diagnosis and iteration.

What to monitor after launch

Keep an eye on Core Web Vitals, JavaScript growth, image weight, third-party count, template regressions and mobile field data. Stores evolve, and performance deteriorates gradually unless it has an owner.

Good ecommerce performance is not the absence of features. It is delivering the necessary features without making customers wait for the interface.

Continue reading

Frontend and performance work sits in Web & Growth at FRN.Q.