Testing Website Loading Speed with webpagetest.org

The topic of loading speed is not a new one: even in the early days of the web, loading time was a critical factor for a website’s success. Internet bandwidth was so low—remember, 56k modems were often the absolute best one could hope for in the late 1990s; today, connections with 100 Mbps and more are common—that even a few hundred kilobytes was the upper limit for a page to achieve a decent loading time.

With increasing bandwidth, the situation for desktop computers has eased somewhat, at least in theory. However, the growing use of mobile devices and increasingly larger screens with high resolutions (back in the late 1990s, for example, 19″ with 1,200 x 800 pixels; today, for example, 27″ with 2,560 x 1,440 pixels) puts website operators in a similar position as back then. It’s a bit like the smartphone battery problem: batteries are becoming more powerful, but devices are consuming more and more power.

Today, loading time is taking on a new dimension: search engines, most notably Google, integrate loading time into their index calculations. Simply put: the slower a website loads, the further down it appears in search results. Since this shift, the topic has gained traction among professional website operators, and a literal race has begun. As of 2026: Google evaluates the loading experience primarily through Core Web Vitals—Largest Contentful Paint (LCP, when the largest visible content has loaded), Interaction to Next Paint (INP, how quickly the page responds to input), and Cumulative Layout Shift (CLS, how much the layout shifts during loading). This is one ranking factor among many; high-quality content remains more important.

There are several levels where optimizations can make a difference. On one hand, there are factors related to the connection itself or the “power”—in a car analogy: the horsepower, whether the car is aerodynamic, how much it weighs… On the other hand, there is whether a website is well-built and prevents unnecessary loading of elements—in a car analogy: the driver; are they driving optimally, do they know the route, or do they have to stop at every traffic light? There are certainly better comparisons than cars ;-). In any case, these two levels are explained in more detail in the following paragraphs.

• Infrastructure: Generally, it matters whether the website is operated on a shared hosting server or a dedicated server. Speed begins with the data center’s internet connection and how the provider’s routers connect the various servers. This results not only in speed but also in the so-called Time to First Byte, a metric for the time it takes for the first byte to travel from the server to the client.
• Web Server: The web server also plays a role in optimization. Generally speaking, web servers using Nginx are faster than Apache—though this isn’t necessarily the case; with some configuration work, Apache can fly too. But it’s not just changing the software that brings speed. Settings like Keep-Alive also ensure that the connection to the web server doesn’t have to be renegotiated after every request.
• Caching is a complex topic because caching exists on many levels (CDN, HTTP reverse proxy like Varnish Cache, local cache, database cache like memcached or Redis, etc.). Caching is one of the most effective options for shortening loading times, depending on how it is used. It should be noted that not everything can always be cached—sites with a high frequency of changes, such as news portals, want visitors to always see the latest articles.

Here is a brief explanation of the 6 points:

1. First Byte Time: The time taken to receive the first byte from the web server. This value can be influenced primarily at the hosting level, e.g., through caching. The value depends on the physical hosting environment (data center, server) and the current system load.
2. Keep-alive enabled: A web server option that keeps the connection between the server and browser open, thus avoiding the need to renegotiate the TCP handshake every time. A website often has 100 or more elements to load—so a seemingly small optimization can make a difference. With HTTP/2 and HTTP/3, many files are now loaded in parallel over a single connection anyway.
3. Compress transfer: Also a web server setting. The web server can transmit data in a compressed format so that less data needs to be transferred. Modern browsers are now all capable of handling compressed data transmission.
4. Compress images: This is where website operators come in. The indicator shows how well the images being loaded are compressed. Can the size be reduced (without loss of quality)?
5. Cache static content: Are the displayed elements coming from the cache, or were they served fresh from the web server?
6. Effective use of CDN: Is the content being served from a CDN (Content Delivery Network)?

The upper table shows further values that represent the results of the speed test. Here, the speed of the website display is divided into individual stages to better understand where the loading times occur.