The right first question is “where does the time go?” This article walks through the places we look first when a store is slow, roughly in the order they tend to matter, and what we do about each. The method is always the same: measure, change one thing, measure again.

Measure before touching anything

Three tools cover almost everything:

• Query Monitor on a staging copy with production data, to see the queries, hooks and HTTP calls behind a single request.
• Server timing or an APM (New Relic, Blackfire, or Server-Timing headers from the host) to see the distribution across many requests, including the ones you would not think to load yourself.
• A slow query log on the database, with a low threshold, for a day.

From these you get a short list: the slowest routes, the slowest queries, the plugins that appear in every trace. Fix in that order. Everything below is the catalogue of what usually turns up.

The product data model

WooCommerce stores products as posts and almost everything about them as post meta. Price, stock, SKU, attributes, visibility: each is a row in wp_postmeta, and a catalogue of ten thousand products with fifty meta keys each is half a million rows in a table indexed on meta_key but not usefully on meta_value.

Symptoms:

• Shop and category pages that get slower as the catalogue grows.
• Filters and sorting by price or attribute that take seconds.
• Admin product lists that time out.

What works:

• Use the lookup tables. WooCommerce maintains wp_wc_product_meta_lookup precisely so that price, stock and rating queries do not hit post meta. Custom queries that sort or filter by price should join that table, not wp_postmeta. Check that the table is populated (wc update and the regeneration tools exist for a reason).
• Stop querying meta for lists. A product grid that calls get_post_meta() per product for a value the lookup table already has is the most common self-inflicted wound we see in themes.
• Index what you actually filter on. If the business genuinely filters on a custom meta key, that data belongs in a custom table with an index, or at minimum in a taxonomy.

Orders: move to HPOS

Orders have the same problem as products, only worse, because order data grows without limit and is written on every checkout. High-Performance Order Storage (HPOS) moves orders into dedicated tables with real columns and indexes. On stores with more than a few tens of thousands of orders it is the single largest database win available, and it is now the default for new installations.

The work is in compatibility. Every plugin that touches orders must declare HPOS support and use the CRUD API ($order->get_meta(), wc_get_orders()) instead of get_post_meta() and WP_Query on the shop_order post type. The migration is safe and reversible, but it is a project, not a checkbox: audit the plugins, run with compatibility mode on staging, then switch.

Cart fragments and the uncacheable request

Every page in a default WooCommerce theme fires an AJAX request after load to refresh the mini-cart (“cart fragments”). It is uncached by definition, it starts WordPress from scratch, and it runs even for visitors who have no cart. On a busy store it can be the majority of PHP requests.

Options, in order of preference:

1. Do not load the fragments script on pages that do not need it. Product and content pages rarely need a live mini-cart. Dequeue wc-cart-fragments outside the cart and checkout, and render the cart count from the session on the rare pages that show it.
2. Use the Store API and the Blocks mini-cart, which fetch cart state only when opened.
3. If the design insists on a live count everywhere, at least make that one endpoint as cheap as possible by unloading unrelated plugins on AJAX requests.

The same reasoning applies to every plugin that adds an uncached request to each page view: live search, wishlist counters, recently viewed products, analytics trackers routed through WordPress. Each one is a full WordPress boot.

Sessions and the object cache

WooCommerce keeps a session per visitor with a cart, in wp_woocommerce_sessions, and reads it early on nearly every request. Without a persistent object cache, transients, options and sessions all round-trip to MySQL.

A persistent object cache (Redis or Memcached) is the first infrastructure change we make on any store that lacks one. It turns thousands of repeated small queries into memory lookups. It also has two consequences that need managing:

• Autoloaded options. Everything with autoload = yes in wp_options is loaded on every request. Plugins that store large serialized arrays as autoloaded options make every request slower, cache or not. We audit the autoloaded size (anything over about a megabyte is worth cleaning) and fix the offenders.
• Transient hygiene. WooCommerce and many extensions cache computed results in transients. With an object cache these live in memory and expire cleanly; without one they accumulate in the database until something cleans them up.

Checkout

Checkout is the request that matters most and is the hardest to speed up, because it runs the most code: shipping calculation, tax, payment gateway initialisation, validation, plus every plugin that hooks into the process.

Where the time usually goes:

