How to choose hosting and what to look for in a plan

Comparison pages for hosting plans are built to be impossible to compare. Disk space, unlimited traffic, a free domain, a 99.9% uptime promise. All the providers show roughly the same figures, yet one can cost several times as much as another.

The parameters that decide whether a site works well are almost never in that table. They are further down, in the small print, or not published at all.

What a plan actually includes

The headline figures are the least useful part of the offer.

• Disk space. A company site rarely uses more than a couple of gigabytes.
• Unlimited traffic. Unlimited until a clause in the terms says otherwise.
• Number of sites. Matters only if you genuinely have several.
• A free domain. Free for the first year, then at the provider’s own rate.
• Uptime promise. Usually stated without saying what happens when it is missed.

Disk space is the classic distraction. A shop with ten thousand product images might reach twenty gigabytes, and a plan offering a hundred sounds generous, but that plan gives no more processing power than the one below it. Space is the cheapest thing a provider has, which is why it is the number they print largest.

The uptime figure deserves reading twice. Ninety-nine point nine percent allows roughly forty minutes of downtime a month, which is acceptable. Ninety-nine percent allows about seven hours a month, which for a shop is a bad month. And a promise means little unless the terms say what you get when it is broken, which is usually a credit against future payments rather than a refund.

Limits that make a site slow down

Processes, memory and execution time

These are the numbers that determine speed, and they are the ones least often published.

If a plan allows, say, ten simultaneous processes, the eleventh visitor’s request either waits its turn or gets an error right away, depending on how the host enforces the limit. From the visitor’s side that looks like a page loading for six seconds instead of one, or an error page, and it happens exactly when traffic is highest, which is to say when it is most expensive.

Maximum execution time is what breaks imports. A catalog update runs for a minute and a half, the limit is thirty seconds, and the process is cut off a third of the way through with no message. The result is a partially updated catalog and no obvious cause.

What happens when a limit is exceeded differs from host to host. Some slow the site down, some return an error page right away, and many also email you an offer to upgrade. The plan description rarely says which, so ask before you pay.

How many visitors a plan will take

Providers rarely state this, and when they do the figure is optimistic. It also depends on the site rather than the plan alone.

A static company page is served from cache and costs almost nothing per visitor. A shop where each visitor filters the catalog, adds items to a cart and logs in is a different order of load entirely, because caching helps far less when every page is personalized.

Timing matters as much as the numbers. A thousand visitors spread across a day are not the same as a thousand in the half hour after a newsletter goes out. The second case needs headroom that a regular plan rarely has, which is why sites most often go down right after a newsletter or an ad launch.

The honest way to find out is to test rather than to ask. Deploy the site, generate load, watch what happens. Doing that after a sale campaign has already begun is the expensive version of the same test.

Shared hosting, VPS and cloud in plain English

The three tiers differ in what you share with other people.

Shared hosting puts several hundred sites on one server, dividing its resources between them. It is the cheapest option and it is entirely adequate for a company site, a portfolio or a small catalog. Its weakness is that a neighbor’s traffic spike can affect you, and that you cannot change the server’s own settings.

A virtual server gives you an allocated slice of a physical server with its own operating system. You install what you need, set the limits yourself and neighbors affect you far less. In exchange, somebody has to administer it, because the provider’s responsibility usually ends at the hardware.

Cloud hosting is the same idea with the ability to add resources quickly and pay for what is used. It suits projects with uneven load and is a poorer fit when the load is steady, because the flexibility is paid for whether or not it is used.

The choice between staying on hosting and moving to your own server is a separate decision with its own arithmetic, and it is weighed up in our article on your own server versus shared hosting.

Software versions and the database

Running a site on an old version of PHP is a problem that builds up unnoticed.

• Which versions are offered. A current one should be among them.
• Whether you can switch yourself. Through the panel, without a support ticket.
• Whether versions can differ per site. Useful when one is older.
• Which database is provided and which version. Not every plan says.
• Whether extensions can be added. Some projects need a specific one.

The practical risk is not that an old version is slower, though it is. The risk is that it stops receiving security fixes, and a site sitting on an unsupported version accumulates known vulnerabilities that nobody will ever patch.

The database version matters for the same reason plus one more. Newer versions handle complex queries on large tables considerably better, and a catalog with tens of thousands of items feels that difference on every filtered page.

Mail on hosting and why messages do not arrive

Almost every plan includes mailboxes, and almost every plan handles them badly.

The reason is not the provider’s incompetence. A shared hosting server sends mail from hundreds of sites, some of which send things nobody asked for. The server’s address accumulates a poor reputation, and your order confirmations inherit it.

The consequence is familiar to any shop owner. Order confirmations land in junk, password resets do not arrive, and the inquiry form appears to work while nothing reaches the inbox. Nobody notices until a customer complains, and by then a month of inquiries has gone.

Checking whether you have this problem takes five minutes. Place three test orders on your own site, each with an email address at a different mail provider, and see where the confirmations land. If even one of them goes to junk, the situation is worse than it looks, because the customers you never see are simply not getting their confirmations.

