PrestaShop speed optimization for product, category and cart pages

The description and price are already there, and the main photo is still loading. That's LCP, usually caused by image size or load order, less often by server power.

The customer taps a size filter, a banner loads in at the same moment, and they tap the wrong product. That's CLS: no reserved space for elements that load in later.

Nothing happens, so the customer taps again, and two units land in the cart. That's INP, usually caused by too many scripts running in the background at the same moment.

PrestaShop speed optimisation: what we actually do in the store

• ✓ Baseline measurement: TTFB, LCP, INP and CLS, separately for the product page, category page and cart
• ✓ Server and database: PHP version, OPcache, page caching, queries generated by catalogue filtering
• ✓ Modules: how much time each one adds to generating the page, and which you can disable with no loss of store functionality
• ✓ Product images: next-generation formats, dimensions set in the code, thumbnails generated once instead of on every visit
• ✓ External scripts: the ad pixel, chat and reviews module, each priced in milliseconds, with what you lose by removing it
• ✓ A re-measurement after implementation, on the same three page types and under the conditions recorded the first time

The analysis covers the store's code and configuration, not your contract with the server provider. It leaves you with a list of fixes, each with a calculated gain and a number of hours, so you can have the fixes implemented by us, your own developer, or anyone who knows PrestaShop.

• Product pages take several seconds to build on a phone.
• Core Web Vitals in Search Console are showing red.
• Product campaigns get more expensive because the landing page is slow.

• The store crashes or loses orders in the cart: that's a technical audit.
• The customer reaches the cart and leaves despite a fast store: that's a store UX audit.
• The server can't handle a promotion peak: that's PrestaShop hosting.

A hundred on PageSpeed Insights is the easiest thing to promise and the least worth buying. The score is calculated for a single load of a single page under lab conditions, and a store that needs to collect orders has to load analytics, an ad pixel, chat and a reviews module. You can switch them off and get a hundred, only then nobody knows where the orders are coming from any more.

JustIdea works from field data, meaning readings from your customers' own browsers, not a simulator's score. Our store speed optimisation rests on three readings: server response time, the moment the largest element appears, and whether the layout jumps under your finger. We run each one separately for the product page, category page and cart, because a different thing slows down each of those three: images, filters and payment scripts.

PrestaShop optimisation follows an order, and it comes from how much each layer gives back. First the server and caching, because they work across the whole catalogue at once. Then product images and above-the-fold fonts. Last, external scripts, where the slack is often biggest, but you have to decide what to give up.

The difference is biggest on a phone, because the processor is weaker and signal strength varies. That's why we measure the mobile version separately, and check the template alongside how CSS and JavaScript files block the product page from painting. The same store can score green on desktop and red on mobile, so the report shows both separately.

Core Web Vitals is the set of metrics Google uses to describe how a page loads for real users, not in a lab. We add server response time on top, because without it the other three have no way to be good. This is each one in the context of a store.

Ratings instead of promises about milliseconds

A promise about speed is easy to make and hard to hold anyone to, because the result also depends on hosting and the template. Instead, we show how clients have rated JustIdea on three public platforms.

Four things we hear about store performance

We answer every one of them with a measurement from the customer's phone, not an impression from the office.

“The store loads fast for me”

For you it loads from the browser cache, logged in, on a company connection. A customer arrives for the first time, on a phone, from an ad, on a product page they've never seen. We measure it the way they and Google see it, not the way the owner does.

“A hundred on PageSpeed is marketing, not sales”

Agreed, a hundred isn't the goal and we don't sell it. The goal is the Core Web Vitals thresholds Google publishes, and how fast the store responds when you add to cart. We order fixes by impact on conversion, not by a tool's score.

“We'll have to change hosting”

Less often than you'd think. Usually images sit at full original size, a dozen or so tracking scripts start before the content, and modules load on every page. We check hosting as part of the analysis and say plainly whether that's the actual ceiling.

“The effect will disappear after a month”

It will, if nobody keeps an eye on new modules and images. That's why the analysis ends with a set of rules for your team, and post-launch support includes a re-measurement. A store doesn't break on its own, later implementations without measurement break it.

Store speed optimisation: questions before you decide