• Shipping methods that call external APIs on every recalculation. Rates should be cached per destination and cart signature for a sensible interval.
• Tax lookups done live instead of from a cached table.
• Gateways that initialise on every page, not just the checkout. Payment plugins are frequent offenders here, loading SDKs and making token calls on the home page.
• Order creation hooks that send emails synchronously, call a CRM, or regenerate reports before the customer sees the confirmation page. Those belong in a queue (Action Scheduler is already there).

Blocks-based checkout with the Store API is measurably lighter than the shortcode checkout, because the front end talks to a purpose-built REST API instead of posting the entire form and re-rendering. Whether a store can use it depends on gateway and extension support, which is the audit we do first.

Plugins that touch every request

The last category is the most political. Every active plugin has a fixed cost on every request: files loaded, hooks registered, options read. Most are cheap. A few are not, and they do not announce themselves.

The trace tells you which ones. In our experience the usual names are page builders with front-end assets, all-in-one SEO and security suites, translation plugins that scan output, and analytics or marketing integrations that load their SDK server-side. The fix is rarely “delete it”; it is usually “load it only where it does something”, which is a small must-use plugin that deactivates plugins by route.

What does not help much

Two things show up in every performance conversation and rarely move the numbers on a store:

• Front-end optimisation plugins (minify, combine, defer). They improve a Lighthouse score on a cached product page and do nothing for the checkout, which is where revenue is lost. Do them last, not first.
• Moving hosts without changing anything else. A faster server makes a slow query faster in absolute terms and changes nothing about how the store scales. If the plan is to grow, the data model and the request profile have to change.

The order we work in

1. Measure: traces, slow query log, autoload size, request counts per route.
2. Infrastructure that removes whole classes of cost: object cache, PHP 8.x, HTTP/2, a CDN for static assets.
3. Data model: lookup tables, HPOS, custom tables for anything filtered at scale.
4. Request profile: remove uncached requests per page view, load plugins by route.
5. Checkout: cache external calls, queue side effects, evaluate Blocks checkout.
6. Front-end polish, once the server side is honest.

Every step is reported with a before and an after, on the routes that matter. That is the difference between performance engineering and performance plugins.

None of it is exotic. The value is not in any single tool but in never having to decide again where things go.

Why a uniform structure matters more than the tools

WordPress does not impose a project layout. A site can be a theme with a functions.php of four thousand lines, a dozen plugins from a marketplace, or a Composer-managed application with a proper dependency tree. All three run. Only one of them can be tested, reviewed and handed to a new engineer without a walkthrough.

When every project uses the same layout:

• Onboarding is measured in hours. An engineer who has worked on one of our projects knows where the code, the tests, the environment definition and the deployment scripts are on all of them.
• Tooling is copied, not rebuilt. The CI workflow, the linter configuration and the test bootstrap are the same files. Improvements made on one project are pulled into the others.
• Reviews focus on the change. Nobody spends review time arguing about file placement or formatting; the linter already did.

The repository layout

The root of a site repository looks like this:

.
├── .github/workflows/     # CI: lint, unit, e2e, deploy
├── config/                # Environment config (never secrets)
├── web/                   # Web root
│   ├── wp/                # WordPress core, installed by Composer
│   ├── app/               # wp-content equivalent
│   │   ├── mu-plugins/    # Site-specific, always-on code
│   │   ├── plugins/       # Third-party and our own plugins
│   │   └── themes/        # The site theme (and only that)
│   └── index.php
├── tests/
│   ├── phpunit/           # Unit and integration tests
│   └── e2e/               # Playwright specs
├── composer.json
├── package.json
├── phpcs.xml.dist
├── phpstan.neon.dist
└── .wp-env.json

A few decisions in there are worth explaining.

WordPress core is a dependency, not a checkout. Composer installs it into web/wp/, and wp-content moves to web/app/. Core is never edited, and upgrading it is a version bump in composer.json that goes through the same pull request flow as any other change.

Site logic lives in must-use plugins. Business logic that must always run (custom post types, integrations, roles) goes into web/app/mu-plugins/, split into small, single-purpose files or a single namespaced plugin with an autoloader. It does not live in the theme, so a redesign never risks breaking an integration.

The theme is presentation only. Templates, block patterns, theme.json and assets. If a function in the theme does something a different theme would also need, it is in the wrong place.

Third-party plugins are pinned. Every plugin, including premium ones through a private Composer repository, is listed with a version. The lock file is committed. Production runs exactly what was tested.

Coding standards as a gate, not a suggestion

phpcs.xml.dist extends the WordPress Coding Standards ruleset with a small set of project-specific rules: the text domain, the prefix for global functions and hooks, and the minimum PHP version for the compatibility sniffs.