The second check is the sender address. Messages from the site should come from an address on your own domain, authenticated with SPF and DKIM, rather than from an arbitrary system address on the server. Since 2024 Gmail and Yahoo have required at least SPF or DKIM from every sender, and mail that fails these checks may land in spam or be rejected.

The correct arrangement is to send transactional mail through a dedicated service rather than through the hosting server, and to keep the mailboxes wherever is convenient. That is a configuration decision, not a hosting one, and you make it once, whichever plan you buy. On ordinary hosting we set it up as part of website support, and on your own server as part of server administration.

Server location and speed for your visitors

Physical distance costs time on every request, and no amount of optimization removes it.

Put the server in the region where most of your visitors are. A site serving Germany that runs on a server in Texas pays for the ocean on every page.

The complication arises when the audience is split across continents. Then the answer is a content delivery network, which keeps copies of images, styles and scripts close to the visitor while the site itself stays in one place. That covers most of the difference for a static page and rather less for a shop where every page is generated fresh.

Providers do not always say where the server actually is. A company registered in one country can perfectly well rent capacity in another, and the only reliable way to find out is to ask directly and then measure the response time from where your customers are.

What the host does for you and what you will do yourself

This is the line that separates plans priced similarly.

• Server updates. On shared hosting the provider handles them. On a virtual server, nobody does unless you arrange it.
• Backups. Often included, often only of the whole server, often kept for a week.
• Monitoring. The provider watches the server, not whether your site works.
• Site software updates. Never the provider’s responsibility.
• Security. Basic protection of the server, not of what runs on it.

The most common misunderstanding sits on the backup line. The provider’s backup exists to restore the provider’s server after a failure, not to restore your shop after a bad update. Not every plan lets you restore a single file or database yourself from the control panel. The copy may be a week old, and on some plans support will restore it only for a fee.

The other frequent gap is monitoring. The provider knows the server responds. Whether your checkout returns an error on the payment step is not something they check, and it is the thing that actually costs money. Site updates, your own backups and this kind of monitoring are covered on a regular basis by project support and development.

How to test a host’s support before paying

Support is the parameter you cannot see in the table, and it is the one that matters at the worst moment.

The test costs nothing. Before buying, write to them with a specific technical question, and note how long the reply takes and what it says. A question about execution limits or the version list is enough. What you learn is whether the answer comes within an hour or the next day, and whether a person read the question or a template was sent.

The second test is to ask what happens at three in the morning on a Sunday. Some providers answer honestly that urgent matters wait until Monday, which is fine to know in advance and unpleasant to discover during an outage.

The third test is the provider’s status page. A decent provider has one, and it shows the incident history, how often there were outages, how long they lasted and what was done about them. The absence of such a page does not mean there were no failures, only that they are not talked about.

A test environment and why it matters

The ability to make a copy of the site and try changes on it is worth more than several gigabytes of disk space.

Without it every update is made on the live site, which means every update is a small gamble. With it, an update is applied to the copy, checked, and only then repeated on the live one. Some plans include this, some sell it separately and some do not offer it at all, and the difference rarely appears in the comparison table.

Red flags when choosing

Some signals are worth reacting to before paying rather than after.

• No published limits. If processes and memory are not stated, expect them to be low.
• Unlimited everything. Unlimited is a marketing word, not a technical one.
• A very long minimum term. Three years prepaid at a discount is a trap when support turns out to be poor.
• A short refund window. A week to get your money back is noticeably shorter than what large providers offer.
• Support only by ticket form. With no stated response time.
• Migration treated as a favor. Moving a site in should be a standard service.

A separate signal is the absence of any way to leave. Check before paying how a full copy of the site and database is obtained, and whether the panel provides it or a support request is required. A provider who makes leaving awkward has made a deliberate decision about that.

When a plan can no longer save you

Sometimes the site is slow and the answer is not a bigger plan.

If the pages are heavy, the database is full of years of accumulated records and thirty extensions are running, a more expensive plan buys a few months and changes nothing structural. The causes and the order in which to address them are set out in our article on why a website loads slowly.

You can run a first check yourself at no cost. See how many database queries the home page makes and how many of them repeat, whether caching is on, and how heavy the images are. If any of these needs fixing, moving to a bigger plan or another host will only postpone the problem.

When the plan is genuinely the limit, the signs are different. The site is fast when traffic is low and slows predictably as it rises. The panel shows the process limit being hit. Imports fail at the same point every time. Those are resource ceilings, and there a move is the correct answer rather than an optimization.

Moving without downtime is a routine procedure with a defined order, and it is described step by step in our article on moving a website to a new server. What tends to be forgotten in the move is who then keeps the new setup current, and that question is covered in our article on what website support includes.

Conclusions

A hosting plan is chosen on the numbers that are not printed in large type. Processes, memory, execution time, the version list, where the server physically is and how support behaves when something breaks.

Disk space and unlimited traffic decide almost nothing, and they are the two figures the comparison table is built around. Reading past them takes twenty minutes and saves the migration that otherwise happens six months later.

If you are choosing between plans and are not sure which one your site actually needs, send us its address and the offers you are comparing. We will look at what the site really consumes, say which of the plans covers it and which is money for figures you will not use, and if the current one is adequate, show what to fix in the site itself.