How to choose the fastest web host in 2025?

Is your web hosting too slow?

Les choix technologiques et matériels de votre hébergeur impactent directement les performances de votre site web. Pourtant, la plupart des hébergeurs restent vagues sur leurs infrastructures et leurs performances réelles. En tant que client, vous ne savez souvent pas ce pour quoi vous payez.

At LRobwe're trying to do better. Much better. We have a transparent approach: we measure, compare and optimize every parameter, every hardware choice, to guarantee the best possible loading speed. up to 10x faster than the competition. We aim to offer you the fastest specialized WordPress web hosting. And since we're proud of the results, we're happy to share them with you.

In this article, we unveil our CPU and IOPS (SSD NVMe) benchmarks to explain how we choose our servers. We'll show you what really makes the difference in web performance.

What makes a good web host?

A web infrastructure has many components. Between software, hardware, choice of infrastructure and policy for filling in, monitoring, fighting bots... All this will have an impact on the final speed of your site.

While you, as a webmaster, certainly have your part to play in optimizing your website (and LRob can help you with this), the web host plays a central role that you can't cut out.

Let's take a look at what makes up a web server, and how each element impacts performance. And let's take a look at LRob.

Software components

Web server software is not that numerous. However, they can have a drastic impact on final performance.

Here's a summary of the various software components and their impact.

Serveur front (Apache, nginx, LiteSpeed…)

This is the HTTP(S) server itself. It communicates directly with the outside world, and its support for new technologies such as HTTP/3 or Brotli compression can improve visitor loading speed. The nginx and LiteSpeed servers are considered the best performers, while Apache is the most compatible.

• At LRob, we combine the best of both worlds, with Apache on the "back" and nginx on the "front", via a fairly common technical trick called "reverse proxy". This maximizes performance and compatibility at the same time, while adding support for HTTP/3 and Brotli compression and file caching, thanks to nginx.

Front-end server configuration Beyond support for new HTTP standards such as HTTP/3, two main criteria stand out: the maximum number of clients connected simultaneously, and the lifetime of a connection. This directly determines the maximum number of visitors supported. Other criteria, such as the nginx file cache, may also come into play.

• LRob intelligently optimizes these limits so that they have the maximum value supported by the hardware, without saturating CPU or RAM resources. The configuration also enables nginx file caching in addition to system caching. Values can be increased on request to suit specific requirements.

Database server (MySQL, MariaDB)

The database is called up each time a page is visited. Using a more recent version of MySQL or MariaDB and optimized configurations will improve performance. MariaDB is generally considered the most open-source and the most powerful. Both are generally inter-compatible.

• LRob servers currently use MariaDB 10.11 and MariaDB 11.4.

Database server configuration MySQL and MariaDB include numerous settings, such as maximum query size and RAM cache size. None of the hosting providers mention this. Yet generous RAM settings can boost database performance tenfold.

• At LRob, the innodb buffer is a minimum of 32GB, which means that almost all databases can be included in server RAM for maximum performance.

PHP versions

Every new version of PHP has been faster than its predecessor for some years now. If your site and host are compatible, then you should always opt for the latest version for maximum performance.

• PHP 8.4 is the latest version, already available from LRob at the time of writing.

PHP handlers (CGI, FastCGI, FPM, LSPHP...)

The PHP handler or "connector" is the link between the front-end server and PHP. It can have a drastic impact on performance. FPM and LSPHP are the two best performers.

• LRob uses FPM with a dedicated instance per site rather than a general instance on the server.

PHP handler configuration The PHP handler will determine not only the limits of PHP itself (for example, the maximum execution time of a script, or the maximum amount of RAM a script can use), but also the number of simultaneous PHP threads that can run, which ultimately determines the maximum number of visitors you can serve in a given time - a criterion that also depends on the final speed of your site.

• At LRob, PHP limits depend on your accommodation offer. They are shown in full transparency and are sized in line with the dimensions of your offer. Note that a PHP-FPM thread on a powerful server can serve more pages per second than on a less powerful server. So even with the LRob Starter package, which offers just 2 FPM, you can serve several thousand pages per minute (over 7500 pages/minute) with a well-optimized site.

