1. How Long Can You Wait? Nielsen's Time Limits for Page Loading
How many seconds can you wait for a page to appear? In 1993, Jakob Nielsen proposed three important limits. 0.1 seconds is the limit for feeling an "immediate response." 1 second is the limit for keeping your train of thought uninterrupted. 10 seconds is the limit for maintaining attention on the screen [1]. These guidelines are based on research from 1968 and 1991 [1].
In modern web browsing, one key measure is the time until the largest part of the page (like a big image or text block) becomes visible. It is considered "good" if this happens within 2.5 seconds for 75% of page loads [2]. We will treat this 1 to few seconds as the "budget" available for communication and see what uses it up, starting with things that cannot be shortened.
2. Why Data Takes Time to Travel: The Speed of Light in Cables
Even light traveling through fiber-optic cables takes time proportional to the distance. Light travels at about 300,000 km per second in a vacuum. Inside glass, it slows down due to the refractive index (about 1.5) [3]. Roughly dividing, light in fiber-optic cables travels at about 200,000 km per second.
The straight-line distance from Tokyo to Los Angeles is about 8,800 km. At 200,000 km per second, a one-way trip takes about 44 milliseconds, and a round trip takes about 88 milliseconds. This "go and return" time is called RTT (Round Trip Time). This theoretical lower limit, where light just travels, is close to the 0.1-second limit mentioned earlier.
Think of it like an echo. If you shout "Hey!" toward a mountain, the farther the mountain, the longer you wait for the reply. However, in communication, the other computer actually receives the message, creates a reply, and sends it back. The 88 milliseconds is the lower limit assuming a straight cable and zero processing time for equipment. Real undersea cables are not straight, so it takes longer. Using the same calculation, Tokyo to Osaka (about 400 km) is about 4 milliseconds for a round trip. A round trip across the ocean takes more than 20 times as long as a domestic one. How many of these round trips are needed to view a page?
3. How DNS Turns a Web Address into an IP Address
When you type a URL into a browser, the first thing needed is the other computer's number (IP address). The system that looks up numbers from names is DNS. If nothing is stored, the query follows a path: root servers, then servers responsible for endings like .jp or .com, then the server for that specific domain [4]. Each step requires a round trip.
To save time, answers are stored. Computers and cache servers keep query results for a set time (TTL) and reuse them. After the time passes, they are discarded [4]. It is like writing down a friend's address in a notebook. Unlike a notebook, however, the storage time is fixed. On the second lookup of the same name, the answer might come from nearby storage without going far. The first step varies from almost no round trips (if cached) to many round trips. Next is delivering the first message to the computer whose number you now know.
4. The Three Round Trips Needed to Start Talking to a Website
Once the number is known, a connection is made. First, a greeting like "Hello" and "Yes" (TCP) takes 1 round trip. Actually, this greeting involves aligning the numbers both sides will use [5]. Next, for https pages, encryption methods and keys are decided (TLS). Until TLS 1.2, this took 2 round trips. With TLS 1.3 in 2018, the arrangement for new connections became 1 round trip [6][7].
Only then can you send the request (HTTP) saying "Please give me this page." It takes another 1 round trip until the first byte of the reply returns. For a first connection from Tokyo to Los Angeles, the breakdown of lower limits is: TCP connection (1 round trip, ~88 ms), TLS 1.3 arrangement (1 round trip, ~176 ms in total so far), and HTTP request plus first byte (1 round trip, ~264 ms in total).
5. Why One Web Page Means Dozens of Files to Download
The first thing returned is usually one HTML file. Inside it, references to other files are written: CSS for appearance, JavaScript for movement, images, and font designs. The browser reads the HTML and requests these additional files.
In a July 2025 survey by HTTP Archive, the median number of requests per page was 77 for computers and 72 for smartphones. JavaScript files were the most common [8]. In HTTP/1.1, multiple connections to the server were created to fetch many things at once [9]. Each new connection requires the greetings from the previous section (though reused connections are possible). HTTP/2 (RFC 9113, 2022) allowed multiple exchanges to happen simultaneously over a single connection [9]. There is also an order barrier: until the HTML arrives, you don't know which files are needed. Browsers have a "preload scanner" to find and request files ahead of time [10]. Still, dozens of requests hit the wall of round trips. How is this waiting reduced?
6. How TLS 1.3, QUIC, and Nearby Copies Cut Down Round Trips
The speed of light cannot be changed. So, efforts have been made to reduce the number of round trips and the distance of each trip. One way to reduce trips is TLS 1.3, which cut new connection arrangements from 2 to 1 round trip. For previous connections, 0-RTT allows sending encrypted data with the first message. However, this has a weakness: if the first data is captured and replayed, there is no guarantee against that. The standard notes this as a trade-off for performance [6][7].
QUIC combines the TCP connection establishment and TLS 1.3 arrangement into one, speeding up connection setup [12]. Google started it as an experiment in 2013 [13], and the IETF standardized it as RFC 9000 in 2021 [11]. It is built on UDP, not TCP, to make it easier to spread to existing devices and networks [11]. HTTP/3 (RFC 9114, 2022) runs HTTP over QUIC. HTTP/2 uses one TCP connection, so if one packet is lost, unrelated exchanges stop. QUIC handles exchanges separately, avoiding these stops [14].
Another trick is shortening distance. A CDN places copies of content on servers around the world, so a nearby server answers. Since delay increases with distance, a nearby server makes round trips cheaper [15]. If a copy is in Tokyo or Osaka, the round trip is in the few milliseconds range from the Chapter 2 calculation. But just receiving data doesn't draw the picture. How does the browser assemble it?
7. How the Browser Turns Received Data into a Screen
The received bytes are not yet a screen. The browser reads HTML to create the page structure (DOM) and CSS to create appearance rules (CSSOM). It combines these to create a drawing tree, then calculates size and position (layout), and finally paints it to the screen [10].
HTML parsing starts as soon as data arrives, without waiting for everything. While waiting for CSS, HTML parsing and downloading continue, but normal JavaScript execution is paused [10]. Layout may be recalculated if images arrive late [10]. The LCP measure from Chapter 1 records the time when the largest part of this assembled page becomes visible [2]. Returning to the start: for a new host, it takes 3 round trips (excluding DNS) to get the first byte. Files from the same host can reuse the connection. The 1 second to view a page includes both these round trips and the browser's assembly work.
8. How to See a Page's Round Trips in the Network Tab
You can see the page's round trips in the browser's developer tools. Open the "Network" tab and reload the page. Do this together with someone at home.
Look at the timing. Select one file and view "Timing." You will see separate displays for DNS lookup, connection (including TCP and TLS greetings), and waiting for the server's reply [16]. Check which fields get shorter or disappear when you open the page a second time. Some of the round trips counted in this article may vanish.
For safety, network records may contain login information. Do not post screenshots of the screen on social media or export the records to files and give them to others.