WooCommerce 11.1 includes variable-product performance improvements, but a single Lighthouse run cannot show where the time went. Page cache can hide database work, persistent object cache can hide query behavior, and a CDN hit can bypass the origin entirely. The reverse problem is stale availability or pricing after a variation update. A useful benchmark records cache state, origin work, browser work, and invalidation as separate branches.
Use this before and after WooCommerce 11.1 on stores with large variation sets, slow product pages, Redis or Memcached, full-page cache, CDN cache, search filters, or frequent stock and price updates.
Quick answer
Choose small, medium, and large variable-product fixtures and freeze traffic, plugins, theme, PHP, database, and infrastructure. Run a cold origin request after clearing only the named caches, then repeated warm object-cache, page-cache, CDN, and browser runs. Capture TTFB, total HTML, variation payload, query count and time, object-cache hits, PHP time, memory, main-thread work, and Largest Contentful Paint. Change one variation's stock and price, then measure which cache keys purge and how quickly every public path becomes correct.
What to check first
- Record product and variation counts, attribute terms, stock mode, prices, extensions, theme template, PHP workers, database, object cache, page cache, and CDN configuration.
- Name each cold and warm state precisely and automate the same URL, device, location, cookie, login, and query-string fixture.
- Measure origin TTFB, SQL count and duration, cache hits and misses, PHP memory, HTML bytes, variation JSON bytes, browser main thread, and LCP.
- Update one variation through wp-admin and API, then test product, archive, search, cart, Store API, feed, and logged-in paths for stale data.
- Run enough samples to report median and a slow percentile instead of choosing the best request.
Test scenarios to run
Run the same controlled fixture across these branches. Write down the expected result before testing so a surprising response is easy to identify.
| Scenario | Fixture | Expected result |
|---|
| Cold origin | Object and page miss | Bound database and PHP work |
| Warm object cache | Page miss, object hit | Fewer repeated queries |
| Warm CDN | Edge hit | Fast response with correct variant |
| Variation update | Stock and price changed | Owned caches invalidate |
Decision rule
Call the change an improvement only when the owned cache state is reproducible, cold and warm results improve or remain within budget, and stock plus price invalidation is correct.
Safe fix order
Use a sequence that makes each result easy to prove. Stop when new evidence changes the scope or owner of the problem.
- Freeze the benchmark environment
- Measure named cache states
- Separate origin and browser payload
- Test variation invalidation
- Compare medians and slow percentiles
Diagnostic table
Use this table to connect the observed behavior to evidence and a verification step.
| Action | Evidence | Verification |
|---|
| Freeze the benchmark environment | Record product and variation counts, attribute terms, stock mode, prices, extensions, theme template, PHP workers, database, object cache, page cache, and CDN configuration. | Cold, object-warm, page-warm, CDN-warm, and browser-warm results are labeled and repeatable. |
| Measure named cache states | Name each cold and warm state precisely and automate the same URL, device, location, cookie, login, and query-string fixture. | Query, PHP, payload, browser, and user timing metrics identify the actual bottleneck. |
| Separate origin and browser payload | Measure origin TTFB, SQL count and duration, cache hits and misses, PHP memory, HTML bytes, variation JSON bytes, browser main thread, and LCP. | Variation price and stock changes reach every customer path within the stated cache window. |
| Test variation invalidation | Update one variation through wp-admin and API, then test product, archive, search, cart, Store API, feed, and logged-in paths for stale data. | Logged-in, language, currency, and customer-group variants do not share the wrong response. |
Useful command or data shape
Adapt paths, IDs, and privacy handling to the site before running commands or storing data on production.
curl -sS -D headers.txt -o product.html 'https://example.com/product/variable-item/'
wc -c product.html
wp profile stage --all --url='https://example.com/product/variable-item/'
# Label cache state and keep the same fixture for every run.
Production verification checklist
- Cold, object-warm, page-warm, CDN-warm, and browser-warm results are labeled and repeatable.
- Query, PHP, payload, browser, and user timing metrics identify the actual bottleneck.
- Variation price and stock changes reach every customer path within the stated cache window.
- Logged-in, language, currency, and customer-group variants do not share the wrong response.
Why this usually happens
- A benchmark labeled cold still receives an object-cache, page-cache, or CDN hit.
- Variation JSON size grows while server timing improves, moving the bottleneck into the browser.
- A performance plugin caches price or stock without listening to the correct invalidation event.
- Logged-in, currency, language, or customer-group variants create different cache keys from the test request.
Field notes
- Write the expected result before changing anything and keep one repeatable canary fixture for the full test window.
- Record exact versions and UTC timestamps because caches, retries, scheduled actions, and deployments can change the evidence between checks.
- Test the public browser path and the stored server-side result, not only an admin preview or isolated API response.
- Close the task only after the visible workflow, logs, stored record, and relevant downstream system agree.
Mistakes to avoid
- Changing production before recording the exact version, URL, role, request, UTC time, fixture, and rollback point.
- Treating one successful browser view as proof while logs, stored records, background jobs, caches, and downstream systems remain unchecked.
- Testing a different role, locale, cache state, form, order, device, or integration path from the one users actually reach.
- Leaving debug output, temporary exclusions, test accounts, broad permissions, helper code, or relaxed firewall rules active after verification.
What to tell the client or owner
Give the owner a concise evidence packet with the affected workflow, exact versions, UTC test time, fixture ID, expected result, actual result, key logs, change made, rollback point, final result, owner, and next review date. Remove credentials and personal data before sharing it.
Questions teams ask during testing
Should I test this directly in production?
Start with read-only evidence and reproduce on staging when the change affects code, security, checkout, forms, indexing, or permissions. If production is required, use one named canary, a short monitored window, and a tested rollback.
How do I avoid a false positive?
Repeat the same fixture with the same versions, URL, role, locale, cache state, and downstream integration. Compare stored evidence and logs instead of relying on a visual impression.
What evidence should I keep?
Keep UTC time, exact versions, URL or record ID, expected result, actual result, relevant log lines, change made, rollback point, owner, and final verification. Redact credentials and personal data.
When should I escalate?
Escalate when the site is unavailable, security scope is unclear, checkout or lead capture is affected, several systems disagree, or the next action could destroy evidence.
When HandL WP should help
Bring in help when this affects leads, checkout, search visibility, security, paid media reporting, or a client production site. HandL WP can trace the issue through WordPress, hosting, cache, tracking, and Search Console, then verify the workflow after the technical fix.
If this is active on a production site, have HandL WP benchmark WooCommerce variable products.
Related HandL WP guides
Use these related guides when the same issue touches tracking, security, checkout, or crawler visibility.
Helpful references