woocommerce Case study
A2 Loopback Forensics
Some slowness does not show up in a query log. WordPress makes HTTP calls to its own hostname for cron, the REST API and health checks, and when those calls stall the symptom appears somewhere else entirely. This is the diagnostic work that found where the time was actually going.
The business problem
The admin was slow, the database was not the bottleneck, and the slow query log was unremarkable. That combination usually means the request is blocked on something that is not the database. The suspects were WordPress loopback requests: the site calling its own URL through the HTTP API, where a firewall rule, a DNS quirk or a proxy can turn an internal call into a full timeout.
What I delivered
- A tracing pass over every outbound call WordPress makes during an admin request, separating true third-party calls from the site calling itself.
- Explicit host detection that treats the site's own hostnames, localhost and 127.0.0.1 as local, so the egress controls that came out of this work could never accidentally block WP-Cron or the REST API.
- Fail-fast timeouts on the remaining external calls, which converts an invisible ten-second stall into a fast, visible failure.
- A monitor mode that logs what would have been affected before anything is actually blocked.
Technical approach
- The first question was not how to make it faster but what the request was waiting on, which meant instrumenting the HTTP layer rather than the query layer.
- Site hostname resolution handles the www and non-www forms and the configured home and site URLs, because a loopback request to the wrong variant is exactly the case that breaks.
- Findings fed directly into the egress firewall rather than staying in a report, so the diagnosis and the fix live in the same code path.
- Everything defaults to observing, not intervening. Blocking is opt-in per destination once the logs justify it.
Result and evidence
The slowness was traced to outbound calls rather than to WordPress or the database, which redirected the whole effort away from query tuning that would not have helped. The concrete output is the loopback-safe host detection now used by the egress firewall in production.
Commercial value
The saved effort is the point. Without this pass the obvious next step would have been database work on a system whose database was fine.
Readable implementation brief
implementation_brief {
project: "A2 Loopback Forensics"
question: "what is the admin request blocked on?"
method: "instrument the HTTP layer, not the query layer"
finding: "outbound calls, not DB; loopback must stay exempt"
local_detection: "home_url + site_url hosts, www variants,
localhost, 127.0.0.1"
output: "loopback-safe host check used by the egress firewall"
posture: "monitor first, block per destination after evidence"
}What this project shows
Diagnosis is the part of performance work that gets skipped, and skipping it is how teams spend a month optimizing the wrong layer.
I would rather spend a day proving where the time goes than a week making something fast that was never slow. This page exists because that day paid for itself.