Lesson 3: How to correctly measure backend performance?

TLDR

Your caching plugin is not a performance solution — it’s a mask. In this lesson, you’ll learn how to measure what’s actually happening on your server when the cache isn’t there to save you. We’ll use k6 for load testing, Query Monitor and Code Profiler for real-time diagnostics, and wp profile from WP-CLI for surgical command-line profiling.

This is where the course stops being theoretical and starts getting uncomfortable.

Your cache is lying to you

In Lesson 2, we established that TTFB is the first thing to check when diagnosing performance. If the server responds slowly, no frontend optimization in the world will save you.

But here’s the problem: most store owners have never seen their real TTFB.

Why? Because caching plugins intercept the request before WordPress even wakes up. When you run a PageSpeed test on a cached page, you’re not measuring your store. You’re measuring a static HTML file served from disk or memory. That tells you nothing about what happens when:

• A customer logs in (cache bypassed).
• Someone adds a product to the cart (cache bypassed).
• A bot crawls 500 product pages simultaneously (cache cold).
• Your cron jobs fire during a sale (cache irrelevant).
• WooCommerce recalculates shipping in real time (cache impossible).

Every transaction that actually matters to your revenue happens outside of cache.

The checkout page, the cart, the “my account” area, AJAX add-to-cart calls — none of these are cacheable. And yet, when I ask store owners about their backend performance, they show me a cached homepage scoring 98 on PageSpeed.

That’s like checking your heart rate while sleeping and assuming you’re fit for a marathon.