RAM cache support

RAM cache support (Redis, memcached): If your site and host are compatible, this can boost your site's performance tenfold by storing your pages and requests in server RAM.

• LRob provides a Redis cache as standard on all its hostings.

Hardware components

The hardware behind web servers makes a major difference to final loading speed. Several components interact.

The CPU

The server processor will directly determine the computing power available.

This can be summarized in 2 parts: Single-thread power, multi-thread power. In other words, the amount of work achievable on a single task running on a single processor core, and the total amount of work achievable on all processor cores at the same time.

Roughly speaking, single-threaded power determines the speed of your site when there is only one visitor, while multi-threaded power determines the maximum number of visitors you can accommodate. Note that when you use full multi-threaded power, you reduce single-threaded power to a greater or lesser extent, depending on the type of CPU used, as we'll see in the following benchmarks.

• In 2025, LRob chooses 12- to 16-core processors (24 and 32 threads) from AMD, which offers the best raw performance according to our various measurements.

RAM

RAM stores server programs and CPU calculations. The more RAM a server has, the more cache it can hold (MySQL, Redis, nginx, files) and the more PHP processes it can run. Once again, this affects the maximum number of simultaneous visitors and the performance achieved.

• In 2025, LRob chose servers with 128GB RAM as standard, so as never to run out and benefit from generous caching to avoid any slowdown.

Storage IO

Storage capacity is not a criterion of speed on a web server. Instead, we measure IO speeds, i.e. disk input-output speeds.

Any reading or writing of files not in server RAM will use IO, whether it's a MySQL query or reading your site's PHP and multimedia files. This can have a monumental impact on a site's speed, especially where MySQL is concerned, which is generally the most sensitive to the number of random operations every second (especially for writing, which cannot be cached in RAM).

The classic hard disk is the slowest, followed by SATA SSDs, and then NVMe SSDs, which are the fastest. In the case of virtualized servers, the disks, whatever their form, can be deported to a SAN. In the case of a SAN, storage is no longer local, which can lead to a reduction in throughput and an increase in access latency.

• In 2025, LRob will be exclusively choosing servers with NVMe SSDs in local RAID (the fastest available) so as never to have to wait for disk accesses!

Choice of IT architecture

Two types of server are available from your hosting provider:

• Dedicated servers
  • LRob uses dedicated servers only.
• Virtualized servers

A dedicated server is a "normal" physical machine that hosts services.

A virtualized server is a sub-server created from a larger machine. This is known as a "VPS" (virtual private server) or "VM" (virtual machine), each with its own operating system. This gives the host greater versatility, but costs more in terms of RAM and disk space, and a drop in performance can occur due to virtualization and the number of systems to be run.

The servers can then be deployed in different ways:

• Classic LAMP (Linux Apache MySQL PHP) server: everything on the same machine (dedicated or virtualized)
  • LRob uses only classic, local LAMP servers on dedicated servers.
• Cluster: each application is separated on a different machine (dedicated or virtualized).

The second method is more versatile, and can support higher total traffic and economies of scale on large volumes, with potential service redundancy. On the other hand, it adds complexity to the architecture and can have a significant performance cost. Because each machine is separate, it creates latency due to the network and the different protocols used, for each file access, each MySQL query, each PHP execution. What's more, the hardware used is generally processor-based, with many cores (32 or more) but low performance per core.

Used to excess, LRob believes that clusters only really come into their own when the number of visits per minute exceeds tens of thousands, as in the case of social networks or government websites. For the average person with one or more websites, the main effect of clusters will often be to reduce performance.

Especially since, as you'll see at the very end of this article with a load test on the "Copines de bons plans" site, you can already make more than 12,000 visits per minute on 2 FPM processes at LRob... And much more on higher offers, provided your site is very well optimized.

Note: Although the LRob infrastructure is based on dedicated servers, the offers you order on the LRob portal are indeed shared offers. They're certainly high-performance shared services, more powerful than what you'll find on a VPS or even a low-cost dedicated server, but technically they are shared services, meaning that several sites and users are on the same physical machine.

