# Is Your Site Slow? Measure Before You Buy a More Powerful Server
Table of Contents
A slow site isn’t just annoying: it’s a cost. Someone who opens a page and watches it struggle to load leaves, and with them go visits, sales and trust. Google, in turn, factors speed into who it shows first: a slow site starts further back in search results too.
Faced with a slow site, the instinct is almost always the same: “let’s get a more powerful server”. It is the most natural reaction and, nine times out of ten, it is also the wrong one. A bigger server hides the problem for a few months, costs you more every month, and then the slowness comes back, because the cause was never the horsepower. The rule is one: measure first, spend later.
Let’s look at why the hardware is rarely the answer, which two numbers you can check yourself for free, and where slowness actually comes from.
Why a more powerful server (usually) doesn’t fix it
The bottleneck of a slow site is almost never raw compute power. In the vast majority of cases it is something else: huge unoptimised images, a missing or misconfigured cache, badly written database queries, or too many third-party scripts dragging the load down. Doubling CPU and memory touches none of these causes: it papers over them at a steep price, until traffic grows and the problem resurfaces.
The comparison is city traffic. If the roads are jammed because of too many poorly timed traffic lights, buying a faster car won’t get you there sooner: you sit in the same queue, just in a more expensive vehicle. Speed helps when the road is clear, not when the problem is how the route is organised.
The two numbers to check, for free
Before spending a cent, look at how the site is actually doing. Two indicators are enough, and you’ll find them free in tools like Google’s PageSpeed Insights, simply by pasting in the site’s address:
- LCP (Largest Contentful Paint): how long the largest element on the page takes to appear, usually the image or headline at the top. It depends heavily on how quickly the server responds, an aspect with a precise name: the response time, or TTFB.
- INP: how responsive the page is when you click or type in it. A high value tells the story of a page weighed down by too much code running in the browser, often third-party scripts. It is the metric that replaced the old FID among Google’s Core Web Vitals.
These two numbers tell you where to look. A high LCP points toward the server and loading; a high INP points toward scripts and code. It is the difference between knowing and guessing.
The real causes of slowness, in order of frequency
In practice, a site’s slowness almost always comes from these causes, and it helps to know them because each has a different, targeted fix:
- Huge unoptimised images. A 4 MB photo loaded as-is weighs more than the rest of the page combined. Resizing and compressing them well is often the single change that pays off most.
- Missing or misconfigured cache. Without a cache, the server rebuilds every page from scratch on each visit. A cache done right, server-side and browser-side, cuts times sharply.
- Slow database queries. On CMS and e-commerce this is a classic: a single badly written query can freeze whole screens. It is the heart of the problem when, for example, a PrestaShop store slows down at peak times.
- Too many third-party scripts. Chat, tracking pixels, marketing tags, widgets: each adds weight and delay. They often pile up by the dozen without anyone reviewing them.
- An undersized or misconfigured server. Yes, sometimes the server really is the cause, but you find that from a measured high TTFB, not from a hunch.
When the server really is to blame
It is worth saying honestly: sometimes the cause really is the hardware, an overloaded shared host or a machine undersized for the real traffic. But even then the answer is rarely “buy more power”. Often it is enough to add a caching layer (Redis, Varnish), tune the web server and database properly, and the same hardware handles three times the load. You move to a bigger server only after measuring that you truly need it, not as a first blind attempt.
In short
A slow site is rarely solved by buying hardware. First you measure LCP, INP and the server’s response time; then you act on the real cause, which in the vast majority of cases is heavy images, a missing cache, slow queries or scripts too many. Often the same hardware, tuned well, runs three times faster, at a far lower cost than a bigger server that hides the problem for a few months. If you want to understand where your site’s slowness comes from before you spend, that is the kind of analysis we start from.
