Web performance metrics have become a mandatory stop in every audit, and they often produce endless lists of recommendations, half of which have no measurable effect. On a PrestaShop store, five projects concentrate most of the available gain.
Measure in the right place
A preliminary point, and it changes everything.
Audit tools run a single test under simulated conditions. They are useful for diagnosis, they do not measure what your visitors actually experience.
Field data, collected on real visits, is what counts. It is available in the dedicated Search Console report, and it often differs sharply from lab results.
Three reasons for the gap: your visitors have varied devices and connections, they land on different pages from the one you test, and some of them browse with an already warm cache.
The method: diagnose in the lab, decide on the field. A problem visible in testing but absent from real-world data is not a priority.
Project 1: the product page’s main image
It is almost always the element that determines your main loading metric, and it is the most profitable project.
Four actions, in order of effect.
Do not lazy-load it. The image visible on arrival must load immediately. Lazy loading applied to every image without distinction delays precisely the one that matters.
Preload it, telling the browser it is a priority. That starts the download before the page is even fully parsed.
Serve the right size. A 2000-pixel image displayed at 600 wastes several hundred kilobytes. Responsive formats settle the case.
Use a modern format, which cuts weight by 30 to 50% at equivalent perceived quality.
These four actions take a day and usually produce the most visible gain of the whole performance effort.
Project 2: visual stability
The second project by return, because the causes are few and easy to identify.
Five sources of layout shift on a store.
Images without declared dimensions. The browser does not reserve the space and content jumps when the image arrives. Declaring width and height is enough.
Banners inserted after load: cookies, promotions, announcements. Reserve their space or display them as an overlay.
Custom fonts. Text first renders in a fallback font, then changes, which shifts the layout. Preloading and an appropriate display setting limit the effect.
Module blocks loaded asynchronously: reviews, similar products, chat. Each one pushes the content below it.
Ads and third-party embeds, whose height varies.
Diagnostic method: open a product page with developer tools, enable the layout-shift indicator, and reload. The moving areas appear immediately.
Full Page Cache & Speed Optimization for PrestaShop 8 & 9Page cache, Critical CSS and advanced optimization for PrestaShop 8 and 9.€149.00
Project 3: interaction responsiveness
The newest metric and the worst handled on stores, because its causes are less obvious.
It measures the delay between a visitor’s action and the visible response. On a store, three interactions concentrate the problems.
Faceted filters, when handling the selection blocks the main thread before the network request even starts.
Add to cart, when it triggers several synchronous operations before visual feedback.
Opening the menu on mobile, if the menu is built at click time rather than at load.
Three fixes, applicable without a rebuild.
Give immediate visual feedback, before processing. A button that changes state on click improves the metric even if processing takes the same time.
Split long tasks to hand control back to the browser between steps.
Reduce the code executed on click, especially third-party scripts hooked to the same events.
Project 4: server response time
It conditions every other metric: nothing can render before the server has answered.
Three levers, in order of effect on PrestaShop.
Full page cache. It turns dynamic generation into serving a ready-made file. It is the biggest gain on category and product pages.
Application cache, on catalog data, which avoids recomputing what has not changed.
Optimising the slowest queries, identified in the database log.
Two precautions on the page cache. It must be invalidated correctly on price and stock changes, or it will display wrong information. And it must exclude personalised pages: cart, account, checkout.
An often overlooked point: the cache only serves visitors who arrive after the first one. On a ten-thousand-page catalog with moderate traffic, a large share of visits stays uncached. Pre-warming the cache on the most visited pages handles this.
Project 5: third-party scripts
The most thankless project, and often the most profitable.
An average store loads between eight and twenty external scripts: analytics, advertising, chat, reviews, cookies, maps. Each was added for a good reason and none has ever been removed.
Three actions.
Take inventory. List the scripts loaded on a product page, with their weight and execution time. Developer tools give it in minutes.
Remove what is no longer used. You will almost always find an abandoned analytics tool or a pixel from a finished campaign.
Defer what remains. A chat, a review widget or a secondary tracker does not need to load before the content renders.
Add a governance point: condition advertising scripts on consent, which is mandatory anyway and has the side effect of lightening the page for those who refuse.
What achieves nothing
Four common recommendations whose effect is nil or marginal on a store.
Minifying the HTML. The gain counts in kilobytes, invisible next to the weight of images.
Cutting the number of requests at any cost. This recommendation dates from older protocols. On current protocols, multiplexing makes the request count far less decisive.
Removing every custom font. A well-loaded font costs little and serves your identity. The problem is the loading method, not the font.
Aiming for one hundred out of one hundred in an audit tool. The score is not the goal, the field thresholds are.
Order and pace
A sequence over three months.
Week 1: a field-data survey, per page type, to know where you actually stand.
Weeks 2 and 3: projects 1 and 2, main image and visual stability. They are the fastest and most visible.
Weeks 4 to 6: project 4, server cache, which requires testing and careful invalidation.
Weeks 7 and 8: project 5, inventory and clean-up of third-party scripts.
Then: project 3, responsiveness, which is the most technical and whose effect is measured over time.
A method point: field data relies on a sliding window of several weeks. Do not draw conclusions until a month after a change.
The Page Cache and Speed Optimisation module for PrestaShop covers the fourth project on PrestaShop 8 and 9: full page cache with invalidation on price and stock changes, automatic exclusion of personalised pages, pre-warming on the most visited pages and deferred loading of non-critical scripts.
