Servers
Shared hosting or your own server?
When a site is slow the design gets blamed first, but the cause is usually underneath it. When shared hosting is enough, and the five signs that it no longer is.
7min read
When a site loads slowly, the first thing people look at is usually the design and the images. Those matter, but more often the cause is underneath: where the site is hosted. This post is about what is enough, and when.
Three options
| Shared hosting | Virtual server | Managed platform | |
|---|---|---|---|
| Monthly cost | Lowest | Middle | Usage based |
| Resources | Shared | Reserved for you | Scales automatically |
| Administration | Provider | You | Provider |
| Root access | None | Yes | Limited |
| Handling traffic spikes | Weak | Up to capacity | Good |
On shared hosting dozens of sites live on the same machine. When one of your neighbours gets busy, your site slows down, and you can neither see this nor fix it. That is exactly why it is cheap.
When shared hosting is enough
- A brochure site: few pages, content that rarely changes, modest traffic.
- A corporate site that does not sell. There is a contact form, not a basket.
- Cases where the budget really is tight and the site is not business critical.
When it stops being enough
Any one of these five is reason enough to move:
- The site slows down at certain times and nobody can find out why. Usually a neighbour is loaded.
- You have moved into e-commerce. A basket and a checkout are a different kind of load from a brochure site, and slowness costs you sales directly.
- You are running campaigns. Sudden traffic from advertising is the thing shared hosting struggles with most, and your site is down while the ad budget is being spent.
- Mail delivery is suffering. You share sending reputation with every other site on that server. We wrote about that in the business email post.
- You are about to install Odoo or something similar. Shared hosting will not run it at all.
What changes on your own server
Resources are reserved for you, you get root access, and you can install what you like. In exchange, updates, backups and security become your responsibility.
The common mistake here is setting a server up and forgetting it. An unpatched server becomes an open door within months, and it is usually noticed only after something goes wrong. Server management exists for exactly this part: the build is a day of work, the following two years are the real job.
Finding the source of the slowness
Before deciding to move, confirm the problem really is underneath. Three measurements are enough:
| Measurement | What it tells you | If it is bad |
|---|---|---|
| Time to first byte | How fast the server answers | The problem is underneath |
| Full load time | How fast the whole page arrives | The problem is images or code |
| Repeat at different hours | Whether it fluctuates | Fluctuation means neighbours |
If time to first byte is high, optimising the design will not help; the problem is where the site lives. The reverse is also true: a fast first byte with a slow page means changing servers is money wasted, and you should look at images and code instead.
Repeat the same measurement at different times of day. Fast in the morning and slow in the evening means neighbours are loading the machine on shared hosting, and there is nothing you can do about it from your side.
When virtualisation comes in
If you need to run several systems on one machine, separating them is healthier than stacking them. One crashing does not take the others down, and one being updated does not stop the rest.
We use Proxmox for virtualisation. When a single server holds several client systems, or a single business runs several environments (live and test), this arrangement makes the work considerably easier.
Before you move
Changing servers is riskier than it looks; get the order wrong and the site is down for hours. The sequence we follow:
- Find out where the domain is managed. Surprisingly often nobody knows, and during the move there is no one to call.
- Build on the new server and test it. While the old one is still serving, the new setup is tried on a temporary address.
- Shorten the DNS times in advance. That is what decides how long the switch takes to propagate; do it a day before.
- Point it over and do not switch the old one off. Leave it up for at least a week; until propagation finishes some visitors still land on it.
- Do not forget mail records. This is the single most commonly missed item during a server move, and by the time it is noticed some mail has already been lost.
Frequently asked
Where should my server be?
Close to the majority of your visitors is good for speed. For an audience mostly in Türkiye and Cyprus, European data centres are fine, and putting a content network in front narrows the gap further.
Will my site go down during the move?
Done properly, no. The new server is built and tested first, then DNS is pointed at it, and the old server stays up for a while so nobody arriving mid-switch finds nothing.
Managed platform or my own server?
A managed platform takes over maintenance and starts you quickly, in exchange for some restrictions. A concrete example: some of them block outbound mail ports and do not document it. Ask about the restrictions up front.
How often should backups run?
As often as the amount of work you can afford to lose. For a site taking one order a day, daily is fine. For one taking dozens an hour, a daily backup means losing a day of sales.