A site is slow, and the first suggestion is always a bigger plan. Sometimes that is right. Frequently it moves the same slow site onto a more expensive server.
One measurement tells you which.
Time to first byte
curl -o /dev/null -s -w 'connect %{time_connect} ttfb %{time_starttransfer} total %{time_total}\n' https://example.com/
The middle figure covers everything before the first byte of the page arrives: the round trip, the web server, and the application generating the page.
Run it five times. The first may be uncached and unrepresentative, and a single measurement of anything is a guess.
Reading it
Under 0.3 seconds. The server responded quickly. If the page still feels slow, the delay is in what the page loads afterwards, and hosting is not the cause.
0.3 to 1 second. Unremarkable for an application-generated page, worth improving, rarely the whole story.
Over 2 seconds. Something is genuinely wrong in generating the page, and it is worth finding before doing anything else.
The second measurement, which decides it
If the first figure is large, request a plain static file. An image, a stylesheet, anything the application does not touch:
curl -o /dev/null -s -w 'ttfb %{time_starttransfer}\n' https://example.com/favicon.ico
Static fast, application slow. The server is fine. It serves files instantly and is being asked to do slow work. The problem is the application, and a bigger server buys a smaller version of the same delay.
Both slow. Now it is the server, or the network. This is the case where upgrading actually helps.
Two commands, thirty seconds, and the decision is made on evidence rather than on a support suggestion.
When the server responds fast and the page is slow
Everything after the first byte belongs to the page: images, scripts, fonts, third-party services.
Open the browser's network view and sort by time. Common findings, in rough order of frequency: images uploaded at camera resolution, a chat or analytics script waiting on someone else's server, fonts loaded from a third party, and a video embed pulling a large amount of code for a thumbnail.
None of these is affected by the hosting plan. Speeding up a website in the right order goes into what to do first, and measuring page speed properly deals with judging the result.
When the application is slow
The two dominant causes, and both are cheaper to fix than to outgrow.
No caching. Every visit rebuilds the page from the database. Enabling caching frequently takes a two-second response to under 200 milliseconds, which is a larger improvement than any plan upgrade offers. See understanding caching layers.
One expensive component. A plugin running a query on every page load, or a query with no index. This is where profiling earns its time. For finding it, see optimising WordPress performance.
Slow only sometimes
If it is fast at night and slow in the afternoon, that is a queue rather than a bug. Requests are waiting for a free process.
Caching is the fix, because a page served from cache never occupies one at all. Monitoring your hosting resources explains confirming it, and this pattern is the clearest signal that shared hosting limits are being reached.
Slow only for you
Before concluding anything, check from elsewhere. Another network, a phone on mobile data.
A site that is slow from your office and fast everywhere else is a local network or DNS problem, and a good deal of time has been spent optimising servers that were never slow.
When upgrading genuinely is the answer
Caching is working, the application is lean, the static file is slow too, and the load is consistently high during normal traffic.
That is a real limit, and moving is the right response. Moving from shared hosting to a VPS has the detail. What is not a reason is a slow site nobody has measured.
Where the time actually goes
One command breaks the request into its parts, which turns a single number into a diagnosis:
curl -o /dev/null -s -w \
'dns %{time_namelookup} connect %{time_connect} tls %{time_appconnect} ttfb %{time_starttransfer} total %{time_total}\n' \
https://example.com/
Each figure is cumulative, so the interesting number is the gap between consecutive ones.
A large jump at dns is name resolution, not the server. A large jump at connect is network distance or a saturated link. A large jump at tls is the handshake, frequently a certificate chain being fetched. A large jump between tls and ttfb is the server generating the page, which is the only part hosting affects.
People upgrade hosting to fix numbers that appear before the server was involved at all.
Compare a cached and an uncached request
curl -o /dev/null -s -w 'ttfb %{time_starttransfer}\n' https://example.com/
curl -o /dev/null -s -w 'ttfb %{time_starttransfer}\n' "https://example.com/?nocache=$(date +%s)"
The query parameter defeats most page caches, so the second figure is what the application actually costs.
A large gap means caching is working and the application is slow underneath, which is fine until something invalidates the cache, at which point every visitor meets the second figure at once.
Little or no gap means either nothing is cached, or the cache is not being hit. That distinction is worth resolving before any other work. Understanding caching layers goes over checking which layer is answering.
Measure from where the visitors are
A single measurement from your own machine reflects one network, one location and one moment.
Run the same command from a different network; a phone on mobile data, or a server elsewhere, before concluding anything. A site that is slow from one office and fast everywhere else is a local problem, and a considerable amount of server optimisation has been done in response to a slow office connection.
Also run it several times at different hours. A figure that is good at night and poor in the afternoon is a queue in place of a fault, and the response is caching rather than capacity. Monitoring your hosting resources goes into confirming it.
When the numbers are fine and it still feels slow
A fast first byte and a page that feels sluggish is a rendering problem, not a hosting one.
The usual causes are a large amount of JavaScript occupying the browser before the page responds to input, fonts loading late and shifting the text, and images without dimensions moving the layout as they arrive.
None of that is measurable with the commands above, and none of it improves with a bigger server. Measuring page speed properly explains the measurements that do capture it.