PageSpeed 99/100 on a Real PrestaShop Store with 130+ 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 8.2 store. It runs over 130 active modules — our entire catalog of SEO tools, checkout systems, product managers, blog engine, social feeds, analytics dashboards, and more. Every module loads its own CSS and JavaScript. Every module hooks into the front office.

And yet, here are our Google PageSpeed Insights scores:

• Mobile: 99 Performance, 100 Accessibility, 100 Best Practices, 100 SEO
• Desktop: 97 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: 120ms
• Cumulative Layout Shift: 0
• Speed Index: 1.5s

Desktop

• First Contentful Paint: 0.3s
• Largest Contentful Paint: 0.6s
• Total Blocking Time: 150ms
• Cumulative Layout Shift: 0.008
• Speed Index: 0.6s

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.

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 pattern. The browser renders the page immediately with the inlined styles, and the rest loads in the background without blocking anything.

CSS Purging

With 130+ modules, the combined CSS contains thousands of rules that are never used on any given page. We run PurgeCSS against the actual HTML of nine 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 (~417KB): Core functionality — jQuery, theme scripts, navigation, checkout scaffolding
• Deferred bundle (~47KB): Non-critical module scripts — social feeds, popups, product stats, cookie banners

The deferred bundle loads via requestIdleCallback, which means it only executes when the browser is idle. This eliminates its impact on Total Blocking Time entirely.

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 banner images are served in AVIF format with aggressive compression. 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 100 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 modules. 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 130+ active modules on a real production store, your store can get there too.