1st post and I have spent a lot of time reading today. I have a website that is giving me what I think is an odd-ball reading. I have tested in various ways using Chrome and Firefox browsers to webpagetest and get the same result. I am sure it is a server issue, I am just asking for thoughts on where to look on the server. The server seems to be ok, I am confident it is specific to this account within the CPanel server that I look after. Other sites are not showing the same symptom.
I’ve highlighted the waterfall section I am trying to figure out. There is obviously some CPU activity, but zero bandwidth which I think indicates stuff is being processed. There is other stuff to be addressed after the first html load, but if I can shave this 1+ second out from the start then the overall load is not too bad for an uncached, no-cdn site. Why?, because I cannot see any value in those tools before fixing more fundamental issues. At least I think it makes sense…
No solution as yet. I have in fact built a new VM server today for the purpose of testing at a very low level.
My view at the moment is that the issue lies with the configuration of Apache or PHP or CPanel/WHM in general.
I am currently testing a static page with “This is a webpage” as the only text and still finding a “Wait” or Connect delay of up to 900ms.
If I swap from the static test page to a fresh Wordpress install with the only change being to disable wp-cron, that Wait time is still pushing 1.5 seconds.
As stated it is a brand new, AlmaLinux 8.5 / CloudLinux / Cpanel/WHM standard / common web hosting solution, with out-of-the-box settings. The following screenshot is the first scan of the bare-bones WP site on the out-of-the-box server this morning with a 3 second wait.
The above was after I had primed the site with a few visits to ensure the server was operating and not still starting up. Overall, I am still investigating. I have tweaked Apache today and achieved some improvement, but not enough to make me happy, with WP still pushing 1 to 1.5 seconds of nothingness.
Just to be clear, the generic comments for ‘improve ttfb’ often start with a Wordpress cache recommendation(vested interests perhaps;-). To me that is useless if the underlying kit is failing before you start.
As a final follow up for today, I have tweaked the server, and then installed CSF/CXS which are common on a WHM Server, and they had zero impact on load times. So without further tuning I still have around a 900ms ‘Wait’ time that I just cannot wrap my head around.
When I look at this everything to the left of the first redline is subject to external forces: bandwidth, dns resolution, dns cache, connection time, and ssl are taking less than a second all up, but that is then doubled by the server doing ‘something’ or maybe ‘nothing’. Everything to the right of the second redline is addressable with tuning and is with the website itself, but not much point when almost a second is being ‘lost’ with the server.
So my question is, how can we determine what the server is doing in that time?
Monitoring on the primary server services is not showing anything overloaded or broken. Although there is less than 24 hours of data to analyse.
Best bet is an APM solution of some kind (unless you want to continue with trial and error). They instrument the back-end code and usually point out any code or database issues pretty quickly. I used to use NewRelic’s old offering when it was free and it sounds like they have a free one again, might be a good place to start.
That said, if you’re seeing the same long delays with a completely static page then the problem is upstream of the application. A few possibilities come to mind:
Load balancer/CDN in front of the app is slow connecting to the actual server (the WPT view will only include the connect time to the edge).
REALLY horrible hosting/VM where the whole VM is paged out and needs to start up when the request comes in.
My guess is something related to CDN though. i.e. if it is fronted by Cloudflare or something like that it could be hiding the latencies from the test location back to the actual origin and if you’re testing a site hosted in AU from the US (or the other way around), the round trips to set up the connection can be a few seconds.