<?xml version="1.0"?>
<ruleset name="Project">
    <file>web/app/mu-plugins</file>
    <file>web/app/themes/project</file>

    <arg name="extensions" value="php"/>
    <arg value="sp"/>

    <rule ref="WordPress"/>
    <rule ref="WordPress.WP.I18n">
        <properties>
            <property name="text_domain" type="array" value="project"/>
        </properties>
    </rule>
    <rule ref="WordPress.NamingConventions.PrefixAllGlobals">
        <properties>
            <property name="prefixes" type="array" value="project"/>
        </properties>
    </rule>

    <config name="testVersion" value="8.1-"/>
    <rule ref="PHPCompatibilityWP"/>
</ruleset>

Two things make this work in practice. First, the linter runs in CI and blocks the merge, so the standard cannot drift. Second, phpcbf fixes formatting automatically, so engineers are not asked to hand-indent code to satisfy a robot. What remains for humans are the sniffs that matter: escaping output, sanitising input, nonces on state-changing requests, prepared SQL.

PHPStan sits next to it at a moderate level with the WordPress stubs installed. It catches the class of bug the linter cannot: calling a function with the wrong argument type, a property that may be null, a hook callback with the wrong arity.

Unit and integration tests

We use PHPUnit with the WordPress test framework, run against a real database inside wp-env. The distinction we keep:

• Unit tests cover pure logic: price calculations, data transformations, validation. They do not need WordPress loaded and run in milliseconds.
• Integration tests cover code that talks to WordPress: a custom REST endpoint, a hook that changes an order status, a query with meta conditions. They load WordPress and use its factories.

A typical integration test for a REST endpoint:

public function test_endpoint_requires_capability(): void {
    wp_set_current_user( self::factory()->user->create( [ 'role' => 'subscriber' ] ) );

    $request  = new WP_REST_Request( 'POST', '/project/v1/export' );
    $response = rest_get_server()->dispatch( $request );

    $this->assertSame( 403, $response->get_status() );
}

The goal is not coverage as a number. The goal is that every piece of logic a client would be upset to see broken has a test that would fail if it broke.

End-to-end tests for the flows that pay the bills

Unit tests cannot tell you that checkout works. For that we use Playwright against a full WordPress instance started by wp-env in CI, with a seed script that creates the products, pages and users the tests need.

We keep the end-to-end suite deliberately small: the handful of journeys whose failure would be a real incident. On a store that is usually:

1. Browse to a product, add it to the cart, complete checkout with the test payment gateway.
2. Log in to the account area and see the order.
3. Submit the main lead or contact form.
4. Load the home page and the top landing pages without console errors.

test('guest checkout completes', async ({ page }) => {
  await page.goto('/product/sample-product/');
  await page.getByRole('button', { name: 'Add to cart' }).click();
  await page.goto('/checkout/');
  await page.getByLabel('First name').fill('Test');
  await page.getByLabel('Last name').fill('Customer');
  await page.getByLabel('Email address').fill('test@example.com');
  await page.getByRole('button', { name: 'Place order' }).click();
  await expect(page.getByText('Your order has been received')).toBeVisible();
});

Each test takes seconds. The suite runs on every pull request and again after every deployment, against the deployed environment. The second run is the one that catches configuration drift: a payment gateway left in the wrong mode, a caching rule that broke the cart.

Continuous integration

The workflow is the same file on every project, with the project name as the only variable:

1. Install PHP and Composer dependencies with caching.
2. Run phpcs and phpstan.
3. Start wp-env, run PHPUnit.
4. Build front-end assets, start the site, run Playwright.
5. On the main branch, deploy to staging; on a tag, deploy to production.

A pull request that fails any of the first four steps cannot be merged. It sounds strict. In practice it removes an entire category of conversation (“did you test it?”) and replaces it with a green check.

What this costs, and what it returns

Setting this up on a new project takes a day, most of it copying from the previous one. Maintaining it costs a few hours a month, mostly dependency updates.

What it returns, over the years a site is in production:

• Regression testing that does not consume QA hours. The suite runs on every change, including plugin and core updates.
• Fast onboarding. New engineers ship on their first day because the structure and the tooling are already familiar.
• A codebase that can be handed over. If a client ever moves in-house or to another agency, they receive a repository that explains itself.

That last point is the real reason. A site built this way belongs to the client in a meaningful sense, not just legally. That is what we mean by engineering, as opposed to assembling.