A slow website makes everyone reach for their wallet. The site drags, the host's upgrade page is one click away, and a rival host's ad is promising ten times the speed. Surely the fix is to spend money somewhere — the only question being whether you give it to your current host or a new one.
Slow down, in the good sense. In our experience helping people untangle sluggish sites, the hosting company is the true culprit less than half the time. The rest is the site itself: bloated pages, missing caching, a plugin quietly hammering the database, an ancient PHP version nobody ever switched. Upgrade the plan under a bloated site and you get the same bloated site with more expensive hosting. Migrate it and you get the same slow site with a week of migration stress on top.
So this guide is deliberately diagnosis-first. We will measure properly, fix the cheap things, establish whether the host is genuinely the bottleneck, and only then walk the decision tree: upgrade in place or move — and if you move, how to do it with near-zero downtime.
Measure Before You Blame Anyone
Feelings are not measurements. Your own visits are polluted by your browser cache, your Wi-Fi, and the fact that you look hardest when you are already annoyed. Before touching anything, build a small baseline:
- Pick three pages — the home page, a typical content page, and your heaviest page (a shop category, a gallery).
- Test them from the outside with a reputable free speed-testing service, from a location near your actual audience, several times a day for a few days.
- Record two numbers separately: time to first byte (TTFB — how long the server takes to start responding) and total load time (how long until the page is usable).
- Note the clock. Test in the morning, mid-afternoon, and during your traffic peak. Patterns by hour are evidence; single readings are anecdotes.
The two numbers split the problem in half. A slow TTFB means the server side is struggling: the machine, the database, or the code that builds each page. A fast TTFB followed by a long load means the server did its job quickly and the delay lives in the front end — oversized images, too many scripts, heavy themes. That single distinction saves people more money than any coupon ever has.
Fix the Cheap Things First
Whatever the measurements say, do these before spending anything, because they are free and they help on any hosting.
Turn on caching
Most CMS pages are rebuilt from the database for every visitor even though they change once a week. A page-caching plugin or the host's built-in cache serves stored copies instead, and on a typical WordPress site this one change can transform TTFB. It is the highest-value free fix in hosting.
Put your images on a diet
Images are the usual front-end offender: camera-sized photos squeezed into small slots by the browser. Compress them, resize them to the dimensions actually displayed, and serve modern formats. Front-end weight drops dramatically, and no host upgrade can substitute for this.
Audit plugins and extensions
Deactivate what you do not use, then look hard at what remains. Related-post generators, broken-link checkers, statistics collectors, and page builders are frequent database hogs — this applies equally to WordPress plugins and Joomla extensions. Disable suspects one at a time and re-measure TTFB; the guilty one is often obvious.
Update the PHP version
Each major PHP release runs meaningfully faster than the last, and hosts leave old sites on old versions unless someone flips the switch in the control panel. It takes two minutes; test the site afterward.
Re-run your baseline after these fixes. A large share of slow websites are cured right here, at a cost of zero.
How to Tell the Host Is Genuinely the Bottleneck
If TTFB is still poor after caching and cleanup, it is time to examine the host — with tests, not vibes.
The static-file test. Upload a plain image or text file and measure how fast it is served at different hours. A static file involves no PHP and no database; if the server is slow handing over a plain file, no amount of site optimization will save you. That is the cleanest possible evidence against the host.
Peak-hour degradation. If your site is fine at dawn and crawls every evening, you are likely sharing a server with too many neighbors, or with one abusive one. This is the classic signature of an oversold shared server.
Resource-limit throttling. Check the control panel's resource-usage screens for CPU, memory, and entry-process limits being hit, and look for the telltale errors — resource-limit pages, 503s, or 508s — in your logs. If you are pinned at the ceiling constantly, your plan really is too small for your site. If usage is low and the site is still slow, the plan is not the problem and upgrading it will not help.
Support's answer. Open a ticket, share your measurements, and ask directly whether your account is hitting limits or the server is under unusual load. Honest hosts answer with numbers. Evasive answers to a data-backed question are themselves diagnostic.
The Decision Tree: Upgrade or Move
Now, and only now, the money question. It resolves on two axes: is the host competent, and is your usage genuinely outgrowing the plan?
Upgrade with your current host when the evidence shows real resource exhaustion — you are throttled at the caps after optimization — and the host has otherwise behaved well: static files are fast, support answers straight, uptime is solid. Outgrowing a plan is success, not betrayal; moving up a tier or to a VPS at a good host is the low-risk path and takes minutes rather than days. Our guide to comparing web hosting plans covers what the next tier should include.
Change hosting company when the evidence indicts the environment rather than your usage: slow static files, evening slumps with your resource usage low, chronic outages, or support that stonewalls measured questions. Upgrading on an oversold server often just gives you a bigger slice of a bad machine. Choose a replacement using independent sources — our hosting reviews and uptime tracking exist for exactly this moment — and favor hosts that publish their resource limits plainly.
Do neither when your fixes brought TTFB down and the remaining slowness is front-end weight. Spend your energy on the site, not on invoices.
Symptoms, Causes, and Actions at a Glance
| Symptom | Likely cause | Action |
|---|---|---|
| High TTFB, all hours, even on a static file | Weak or oversold server | Change hosting company |
| Slow only at peak hours; your resource usage low | Noisy neighbors on shared server | Ask host to move you; if refused, migrate |
| Resource limits constantly maxed after optimization | Site has outgrown the plan | Upgrade plan with current host |
| Fast TTFB, slow full load | Heavy images, scripts, theme | Optimize the front end; no hosting change |
| High TTFB on CMS pages, fast static files | No caching, heavy plugins, old PHP | Cache, prune plugins, update PHP |
| Random outages, evasive support | Host quality problem | Change hosting company |
How to Migrate with Near-Zero Downtime
If the verdict is migration, the good news is that a careful move is boring — and boring is the goal.
- Buy the new plan before touching the old one. Overlap costs a few weeks of double hosting and buys you an escape hatch. Budget-conscious? Our best cheap web hosting guide covers finding a solid landing spot without overpaying.
- Copy the site to the new server — files and database. Many hosts migrate incoming sites free; otherwise your CMS ecosystem has well-worn migration tools.
- Test on the new server before switching. Use the host's preview URL, or point your own computer at the new server via a hosts-file entry, and click through the whole site: forms, checkout, admin, email.
- Lower the DNS TTL a day ahead. Set your domain's time-to-live to a few minutes so the eventual switch propagates fast.
- Freeze changes, do a final sync, then switch DNS. Stop publishing and pause orders if you can, copy any last changes, then update the DNS records to the new server. With a low TTL, most visitors move over within minutes.
- Keep the old account for a couple of weeks. It catches stragglers on stale DNS and holds your fallback copy until you are certain. Only then cancel — and check the money-back window on the new host has not lapsed while you dithered.
Done in this order, visitors see at most a few minutes of ambiguity, and usually nothing at all.
FAQ
What is a good TTFB for a shared hosting site?
As a working rule, a few hundred milliseconds is healthy for a cached page on shared hosting, and under about two hundred is very good. Approaching a full second consistently deserves investigation, and multiple seconds means something is wrong — in the site or the server, which is exactly what the static-file test distinguishes. Judge by your own trend across hours and days rather than a single reading.
Will a CDN fix my slow website instead?
A CDN moves your static assets closer to visitors and can noticeably improve full-page load times, especially for far-away audiences. What it cannot fix is a slow origin server: your TTFB for the HTML itself still depends on the host and your CMS. Treat a CDN as a legitimate front-end optimization to layer on top of a healthy server, not as a bandage over a failing one.
Can I ask my host to move me to a less crowded server?
Yes, and it is worth trying before migrating. If your evidence shows peak-hour degradation while your own usage is low, open a ticket, present the numbers, and ask whether the server is heavily loaded and whether you can be moved. Good hosts do this quietly all the time. A refusal — or a denial that contradicts your measurements — tells you the relationship has run its course.
How long does a hosting migration actually take?
For a typical CMS site, the copying and testing take an afternoon, and the DNS switch takes minutes once the TTL is lowered. The realistic total is a weekend done calmly, including the buffer days for DNS propagation and keeping the old account alive. Large stores with constant orders need more choreography around the change freeze, but even they rarely need visible downtime.
The Bottom Line
A slow website is a measurement problem before it is a spending problem. Split the delay with TTFB versus full-load numbers, harvest the free fixes — caching, image weight, plugin pruning, PHP updates — and then let the static-file test and your resource graphs testify about the host. Genuine growth on a good host means upgrade in place; a bad environment means migrate, calmly and with overlap. The only wrong move is the most popular one: paying somebody, anybody, before you know what is actually slow.