LightBox SEO

The problem

WooCommerce is one of the harder places to earn a strong mobile performance score. A commerce build arrives with cart and session logic that resists caching, a plugin surface where every add-on brings its own CSS and JavaScript, and product pages heavier than anything else on the site. Most builds accept 60s or 70s on mobile as the cost of doing business.

Approach

1. 01

   Treated performance as an architecture decision rather than a plugin: what loads, on which templates, and in what order.

2. 02

   Built structured data as a connected graph so products, organisation, and pages resolve as one entity rather than as unrelated markup blocks.

3. 03

   Used semantic page architecture and deliberate internal linking so topical authority accumulated across the site rather than sitting in isolated pages.

4. 04

   Put Cloudflare in front for CDN, DNS, and SSL, with caching rules matched to which routes could actually be cached.

Outcome

A 100/100 mobile Google PageSpeed score on the WooCommerce build, with secure payment processing and local search coverage across the full 50-mile service area.

In short

How was a 100/100 mobile PageSpeed score achieved on a WooCommerce site?

By treating performance as a build decision rather than a post-launch optimisation. WooCommerce's default behaviour is to load cart, session, and plugin assets on every template, including pages that will never use them — so the first move is deciding per template what is actually required and dequeuing everything else. From there: server-rendered HTML with no render-blocking third-party JavaScript, images in modern formats with explicit dimensions so layout never shifts, locally hosted fonts with font-display swap and only the weights in use preloaded, critical CSS inlined, and Cloudflare in front with caching rules that distinguish cacheable routes from genuinely dynamic ones. No single change produces the score; it is the absence of the twenty things a default commerce install would otherwise load.