"The site is slow, let us upgrade the server" is the most common opening in the support tickets we receive. In most cases an upgrade does not fix it, because the bottleneck is neither CPU nor RAM.
Do not decide before measuring. The sequence below narrows the problem down in a few minutes.
Start by measuring TTFB
Time to first byte is how long the server takes to process a request and begin responding. To measure it:
curl -o /dev/null -s -w "connect: %{time_connect}s\ntls: %{time_appconnect}s\nfirst byte: %{time_starttransfer}s\ntotal: %{time_total}s\n" https://example.comRead the result like this:
- First byte under 200 ms: the server side is healthy. The problem is most likely in the front end — image weight, render-blocking scripts, third-party tags.
- First byte 200–800 ms: look at the application layer, usually database queries.
- First byte above 800 ms: there is a real bottleneck; continue below.
Find out where the load actually is
top -b -n1 | head -20
iostat -x 1 3
free -hThree signals matter here:
- High
%iowaitmeans you are waiting on disk; the problem is storage, not CPU. - Any swap usage means RAM is short and every request is hitting disk.
- A load average above your core count means you genuinely are CPU-bound.
The most common real cause: the database
In our experience the large majority of slow sites come down to unindexed queries. Doubling the server makes a full table scan twice as fast; adding an index can make the same query a hundred times faster.
Enable the slow query log and review a day of data. Almost always a handful of queries account for most of the total time.
When an upgrade is genuinely the answer
Upgrade when all three hold: load average is consistently above your core count, swap is actively in use, and there is no obvious query left to fix in the application.
Otherwise a bigger server simply reproduces the same problem at a higher price.