Mobile speed on a PrestaShop store: what to measure and what really makes a difference

You test your store from the office computer, on fibre, and it runs fine. Your customer opens it on a mid-range phone, with patchy coverage, on the bus. For them, the same page takes several seconds to show the product photo and responds sluggishly when they tap “Add to cart”. That second experience is the one that counts, both for selling and for Google, which indexes and assesses pages by their mobile version.

Lab and field: two different measurements

Before changing anything, tell apart two kinds of data:

• Lab data: what a simulated test such as Lighthouse or the lower part of PageSpeed Insights gives you. Useful for diagnosis, because it always measures under the same conditions, but it is a simulation.
• Field data: what real Chrome users have experienced over recent days, aggregated. It is what appears at the top of PageSpeed Insights (if there is enough traffic) and in Search Console’s Core Web Vitals report.

Obsessing over the lab score is a common mistake. A store can score 60 in Lighthouse and pass on real data, or score 90 and fail because its users are on slow phones. What Google uses as a signal is field data.

The three metrics, in store terms

They are assessed at the 75th percentile of visits: it is not enough for the page to work well for most people, it has to work well for three out of four.

What slows PrestaShop down on a phone

Server response time

If the server takes a while to generate the page, everything else starts late. In PrestaShop the weight comes from each page’s database queries, modules that add logic on front-office hooks, an old PHP version and hosting without enough resources. A full-page cache, which serves already generated HTML to anonymous visitors, is usually the single most visible improvement here.

CSS and JavaScript that page does not need

Each module tends to load its files on every page: the contact form CSS on the product page, the configurator script on the home page. On a phone, downloading, parsing and executing all that delays rendering and, above all, worsens INP, because the phone’s processor is busy when the user touches the screen.

Third-party scripts

Chats, advertising pixels, heatmaps, review widgets. Each one adds requests and processor work. Many are not needed until the user interacts with the page.

Images

Product photos uploaded at a large size, without modern formats, or a home page carousel that makes the phone download an image intended for desktop screens. The LCP element of a product page is almost always the main photo: if it is heavy or lazy-loaded, LCP suffers.

Fonts

Several font families, with many weights, loaded from external servers. On top of the weight, they delay the text or make it jump when the final font is applied.

What really makes a difference, in order

1. Server and PHP up to date. A supported PHP version and an updated PrestaShop are faster on their own, and let you use current caching and optimisation tools that do not work on old versions.
2. Page cache for anonymous visitors, with the right exclusions for cart, checkout and account, and automatic purging when products or prices change.
3. Remove CSS and JS from the pages where they are not used, instead of just combining and minifying them. Combining everything into one big file does not reduce what the phone has to process.
4. Delay third-party scripts until the first interaction, with a list of exceptions for what must always load.
5. The main image without lazy loading and at the right size; everything else, lazy-loaded. Reserve the space for images and banners with their dimensions to avoid layout shifts.
6. Fonts served from your own server, only with the weights you use and with font-display set appropriately.

How to measure before and after

• Note the field data for the key templates (home page, category, product page) before you start.
• Use lab data to check that the change does what you expect on a specific URL.
• Wait for the field data to update: it reflects a period of several weeks, so the improvement will not show the next day.
• Also test on a real mid-range phone, with the connection throttled from the browser tools: it is the closest thing to what many of your customers experience and it uncovers problems that the office fibre hides, such as menus that are slow to open or buttons that move.
• Look at your business too: mobile conversion rate, bounce on product pages, carts started.

Speed is one signal among many for Google, and nobody can promise you rankings for improving it. What is clear is that a store that is fast on mobile loses fewer customers along the way.

How to solve it in PrestaShop

Rekire’s Fast Store Pack brings together the pieces in this article: All In One Cache (full-page disk cache with automatic purging when products, categories or prices are saved, Redis query cache from PrestaShop 8 and OPcache management), its setup and training service, RKR OptiMatters and Cache Buster. OptiMatters takes an inventory of the CSS and JS each page type loads, with its weight and source module, lets you remove, defer or delay them until the first interaction per page, device or controller, serves Google Fonts from your server with only the weights you use, and includes a before/after mode visible only to whoever is logged in to the back office.