Building lightning-fast WordPress sites at scale.

01Introduction

WordPress runs a huge share of the web, but a default install rarely delivers the speed people expect in 2024. That gap isn’t WordPress’s fault so much as a consequence of how flexible it is: every theme, plugin, and integration is an invitation to add work to a page load.

This article walks through the approach I use on large WordPress builds — the one that produces sites that are not just fast on launch day, but consistently fast at scale, with a team of contributors publishing daily.

02The performance problem in WordPress

Out of the box, WordPress prioritizes flexibility. Flexibility comes with overhead: excessive queries, render-blocking assets, unoptimized images, and plugins that leak performance across every template. At scale these small inefficiencies compound, and they show up where it hurts — Core Web Vitals, search visibility, and user trust.

The usual response is to install a caching plugin and call it done. Caching hides symptoms, and it hides them unevenly: the cached homepage looks great in a lab test while logged-in users, search pages, and every uncached path stay slow.

Performance is not a feature. It’s a foundation. You can’t optimize what you haven’t architected.

03A system-level approach

Instead of chasing individual scores, I treat the site as a stack and ask what each layer is responsible for. Every request passes through all of them, so a fix at the wrong layer just moves the cost around.

• Browser & deviceWhat the visitor actually experiences
• CDNGlobal edge delivery and asset caching
• Caching layerPage, object, and transient caches
• ApplicationWordPress core, theme, and plugins
• DatabaseOptimized queries and indexes

Working top-down keeps the effort honest. If the database is doing unnecessary work on every request, no amount of edge caching makes the site feel fast for the people who miss the cache.

04Building a fast theme architecture

A fast WordPress site starts with a lean, intentional theme. I build with performance in mind from day one, which in practice means four commitments:

• Minimal dependencies and no render-blocking assets in the critical path.
• Component-driven templates with clear data boundaries.
• An efficient enqueue strategy: critical CSS inlined, everything else deferred.
• Accessibility and semantics baked in, not bolted on afterwards.

The enqueue strategy is where most themes quietly lose a second. Deferring non-critical scripts is a few lines and one of the highest-leverage changes available:

add_filter( 'script_loader_tag', function ( $tag, $handle ) {
    $defer = [ 'app', 'vendor' ];

    if ( in_array( $handle, $defer, true ) ) {
        return str_replace( ' src=', ' defer src=', $tag );
    }

    return $tag;
}, 10, 2 );

Notice what this doesn’t do: it doesn’t defer everything. Blanket deferral breaks scripts with ordering assumptions. An explicit allowlist is boring, reviewable, and safe to extend.

05Data, caching & delivery

Once the theme is lean, the remaining cost is data. Most slow WordPress pages are slow because they ask the database for more than they need, on every single request. Cache the expensive query rather than reaching for a full-page cache to paper over it:

// Cache the expensive query, not the whole page.
function la_featured_posts() {
    $key   = 'la_featured_posts_v2';
    $posts = get_transient( $key );

    if ( false === $posts ) {
        $posts = get_posts( [
            'posts_per_page'      => 6,
            'no_found_rows'       => true,
            'update_post_meta_cache' => false,
        ] );

        set_transient( $key, $posts, 15 * MINUTE_IN_SECONDS );
    }

    return $posts;
}

Then layer delivery on top: object caching in memory, page caching for anonymous traffic, and a CDN configured with cache keys that match how the content actually varies. Version your cache keys — the _v2 above is there so a shape change can’t serve stale data.

06Measuring what matters

Lab tools tell you whether a change is plausible. Field data tells you whether it worked. I keep both, and I only celebrate the second. On the build behind this article, the numbers moved like this:

Build

2.1s

LCP

0.9s

CLS

0.02

TBT

60ms

Just as important: a budget in CI that fails the build when a bundle crosses its threshold. Without it, every one of these wins has a shelf life of about one sprint.

07Lessons learned

1. Architecture beats optimization. The cheapest millisecond is the one you never spend.
2. Plugins are dependencies. Each one needs an owner, a reason, and a performance cost you’ve measured.
3. Editors are users too. If publishing is slow, content quality drops — and that costs more than a slow page.
4. Budgets keep wins. Enforcement in CI is what separates a fast launch from a fast site.

08Key takeaways

Treat the stack as a system, put the work in the layer that owns it, and measure in the field. Do that and WordPress is entirely capable of feeling fast at any scale — with the editorial flexibility that made you choose it in the first place.

If you’re staring at a slow platform and not sure which layer is to blame, tell me about it — that diagnosis is most of my work.