E‑commerce performance audit – Core Web Vitals and store speed
We establish where a store loses time: in the browser, the application, the infrastructure or the integrations. We join measurement of the key paths with an analysis of the back end, so that a symptom can be told from its cause and the first thing to fix can be named. The result is a report with evidence, priorities and the conditions for re-measuring.
The set of paths, devices and environments is agreed before the work starts, so that measurement matches the situations that matter to sales and to the team's work.
- Buying journeys
- Core Web Vitals
- Backend and data
- Infrastructure and integrations
Slow loading is a symptom. The source can sit in several layers
A PageSpeed Insights result can confirm that a user waits too long. On its own it does not yet explain whether the cause is the theme, the application code, the database, the server, a marketing tag or an external API.
How a problem is diagnosed has to match the situation it appears in. A slow product page on a phone is one investigation, a checkout that slows down during a campaign is another, and an admin panel blocked by imports is a third.
- 01
The product page takes a long time to load on a phone
- Possible areas
- Images, JavaScript, fonts, rendering, cache, application response time.
- Consequence
- The user waits before seeing the offer and being able to start buying.
- 02
Checkout slows down during a larger campaign
- Possible areas
- Sessions, database, payments, external services, server resources, the way scaling works.
- Consequence
- The problem appears exactly when the company is sending the store the most paid traffic.
- 03
Imports and the admin panel block the team's work
- Possible areas
- Indexing, scheduled jobs, queues, database queries, ERP or PIM integrations.
- Consequence
- Updating the offer takes longer, and background operations start affecting the sales side.
- 04
The store is fast one day and noticeably slow the next
- Possible areas
- Cache, load, external APIs, background jobs, differences between environments.
- Consequence
- The team cannot reproduce the problem and ships fixes with no shared point of reference.
The same symptom therefore leads to different investigations. If the suspicion is about code quality, architecture or technical debt rather than response time itself, the right scope is a technical e‑commerce audit.
Core Web Vitals – LCP, INP and CLS
Core Web Vitals are the three metrics Google uses to describe the quality of the experience on a page: how quickly the main content appears, how quickly the interface answers a user's action, and how stable the layout is.
The definitions and the thresholds come from Google (opens in a new tab). A “good” result means the threshold is met for 75% of visits — one fast run on a desktop does not settle it. FID is no longer one of the Core Web Vitals; INP took its place.
LCP
Largest Contentful Paint
How quickly the main content of the page loads.
Good resultup to 2.5 s
In a store that element is usually the product photo, the banner on the home page or the first tile on a listing. The delay comes from the weight and the order of the resources, not from how many elements the page holds.
INP
Interaction to Next Paint
How responsive the page is after a user interaction.
Good resultup to 200 ms
It measures the delay between a click and a visible response: opening a filter, adding to the cart, choosing a variant. The most common cause is JavaScript running at the same moment.
CLS
Cumulative Layout Shift
How visually stable the page is.
Good resultup to 0.1
Layout jumps while loading — a banner arriving late, a font with no space reserved, a consent bar — end in a click on the wrong element, most often in the cart and the checkout.
The metrics are measured separately for mobile and for desktop, because the same resources behave differently on a slower processor and a slower connection.
What most often slows an online store down?
Performance is rarely broken by one thing. It is usually several overlapping costs, each of them small on its own, that together push LCP and INP past the thresholds.
The most common sources of slowdown
- Images
- photos larger than the space they are displayed in, no modern formats, and no lazy loading below the fold
- JavaScript
- code running before the first interaction, large bundles with no splitting, and libraries loaded on every view
- CSS
- render-blocking stylesheets, styles unused on the view, and no separate style for the first screen
- Fonts
- faces loaded with no fallback display, in several weights, and from external domains
- Third-party apps and scripts
- tag manager, chats, A/B tests, heatmaps and advertising pixels — usually the single biggest cost to INP
- Rendering
- long tasks on the main thread, forced layout recalculation, and work done before the content is painted
- Cache
- a low hit rate, premature invalidation, and views excluded from cache without needing to be
- API requests
- data fetched while the view loads — stock, prices, recommendations — with no timeout and no fallback
- Dynamic elements
- carousels, search suggestions, filters and configurators that rebuild the view after it has been painted
- Render-blocking resources
- scripts and stylesheets in the head that hold the content back until they are fetched
Where this audit ends
A performance audit covers all five layers above: the critical paths, the front end, the application and back end, the infrastructure and data, and the integrations and behaviour under load. The boundary is not a layer but a question: here we ask what is slowing the store down and what will speed it up most. Judging code quality, security, upgrade readiness and technical debt — whether or not they bear on load time — belongs to the technical e‑commerce audit.
The audit joins measuring the user's experience with an analysis of the back end
A store's performance comes from where several layers meet. Improving one of them need not produce a noticeable change if the main delay sits somewhere else.
The scope is agreed before the audit starts. It should cover the paths that matter most to sales and operations, not an arbitrary set of URLs.
Critical paths and templates
The scope can include the home page, listings, the product page, search, the cart, checkout, the customer account and selected B2B processes. Which URLs and which device variants are covered is agreed before measurement.
What is checked
- the home page and campaign landing pages
- listings with filters and sorting
- the product page and variant selection
- search and its suggestions
- the cart, plus checkout with delivery and payment
- the customer account and selected B2B processes
Frontend and browser
The analysis covers how images, fonts, CSS and JavaScript load, how content renders, which third-party scripts run and what the Core Web Vitals say. The results should point to the resources delaying display or interaction.
What is checked
- the order and weight of the resources behind the first render
- images: formats, dimensions, how they load
- fonts and render blocking
- JavaScript executed before any interaction
- marketing scripts and the tag manager
- Core Web Vitals on the devices in scope
Application and backend
We check response times, how caching behaves, sessions, the cost of selected operations, database queries, indexing, queues and background jobs. The exact scope depends on the technology and on the access granted.
What is checked
- application response times on the paths in scope
- cache hits and cache invalidation
- session and cart handling
- database queries in the most expensive operations
- indexing and catalogue recalculation
- queues and scheduled jobs
Infrastructure and data
The analysis can cover resource usage, environment configuration, the database, the caching layers, the CDN, logs and whatever monitoring data exists. How far we work with the hosting administrator, and which tools we can reach, is agreed before the work starts.
What is checked
- CPU, memory and disk usage under traffic
- application server and database configuration
- caching layers and the CDN
- logs and available monitoring data
- differences between the production and the test environment
Integrations and load
We check how payments, ERP, PIM, WMS, search and marketing tools affect the critical processes. Load tests require the environment, the scenario and safe limits to be agreed before anything runs.
What is checked
- response times of external services inside the buying journey
- the effect of ERP, PIM and WMS on the catalogue and stock levels
- how payments and delivery behave under heavier traffic
- how errors and timeouts are handled
- the scope of load testing: to be agreed with the scope of the service
The scope can include the home page, listings, the product page, search, the cart, checkout, the customer account and selected B2B processes. Which URLs and which device variants are covered is agreed before measurement.
What is checked
- the home page and campaign landing pages
- listings with filters and sorting
- the product page and variant selection
- search and its suggestions
- the cart, plus checkout with delivery and payment
- the customer account and selected B2B processes
The analysis covers how images, fonts, CSS and JavaScript load, how content renders, which third-party scripts run and what the Core Web Vitals say. The results should point to the resources delaying display or interaction.
What is checked
- the order and weight of the resources behind the first render
- images: formats, dimensions, how they load
- fonts and render blocking
- JavaScript executed before any interaction
- marketing scripts and the tag manager
- Core Web Vitals on the devices in scope
We check response times, how caching behaves, sessions, the cost of selected operations, database queries, indexing, queues and background jobs. The exact scope depends on the technology and on the access granted.
What is checked
- application response times on the paths in scope
- cache hits and cache invalidation
- session and cart handling
- database queries in the most expensive operations
- indexing and catalogue recalculation
- queues and scheduled jobs
The analysis can cover resource usage, environment configuration, the database, the caching layers, the CDN, logs and whatever monitoring data exists. How far we work with the hosting administrator, and which tools we can reach, is agreed before the work starts.
What is checked
- CPU, memory and disk usage under traffic
- application server and database configuration
- caching layers and the CDN
- logs and available monitoring data
- differences between the production and the test environment
We check how payments, ERP, PIM, WMS, search and marketing tools affect the critical processes. Load tests require the environment, the scenario and safe limits to be agreed before anything runs.
What is checked
- response times of external services inside the buying journey
- the effect of ERP, PIM and WMS on the catalogue and stock levels
- how payments and delivery behave under heavier traffic
- how errors and timeouts are handled
- the scope of load testing: to be agreed with the scope of the service
If measurement points to server resources or environment configuration, the next step may be a change or a review of the hosting — for Magento 2 we describe it on the Magento 2 hosting page. The audit itself stays independent of that decision: its job is to establish whether the problem really is in the infrastructure.
PageSpeed Insights versus real-user data – what do we analyse?
The same URL measured at a different moment, on a different device and with the cache in a different state gives a different result. So the conditions are agreed before measurement, and every significant observation states them alongside its evidence.
Before measuring we establish the critical paths, the devices, the traffic sources, the network conditions and the moments at which the store loses performance. Without that, results from different days and different tools can support contradictory conclusions, and the team ends up with a list of alerts instead of a diagnosis.
Fixed conditions have a second use: they make it possible to check whether a shipped change actually helped. Re-measuring without the same scenario settles nothing.
The kinds of data in an audit
- Lab data
- A measurement under controlled conditions, on a set device and connection. Good at showing the cause, silent on what customers actually see.
- Real-user data (field data)
- Results gathered from real visits, on the hardware and connections customers really use. This is what settles whether a problem is real.
- Core Web Vitals
- LCP, INP and CLS computed from real-user data for 75% of visits. A lab result can approximate them, but it does not replace them.
- Mobile results
- A separate measurement for phones — a slower processor and a slower connection change the conclusions, especially for INP.
- Desktop results
- A separate measurement for desktops, which matters in B2B and anywhere orders are placed from an office.
Neither a Lighthouse result nor a PageSpeed score is the final verdict on a store's performance. They are diagnostic tools: they show where to look, and real-user data gathered under agreed conditions is what settles it.
The conditions fixed before measuring
- Paths and URLs
- Specific templates and processes rather than an arbitrary set of addresses. The scope is chosen by what matters to sales and to the team's work.
- Devices and network
- Device class, browser and connection parameters. A slow product page on a phone and the same page on a desktop are two different measurements.
- Environment
- Production, a copy of production or a test environment — together with a note on how it differs from production in data and resources.
- Moment and scenario
- Time of day, traffic level, campaigns in flight, imports and background jobs. Some problems only appear under particular conditions.
- State of cache and data
- Whether the measurement covers a first visit, a visit with the cache warm, or the situation right after invalidation. Catalogue size and the number of variants matter here.
How many repetitions are taken, how field and lab data are combined and how a large catalogue is sampled are all agreed together with the scope of the audit. They depend on the store's technology, the environments available and the access granted.
Core Web Vitals, UX and SEO – why does performance matter?
Good Core Web Vitals support the quality of the user experience and are one of the elements Google's ranking systems take into account. They are not, however, a standalone factor that guarantees high positions in search results.
User experience
A slow product page and a jumping layout in the cart cost attention first and the order second. It is the one effect of performance a company controls entirely.
Visibility in search
Core Web Vitals are one of the signals ranking systems take into account. On their own they do not move a page up the results — content and how well it answers the query decide that.
Campaign cost and conversion
A slow landing page wastes traffic the company paid for. An improvement in performance usually shows up first in abandonment data, not in positions.
We do not promise that a better PageSpeed score will automatically raise positions in Google — there is no such relationship. Where visibility is the goal, performance is one part of the work rather than the whole of it. Problems that reach beyond performance belong to the technical e‑commerce audit.
First we establish what to measure and under what conditions
Comparable measurement needs a shared scenario. The scope should account for the technology, the devices, the critical processes, the environments available and the moments at which the problem appears.
The stages run from a conversation about symptoms to a report that can be turned into a backlog. Each of them ends in material that can be returned to when the changes are verified later.
- 01
Context and scope
We gather information about the technology, the infrastructure, the traffic, the campaigns, the integrations and earlier attempts at optimisation. Together we name the processes whose slowdown has the greatest effect on sales or on the team's work.
Result of the stageA list of the critical paths and processes to be measured
- 02
Baseline conditions
We agree the devices, network parameters, environment, set of URLs and user scenarios. That is what makes results taken at different moments comparable.
Result of the stageThe measurement scenario: devices, network, environment, URLs
- 03
Measurement
We measure the user layer and whatever parts of the back end we can reach. The scope depends on access: some observations can be gathered from outside, others need logs, monitoring or access to the environment.
Result of the stageResults for the user layer and the reachable parts of the back end
- 04
Diagnosis
Results are compared across layers. We check whether the problem can be reproduced and whether the delay observed actually belongs to the cause named, rather than merely appearing alongside it.
Result of the stageObservations tied to a layer, to code, to configuration or to a service
- 05
Report and discussion
We hand over a report with the observations, evidence, priorities and means of verification, and then go through the results with the team on the client's side.
Result of the stageThe report and a backlog of recommendations in an agreed order
Load tests, where they are in scope, only run once the environment, the scenario and safe limits have been agreed and the people responsible for the platform have accepted them. Without those agreements we stay with measurements that cannot affect the store's availability.
What do you get after a performance audit?
Every problem is described by the same chain, from the metric it shows up in through to its priority. That way the report goes straight into a backlog, with no step in between to translate a tool's output into a task for the team.
The recommendations are split into two groups, because their cost of entry differs: some can be shipped as part of ordinary maintenance, others need a planned development stage.
| Field | Content |
|---|---|
| Problem | The main image on the product page loads at full size, with no next-generation format. |
| Metric | LCP on mobile, above the 2.5 s threshold. |
| Cause | No size variants and no format conversion in the product page template. |
| Recommendation | Variants matched to where the image is displayed, a next-generation format, and a loading priority for the first screen. |
| Impact | A shorter time to the main content on the view with the largest share of traffic. |
| Priority | Quick win — a change in the template, with no reach into the architecture of the store. |
The format of a single problem
Problem
The main image on the product page loads at full size, with no next-generation format.
Metric
LCP on mobile, above the 2.5 s threshold.
Cause
No size variants and no format conversion in the product page template.
Recommendation
Variants matched to where the image is displayed, a next-generation format, and a loading priority for the first screen.
Impact
A shorter time to the main content on the view with the largest share of traffic.
Priority
Quick win — a change in the template, with no reach into the architecture of the store.
An example of the format. It is not the result of any client's audit.
Group 01
Quick wins
Changes with relatively little effort and a fast effect. They usually sit in configuration, in a template, or in the way resources are loaded.
- image variants, formats and loading priority
- deferring scripts not needed before the first interaction
- tidying up the tag manager and third-party scripts
- reserving space for elements that arrive late
- fixes to cache configuration and headers
Group 02
Changes that need development
Changes that reach further into the front end, the architecture or the way the store works. They enter the plan as a stage of their own, with their own estimate.
- splitting and rebuilding the JavaScript bundles
- changing how the listing or the filters render
- rebuilding the dynamic components in the cart and the checkout
- changing the cache strategy for personalised views
- replacing third-party scripts or narrowing their scope
Every recommendation states the measurement conditions it rests on and says what has to be measured again after it ships. Without the same scenario, a repeat measurement settles nothing about whether the change helped.
FAQ – e‑commerce performance audit and Core Web Vitals
The exact terms depend on the store's technology, the environments available and the source of the problem. We settle these before measurement begins.
We do not quote a single price, because an audit is priced by its scope: the number of paths and templates measured, the number of devices and environments, whether real-user data is available, whether load tests are included, and whether the scope reaches the back end. We confirm the figure and the dates once the scope is settled.
It depends on the number of paths and templates, the number of device variants, how much monitoring data exists, and whether the scope includes load tests. Measurement also needs a window: some problems appear only under traffic or during background jobs. The timing goes into the offer along with the scope.
They are the three metrics Google (opens in a new tab) uses to describe the quality of the experience on a page: LCP (how quickly the main content loads), INP (how responsive the page is after an interaction) and CLS (how visually stable the layout is). They are computed from real-user data. FID is no longer one of the Core Web Vitals — INP took its place.
LCP: up to 2.5 s. INP: up to 200 ms. CLS: up to 0.1. The thresholds apply to 75% of visits, separately for mobile and desktop, so one fast measurement on a desktop does not mean the metric is met.
PageSpeed Insights is a tool; Core Web Vitals are metrics. The tool shows two things at once: a lab result from Lighthouse, obtained under controlled conditions, and real-user data where it is available for the URL. The Lighthouse score is a diagnostic pointer, not the final verdict on a store's performance — real-user data is what settles it.
Yes, and it usually matters more than the desktop version. The same resources behave differently on a slower processor and a slower connection, so measurements are taken separately for mobile and for desktop. The device class and the network parameters are agreed before measuring.
Yes. The scope covers representative stages of the buying process: the home page, the listing with filters, the product page, the cart, and the checkout with delivery and payment. The cart and the checkout are where the cost of dynamic elements and third-party scripts shows up most clearly, so leaving them out would leave the most expensive part of the journey unmeasured.
A performance audit concentrates on response time, page loading, stability under load and the bottlenecks between the frontend, the application, the database, the infrastructure and external services. A technical e‑commerce audit assesses the code, architecture, security, documentation, technical debt and room for further development more broadly.
Yes, Core Web Vitals (opens in a new tab) are one of the areas measured on the frontend. Lighthouse or PageSpeed Insights results alone are not enough to establish the source of a problem across the whole platform, though: they show the effect visible in the browser, not the layer causing it.
The external part can be done, but the diagnosis will be limited in scope. Access to code, logs, monitoring or the environment is what makes it possible to see what happens on the application and infrastructure side. Required access is agreed before the work starts, and we say plainly which findings cannot be reached without it.
Load tests require the environment, the scenario and safe limits to be agreed. We do not run them without a prior risk assessment and the acceptance of the people responsible for the platform. Whether such tests are part of the standard scope is settled with the scope of the audit — it depends on the technology and on the environments available.
A report with observations, evidence, possible causes, priorities and the means of verifying changes, together with an ordered backlog of recommendations. The format of the report and the backlog, and the shape of the meeting that discusses the results, are to be confirmed with the proposal.
An audit can be the basis for a separate implementation scope. We estimate that work once the dependencies, risks and order of the recommendations are known. An audit does not oblige a client to give the implementation to the same supplier — the report is written so that it can be handed to another team.
We do not set a fixed interval, because performance is broken by changes rather than by the passage of time. A repeat audit makes sense above all after a large release, after a redesign, after a change of front end, after adding large integrations or scripts, and when Core Web Vitals data clearly gets worse. Between audits, watching the real-user data is enough.
When the source of an urgent failure is known, direct diagnostics and a fix may fit better, or ongoing care of the store under AURORA CARE. If the company is preparing a new implementation or choosing a platform, a better starting point is a pre-implementation analysis.
Let's discuss where the store slows down and what scope of measurement makes sense
Tell us the technology, the store's address and the situations in which the problem appears. That is enough to establish whether what you need is a full audit, limited diagnostics or a different analysis.
You do not have to prepare a technical brief. A description of the symptoms and what is already known is enough — we will ask the rest of the questions ourselves in the first conversation.
Have ready, if you can
- example URLs or processes that run slowly
- when the problem occurs
- the store's and the hosting's technology
- what has recently changed in the store
- earlier attempts at optimisation
- planned campaigns or periods of heavier traffic