A customer came to us with a website that felt sluggish across the board. Before diving into the server side, we checked the obvious front-end suspects first: image sizes, theme weight, caching setup. Nothing stood out. The front end was clean, indicating the delay occurred before any content even left the server. You could actually see it sitting there in the browser’s Network tab, that long bar before the first byte arrived.<\/p>\n\n\n\n
Identifying the Bottleneck<\/strong><\/p>\n\n\n\n To get a clearer picture, we ran a curl timing breakdown:<\/p>\n\n\n\n curl -o \/dev\/null -s -w “DNS: %{time_namelookup}\\nConnect: %{time_connect}\\nSSL: %{time_appconnect}\\nTTFB: %{time_starttransfer}\\nTotal: %{time_total}\\n” https:\/\/xyz.com<\/p>\n\n\n\n Output came back like this:<\/p>\n\n\n\n DNS: 0.021<\/p>\n\n\n\n Connect: 0.034<\/p>\n\n\n\n SSL: 0.083<\/p>\n\n\n\n TTFB: 2.154<\/p>\n\n\n\n Total: 2.521<\/p>\n\n\n\n DNS, connection, and SSL are all fast. The 2.15-second TTFB was the problem, and it was clearly happening at the server or application layer, not anywhere in between.<\/p>\n\n\n\n Step 1: Server Resource Analysis<\/strong><\/p>\n\n\n\n The first thing was to get eyes on the server itself. We pulled up top, htop, vmstat, iostat -x, and free -h to see what was going on. The numbers weren’t pretty. CPU was sitting at 95% more often than not, PHP-FPM had run out of workers to handle new requests, load average had climbed well past anything reasonable, and memory was almost gone. Basically, the server was already at its limit just handling day-to-day traffic; there was nothing left in reserve.<\/p>\n\n\n\n Step 2: Web Server Review<\/strong><\/p>\n\n\n\n We pulled the service status for both Apache and Nginx, then sat watching the access and error logs scroll by in real time. Right away, we could see requests regularly taking 2+ seconds. So we started making adjustments: more PHP-FPM workers, Keep-Alive switched on, worker process tuning, Brotli\/Gzip compression, HTTP\/2 enabled. Some of that helped. But the CPU was still climbing above normal after normal traffic, which told us we hadn’t found the real problem yet.<\/p>\n\n\n\n Step 3: PHP Performance<\/strong><\/p>\n\n\n\n The site was WordPress with quite a few plugins piled on top, so slow logging felt like the right next move:<\/p>\n\n\n\n request_slowlog_timeout = 3s<\/p>\n\n\n\n slowlog = \/var\/log\/php-fpm\/slow.log<\/p>\n\n\n\n That pointed us to something almost immediately: one plugin was constantly hitting the database on every request, regardless of which page was being loaded or whether it needed to. We also reviewed the PHP version, confirmed that OPcache was actually doing anything, and reviewed memory limits and the max execution time. Getting PHP upgraded and OPcache working properly took a decent chunk off script execution times.<\/p>\n\n\n\n Step 4: Database Analysis<\/strong><\/p>\n\n\n\n Next, we turned our attention to the database. SHOW PROCESSLIST showed us what was running, then we flipped on slow query logging:<\/p>\n\n\n\n slow_query_log = ON<\/p>\n\n\n\n long_query_time = 1<\/p>\n\n\n\n Three things stood out: indexes were missing on tables that really needed them, the same SELECT queries were firing repeatedly when they could have been cached, and WordPress had accumulated a huge number of autoloaded options that were being pulled on every page load, whether needed or not. We added the missing indexes, optimised the heavy tables, cleared expired transients, switched off unused plugins, and reduced autoloaded data. Backend processing time dropped noticeably.<\/p>\n\n\n\n Step 5: Caching<\/strong><\/p>\n\n\n\n Up to this point, every request was going through the full PHP and MySQL stack. To prevent requests from hammering the backend, we implemented several caching mechanisms: FastCGI cache, Redis for objects, PHP OPcache, and browser-level caching. Full-page caching for unauthenticated users had the biggest single impact; those requests stopped hitting the backend entirely.<\/p>\n\n\n\n Step 6: CDN Optimisation<\/strong><\/p>\n\n\n\n Static assets were already served from a CDN, but HTML responses were still served from the origin server. Once we tightened up the edge caching rules, far more requests started being answered by CDN nodes rather than bouncing all the way back to the origin. That alone took a good amount of pressure off the server and made a visible difference for visitors around the world.<\/p>\n\n\n\n Step 7: DNS and SSL<\/strong><\/p>\n\n\n\n DNS was quick to rule out. dig and nslookup both returned a lookup time of around 20ms. DNS wasn’t adding any meaningful delay here. SSL came back clean too via openssl s_client: TLS 1.3 active, session reuse working, OCSP stapling in place. Neither was the problem.<\/p>\n\n\n\n Step 8: The Root Cause<\/strong><\/p>\n\n\n\n Once we delved deeper into profiling, the real culprit emerged. A third-party WordPress plugin was making external API <\/a>calls on every single page load. When those external services were slow, which they sometimes were, the entire page sat waiting. We cached the API responses, tightened the timeouts, removed unnecessary calls, and deferred a few lower-priority features. That was the fix that made the biggest remaining difference.<\/p>\n\n\n\n Results<\/p>\n\n\n\n MetricBeforeAfterTTFB2.15s210msTotal Load Time2.52s790msCPU Usage95%42%DB Queries per Page340112<\/p>\n\n\n\n Beyond the numbers, the site felt genuinely different, stable under traffic peaks and responsive in a way it hadn’t been before.<\/p>\n\n\n\n Preventive Measures<\/strong><\/p>\n\n\n\n A few things worth keeping in place to avoid ending up back here:<\/p>\n\n\n\n Conclusion<\/strong><\/p>\n\n\n\n High TTFB almost never comes down to a single factor. In our experience, it’s usually a combination of smaller problems stacking up across the server, application, and database layers. Working through each layer methodically and actually measuring the impact of each change, rather than assuming, is what got this site from 2.15 seconds down to 210ms. The numbers matter, but so does the stability that comes with them.<\/p>\n\n\n\n Facing issues? <\/p>\n\n\n\n Our technical support\n
engineers can solve it. <\/p>\n\n\n\n![\"Contact](\"https:\/\/no-cache.hubspot.com\/cta\/default\/2725694\/3350a795-db50-482f-9911-301930d1b1be.png\")
<\/a><\/span>