Measure the time before the first byte arrives. If that is consistently above about half a second on a simple page, the server is the constraint. If it is fast, the problem is what the page contains.

Hosting gets blamed first

When a site is slow, the host is the natural suspect, because it is the part nobody in the business understands and the part that sends a bill.

It is usually not the cause.

On most small business sites the server responds perfectly quickly and then sends four megabytes of images, six scripts, and a font, which is what takes the time.

Upgrading the hosting in that situation produces a faster delivery of the same excessive payload, which is a modest improvement for a recurring cost.

The number that separates the two

Time to first byte: how long between requesting a page and the first piece of it arriving.

That interval is almost entirely the server's responsibility. Everything after it is what the page contains.

Any browser's network view will show it, and most speed tools report it directly.

As a rough guide, under about two hundred milliseconds is good, up to half a second is acceptable, and consistently above about eight hundred milliseconds on a simple page is a server problem worth pursuing.

Test a simple page rather than the homepage, since a homepage doing a great deal of work will produce a slow first byte for reasons that are not the host's fault.

What makes a server slow

The third is the most common and the cheapest to fix, and it is frequently mistaken for a hardware problem.

Caching comes before upgrading

Worth trying first in almost every case.

Without caching, every visitor causes the server to assemble the page from scratch: run the code, query the database, and build the output.

With caching, the finished page is stored and served directly, which for most business sites removes the majority of the server's work.

A page that took eight hundred milliseconds to assemble can serve in under a hundred from cache, which is a larger improvement than most hosting upgrades deliver.

Many hosts include this and have it switched off, and most platforms have a plugin that does it. It costs nothing to try and it changes the diagnosis, since a site that is still slow with caching on has a genuine server problem.

Shared hosting and the neighbours

The characteristic pattern is worth recognising because it is diagnostic.

A site on shared hosting is one of many on the same machine, and their traffic affects your response times.

The signature is inconsistency: fast at seven in the morning, slow at two in the afternoon, occasionally very slow for twenty minutes with no pattern you can influence.

A single test tells you nothing about this. Test the same page at several times across a couple of days, and if the first byte time varies by a factor of four, you are sharing with somebody busy.

That is a genuine reason to move, and it is one of the few cases where paying more reliably produces a better result.

A worked example

A professional practice was quoted for a hosting upgrade after complaints that the site was slow.

Measuring first byte on a simple interior page gave about two hundred and forty milliseconds, which is entirely respectable.

The homepage took nine seconds to become usable, and the waterfall showed why: an uncompressed banner, a font blocking text, and a chat widget loading before anything else.

None of that would have been improved by a faster server, because the server was not what anybody was waiting for.

They fixed the three items and the page became usable in under three seconds on the same hosting.

The upgrade was cancelled, and the money went into product photography instead.

Where the server actually is

A cause that is easy to check and easy to overlook.

Distance adds a fixed delay to every request, and a site hosted on another continent from its customers carries that on everything.

For a business serving one region, the server should be in or near that region, and it frequently is not, because hosting was bought on price from whoever appeared first in a search.

You can check where a site is hosted in a few seconds with a lookup tool.

Moving is a real piece of work rather than a setting, so it is worth confirming with a first byte measurement from your own region before deciding, but for some sites this single factor is most of the problem.

What an upgrade buys, honestly

When the server genuinely is the constraint, the options differ in what they actually change.

A better shared plan usually means fewer neighbours and more allowance, which helps and remains shared.

Managed hosting for your platform typically includes caching, updates, and support that understands the software, which for a small business is frequently worth more than the raw performance.

A dedicated or virtual server gives you the machine and the responsibility for maintaining it, which is only sensible if somebody is going to do that.

Ask any prospective host what their typical first byte time is and whether they include caching, since those two answers predict more than the specification list does.

The counter-case

There is a version of this that goes wrong in the other direction.

Sites do outgrow their hosting, and a business that keeps optimising images while the server is genuinely struggling is avoiding the real problem to save a modest monthly cost.

A shop with growing traffic, a site with logged-in users, or anything doing real work per request will eventually need more than the cheapest plan, and holding out produces outages at exactly the moments that matter.

The signal is the measurement rather than the symptom: a consistently slow first byte, with caching enabled, that gets worse under traffic. That is a server at its limit and no amount of image compression will address it.

Diagnosing it

  1. Measure first byte on a simple interior page.
  2. Test at several times across two days.
  3. Turn on caching before concluding anything.
  4. Check where the server is relative to your customers.
  5. If first byte is fast, fix the page, not the hosting.
  6. If it is slow and varies wildly, you are sharing with somebody busy.
  7. Ask a prospective host about first byte and caching.

Step one takes two minutes and settles most of these arguments before any money is spent.

Who else is on your machine is covered in shared hosting and who else is on it.


Frequently asked questions

Is my hosting making my site slow?

Usually not. Most small business sites have a server that responds quickly and then sends four megabytes of images and scripts, which is what takes the time.

How do I tell if the server is the problem?

Measure time to first byte on a simple interior page. Under two hundred milliseconds is good, up to half a second acceptable, and consistently above eight hundred is a server problem.

Should I upgrade hosting or fix the pages?

Measure first. If first byte is fast, upgrading delivers the same excessive payload slightly quicker for a recurring cost. Fix what the page contains instead.

What should I try before upgrading?

Caching. Without it the server rebuilds every page for every visitor. A page taking eight hundred milliseconds to assemble can serve in under a hundred from cache.

How do I spot a busy shared server?

Inconsistency. Test the same page at several times across two days. If first byte varies by a factor of four, you are sharing with somebody consuming the machine.

Does server location matter?

Yes. Distance adds a fixed delay to every request, and hosting bought on price is often on another continent from the customers it serves.

West Coast Media Solutions Inc. provides web design, web development, hosting, digital marketing, and business consulting to organisations across Canada, drawing on more than twenty-five years in the field.

Been quoted for a hosting upgrade?

Measure first byte on a simple page first. Two minutes, and it usually shows the server was never the problem.

Start a Conversation