When a website is slow, many people immediately reduce image sizes or remove some plugins. While this can sometimes help, it doesn't always address the root cause. If the browser takes a long time to receive the first byte from the server, the page will feel slow even before images and JavaScript start loading.
The wait time before the first byte is called Time to First Byte or TTFB. Simply put, TTFB is the delay between the request sent by the browser and the initial response received. Think of it like calling a restaurant: TTFB is not the time until the food arrives at the table, but how long it takes for someone to pick up the phone and start answering.
TTFB is not the only measure of website quality. However, it serves as the foundation for subsequent metrics like First Contentful Paint and Largest Contentful Paint. If the initial response is delayed, improvements on the image or frontend side often feel less impactful.
High TTFB Doesn't Necessarily Mean the Server Needs to Be Replaced
A high TTFB value can stem from several layers. The request may traverse a long network distance, slow DNS, delayed connection to the server, PHP processes waiting on the database, or dynamic pages that never benefit from caching.
Therefore, upgrading server specifications without knowing the bottleneck can be wasteful. A larger server does not automatically resolve poor MySQL queries, PHP code calling external services, or cache configurations that are never hit.
In practice, TTFB numbers are also influenced by the visitor's location and network conditions. Use testing from multiple locations, then compare with real user data. Do not draw conclusions based on a single test on your own laptop.
First Separate: Network Issues or Origin Issues?
The term origin refers to the main server that generates the website response. A CDN or reverse proxy can serve cached content from a closer location, but when the cache is unavailable, requests are typically forwarded to the origin.
A useful initial step is to compare several types of URLs:
- Simple static pages, such as small HTML files.
- Dynamic pages processed by PHP.
- Pages that should already be cached.
- Admin endpoints or APIs that should not be cached.
If the simple HTML file is fast but the PHP page is slow, attention should be directed to the application, PHP-FPM, or database. If everything is slow, check the network, DNS, TLS, server capacity, and data center location first.
For basic checks, you can use browser DevTools, PageSpeed Insights, or commands like curl. The following example is just to see connection time and initial response:
curl -o /dev/null -s -w "DNS: %{time_namelookup}s\nConnect: %{time_connect}s\nTTFB: %{time_starttransfer}s\nTotal: %{time_total}s\n" https://example.com/The numbers from curl help with diagnosis but are not a substitute for real user data. Testing from servers located close to the origin can yield different numbers from the experience of visitors in other countries.
Check the PHP-FPM Path and Process Queue
On PHP-based websites, dynamic requests are usually forwarded to PHP-FPM. If all workers are busy, new requests will wait in the queue. From the visitor's perspective, the symptoms are similar to a slow server, while the issue is actually an imbalance between process capacity and traffic patterns.
Check the following:
- Are there too few PHP-FPM workers?
- Are there too many workers causing RAM exhaustion and the server starting to swap?
- Is there a spike in processes at certain times?
- Do the logs show processes running for an excessively long time?
- Is the PHP timeout too high, causing stuck processes to accumulate?
Do not simply increase the number of workers. Each worker requires memory. An overly aggressive configuration can cause the server to run out of RAM and actually slow down the entire website.
Ensure OPcache is Truly Active
OPcache stores compiled PHP bytecode in memory. This way, PHP does not need to read and recompile files on every request. PHP documentation explains that OPcache is designed to reduce this workload and is available as part of modern PHP installations.
A common issue is not just that OPcache is inactive, but that its capacity is too small, too many files are not accommodated, or code changes are not applied according to the deployment strategy. Check its status through monitoring tools or safe diagnostic functions, not by displaying configuration information publicly.
Avoid copying configurations from other servers without testing the application's needs. Settings like opcache.validate_timestamps can affect when file changes are detected. If timestamp checks are turned off, the deployment process must include steps to reset or restart the cache to ensure new code is actually used.
Trace Database Queries and External Services
Pages that appear simple can perform a lot of work behind the scenes: fetching product lists, calculating stock, loading recommendations, checking sessions, and then calling payment APIs or shipping services.
Record the duration of each part, not just the total page time. Enable slow query logging in the appropriate environment, check queries that scan too many rows, and ensure that frequently used columns for searches have the proper indexes. However, excessive indexing also adds costs when data is written. Database changes should be tested with traffic patterns that closely resemble real conditions.
External services also need to have timeouts. APIs that do not respond should not make visitors wait indefinitely. Use timeouts, fallbacks, and if possible, move non-essential work to background queues.
Use Caching for Pages That Are Worth Storing
Page caching can prevent the server from doing the same work repeatedly. For articles, category pages, or landing pages that do not change every second, full caching at a CDN or reverse proxy often has more impact than simply adding CPU.
However, do not cache pages that contain personal data, shopping carts, or responses that depend on sessions without clear rules. Caching errors can be more serious than slow pages because one user's data could potentially be displayed to another user.
Start with safe public pages. Set cache duration, invalidation rules after content changes, and exceptions for certain cookies or parameters. After that, monitor the cache hit and cache miss ratios to ensure the feature is working properly.
What Does This Mean for Us?
The Core Web Vitals targets remain important, including LCP, INP, and CLS. However, TTFB should be used as a diagnostic indicator, not the only value to chase. The web.dev documentation refers to TTFB as a foundational metric that precedes the subsequent loading experience, while the Core Web Vitals assessment looks at user experience more broadly.
A reasonable order of improvements is:
- Measure from multiple locations and compare static pages with dynamic pages.
- Ensure DNS, connections, TLS, and server locations are not bottlenecks.
- Check the PHP-FPM queue and CPU and RAM usage.
- Ensure OPcache is active and aligns with the deployment strategy.
- Profile database queries and external API calls.
- Implement caching on safe public pages, then measure the cache hit rate.
- Retest with real user data, not just a single result from testing tools.
A fast website is not the result of a single “optimize” button. It usually comes from the habit of measuring, isolating the problematic layers, and then changing one thing at a time. With this approach, you can address the root causes without paying for server capacity that may not be needed.
Sources & Further Reading
- Optimize Time to First Byte
- Web Vitals
- PHP OPcache Manual
- PHP OPcache Runtime Configuration
- NGINX FastCGI Module Documentation
– Rio Yotto @rioyotto