TTFB is the wait time until the first response byte is received, not the full display time of the page. If HTML starts late, shrinking the hero image may reduce the download volume but does not necessarily change the TTFB. This time can be used in DNS, connection and TLS, CDN, web server array, PHP execution, database query, or external API.
Quick answer:Measure a fixed URL from multiple positions and times, separate cache hits and misses, and match the request time with the access log and application timing. Then adjust the slowest layer. A general, fixed number for TTFB is not going to take the place of the actual baseline and your users' needs.
What are the sections of the TTFB?
- Resolving DNS and setting up TCP
- TLS negotiation in HTTPS
- Network path to CDN or origin
- Wait in the reverse proxy or PHP-FPM queue
- WordPress, plugins and templates
- MySQL queries and contacts to external services
- Production and delivery time of the first response part
Do not compare the results of the Tehran browser directly with the European probe or hot server request.
Repeatable measurement
curl -sS -o /dev/null -w 'dns=%{time_namelookup} connect=%{time_connect} tls=%{time_appconnect} start=%{time_starttransfer} total=%{time_total}
' https://example.com/pageReplace the sample domain. Try several times and keep redirects, cookies, compression and location constant.time_starttransferIt brings together all the components before the first byte and it's not PHP time alone.
Separate the hit and miss cache.
A public page may be answered in a CDN or page cache, while the user logs in, searches and checkouts arrive at the origin. Do not save the cache header and cut the first request after the purge with a hot request. Low hit rate, unwanted bypass or continuous purge can ruin the average.
Caching personal responses or shopping cart is a risk of data exposure and misbehavior. Design the rule based on the actual cookie, path and method and test it with two independent sessions.
If the time is on the network or TLS
Check DNS chain, geolocation, packet loss, HTTP/HTTPS redirects, and certificate chain. A CDN can reduce the distance of cached content, but dynamic miss is still dependent on the origin. Schedule changing DNS or certificates with TTL and rollback; disabling TLS authentication is not a performance solution.
If the request stays in the PHP-FPM row
Active/idle worker, see row, duration and memory consumption when slow. Worker increase is only useful when CPU and RAM capacity are high. On saturated CPU, more worker can increase competition; on limited RAM there is a risk of swap and OOM. Long timeout also does not treat row.
If the CPU time is high,The WordPress CPU detection manual.PHP-FPM controlled slowlog can display a long request stack, but file access and overhead must be managed.
WordPress running time
The plugin or template may run a large query, duplicate processing, or concurrent HTTP call. In staging with the Query Monitor or profiler, record the hook, caller, and duration. The number of plugins or queries is not a sufficient metric; duration, frequency, and request path matter.
A page that is for the moderator only should be viewed separately from the public page.The slowdown wp-adminIt's not usually solved with a public page cache.
Database and query
Slow query log, plan, and checked rows. A query without an index or lock can wait for the rest of the request. Deleting an option and a transient or creating an index without recognizing a schema is risky; first, have a backup and clone and measure the write effect of each index.
API and external service
Font, license, CRM, price, text, or security service may be sounded in the page output path. Timeout and retry can multiply the TTFB. Async or cache unnecessary calls only if the latest data logic allows. Disabling TLS verification or hard-coding IP is not a stable way.
The process of reform from low-risk to advanced
- Remove additional redirects and obvious cache errors.
- Cache the right public pages with the right policy.
- Remove unnecessary HTTP calls and jobs from the interactive request.
- Query and correct the wrong autoload based on the evidence.
- Synchronize PHP-FPM and OPcache with workload and resources.
- Change the hosting capacity or architecture if you can prove the limitations.
Common Mistakes
- Using a test and a location
- One knows TTFB with Core Web Vitals or full-time page
- Caching personal and transactional endpoints
- Increase worker without computing RAM and CPU
- Delete the database to reduce the number without finding the query
- Ignoring redirect and cache status
What do we measure after change?
Compare median and higher hashes across multiple URLs and hit/miss mode. Error rate, CPU, PHP queue and query time should not be aggravated to reduce the appearance of TTFB. Keep checkout, login and logged in users on smoke test.
When is a specialist examination necessary?
If the TTFB is alternating, load-dependent, or varies between edge and origin, a general change is not responsible.WordPress speed boost serviceIt can document time between network, cache, PHP and MySQL separation and pre- and post-results.
Common Questions
Does a CDN always reduce TTFB?
It usually helps to cache near the user; dynamic miss or origin will still need to be corrected.
Does the image affect the TTFB?
It usually has a greater impact on downloads and renders, unless it is generated or processed on a server request.
Why is the first request slower?
DNS, TLS, connection and cold cache may play a role; compare with a few labeled executions.