The Request Path Most People Never See
When someone opens a WordPress page, their request travels through several layers before WordPress even runs. Understanding that path is the key to fixing real performance issues.
Here is a simplified server-level breakdown.
1. DNS and TLS Handshake
The request begins with DNS resolution and a secure connection. Slow DNS or heavy TLS negotiation adds latency before the page even starts loading.
2. CDN and Edge Cache
If you use a CDN, the request may be served at the edge. This is the fastest path because it avoids the origin server entirely.
3. Load Balancer and Reverse Proxy
When the request reaches your origin, a load balancer or reverse proxy routes it to the right site or container. Full-page caching can stop the request here and return HTML immediately.
4. PHP-FPM and Worker Availability
If the page is not cached, the request enters PHP. At this point, the number of available workers determines how quickly the request can be processed. Too few workers create queues and slow responses.
5. WordPress Core and Plugin Execution
WordPress loads core files, themes, and plugins. This is where inefficient code can slow things down, but it is only one part of the pipeline.
6. Database Queries
Most dynamic pages hit the database. Slow queries or insufficient database resources increase response time and TTFB.
7. Response and Compression
Finally, the server sends HTML back to the client. Compression and protocol choices (HTTP/2 or HTTP/3) affect how fast that response is delivered.
Where Bottlenecks Actually Appear
Most slowdowns happen before WordPress code even runs:
- CDN misses lead to more origin traffic.
- PHP worker limits cause queueing.
- Database I/O constraints increase query time.
- Overloaded servers add latency everywhere.
The Takeaway
WordPress performance is a full-stack problem. The fastest sites optimize each layer, not just themes and plugins. When you understand the request path, you can fix the real bottlenecks.
XeroWP focuses on server-level performance so WordPress requests stay fast from edge to database.