Filling and blocking attacks: server load management

Server load is the average resource utilization of the machines. The aim is to have the lowest possible average load, with the highest possible resource reserve. This enables the servers to withstand peaks in traffic and load. For example, when one of your articles is a big hit on the web, or you're featured on TV or radio, we try to avoid server saturation at all costs.

You can often tell from the fluctuating performance that hosting providers have their servers full to bursting, to maximize their profitability. What's more, they don't necessarily effectively block attacks by pirate robots, which on low-traffic sites can account for up to 95% of the load. Imagine, 95% of your hosting resources occupied by bots... Don't imagine, this is what can happen without protection.

And if most hosts don't block bots, it's a strategic choice in my opinion: on the one hand, it encourages customers to switch to dedicated servers or higher (because of slowness), and on the other, blocking attacks sometimes generates false positives, i.e. customers who block themselves and therefore request support, which most hosts don't want to handle.

In practice, the kind of overloaded server we often see causes constant or occasional slowness on your site.

At LRob, we strive to offer maximum performance at all times. To achieve this, we apply a strict policy:

• We have set ourselves the target of not exceeding 25% at average load and 50% at peak.. If this happens : Reduce the load at source (block attacks? optimize a site?) or migrate the heaviest and/or most popular sites to a new machine.
• Blocking attacks at various levelsto save up to 95% of useful resources, while protecting your websites from attacks.
• Intelligent FPM process limits, so that no site overloads the servers
• Systematic contact with owners of slow or very popular sites to propose optimization solutions to reduce server load
• 24/7 monitoring server performance and direct intervention in the event of anomalies

Hardware performance: The technology gap

As we've seen, the choice of hardware can play a drastic role in performance. Today, we're going to focus on the two essential elements for translating website performance: CPU computing power, and disk read/write performance (IO).

Computing power (CPU)

We measured a wide range of servers to get a representative idea of what can be obtained depending on the type of server chosen.

Test of the day: Geekbench 6.4, gives you a good idea of the computing power of your machines.

Click here to find out more about cores and threads.

CPU cores" each provide a unit of computing power for a program that would only be able to use a single core. Modern processors have several cores. When all cores are used at the same time, performance per core drops (due to other limiting factors, such as power consumption and temperatures, RAM speed, or the speed of internal CPU caches).

To determine whether an application is capable of using one or more cores, we refer to it as a "monothread" or "multithread" application. Some applications fall somewhere in between.

MySQL is multithreaded.

Apache and nginx are a single-multithread mix: each thread corresponds to a file upload or HTTP session.

PHP is also a single-multithread mix: each thread corresponds to the execution of a PHP page (if several scripts are called, they will remain locked in a thread). In other words, a single visitor can only use one CPU core at a time.

We understand that for maximum performance, you need at least 2 cores, otherwise all these programs will have to share a single CPU core. And if you're expecting visitors, you'd better have a lot more, and choose high-performance cores!

So here are the machines that go through the Benchmark mill today:

• VM 2 Intel Xeon cores at PulseHeberg
• VM 2 Intel Xeon cores at Hetzner
• VM 2 ARM cores at Hetzner
• VM 4 cores AMD Epyc at Hetzner
• Dedicated AMD Ryzen 9 3900 12 cores 24 threads server at Hetzner (production server)
• Dedicated server AMD Ryzen 9 5950x 16 cores 32 threads at Hetzner
• AMD Ryzen 9 5950x 16 cores 32 threads personal computer (for control, manual overclocking 4.4Ghz fixed)
• VM 8 cores AMD Ryzen 9 9900x at PulseHeberg

And we will measure three values:

• Single Thread performance, i.e. the raw power of a single processor core. This corresponds to performance when a single task is running (which determines the best speed for loading a single web page when the server is idle).
• Multi-thread performance, i.e. the total power supported. This has an impact on the maximum number of simultaneous visitors.
• Multi Thread performance per core, i.e. the performance you can expect when the server is running at full load. This is obtained by dividing the Multi Thread performance result by the number of CPU cores.

