A bigger hosting plan fixes a slow website only when the server is what's slow. Before upgrading, rule out cheaper causes such as photos uploaded at full camera size, a plugin doing too much on every page, or chat and tracking scripts from other companies. Run one test to see whether the server is slow to answer or the page is heavy, fix the cheap causes first, and leave the upgrade for last.
That order matters for your budget. Image optimisation is a content fix rather than a recurring cost. A higher plan costs more every month, and if the page itself is heavy, a faster server may change little of what visitors wait for.
One test: slow server or heavy page?
Open PageSpeed Insights, enter the slow page and look at two things.
Time to First Byte (TTFB). This is how long a browser waits from asking for the page until the first piece of it arrives. It covers redirects, the domain lookup, the connection and the time your server spends building the page. Google's guidance says most sites should aim for 0.8 seconds or less. PageSpeed Insights shows it in the real-visitor data, if your site has enough visitors for Google to have data; a new or quiet site may have none. You can also check it yourself: open your browser's developer tools, go to the Network tab, reload the page and open the timing details of the first request in the list (the page itself). Do it a few times, logged out, in a private window, because that's what visitors get.
What the page loads. The lab test lower down lists large images, scripts and other files. A page can have a quick first byte and still take ages to appear because of what comes after.
Then read the result against this table:
| What you see | Where the time goes | Start with |
|---|---|---|
| Slow first byte on every page, even a short one | The server building pages: plugins, database, no caching, or hosting limits | Caching and plugins |
| Slow first byte only on some pages (search, shop filters, account pages) | Heavy work behind those pages | The plugin that powers them |
| Quick first byte, slow to appear | Page weight: images, scripts, embeds | Images and third-party scripts |
| Fine most of the day, errors at busy times | Hosting resource limits | Your host's resource usage page |
A quick extra check: open the address of one image on your site in a new tab. If the image appears instantly but the page's first byte takes seconds, the network is fine and the time goes into building the page.
Also check the address you share. If http://yourbusiness.com redirects to https://yourbusiness.com, which then redirects to https://www.yourbusiness.com, each hop adds waiting time. Link and advertise the final address.
TTFB is not one of Google's Core Web Vitals. Use it here as a diagnostic, not a score to chase.
The fixes, cheapest first
- Images. A photo straight from a phone can be far larger than any screen will show. Resize images to the largest size they're displayed at, compress them, and use a modern format such as WebP. It needs no hosting change and helps the page appear sooner.
- Plugins. The WordPress performance guide recommends deleting plugins you don't need and switching plugins off one at a time to measure the effect. Make a list and mark each plugin "the site needs this", "nice to have" or "no idea". Delete what nobody uses. For the rest, switch them off one by one at a quiet hour, or on a copy of the site, and measure the first byte again. Plugins that do something on every page (visitor statistics, related-post lists, sliders) are good ones to test first.
- Third-party scripts. Chat widgets, tracking pixels, review badges, embedded maps and videos all load from other companies' servers. They can slow the page down after the first byte, and a faster server of your own doesn't speed up theirs. Remove the ones nobody looks at; a map can be replaced by a link to the map.
- Scheduled tasks and the database. WordPress runs its scheduled tasks when someone loads a page, so a backup, import or security scan set by a plugin may run during a visitor's request. Set heavy jobs like backups to run at night if the plugin allows it. Data left behind by plugins you deleted can also slow the database; a developer can check and clear it.
- Caching. A page cache saves a ready-made copy of each page so the server doesn't build it from scratch for every visitor. WordPress's own guide calls it the biggest benefit for the smallest hassle. Use one caching plugin, or the one your host provides, not two.
If caching "didn't help", check three things: that you tested logged out in a private window, as a visitor would; that the slow page is one that can be cached at all (pages that differ per visitor, such as the cart, checkout and account pages, may be excluded from the cache, so they stay as slow as the server makes them); and that the cache is switched on for the whole site, not just installed.
Reading your host's resource usage
Shared hosting plans set limits on how much processing power, memory and how many simultaneous processes your site can use. Your hosting control panel may have a page showing your usage against those limits over the last hours or days. When a site hits them, it can slow down or start returning 503 Service Unavailable errors.
Look at when the usage peaks:
- At the same time every day: a scheduled task, such as a backup or an import. Move it or change its timing.
- Together with your visitor numbers: caching is the first fix, then plugins.
- High all the time with little traffic: a plugin or piece of code doing too much work, or a burst of requests from bots. Your access logs will show which pages are being requested.
What caching and a CDN don't fix
A page cache helps pages that are the same for every visitor. It does little for the cart, checkout, search results or anything personal.
A CDN (content delivery network) serves copies of your images, stylesheets, scripts and fonts from servers closer to your visitors. That helps the page appear sooner, especially for visitors far from your server. Whether it also caches whole pages depends on the CDN and its settings. Cloudflare's documentation, for example, says it doesn't cache HTML by default. Check what yours caches: if it only serves static files, a page that takes three seconds to build at your server still takes three seconds to build.
When hosting really is the limit
After the cheap fixes, the host is the likely bottleneck if:
- a simple, cached page still has a slow first byte;
- resource usage sits at the limit during normal traffic, not just during a scheduled job;
- 503 errors line up with real visitor peaks.
The WordPress performance guide says more processing power and memory can make a big difference, and that shared hosting users who keep hitting their limits benefit from a plan with higher ones.
Take Hostinger as an example of what to check with your host. Its guide to plan limits explains that hitting the processing limit slows the site down, while hitting the memory or process limit causes 503 errors. Its 503 guide adds that a 503 with low resource usage can mean the disk space or file count limit is full, and lists a temporary boost among the options for a short spike. Both guides suggest optimizing the site before upgrading. If you consider Hostinger's CDN, check which plans include it and what it caches on its current pages before you buy.
Upgrade or move?
Upgrading with your current host is the quicker route when the host is otherwise fine and the next plan raises the exact limit you keep hitting. There's no DNS change and nothing to copy.
Moving is worth it when support is slow to help, when the plan you'd need costs more than a comparable plan elsewhere once renewal prices are counted, or when you've outgrown shared hosting altogether and need a VPS or cloud plan. If you decide to move, follow the steps in how to move a website to new hosting without downtime.
Either way, keep the fixes from earlier. A page full of oversized photos is just as heavy on a faster server.