WooCommerce admin slow? Where wp-admin loses its time

Query Monitor is a free plugin, active on more than 200,000 sites, that adds a toolbar menu to every admin page with generation time, peak memory and query count. Open the screen people complain about, usually Orders or a product edit page. Its queries-by-component view ranks plugins by the database time they caused, and anything over 0.05 seconds lands on the slow-query list. The HTTP API panel shows every outbound request, which plugin sent it and how long it took. One blind spot: Query Monitor times a single request, so an admin that is slow only at 10 a.m., when three people work at once, is waiting for PHP workers, and no single page will show that queue.

The reports under the Analytics menu (wc-admin internally) read their own lookup tables, such as wc_order_stats, and fill them with background jobs whose hooks start with wc-admin_. Since WooCommerce 10.5, Analytics → Settings has an Updates option. Scheduled refreshes every 12 hours and is what WooCommerce recommends for most stores; Immediately writes as data arrives, and the documentation warns it may affect performance on busy stores. For a store taking orders all day, Immediately is the worse choice unless somebody needs live revenue. Run a historical import by year or quarter, never as one all-time job on a large store. If nobody opens the reports, untick WooCommerce Analytics under WooCommerce → Settings → Advanced → Features (the woocommerce_analytics_enabled option), knowing the menu disappears for the whole team.

Before High-Performance Order Storage (HPOS), each order was a row in wp_posts with its details in wp_postmeta, next to pages and products. HPOS moves orders into four indexed tables: wc_orders, wc_order_addresses, wc_order_operational_data and wc_orders_meta. New stores get it by default since WooCommerce 8.2 (October 2023); older ones stay on posts tables until someone switches under WooCommerce → Settings → Advanced → Features. WooCommerce's own benchmark used about 400,000 orders. Filtering by customer took 0.016 seconds on HPOS against 0.599 on posts tables. Treat that as a ceiling: it was a development build on a deliberately large dataset, and a store with a few thousand orders will not see a 37-fold gain. Every order-touching plugin also has to declare compatibility first, and while compatibility mode syncs both stores, each order is written twice. Steps and rollback are on the HPOS migration page.

WordPress loads every autoloaded row of wp_options on each request, admin included. Since WordPress 6.6, Site Health reports "Autoloaded options could affect performance" once the total passes 800,000 bytes. The same release stopped autoloading new options over 150,000 bytes, but rows written earlier keep their old flag, which is how a store opened in 2019 can carry several megabytes. `wp option list --autoload=on --format=total_bytes` prints the total. To list the largest rows, read-only: `SELECT option_name, LENGTH(option_value) FROM wp_options WHERE autoload IN ('yes','on','auto-on','auto') ORDER BY 2 DESC LIMIT 20`. Turning autoload off for an option an active plugin reads on every page gains nothing; the bulk read just becomes a separate query.

Action Scheduler, the queue behind WooCommerce emails, webhooks, subscription renewals and Analytics imports, runs from WP-Cron every minute and from admin traffic: at most once every 60 seconds, an admin page load fires a background request that works through due actions in batches of 25. A short queue goes unnoticed. Tens of thousands of pending or failed actions make it constant load. Counts are under WooCommerce → Status → Scheduled Actions; clearing a backlog is covered on the Action Scheduler page.

The Heartbeat API carries autosaves, holds the post lock that stops two people editing one product, and checks for expired sessions. Each beat is a full POST to admin-ajax.php. By default it fires every 60 seconds, or every 120 when the tab is hidden. Scenario: four staff with three tabs each send 12 requests a minute that serve no page anyone reads. The heartbeat_settings filter accepts an interval from 1 to 3,600 seconds. Lengthen it. Switching Heartbeat off, a single checkbox in several optimizer plugins, is the worse option, because autosave and post locking go with it and two people saving the same product overwrite each other silently.

License checks, dashboard news feeds and promotional notices sometimes run synchronously on every admin page load. WordPress waits 5 seconds by default before an HTTP request times out, so one unreachable vendor server adds five seconds to a screen. Query Monitor's HTTP API panel names the culprit. To prove the effect, set WP_HTTP_BLOCK_EXTERNAL to true in wp-config.php on a staging copy, list the hosts you need in WP_ACCESSIBLE_HOSTS, and compare timings. Never on the live store: it also blocks payment gateway calls, live shipping rates and updates. WooCommerce's suggested-extensions feed has its own switch, Show Suggestions, under WooCommerce → Settings → Advanced → WooCommerce.com.

WordPress recommends PHP 8.3 or later, and WooCommerce's server requirements list 8.3 or later, tested up to 8.4. PHP 8.2 loses security support on 31 December 2026. WordPress's built-in object cache lasts one request, so without a persistent store such as Redis every admin screen reads options and product data from the database again; Site Health recommends one once wp_posts holds 1,000 rows. Where it does not help is covered on the Redis object cache page. Workers are the layer a single-page test hides. A PHP worker handles one uncached request at a time, and every admin screen, Heartbeat beat and queue run is uncached. Pressable, for example, gives each site on its Signature plans five dedicated workers. Requests beyond that wait in line, and a long enough wait ends in a 429 or 504. If the admin is fine at 7 a.m. and crawls once the warehouse team logs in, ask the host for worker count and queue time before buying a bigger plan.

The first three steps only read. Analytics and order storage are settings with a trade-off attached. The host comes last because that conversation costs money, and a queue backlog or a 4 MB options table makes any plan look undersized.

• Query Monitor on the slow screen: generation time, slow queries, outbound HTTP calls
• Site Health: the autoloaded options warning, PHP version, object cache advice
• Scheduled Actions: pending and failed counts, and the oldest pending action
• Analytics → Settings: the Updates mode, and whether an import is still running
• Order storage: posts tables or HPOS, and how many orders the store holds
• Host: PHP worker count, queue wait at busy hours, the PHP version in use

One-click database optimizers promise a faster admin by deleting things. Some remove "orphaned" rows by pattern, and a pattern cannot tell a leftover from data an active extension still reads. Others empty the Action Scheduler tables, pending renewals and unsent webhooks included. Dropping a wc_ table because a cleanup report called it unused is worse: wc_order_stats feeds Analytics, and on an HPOS store wc_orders is the order data. The supported routes are narrower. Delete Previously Imported Data under Analytics → Settings removes only analytics data, and `wp transient delete --expired` clears expired transients. Anything else that writes or deletes runs first on staging, after a backup you have actually restored once.

Our free store audit runs this list on your slowest admin screens and returns changes in priority order. It does not promise a load time, because some causes sit with the host. Keeping the admin there month to month, with updates, queue checks and database care, is the Care Plan from $150/mo; see maintenance and support and pricing.