Raw data, with LRob shared web servers in bold:

CPU	Single	Multi	Per core	Link	Remarks
VM 2 cores Intel Xeon E5-2680v4 PulseHeberg	817	1262	631	https://browser.geekbench.com/v6/cpu/10256420
VM 2 cores Intel Hetzner	749	1355	677,5	https://browser.geekbench.com/v6/cpu/10256916
VM 2 cores ARM Hetzner	1099	1975	987,5	https://browser.geekbench.com/v6/cpu/10256650
VM 4 cores Epyc Hetzner	1489	5012	1253	https://browser.geekbench.com/v6/cpu/10267600
Dedicated server 12 cores 24 threads AMD Ryzen 3900	1747	9345	778,7	https://browser.geekbench.com/v6/cpu/10256473	Server in production, low load, result slightly lower than actual
Dedicated server 16 cores 32 threads AMD Ryzen 5950x	2273	12012	750,7	https://browser.geekbench.com/v6/cpu/10256332
Personal PC Ryzen 9 5950X Desktop	2076	14209	888,	https://browser.geekbench.com/v6/cpu/10256353	For control. Manual overclocking 4.4Ghz & Watercooling
VM 8 cores AMD 9900X PulseHeberg	2877	11214	1401,7	https://browser.geekbench.com/v6/cpu/10256848	Out of stock

Graphics:

A number of conclusions can be drawn.

Single-threaded performance

As a reminder, single-threaded performance directly affects the perceived speed of your website. This is the most critical, and often the most overlooked, because conventional hosting providers often tend to choose very large processors, with many cores, but little single-threaded performance. This means they can host many sites, but each individual site will be slower.

And the difference can be major, since our measurements show that the speed can almost quadruple (x3.841)!

The least efficient is the single thread on Intel VPS from Hetzner, the most efficient is the single Thread on AMD R9 9900X VPS from PulseHeberg. The latter, however, is a UFO in the VPS world, offering mind-boggling performance (and unfortunately a victim of its own success since its release, with very limited stocks). We won't be taking this into account for the time being, but it does give us a glimpse into the future.

A small mention for Pulseheberg, which has the merit of clearly indicating on its site that virtualization hosts use Intel Xeon E5-2680v4 (14 cores 28 threads, 2.4-3.3Ghz).

VPSs with ARM processors are still going strong, outperforming our Intel VMs. They can't beat AMD and its famous Epyc, but it's worth remembering that ARM offers a significant gain in terms of power consumption, which is not insignificant for a datacenter.

In fact, Epyc CPUs are almost 2x as powerful as Intel CPUs at Hetzner, with a rounded x1.99 improvement.

Comparing the slowest VPS and LRob dedicated servers, we can see that we're looking at x2.33 and x3.03 single-threaded performance gains for Ryzen 3900 and 5950x respectively.

Starting with the best CPU available in virtualized mode (AMD Epyc at Hetzner) and moving on to the LRob dedicated CPUs, we achieve performance gains of x1.17 and x1.52 respectively. It should be noted that, as the server with a Ryzen 3900 was in production at the time of the benchmark, its measured performance is lower than its actual performance.

Multi-threaded performance

In multi, we have two ways of looking at the results: on the one hand, raw performance, and on the other, the extent to which the gain is proportional to the number of cores. With the latter approach, we can get an idea of the power and saturation of the VM host. Because we're never alone on it.

The "ratio" approach

For 2-core VMs, where a perfect score would be x2 in multi: PulseHeberg's 2-core VM is only x1.54 compared with its single score. Hetzner, on the other hand, scores x1.8 on its 2-core Intel VM. We can imagine that Hetzner has faster CPUs on its hosts, or a lower fill rate. The same applies to ARM with x1.79, which can also be explained by the large number of cores on ARM virtualization hosts.

In VM 4 cores, where a perfect score would be x4, Hetzner gives us a respectable x3.36 on the VM Epyc. With Epyc CPUs going up to 64 cores and more, while maintaining a comfortable frequency, this is very much in line with expectations.

