How I Got a 97–99 PageSpeed Score on WordPress (Without a Page Builder)

After publishing my post “Stop Building Websites with Page Builders: A Developer’s Manifesto”, a few people asked the obvious follow-up question:

“Cool theory — but does it actually work?”

So here’s the proof.

This site currently scores:

• 97 Performance on Mobile
• 99 Performance on Desktop
• 96+ Accessibility
• 96+ Best Practices
• 92 SEO

And no — this isn’t the result of stacking 15 optimisation plugins and praying nothing breaks.

Most of the performance was achieved during development, not after launch.

Performance Starts With Architecture (Not Plugins)

The biggest difference between a fast WordPress site and a slow one isn’t hosting or caching.

It’s how the theme is built.

This site uses a bespoke WordPress theme, built specifically for its content and layout needs. No page builder. No generic theme framework trying to be everything to everyone.

That means:

• No unnecessary CSS or JavaScript
• No deeply nested markup
• No hidden layout logic running on every page

When you control the markup, you control performance.

The Problem With Page Builders (In Practice)

Page builders promise speed and flexibility, but the cost shows up later.

A simple section becomes:

div > div > div > div > heading > span

Each block pulls in:

• Global CSS
• Block-specific CSS
• JavaScript for editing controls (even on the frontend)

Multiply that across a full page and suddenly you’re shipping hundreds of KBs of unused code just to render text and images.

That bloat directly impacts:

• Largest Contentful Paint (LCP)
• Time to Interactive (TTI)
• Core Web Vitals overall

No cache plugin can fully fix that.

Bespoke Themes = Predictable Performance

With a custom theme:

• Every section is intentional
• Every stylesheet is written once, locally
• JavaScript is added only when needed
• Layout logic lives in code, not the database

I use ACF-based blocks so clients can safely update content without breaking layout or brand consistency.

Clients still get flexibility — just guardrails instead of chaos.

Plugins I Use (And Why Only These)

This site runs with very few plugins, because plugins should enhance, not compensate for poor architecture.

LiteSpeed Cache

Used for:

• Page caching
• Asset optimisation
• Server-level performance improvements

Configured conservatively — not blindly enabling every option.

WebP Express

Used to:

• Serve WebP images where supported
• Reduce image payload sizes without sacrificing quality

That’s it.

No animation plugins.
No “mega optimisation” plugins.
No builders hiding performance issues.

Most Optimisation Happened Before Launch

Key performance decisions made during development:

• Semantic HTML (less DOM complexity)
• Component-based CSS (no global overrides fighting each other)
• Minimal JavaScript (no frameworks where vanilla JS works)
• Image sizing handled at template level
• Fonts loaded intentionally (no unnecessary weights)

By the time caching was added, the site was already fast.

Caching didn’t save the site — it enhanced an already solid foundation.

The Real Takeaway

If you care about:

• Performance
• Maintainability
• Security
• Long-term scalability

Then performance can’t be an afterthought.

Page builders make it easy to launch fast —
but bespoke themes make it possible to stay fast.

A bit harder upfront.
Much cheaper long term.

If you’re a developer, agency, or business owner who wants performance without constant firefighting — build less, but build it properly.