Got a call from a client in a panic. Their high-traffic WooCommerce store, the kind with tens of thousands of orders, was timing out in the admin dashboard. The front end was fine, but they couldn’t see or manage new orders. For a business doing that kind of volume, a jammed admin dashboard is a code red.
I assumed it was a hosting problem, since that’s the obvious culprit. So I checked the server resources, and we even threw a Redis object cache at it, hoping to power through. That worked for about five minutes, then the timeouts came right back. The issue wasn’t the server at all. It was the code, and throwing money at more hardware was a dead end.
Finding the N+1 query mess
When the easy fix fails, you have to dig deeper. I installed the Query Monitor plugin and the problem was obvious: the main Orders screen was running hundreds of individual get_post_meta queries. It turned out a third-party shipping plugin had added a custom column to the order list to show the tracking number. Decent idea, bad execution. For every single row, it ran a brand new database query. That is a classic N+1 problem, and it will drag any site to a crawl.
// Step 1: Add the custom column
add_filter( 'manage_edit-shop_order_columns', 'add_shipping_method_column' );
function add_shipping_method_column( $columns ) {
$columns['shipping_method'] = 'Shipping Method';
return $columns;
}
// Step 2: Populate the column EFFICIENTLY
add_action( 'manage_shop_order_posts_custom_column', 'populate_shipping_method_column', 10, 2 );
function populate_shipping_method_column( $column, $post_id ) {
if ( 'shipping_method' === $column ) {
// This is the naive way that causes the N+1 problem.
// $shipping_method = get_post_meta( $post_id, '_shipping_method', true );
// The RIGHT WAY is to pre-fetch this data for all visible posts
// outside this function using a single, optimized query.
// For this example, we just show the concept.
$order = wc_get_order( $post_id );
echo esc_html( $order->get_shipping_method() );
}
}So, what’s the point?
The lesson is that a slow WooCommerce admin is almost always a code problem, not a server one. Before you spend a dime upgrading your hosting plan, do a proper diagnosis. It’s something this line of work reinforces constantly, a point I saw echoed in a retrospective over on Carl Alexander’s blog. The fix is usually about writing more efficient queries, not throwing more resources at the wall.
This stuff gets complicated fast. If you’re tired of debugging someone else’s mess and just want your site to work, drop my team a line. We’ve probably seen it before.
