There is a moment when a website suddenly matters. A mention in a daily paper, a newsletter that does unexpectedly well, a shout-out on a large podcast, the day the public tender opens. In exactly that moment, instead of the usual thirty visitors a day, thirty arrive per minute. And in exactly that moment, a typical SME website does the one thing you want least: it slows down, or it is briefly unreachable.
The usual reaction is that the provider has a problem, or that the website is badly configured. Neither is usually true. What makes itself felt there is a structural property of the model that most Swiss SME websites run on today. It is not wrong, it is built in. And it becomes visible exactly when it hurts.
This post explains three things plainly. First, why the classic hosting model gets structurally slower under peak load, and why that has nothing to do with the quality of the provider. Second, what that actually costs in everyday business, beyond the monthly fee. And third, what a second model alongside it does differently, with current Swiss prices and without trying to talk any provider down.
The classic hosting model, briefly and plainly
Here is how the model that most Swiss SME websites use today works. A provider runs a set of servers in a data center. On each server, many customer sites run at the same time, each with a fixed share of memory, compute and bandwidth. Buy a hosting plan and you rent that fixed share. What is included in the plan, the customer has; what is not included, they do not. In normal operation, that is to say at the usual thirty visitors a day, this is a very efficient solution and in Switzerland typically well executed. Swiss data location, German-language support, automatic backups, a fair price. There is nothing wrong with it.
These hosting plans very often run WordPress, the most common CMS in the world. That is not wrong either, but it brings its own layer of risk, which is not the focus of this post. Anyone interested in that part will find a detailed assessment in the WordPress post on the warnings from the Swiss authorities.
The structural weakness does not lie in normal operation, but in the three points the marketing copy does not mention: peak load, maintenance windows and unexpected outages. They are not provider-specific shortcomings, but properties of the model. They would be there with a perfect provider too.
First: peak load
When a website suddenly gets ten times more visitors than usual, there are two possible reactions: the system grows with it, or it stays the same and gets slower. With classic hosting, nothing grows with it. The rented share is the rented share. Anything beyond that in requests is put into a queue, and the wait grows longer for everyone.
That is measurable. At normal load, a WordPress site typically delivers its content in 200 to 500 milliseconds. When traffic increases tenfold, that time stretches to two, three or five seconds, sometimes more. From the visitor’s point of view the site goes “sluggish”. Studies on website performance have shown consistently for years that with each additional second of load time, a double-digit percentage of visitors leave. Anyone with a slow site at the peak moment loses exactly the visitors the peak moment came about for in the first place.
Important: this is not a question of “paying more for the plan”. The more expensive plans are a fixed share too. They move the threshold at which the slowdown sets in, but they do not remove it. A triple plan still responds to a tenfold spike like a rented share, not like a growing system.
Second: maintenance and unexpected outages
Every running system needs maintenance. Operating systems get security updates, databases are migrated, the hardware under the data center ages and has to be replaced. Swiss providers do this well and usually announce maintenance windows in advance, often at night, with minimal impact. Even so: a website that lives on a running server depends on that server’s availability. When the server is down, the website is down.
Statistically, Swiss hosting providers are very reliable. Advertising 99.9% availability is the norm. 99.9% sounds like “always there”. In reality that is about 8.7 hours a year in which the site is unreachable. If those 8.7 hours occur evenly spread out at 3 a.m., nobody notices. If they occur bundled during a maintenance window or an unexpected outage at 9 a.m. on a Monday, in the middle of the application phase of a public tender, that is a problem with no technical answer.
Here too: no provider is to blame. It is the natural consequence of a website living in a single physical place. When that place has a problem, the website has a problem.
Third: what it really costs
The hosting bill is not the whole bill. The real cost of an outage or a slowdown lies outside the monthly price.
For a Treuhänder, a law firm or a consulting practice, a lost peak moment means inquiries do not arrive. Someone who clicks on the website because they read a friend’s recommendation or an article, and then sees a loading page, moves on to the next provider within 30 to 40 seconds. That is consistently documented in usage research. Out of ten potential clients who came to the site at the peak moment, perhaps three actually reach the contact form.
For a marketing agency running a campaign on a client’s behalf, the problem is even more direct. A press release that catches a wave, a paid post that does unexpectedly well, an event announcement: those are exactly the moments when the client’s hosting becomes the weak point, without the agency having any influence over it. The wave collapses, the client sees it, and the agency has to explain the situation. That is a conversation no agency wants to have.
And for a public tender, a job posting or a tender deadline: the deadline applies regardless of whether your website was reachable. One hour of downtime on the wrong day can cost an application whose value is many times the annual hosting fee.
The second model: serverless
For a few years now there has been a second model that attacks the structural weakness of the first exactly where it sits: at the assumption of a fixed share. In the serverless model there is no fixed share. Instead of renting a server share, you rent the ability to answer individual requests. When nobody is on the site, nothing runs. When fifty visitors arrive at the same time, the response runs fifty times in parallel. When five thousand arrive, five thousand times. The system grows and shrinks with traffic by the second.
Technically, on AWS this means: the content sits statically on a content delivery network called CloudFront, which caches the content on hundreds of nodes worldwide. The few places where computing actually happens (form submission, dynamic evaluations) run in “Lambda” functions that exist only for the duration of a single request. This is not magic but well-understood technology, used today by practically every large website in the world, from Bloomberg to Coca-Cola, and for a few years now accessible to SMEs as well.
What changes concretely for the website: under peak load it does not get slower, it stays fast. It does not depend on a single physical server but lives distributed across a global network. Maintenance windows in the classic sense do not exist, because no single machine has to be maintained. And when one data center fails, another takes over automatically.
The structural comparison
To make the difference clear, a table along the three axes that matter. It is deliberately brief, because the points speak for themselves.
| Property | Classic hosting | Serverless (AWS) |
|---|---|---|
| Behaviour under a spike (10x visitors) | Slows down, can turn into a queue | Scales automatically |
| Outage risk at the peak moment | Present, site tied to one server | Practically zero, distributed |
| Maintenance windows | Needed, usually announced at night | Structurally none |
| Behaviour at zero visitors | Full price keeps running | Near-zero cost |
| Dependence on one data center | High | Low (distributed) |
| Recovery time after an incident | Minutes to hours | Seconds, automatic |
| Official SLA guarantee | Typically 99.9% | CloudFront 99.9%, S3 99.9%, effectively 99.99% with multi-AZ |
| Data durability | Provider-specific | S3: 99.999999999% (eleven nines) |
These eight rows are the argument. They are not sales points, they are technical properties. Anyone running a website whose reachability never matters has no pain in any of the rows. Anyone who has one moment a quarter when the website has to count has an argument in every row.
An honest note on the SLA row: the official contractual guarantee is the same for both models, namely 99.9% monthly uptime. Marketing claims like “eleven nines” refer to data durability, that is to say how unlikely it is that data is lost, not to availability. The real difference lies not in the contractual figure, but in the architecture behind it. When the serverless system runs across several availability zones (which is standard), the effective availability is above the contractual promise. With the classic model, the contractual figure is also the maximum the architecture allows, because behind a Swiss data center stands exactly one data center.
The price comparison, short and clean
The price comparison comes at the end, because it is the weakest lever. Nobody switches hosting over ten francs a month. But if you are already questioning the architecture, it belongs on the table too.
Current prices in the Swiss market for a typical SME website (as of May 2026):
| Provider | Entry plan | Mid plan |
|---|---|---|
| Hostpoint Smart | CHF 17.90/mo. | from CHF 29.90/mo. |
| Cyon Single | CHF 14.90/mo. | from CHF 79.90/mo. (Pro) |
| Infomaniak Webhosting | from CHF 10.91/mo. (net) | as needed |
| Serverless on AWS | CHF 2 to 8/mo. (variable) | grows only with traffic |
Source: provider websites, May 2026, Swiss prices including 8.1% VAT except Infomaniak (net). Always check current rates with the provider.
The price range is not the point. An honest calculation over three years of hosting (15 francs a month is 540 francs over three years) is usually smaller than a single unanswered mandate lost at the wrong peak moment. Anyone who makes the hosting decision on the basis of the monthly price is usually optimising the wrong variable.
When one model, when the other
Three situations in which the classic model remains the right choice:
An existing WordPress site that has run stably for years, sees no spikes and plans none. Switching for the sake of switching costs time and money with no return.
Email mailboxes under your own domain as a central requirement, combined with German-language phone support for a non-technical team. That is exactly what the Swiss providers are built for.
A website without public spikes, without tender pressure, without media presence. Where reachability never becomes a question, the structural weakness is not one, and the effort of a model change is not worth it.
Three situations in which the serverless model is structurally the better choice:
A website that is regularly or irregularly in the public eye. Politics, events, associations, professional bodies, anything with press work or elections or campaigns. Spikes here are not the exception, they are planned for.
A website with a tender function, an application deadline or other moments where being unreachable has a commercial or legal consequence. The single day of downtime costs more here than three years of a model change.
A new website that is being built anyway. Here the model question is part of the architecture decision. It should be answered together with the question “WordPress or static?”, not only at the end.
What an honest recommendation would be
If I had to give an SME neutral advice today, with my own offering out of the picture, it would sound like this.
If your existing website runs stably and spikes were never an issue, leave it where it is. A technical decision that solves no problem today is no improvement tomorrow.
If in the past year you had at least one moment when your website should have counted and did not keep up, that is not a coincidence but a structural signal. Before you switch the provider, check the model. Switching providers within the same model changes little.
If you are building anew anyway, the model question belongs in the first meeting, not the last. It is not a technical detail but one whose consequences play out over years.
Where my own price sits
I build Swiss SME websites serverless on AWS. The typical cost works out between CHF 2 and CHF 8 a month in AWS fees, plus a one-off build phase. That does not fit every project, and it is not an automatic win over a well-maintained classic installation. It is the right choice for a certain kind of project, and for the other kind there are the established Swiss providers who have done for years exactly what they promise.
Sources
- Hostpoint, current web hosting rates: https://www.hostpoint.ch/
- Cyon, current web hosting rates: https://www.cyon.ch/hosting/webhosting
- Infomaniak, current web hosting rates: https://www.infomaniak.com/de/webhosting
- Web hosting comparison Switzerland 2026 (independent comparison with an availability assessment): https://schweizer-domains.ch/webhosting-schweiz-vergleich-2026/
- AWS, Service Level Agreement for Amazon CloudFront (99.9% monthly uptime): https://aws.amazon.com/cloudfront/sla/
- AWS, Service Level Agreement for Amazon S3 (99.9% monthly uptime): https://aws.amazon.com/s3/sla/
- AWS, Amazon S3 data durability (99.999999999%, “eleven nines”): https://aws.amazon.com/s3/storage-classes/
- AWS Pricing Calculator (Lambda, CloudFront, S3): https://calculator.aws/
This post stands on its own. If you want to go deeper on the architecture decision, the next step is the 30-minute call.