Professional web infrastructure: beyond a simple domain

01A domain is an address, not a house

When a business decides to “go online”, the first purchase is almost always a domain: yourcompany.com, a few euros a year, and the feeling of having taken the step. It is a real step, but it is the smallest one. A domain is an address: it says where to go, not what you will find once you get there.

Behind that address there has to be a server, that is, a computer switched on day and night in a data center, which receives visitors’ requests and answers with the pages. The server is the house. And as with a real house, the questions that matter are different ones: how big it is, who lives there with you, how well it copes when a hundred guests arrive at the same moment, who holds the keys.

Between the address and the house there is a third piece, the DNS: the street directory of the Internet, which translates the name people type into the number (the IP address) that computers understand. How domain, DNS and HTTPS certificate work in detail is something I explain in the chapter on what happens when someone types your address. Here what matters is the destination: the server.

For an online business card, a few pages that change once a year, the house can be small. For a business portal, with customers who log in with their own account, bookings, payments, a management system behind it and personal data to protect, the house is the piece that holds everything up. And that is where the “domain + hosting for a few euros” offer starts to fall short.

02Shared hosting: an apartment block with thin walls

Shared hosting is the most common and cheapest formula: a single physical server hosts hundreds, sometimes thousands, of websites belonging to different customers. Each one has its own folder and its own space, but processor, memory, disk and connection are shared. The provider takes care of everything: updates, server security, mail, control panel. You upload the files and that is it.

It is an apartment block: it costs little because the expenses are split, and someone looks after the common areas. But the walls are thin. If the neighbor throws a party, that is, if another site gets a spike in visits or runs a badly written program that eats up the whole processor, you slow down too, without having done anything. In the jargon this is called the “noisy neighbor” effect.

When shared hosting is perfectly fine

It is not a product to look down on: it is a product to use for what it was made for. It is perfectly fine for:

• a brochure site of a few pages, especially if it is made of static files and does not query a database on every visit;
• a personal blog or one for a small business, with steady traffic and no spikes;
• a landing page for a campaign, or a test site.

The limits you discover when it is too late

The problems arrive when the site is asked to become an application. On shared hosting, as a rule:

• you cannot install software as you please: you use the version of PHP and MySQL the provider offers, when it offers it;
• there are hidden ceilings on simultaneous processes, memory per request, maximum script duration, number of database connections;
• scheduled jobs (the overnight emails, the backup, the sync with the management system) have frequency limits or are not available at all;
• you cannot run an always-on service, for example an API in .NET or Node.js, or a real-time notification system;
• the reputation of the IP address is shared: if a neighbor sends spam, the emails from your domain can end up in the junk folder. I talk about it in the chapter on professional business email.

03The VPS: a server of your own, without buying one

A VPS (Virtual Private Server) is a slice of a powerful physical server, separated from the others by a program called a hypervisor. The hypervisor does one thing only, and does it rigorously: it assigns each slice its share of processor, memory and disk, and prevents one slice from touching the resources of another. For the operating system running inside it, that slice is a whole computer.

In practice, a VPS is described with three numbers: the vCPUs (the virtual processors), the RAM and the disk space, almost always on fast solid-state drives. A configuration such as 2 vCPUs, 4 GB of memory and 40 GB of disk comfortably handles a business portal with its database, an API and the scheduled jobs, as long as the traffic stays that of a local or regional business.

The four advantages that count

The other side of the coin: you hold the keys

An “unmanaged” VPS is a house handed over empty, keys in hand. The provider guarantees that the machine is on and connected; everything else is the responsibility of whoever administers it:

• the security updates of the operating system and the programs;
• the firewall, that is, which ports are open to the Internet and which are not;
• the HTTPS certificates and their automatic renewal;
• the backups, which must leave the machine: a backup that lives on the same server disappears along with it. I explain this in the chapter on business backup and the 3-2-1 rule;
• monitoring: knowing the site is down before a customer tells you, and a service that restarts it on its own.

This is why the real question is not “hosting or VPS”, but “a VPS administered by whom?”. A VPS left to itself is less secure than good shared hosting. A VPS administered methodically is the most solid foundation a small or medium business can have, at a fraction of the cost of a dedicated server.

04Linux or Windows Server: how to choose the operating system

An operating system has to be installed on the VPS, and the choice is made once for years. The two families are Linux (in its server distributions: Ubuntu Server, Debian, AlmaLinux, Rocky Linux) and Microsoft’s Windows Server. It is not a matter of taste: it depends on what the server has to run.

Linux: the natural choice for the web

The vast majority of the world’s web servers run on Linux, for very concrete reasons:

• stability: a well-configured Linux server stays up for months; security updates almost always install without a reboot;
• lightness: without a graphical interface, the system takes up little memory and leaves the resources to the applications;
• the web ecosystem: PHP, MySQL and MariaDB, PostgreSQL, Python, Node.js, the Nginx and Apache web servers are born and tested first of all on Linux;
• no licenses: the system is open source, you do not pay per processor or per user;
• secure remote administration with SSH and cryptographic keys, with no remote desktop exposed on the Internet;
• layered security: strict permissions on files and processes, a built-in firewall, fast updates from very large communities.

A myth to debunk: “.NET means Windows”