On the dedicated side, on the Ryzens selected by LRob, we have x5.3 single performance, whether on the 3900 or 5950x, where we would expect x12 or x16.

To be exact, the 12 cores 24 threads Ryzen 3900 gives us a stack x5.3. The 16 cores 32 threads Ryzen 5950x gives us x5.28. So why doesn't it scale more? Because CPU frequency is highly dynamic on these models. So, at low load, when only a few cores are in use, we benefit from far superior performance. In other words, you get the best results on these CPUs by making sure you don't have too high a load.

In desktop version, to control the 5950x (I happen to have the same one at home!), with hand-optimized frequency set at 4.4Ghz, we start from a lower single score, but in multi, we end up with a x6.84. The result is significantly better than the server, but with much higher power consumption too, which would not be viable in a datacenter.

And for the UFO VM, the 8 cores on PulseHeberg's Ryzen 9 9900X, this one only gives us a small x3.89... But this should be put into perspective, as raw performance remains exceptional for an 8-core, surpassing the Ryzen 3900 (12 cores) and approaching the performance of the Ryzen 5950x. Great prospects for the future.

Gross performance

Let's take a look at the total load supported by these various machines.

Let's compare the best Intel dual core machine with our dedicated :
The Ryzen 3900 in prod makes 6.89x the score.
Ryzen 5950x, x8.86 the score.

For the record, I've already seen machines like these 2 Intel VM cores host 50 sites without too many problems. Which means that with 7x the performance we could host 350 sites. However, we've decided to stop at around 200 to 250.

Facing the fastest Epyc 4 cores :
The Ryzen 3900 in prod makes 1.86x the score.
The Ryzen 5950x scores 2.39x.

Performance by core

On our dedicated CPUs, single-core performance is far superior to that of almost all servers, but drops in multi-core performance compared to ARM or Epyc.

It's a choice: By not overcrowding such servers, you get drastically improved performance in everyday life, while not totally collapsing during peak loads. The aim is to ensure that even peak loads are below 50% of total utilization.

