Your website feels slow, and somebody has told you the hosting is to blame. Before you go shopping for a new plan, it is worth finding out the root cause. The reason is, moving to a faster server will not change the quality of a website that needs to be rebuilt, and rebuild or optimize covers how to tell whether yours does. If the issue is the hosting server, though, you have a cheaper fix.
Telling the difference between a website issue and a server issue starts with one number, and reading it is free.
What hosting is responsible for
Hosting itself is the service you purchase, and what you are paying for is space and resources on the host, meaning the server your website runs on. Your hosting account can also come with other services that are either add-ons or part of the plan, such as support, backups, security, e-mail and room to grow. Which of those you are paying for, and where the rest of the money goes, is set out in what it costs to keep a website running.
When somebody types your address, their browser asks the server for the page and then waits. That wait, before anything appears at all, is where the server’s part of the delay shows up, along with some of the website’s own work, and it is there that we can measure whether this is a hosting issue. Everything after that first answer, the images arriving and the layout settling, is mostly decided by how the page was built.
Each of those has a different fix. If the server is slow, you can change or upgrade your hosting. If the page is slow, somebody has to correct how the content is built, which is not done by a server change.
Where to find the number
Google publishes the measurement of that wait, and you can read yours in about a minute. Go to pagespeed.web.dev, put in one of your pages, and run it. The tool is free and needs no account.
In the results, look for Document request latency. That is where Google reports how long the server took to answer, and it flags anything that “took more than 600ms for the server to respond to the request.” Under 600 milliseconds on that run, the server answered quickly. Well over it, something behind that page is slow.
Your report may also have a section built from real visitors, and if it does, there is a second number in there called Time to First Byte. It measures the same wait but counts more of it, taking in redirects, the address lookup and setting up the connection. Google’s guidance is that “most sites should strive to have a TTFB of 0.8 seconds or less,” and it treats anything above 1.8 seconds as poor.
Time to First Byte will not always be there, because Google needs enough real visitors before it has anything to report. Where a single page does not have enough of its own, you may be shown figures for the whole website instead. The on-demand test carries no such limit, though it only ever describes the page you handed it, which is why it is worth running on two or three pages rather than one.
What your number is telling you
The server answered quickly. Document request latency covers the server’s own response time and leaves the address lookup and the connection unexamined. Time to First Byte takes those in as well, so it settles more. How much you have narrowed it down depends on which of those you read. If the slowness is arriving after either of them came back clean, it usually means large images, a heavy theme, too many plugins, or fonts and scripts loading ahead of the content. None of that changes when the server does.
The server was slow to answer. This is the result that makes hosting worth pursuing, though the host may still not be at fault. The same delay can come from the website doing heavy work on every visit, or from a database that has grown unwieldy over the years. Either way, you have turned “the website feels slow” into “the server takes two seconds to answer,” and a specific complaint gets a straight answer where a vague one gets a shrug.
The answer is slow only sometimes. On shared hosting your website draws on the same pool of server resources as other websites, so a neighbor having a busy hour can slow yours down. Your own traffic can do it, and so can a scheduled backup or a cache that empties and refills. Write down the times you notice it and give those times to whoever hosts you, because they can look at the server logs for those hours.
What makes a server slow to answer
Google publishes what usually sits behind a slow first response. Three of those are worth asking about even if you never touch a server yourself.
Caching. A cache holds a finished copy of a page so the server does not have to build it again for the next visitor. Google notes that “older or less visited content may also not be cached, which can result in higher TTFB values on some pages than others,” which explains why your home page can be quick while a service page is not. Ask whether caching is turned on and which pages it covers.
The memory your plan allows. Google’s own guidance on this is blunt: a server short of memory will “thrash and struggle to serve pages up as fast as possible.” Ask what your plan allows and whether your website is near the limit, because the answer is sometimes a larger plan with the same company rather than a different company.
How far your visitors are from the server. Google points out that visitors a long way from the server can get a slow first response even when everything on the server is right, and that a content delivery network reduces that distance by keeping copies of your files closer to them. Ask where your server actually is, and whether a delivery network is included in what you already pay. Neither answer settles the question on its own, and both are quick to find out.
One more question that is not about speed, if your website runs on WordPress. Ask which version of PHP it uses, since PHP is the language WordPress is built on and each version eventually stops receiving fixes. PHP keeps a current list of which versions are still supported at php.net/supported-versions, and WordPress warns that older versions “may expose your site to security vulnerabilities.”
All four start as a question to your current host rather than a search for a new one, which is why they are worth asking before you go shopping.
Two things that follow you to the new host
Say you have asked those questions and the answer is still to move. The page work stays where it is, and two other things travel with you.
Your position in search results. Speed is one of the things Google measures, but it does not determine rankings by itself. A slow page that answers the question somebody searched for can outrank a fast page that does not, so a move alone is not a ranking strategy.
Any fault you have not identified yet. If pages are returning errors, or the website goes down and comes back, find out where that is coming from before you move. Sometimes it is the hosting, and moving is exactly the fix. Sometimes it is the website, and the website will arrive at the new host doing the same thing. From the outside those two look identical, which is why the question is worth answering before you pay to move rather than afterwards.
When there is nothing to move
All of this assumes you have hosting you can change, and some platforms include the hosting and do not let you take the website elsewhere. Wix states this plainly: “since Wix is a SaaS solution, your site must run on Wix’s servers.”
On a platform like that, moving is not a route open to you. What is left is whatever the platform lets you change about your pages, plus the platform’s own support for anything on their side. Knowing which kind of platform you are on saves you a week of researching hosts you cannot use.
Three reminders before you jump ship
Get the number first. Everything above depends on it, and it costs a minute.
Ask about caching, memory and PHP before you ask about price. Those are often fixable where you already are.
Find out what is actually broken before you move. A move may carry an unidentified fault along with it, and you will be paying somebody new to inherit the same problem.
If you would like us to run the check and tell you what we find, e-mail sales@allydrez.com with the address of your website.