Free PrestaShop Speed Test

Why the homepage score is not the whole story

The homepage is usually the lightest page in a PrestaShop store: a slider, a few product blocks, done. The pages that carry revenue are heavier. A category page loads a grid of thumbnails, the faceted search module with its own JavaScript, and often a "quick view" script per product. A product page adds the image gallery, reviews, cross-selling blocks, social sharing and sometimes a live chat that waits for the visitor.

Visitors from Google Shopping, ads and organic search mostly land on those pages, not on the homepage. That is why this test runs a category and a product page on mobile as well. If your homepage scores 80 and your product page 35, the product page is the one to fix first.

How modules slow a PrestaShop store down

PrestaShop is built on modules, and every module can hook into the front office. Two things make them expensive:

• Assets on every page. Many modules register their CSS and JavaScript in the displayHeader or actionFrontControllerSetMedia hook without checking which page is being shown. A reviews widget then loads on the cart page, and a slider script loads on the product page.
• Work on the server. Modules hooked into displayTop, displayFooter or product hooks run PHP and database queries on every request. Some call external APIs while the page is being built, which adds directly to your server response time.

The module table in your report shows the first part: what each module sends to the browser and how long its scripts run on a mid-range phone. The server part shows up as a slow response time, and finding the module behind it needs the profiler inside the shop.

A disabled module loads nothing, but an unused module that is still enabled often does. Check your module list for things you tried once and never removed.

CCC, Smarty cache and debug mode

Most of PrestaShop's own speed settings are in Advanced Parameters > Performance. On a live store I check these first:

• Debug mode: off. It disables caches and slows every page.
• Template compilation: "Recompile templates if the files have been updated". "Force compilation" is for development only.
• Smarty cache: on.
• Combine, Compress & Cache (CCC): smart cache for CSS and JavaScript on, plus Apache optimisation if you run Apache. It cuts the number of files, but older modules sometimes break when their scripts are combined, so test the menu, cart and checkout after switching it on.

The test reads from your page code whether CCC is really active. A store where it was switched off "temporarily" during a module install is more common than you would think.

Lab score vs. real customers

The score from 0 to 100 is a lab test: Google loads your page on a simulated mid-range phone with a slow mobile connection. That is why mobile scores are much lower than desktop, and why the same page can score a few points differently from one run to the next.

Google also collects field data from real Chrome users over the last 28 days. This is what it uses for the page experience part of its ranking. It is only available for stores with enough Chrome visitors, so smaller shops often have none. When your store has it, the full report shows it next to the lab results.

A useful way to read both: the lab test tells you what is slow and why; the field data tells you whether your customers actually feel it.

When a low score matters, and when it does not

Do not chase 100. A store with live chat, reviews, a consent banner and proper tracking will rarely reach it, and removing those to gain points can cost more sales than it saves. What matters:

• The main image or product photo visible within about 2.5 seconds on mobile (Largest Contentful Paint).
• Menus, filters and "Add to cart" that react straight away (low Total Blocking Time, good Interaction to Next Paint).
• A server that starts answering in well under a second, even on category pages with many products.
• A page that does not jump while loading (low layout shift), so shoppers do not tap the wrong product.

What I usually find

After many PrestaShop audits, the same causes keep coming back:

• No page or object cache, an old PHP version, or cheap shared hosting, which gives a slow first response on every page. Why cheap hosting hurts PrestaShop.
• Slider images uploaded straight from the camera or design tool, and a first slide that is lazy-loaded.
• Two or three modules doing the same job, e.g. analytics through a module and through Google Tag Manager.
• Theme and module CSS loaded on every page while each page needs only a small part of it.
• Product thumbnails generated in the wrong sizes, so the browser downloads large images and shrinks them.

For the full list of checks I go through, read the PrestaShop speed checklist, or see how I optimise PrestaShop stores.