So, yes, performance per core drops... But on the other hand, we have a much greater number of cores! Moral: to maintain maximum performance, you have to make sure you never reach this "worst case scenario" (and that's what we do at LRob!).

IO performance (read/write)

IO speed is the speed of reading and writing to your server's disk. This has an impact on many elements, but MySQL (and MariaDB) is the element that certainly benefits most from excellent IO. And better MySQL performance means a faster site, a processor that doesn't wait for disk operations to complete, and ultimately, optimal performance.

In this section, we have simplified the tests for practical reasons, reducing the number of machines tested to the most relevant ones.

We use the Linux benchmark "fio". The benchmark command used produces 75% of reads and 25% of writes, all in random 4K files:

fio --randrepeat=1 --ioengine=libaio --direct=1 --gtod_reduce=1 --name=fiotest --filename=testfio --bs=4k --iodepth=64 --size=8G --readwrite=randrw --rwmixread=75

Gross values :

Server	Type	Read IOPS	Write IOPS	Read MB/s	Write MB/s
VM Intel PH	"SSD RAID 10 storage units	14,2	4,7	58	19,4
VM ARM Hetzner	"highly available and reliable SSD-based storage".	41,4	13,8	169	56,6
Ryzen 3900 Hetzner	SSD NVMe RAID 5 soft	110	36,8	451	151
Ryzen 5950x Hetzner	SSD NVMe RAID 1 soft	114	38,1	467	156
9900x PH	"Local NVMe disks	121	40,5	496	166

Simultaneous read/write speeds :

Even more important, but ultimately quite proportional to data rates, is the number of simultaneous read/write operations per second:

What can we deduce?

Like many, PulseHeberg probably uses conventional SATA SSDs for its Intel VMs, resulting in the lowest score here. On the other hand, on their Performance Cloud offerings, they've clearly selected good NVMe drives, taking the lead in this benchmark.

On the ARM and Hetzner side, we're probably using NVMe SSDs or SATA with a RAID controller card. Data rates are decent, but nothing more. What's more, if a SAN is used, then this throughput may vary over the course of the day.

On dedicated servers with local NVMe SSD RAID, very solid performance is achieved. The difference between our two machines is of the order of a margin of error, probably due to the fact that the Ryzen 3900-based server is in production.

In write mode (the most critical for MySQL), we're 8.1x faster than the slowest machine, and 2.76x faster than Hetzner's ARM VM (which is already a respectable score for a VPS).

Compared with most of the VPS offerings you're looking at, the average should be somewhere between these two, with LRob servers around 5x faster than the norm found on VPS.

In practice, this translates into a MySQL server that executes tasks quickly and is never saturated, and consequently, sites that are always as responsive as possible. In absolute terms, we've never observed disk I/O saturation on such a configuration in normal use.

How does LRob choose its servers?

Of course, the No. 1 criterion is performance.

Virtual servers whose performance is too random are out of the question for web production.

To meet our requirements, dedicated servers with NVMe SSDs and 128GB RAM are an unquestionable prerequisite.

As far as CPUs are concerned, we choose those with the best single-core performance, while offering solid multi-core performance.

The main partner chosen for LRob servers to date is the indestructible Hetzner, with its outstanding eco-responsibility and the quality of its support, with a 24/7 datacenter team.

Why not choose Epyc processors?

This is a legitimate question. With an Epyc 32 cores or more, the total capacity would be much higher. But this would be a bad strategic choice for 3 reasons:

• On the one hand, under moderate load, we achieve better final performance for each of our hosted sites, using Ryzens. In single-core mode, our 5950x outperforms an Epyc by up to 1.52x.
• On the other hand, there's the cost: Epyc machines are very expensive, so they take longer to pay for themselves.
• Finally, it increases the risk unnecessarily: making an Epyc machine profitable would mean putting a lot of sites on it. And yet, LRob for reliability and scalability, we think it's better to have a few more medium-sized servers than fewer large ones. In the end, we've already got enough sites on Ryzen without any slowdowns.

For the time being, this is not yet a reality, but we're keeping a close eye on CPU releases and on what hosting providers are offering.

What about the network?

Network consumption is often overestimated, or slowness is unfairly attributed to it. A slow site doesn't mean a slow network, but rather a slow server that struggles to generate pages and/or a poorly optimized site.

The average network usage of a shared server rarely exceeds 50Mbit/s, with an average of around 10Mbit/s (thanks to webmasters for optimizing their sites!).

But all the servers are gigabit, so 1000Mbit/s is available. We've got room to spare...!

In the end, it's backups and migrations that benefit most from these high speeds.

How does LRob perform?

How does LRob's performance compare with that of other hosting providers?

Without being able to quote the source hosts (legally we could be accused of denigration), we can tell you that LRob does better than almost all the hosts we tested.

We have migrated hundreds of sites to the LRob infrastructure. Only once was there no gain. This was a historic and annoying event. In all other cases, we've seen sites load 2 to 10x faster, with some even loading 20x or even 30x faster after caching or tuning. And all with stable speeds over time.

We now have a fine collection of before-and-after migration graphics, an extract of which is shown below:

So how can you be sure you're choosing the fastest host?

A good way to do this is to choose a host capable of transparency, as we do here.

Our advice is to take a step back from pre-conceived ideas and marketing, and look at actual measurements and data (hardware, architecture), or even better, take your own measurements.

At LRob, we do everything we can to ensure that everyone can benefit from the maximum resources for their site, at all times.

Beyond material choices, internal politics also plays an elementary role:

Good fill rate management and effective attack blocking work wonders. Also, in the event of a spike, we check its origin and correct it if necessary with the owner of each site. Yes, we take the trouble to contact them one by one. And do you know what? It works! Because everyone is always happy to speed up their site.

In the end, we aim for an average CPU load of 20% and 50% at peak, which leaves plenty of room to absorb peaks in activity without slowing down.

Instead of overfilling each server, we consider the server below to be almost full, requiring the deployment of a new machine for future customers:

If you find this transparent policy ideal and would like to benefit from it for your websites, book your LRob hosting now! And be among the first to benefit from hosting on a Ryzen 9 5950X with local NVMe SSD!