«The site is slow, I think I need a bigger plan.» It is one of the messages we get most, and most of the time the bigger plan was not the answer. Before buying anything, twenty minutes of measuring is worth it. This article is about those twenty minutes; what to do afterwards is in «The site is slow: what actually makes a difference».
First: is it the site, or is it the person looking at it?
This question eliminates half of all cases and costs nothing. Run the four tests in this order, before opening a single report.
| 1 |
Open the site on another network. From a phone, on mobile data, not on the office wifi.
|
|
| 2 |
Ask somebody far away. Another city, another country, another operator. If it is fast for them, the site is fine and the problem is between you and it.
|
|
| 3 |
Try a private window, with no extensions and not logged in. A badly configured blocker or an old extension can slow a page down spectacularly.
|
|
| 4 |
Try a second page, and the admin area. Not just the home page, which is usually cached and will lie to you.
|
|
| If it is slow... |
Then the problem is... |
| Only for you, fast for everyone else |
Your connection, the office network, a browser extension, or the DNS server you use. Not the site, and a bigger plan changes nothing. |
| Only on one page |
That page. A gallery, a map, a filtered product list, a form with a great many fields. |
| Only in the admin, with the site fast |
A plugin. The admin area is never cached, so it is where the weight of the code shows up naked. |
| Always, everywhere, for everyone |
The site or the server. Only now does it make sense to keep reading. |
Two numbers that separate the server from the site
«It takes five seconds» diagnoses nothing, because those five seconds can be two completely different things. Two separate numbers matter:
| Number |
What it measures |
| Time to first byte |
How long the server took to start answering. If this one is big, the problem is whatever runs on the server: PHP, the database, missing cache. |
| Time until the page is ready |
How long the browser took to download everything and draw it. If the first number is small and this one is big, the server is fine and the page is heavy. |
| 1 |
Open your browser's developer tools and go to the network tab.
|
|
| 2 |
Switch on the option to bypass the cache and reload the page.
|
|
| 3 |
Look at the first row, which is the page document itself. Its time is effectively the server's time.
|
|
| 4 |
Sort the list by size. Whatever is at the top is what weighs. Nine times out of ten it is images.
|
|
| 5 |
Note the total number of requests. A page making hundreds of requests is loading too much, and that is usually plugins.
|
|
|
Always measure twice. The first visit to a cached page is always the slowest, because it is the one that builds the page and stores it. Measuring once, changing something, and measuring once again leads you to wrong conclusions with remarkable ease. Load, wait, load again.
|
The causes, in order of likelihood
This order is not theory: it is how often each one turns up in the cases that reach us. Look in this order and you will save time.
| 1 |
Images uploaded straight out of the camera. First, and by an enormous margin. A photo of several megabytes in a box a few hundred pixels wide forces every visitor to download all of it to see almost none of it.
|
|
| 2 |
Plugins and themes. Every active plugin costs something on every page, including the pages that do not use it. It is not the count that matters, it is the weight of each one.
|
|
| 3 |
No caching. Without it, every visit makes the server build the page again. It is the single change that cuts time to first byte the most.
|
|
| 4 |
Database queries. «Related products» lists, internal search, and tables that grew for years with nobody looking. They show up as high server time on some pages only.
|
|
| 5 |
An old PHP version. Cheap to fix and often forgotten. See «Changing your PHP version without breaking the site».
|
|
| 6 |
And only at the end, the plan's resources. Last on the list, not first.
|
|
Notice what that order means in practice: the first five are the site and none of them costs money. Only the sixth is solved with a wallet.
How to tell whether it really is the plan
| 1 |
Open Resource Usage, under the Metrics section of cPanel. It plots usage against the limit over time.
|
|
| 2 |
If it is not hitting the ceiling, it is not the plan. Full stop. However slow the site feels, a bigger plan goes nowhere.
|
|
| 3 |
If it is hitting it, ask why before you buy. Hitting the ceiling every day at the same hour points at a cron job running too often, or a bot crawling the site. Hitting it at random hours points at one heavy page somebody visits now and then.
|
|
| 4 |
Cross-check with Errors and Raw Access. If the busy hours line up with hundreds of requests from one address, a bigger plan is not what you need.
|
|
| 5 |
If it is hitting it on real traffic, and the site is already clean, then yes. At that point the honest answer is that the site grew: see the plans or, if you need to set the limits yourself, a VPS.
|
|
|
Changing plan does not cure a badly built site. Worth saying bluntly, because it is your money. A bigger plan gives you more headroom, not more speed. A page the code itself is slow to build takes just as long on a bigger machine: what changes is how many of those pages fit at once. If the page is the problem, the bigger plan only postpones the conversation and raises the bill.
|
|
One change at a time, with the before and after written down. Changing five things at once may well work, but you are left not knowing which one it was, and next time you start from zero. Six lines in a notebook beat any tool.
|
|
Measured it and still lost? Send us the domain, the slow page, and the numbers you got.
Open a support ticket
|
RECOMMENDED PRODUCT Web hosting with cPanel Domain and SSL included, daily backups and the panel you already know. from $10.00/mo See plans |
Português
English