Until a few years ago it was true. Not anymore. Since 2016 Microsoft has rewritten its platform as .NET (formerly called .NET Core), which runs natively on Linux, and it is the version on which all new software is developed. Since 2017 SQL Server has also existed for Linux. A modern C# application can therefore live on a Linux VPS, with the same advantages of lightness and cost as a PHP site.

When Windows Server is truly indispensable

• when there is software written for the old .NET Framework 4.x (WebForms, server-side WCF services), which exists only for Windows and cannot be ported to .NET without partly rewriting it;
• when the company uses Active Directory to manage users, computers and permissions on the internal network: the domain controller is a Windows Server role;
• when you need to run management programs that exist only for Windows, or have several people work on a shared remote desktop;
• when you need some SQL Server feature that is not available in the Linux version (some ancillary services, such as reporting ones): this has to be checked case by case in Microsoft’s documentation.

In all other cases, Windows Server adds the cost of licenses, more memory taken up by the system and a wider attack surface, without giving a web portal anything in return.

05TTFB: how long the person knocking at the door waits

TTFB (Time to First Byte) measures how much time passes from when the browser requests a page to when the first little piece of the response arrives. It is not the full loading time: it is the time during which the visitor stares at a blank screen waiting for the server to start talking.

Google, in its developer guide, describes a TTFB of 0.8 seconds or less as good and one above 1.8 seconds as poor. Every millisecond lost here adds up to everything that comes after: a slow server makes even the lightest site slow.

How to measure it, without special software

• In the browser: open the Developer Tools (F12 key), Network tab, reload the page and click on the first row. In the timing section, the entry “Waiting for server response” is the part of TTFB that depends on the server.
• From the command line: curl -o /dev/null -s -w "%{time_starttransfer}\n" https://yoursite.com/ prints the seconds until the first byte.
• With public tools such as PageSpeed Insights, which also show the data collected from real visitors using Chrome.

What lowers TTFB, in order of effectiveness

1. A well-designed database: the right indexes and queries that ask only for what is needed (we will see this shortly).
2. Caching: a page that is the same for everyone is computed once and delivered ready-made a thousand times.
3. The code: less useless work on every request, fewer libraries loaded for nothing.
4. Reserved resources: on a VPS the processor is not contested by the neighbors.
5. Proximity: a server in Italy or in Europe answers Italian customers faster than one on the other side of the ocean.
6. Modern protocols: HTTP/2 or HTTP/3 and TLS 1.3 encryption remove steps from the connection.

TTFB is only the first of the measures Google uses to assess the visitor’s experience. The other three, the ones you can see in the browser, I explain in the chapter on Core Web Vitals.

06The database: the warehouse that decides the speed

Every time a customer opens their profile, looks for availability or checks an order, the server asks questions of the database, the orderly warehouse where all the data is kept. How long it takes to answer depends less on the power of the server and much more on how the warehouse is organized.

Indexes: the difference between searching and finding

Imagine looking for the word “invoice” in a thousand-page book without an index: you have to leaf through all of it. With the index, you go to the letter I and find the page number. A database index does exactly this: instead of reading every row of a table to find the customers in a given city, it goes straight to the right ones.

Indexes are not free, though: they take up space and slightly slow down writes, because they have to be updated with every new piece of data. They go on the columns that are really used to search, filter and join, not on all of them just in case. Deciding which ones is design work, and it is done by looking at the real questions the portal will ask.

Queries: asking only for what you need

A query is the question the program asks the database. The same result can be requested in very different ways, and the difference in speed can be a hundredfold. The most common mistakes, found in many slow sites:

• asking for all the columns (SELECT *) when three are needed, transferring useless data on every request;
• the so-called “N+1” problem: to show fifty orders, the code asks one question for the list and then fifty separate questions, one for each customer, instead of a single question that joins the two tables;
• filtering in the program instead of in the database: downloading ten thousand rows to show ten;
• never looking at the slow query log or the execution plan (EXPLAIN), which tell you exactly where the database is struggling.

These are mistakes you do not see while the data is small, and that explode when the business grows: the portal that answered in a tenth of a second in January takes three seconds in December. This is why the quality of the source code weighs on server performance as much as the power of the machine, and often more: I talk about it in the next chapter, on the value of a coding professional and the limits of artificial intelligence and page builders.

07How to choose, case by case

Putting together everything we have seen, choosing the infrastructure comes down to a few honest questions about what the portal will do today and two years from now.

The infrastructure is the backbone of everything that comes after: the portal with bookings and the PWA, the business email, the site that needs to be found. A well-chosen server is never noticed. A badly chosen one is always noticed, usually on the busiest day.

Frequently asked questions

Sources

1. web.dev (Google), “Time to First Byte (TTFB)”: definition, phases and the 0.8 and 1.8 second thresholds.
2. Microsoft Learn, “Install .NET on Linux” (in Italian): the Linux distributions supported by modern .NET.
3. Microsoft Learn, “SQL Server on Linux overview” (in Italian): SQL Server for Linux and the features available.
4. MySQL Reference Manual, “How MySQL Uses Indexes”: how indexes avoid reading entire tables.
5. Wikipedia, “Virtual private server” (in Italian): virtualization and the hypervisor.

Chapter updated October 2026. The thresholds and compatibility details cited come from the manufacturers’ official documentation; the times in the plates are examples to show the proportions, not measurements of any particular site.