PageSpeed 99/100 on a Real PrestaShop 9.1 Store with 80+ Modules

Not a Demo. A Real Store.

When you see PageSpeed case studies online, they usually feature a minimal site with a handful of pages and barely any functionality. That is not what this is.

mypresta.rocks is our production PrestaShop 9.1 store. It runs over 80 active modules — and these are not lightweight config-only modules. We are talking about modules that add real front-end functionality: animated sliders, mega menu with dropdowns, a full one-page checkout, a blog engine with comments and sharing, a live search widget, social media feeds, product galleries, sales popups, countdown timers, cookie consent banners, loyalty programs, analytics dashboards, and more.

Every one of these modules loads its own CSS and JavaScript. Every one hooks into the front office and renders visible, interactive elements on the page. This is the kind of setup that normally destroys your PageSpeed score.

And yet, here are our Google PageSpeed Insights scores:

• Mobile: 99 Performance, 97 Accessibility, 100 Best Practices, 100 SEO
• Desktop: 99 Performance, 97 Accessibility, 100 Best Practices, 100 SEO

This is not theory. This is what Google measures right now on our live homepage.

The Numbers

Mobile (Slow 4G, Moto G Power)

• First Contentful Paint: 1.2s
• Largest Contentful Paint: 1.5s
• Total Blocking Time: 110ms
• Cumulative Layout Shift: 0
• Speed Index: 1.4s

Desktop

• First Contentful Paint: 0.3s
• Largest Contentful Paint: 0.9s
• Total Blocking Time: 30ms
• Cumulative Layout Shift: 0.011
• Speed Index: 0.5s

These results come from Lighthouse 13 running on Google’s infrastructure — the same test that powers the PageSpeed Insights report every store owner checks.

How We Did It

There is no single magic trick. Performance at this level comes from a disciplined pipeline that touches every layer of the stack. We covered the foundals in our PrestaShop performance tuning guide.

Critical CSS Extraction

The biggest enemy of fast rendering is render-blocking CSS. PrestaShop’s CCC (Combine, Compress, Cache) system merges all module stylesheets into one large file. On our store, that file is over 500KB.

We extract critical above-the-fold CSS using Google’s Critters library and inline it directly into the HTML. The full stylesheet is then loaded asynchronously using the media="print" onload="this.media='all'" pattern. The browser renders the page immediately with the inlined styles, and the rest loads in the background without blocking anything.

CSS Purging

With 80+ modules, the combined CSS contains thousands of rules that are never used on any given page. We run PurgeCSS against the actual HTML of key pages plus all JavaScript and template files in the theme and modules.

The result: 852KB down to 548KB — a 36% reduction in CSS payload. Less CSS means faster downloads, faster parsing, and a snappier swap with zero layout shift.

JavaScript Splitting

Not all JavaScript needs to run immediately. We split the CCC JavaScript bundle into two parts:

• Sync bundle (~140KB / 41KB gzip): Core functionality — jQuery and PrestaShop core scripts
• Deferred bundle (~497KB / 111KB gzip): Bootstrap, theme scripts, and non-critical module scripts loaded via <script defer>

The deferred bundle loads without blocking the main thread. This alone cut our sync JavaScript by over 60%.

Smart Asset Loading

Checkout JavaScript (180KB+ minified) is completely deferred on non-checkout pages. It loads via requestIdleCallback on the homepage and content pages, and only loads immediately on product, cart, and checkout pages where it is actually needed.

Stripe’s payment JavaScript is removed entirely from non-checkout pages.

Image Optimization

All product and banner images are served in AVIF format via Apache content negotiation — zero PHP overhead. Our batch converter processed 5,399 images, reducing total image storage from 994MB to 44MB (95.6% reduction).

Our mobile hero banner is just 25KB. The desktop version is 56KB. Both maintain excellent visual quality at these sizes.

We preload only the mobile LCP image and nothing else. On a slow 4G connection with ~200KB/s bandwidth, every preloaded resource competes with the critical CSS for bandwidth. Preloading a font or desktop banner actually made our FCP worse — a lesson learned the hard way.

WCAG 2.1 Accessibility

The high Accessibility score required careful attention to contrast ratios across every element on the page:

• All text meets WCAG 2.1 AA contrast requirements (4.5:1 for normal text, 3:1 for large text)
• Interactive elements have visible focus indicators
• Proper heading hierarchy and ARIA labels throughout
• Hidden elements use .visually-hidden correctly for screen readers

Why This Matters

Google uses Core Web Vitals as a ranking signal. A fast, accessible store ranks better, converts better, and provides a better experience for every visitor.

But more importantly for our customers: every optimization technique we use on mypresta.rocks is built into our products. The Performance Revolution module that powers this pipeline is available to all our customers. The same critical CSS extraction, the same JavaScript splitting, the same smart asset loading.

If we can hit 99/100 with 80+ active modules on a real production store — modules that add sliders, search, checkout, blog, popups, and everything in between — your store can get there too. Pair it with Instant Redis for server-side caching and you have a complete performance stack.