LightBox SEO
2016–2026
LightBox SEO was a technical SEO practice I founded in 2016 and sold in June 2026. It covered SEO delivery for client sites alongside full-stack WordPress development, which meant audit findings shipped as code rather than as recommendations handed to someone else.
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
- 01
Treated performance as an architecture decision rather than a plugin: what loads, on which templates, and in what order.
- 02
Built structured data as a connected graph so products, organisation, and pages resolve as one entity rather than as unrelated markup blocks.
- 03
Used semantic page architecture and deliberate internal linking so topical authority accumulated across the site rather than sitting in isolated pages.
- 04
Put Cloudflare in front for CDN, DNS, and SSL, with caching rules matched to which routes could actually be cached.
What was built
- WordPress and WooCommerce build with custom themes and plugins
- Schema.org structured data and semantic HTML throughout
- Internal linking and topical authority architecture
- Cloudflare CDN, DNS, SSL, and caching configuration
- Secure payment processing
- Local SEO across a 50-mile service area, including Google Business Profile and Maps
Stack
- Interface design
- WordPress
- WooCommerce
- PHP
- JavaScript
- Cloudflare
- Schema.org
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.
Key decisions
- 01
Treated performance as a build decision, per template
Instead of: Adding a caching or optimisation plugin to a standard build
Plugins compensate for load that should never have been requested. Deciding per template what is actually needed removes the cause instead of masking it, which is what makes 100/100 reachable on WooCommerce at all.
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.