SLOW ONLINE STORE: THE CAUSES SPECIFIC TO WOOCOMMERCE, PRESTASHOP AND SHOPIFY

A store is not a showcase site with a cart. Every product page crosses the catalogue, stock, prices, variants and the visitor's cart. The speed-up levers are not the same depending on the platform.

What all of them share

Product images first: twenty thumbnails per category page, four to eight per product page, often served at full resolution. Then app scripts: reviews, recommendations, chat, ad pixels, newsletter pop-up, each with its own file. Then fonts and theme. These three items make up 70 percent of the problem whatever the platform; the rest is specific.

WooCommerce

WordPress wasn't designed for commerce, and it shows on caching: the cart, checkout and account pages cannot be cached, and badly configured caching shows one customer's cart to another. WooCommerce filter, variant and tiered-pricing plugins generate heavy queries on catalogues of more than a thousand products. Cart fragments (that little counter at the top right) trigger a request on every page, on all pages, even without a cart. Levers: page caching with clean exclusions, object cache (Redis) if the host offers it, cart fragments disabled outside the shop, database indexes, and a recent PHP version. On a B2B catalogue of 200 products I took over, the mobile score went from 69 to 99 without changing theme.

PrestaShop

PrestaShop is faster than WooCommerce with an equal catalogue, but suffers from two things: modules, often installed by the dozen and never removed, some of which load their scripts on every page, and server response time when the Smarty cache and the application cache are not configured, or when a multilingual store is hit by bots crawling all its URL combinations. On a fine-food store in five languages, the response time had climbed to 10 seconds; it is 1.3 seconds after blocking aggressive bots, preloading the cache and cleaning the logs. Levers: module audit, caching and preloading, protection against automated crawling, WebP images via the native module, PHP 8.

Shopify

The hosting is excellent and you don't touch it; the whole problem lies in the theme and the apps. Every installed app leaves scripts behind, even after uninstalling. Premium themes load carousels and animations for everyone. Product images are served resized by Shopify, but not those inserted in custom sections. Levers: cleaning residual app scripts, lazy loading of off-screen sections, section images in multiple sizes, system or self-hosted fonts. There is no acting on the server, nor on certain scripts imposed by the platform: I say so before quoting.

Headless and custom-built

A headless store (Next.js in front of Medusa, Shopify or WooCommerce) is fast by construction if you don't add back what was removed: the same pixels, the same videos, the same unresized images. On a store of this type, the image grids weighed 56 MB; it was the format and the size that mattered, not the architecture.

Where to start

Measure the most visited product page and the main category page, not just the homepage: that's where the sale happens. Then, in order: images, apps and scripts, caching with its exclusions, database, hosting. A full purchase test after each step, on a copy of the site when possible. If you want someone to take care of it with a written target, the Slow website service covers all three platforms.

Frequently asked questions