# What Happens in the First 100 Milliseconds of a Page Load

When a user presses Enter, the browser instantly triggers a high-stakes, microscopic relay race across the globe. Within the first 100 milliseconds, the application translates a human-readable web address into a numerical IP, establishes a reliable transport connection, negotiates military-grade encryption, and receives the foundational HTML document from a remote server. This invisible marathon relies on multi-tiered caching, the absolute physical limits of fiber optic transmission, and geographic content distribution networks to outpace the limits of human perception.

Imagine attempting to call a colleague on the other side of the planet to request a specific document. Before a single word can be spoken, one must look up their precise phone number in a globally distributed, multi-layered directory, shake hands with three different telecommunications operators to ensure the line is stable, agree upon a secret cryptographic language, and verify the recipient's identity using a digital notary. In the physical world, this administrative overhead would consume minutes. On the modern web, this entire sequence—involving electromagnetic signals bouncing off submarine cables and navigating highly complex server infrastructure—is routinely executed in the time it takes a human eye to blink. This report provides an exhaustive, millisecond-by-millisecond dissection of this extraordinary digital event, exploring the fundamental mechanics, physical limitations, and cutting-edge optimizations that govern the modern internet.

## What Exactly Happens When You Press Enter?

The journey begins the exact moment a user submits a Uniform Resource Locator (URL) into the browser's address bar. To the human user, a URL such as `https://example.com/page` is a simple, memorable destination. To the browser, however, it is a strict, programmatic set of instructions detailing the exact protocol to use (`https`), the specific domain entity to contact (`example.com`), and the exact path of the resource being requested (`/page`) [cite: 1, 2, 3]. This may seem straightforward, but at this initial stage, the browser possesses clear rules for communication but lacks the actual physical location of the server. 

The internet does not route traffic based on alphabetical domain names; it relies on Internet Protocol (IP) addresses. The process of translating a human-readable domain name into a machine-routable IP address is handled by the Domain Name System (DNS). The DNS functions as the internet's master contact list [cite: 4, 5]. Just as an individual might scroll through a smartphone to find a friend's phone number without ever needing to memorize the digits, the browser queries the DNS infrastructure to find the server's numeric location [cite: 4]. 

Because querying a global database for every single web request would introduce crippling latency, the DNS resolution system relies on an aggressive, multi-layered caching strategy designed to resolve the query locally whenever possible [cite: 4, 5]. 

The browser first checks its own internal DNS cache, maintaining a repository of records for websites visited recently [cite: 4]. If the IP address is not found locally, the browser issues a system call (such as `gethostname` on Windows environments) to the underlying operating system [cite: 4]. The operating system maintains its own separate cache of DNS records. If the operating system also lacks the record, the request moves outward to the local network router's cache, and subsequently to the Internet Service Provider's (ISP) DNS server, known as the DNS recursor [cite: 4, 5]. 

Only when all of these local and regional caches fail does a full, recursive DNS query occur. In this worst-case scenario, the DNS recursor must contact the root name server, which redirects it to the appropriate Top-Level Domain (TLD) server (such as the `.com` name server), which in turn directs the query to the authoritative name server for the specific domain [cite: 4]. The authoritative name server retrieves the matching IP address from its records and routes it back through the chain to the user's browser [cite: 4]. In a highly optimized scenario where the user frequently visits the site, this DNS resolution is completed entirely from the local browser cache in well under a single millisecond. However, if a full network lookup is required, it typically adds tens or even hundreds of milliseconds to the timeline, depending on the geographic proximity of the ISP's resolver and the authoritative servers [cite: 6, 7].

## Why Does It Take So Many Steps to Say Hello?

Once the browser possesses the target IP address, it cannot simply begin downloading the webpage payload. It must first establish a reliable, secure line of communication. Before any application data can be transmitted, the client and server must execute two distinct, sequential negotiations: the Transmission Control Protocol (TCP) handshake and the Transport Layer Security (TLS) handshake [cite: 5, 7, 8, 9].

[image delta #1, 0 bytes]



The TCP handshake ensures that both the client and the destination server are present on the network, ready, and capable of exchanging data reliably without loss. This is fundamentally a three-step process universally known as the SYN, SYN-ACK, ACK sequence [cite: 5, 7]. The client machine initiates the process by sending a synchronization (SYN) packet to the server over the internet, inquiring if the server has open ports available to accept a new connection [cite: 5]. If the server is active and possesses available capacity, it responds with an acknowledgment of the SYN packet alongside its own synchronization request, combined into a single SYN-ACK packet [cite: 5]. Finally, the client receives the SYN-ACK packet and acknowledges it by sending a final ACK packet back to the server [cite: 5, 6]. This back-and-forth negotiation requires one full network round-trip time (1-RTT) before the transport layer is considered open.



Immediately following the TCP connection setup, the browser initiates the TLS handshake. This phase is mandatory for securing the connection. Without Transport Layer Security, all web traffic—including API calls, HTML documents, session tokens, and passwords—would be transmitted over the public internet in plain text, rendering it entirely vulnerable to interception and tampering [cite: 10, 11]. The TLS handshake acts as an intricate negotiation where the client and server agree on a specific version of the protocol, decide upon a mutually supported cipher suite, authenticate the server's identity via public key cryptography and digital certificates, and ultimately generate symmetrical session keys for encrypting the subsequent data transfer [cite: 8].

Historically, under the ubiquitous TLS 1.2 standard finalized in 2008, this cryptographic negotiation was prolonged and resource-intensive, requiring two complete round trips (2-RTT) [cite: 10, 11, 12, 13]. First, the client would send a "Client Hello" message detailing its supported TLS versions and cipher suites, alongside a string of random bytes known as the "client random" [cite: 8, 12]. The server would respond with a "Server Hello," selecting a cipher suite and providing its digital certificate [cite: 8, 12]. Then, the client and server would execute a secondary exchange of key information in a subsequent round trip before encrypted application communication could finally commence [cite: 10, 12]. This added significant latency to the connection setup, effectively doubling the time spent establishing the network link.

The deployment of TLS 1.3—finalized by the Internet Engineering Task Force (IETF) in August 2018 under RFC 8446—fundamentally revolutionized this process, bringing massive advancements in both speed and security [cite: 10, 11, 12, 13]. TLS 1.3 consolidates the initial handshake and the negotiation of cryptographic parameters into a single round trip (1-RTT) [cite: 10, 11, 12]. The protocol achieves this by having the client proactively send its key share guesses alongside the initial "Client Hello" [cite: 14]. The server receives the client random and the parameters, instantly creates the master secret, and replies with a "Server Hello" that includes the server's certificate and a "Finished" message [cite: 8]. This architectural overhaul reduces handshake latency by approximately 50%, saving hundreds of milliseconds on distant connections and resulting in noticeably faster, highly-responsive HTTPS experiences [cite: 10, 13, 14].

Furthermore, TLS 1.3 enhances security by ruthlessly eliminating outdated, vulnerable cryptographic algorithms (such as RC4, DES, MD5, and SHA1) and enforcing Forward Secrecy, ensuring that past communications remain secure even if a server's private key is compromised in the future [cite: 11, 12]. 

| Protocol Feature | TLS 1.2 Specification | TLS 1.3 Specification | Performance & Security Impact |
| :--- | :--- | :--- | :--- |
| **Handshake Round Trips** | 2-RTT (Two Round Trips) | 1-RTT (One Round Trip) | Cuts connection setup time by 50%, significantly reducing TTFB and network overhead [cite: 10, 12, 13]. |
| **Cipher Suites** | Supports hundreds of combinations, including weak, vulnerable legacy algorithms [cite: 11, 12]. | Only supports Authenticated Encryption with Associated Data (AEAD) [cite: 11, 12]. | Reduces the attack surface and eliminates computational overhead associated with negotiating older cipher suites [cite: 10, 12]. |
| **Forward Secrecy** | Optional [cite: 11, 12]. | Mandatory [cite: 12]. | Ensures past traffic cannot be decrypted even if the server's primary private key is later compromised [cite: 12]. |
| **Session Resumption** | Requires handshake negotiation [cite: 12]. | 0-RTT (Zero Round Trip Time) [cite: 10, 11, 12]. | Allows returning clients to send encrypted data immediately without waiting for a handshake, reducing delay to zero [cite: 10, 12]. |
| **Version Negotiation** | Present [cite: 11]. | Removed [cite: 11]. | Prevents malicious downgrade attacks by forcing modern, secure protocol standards [cite: 11]. |

Perhaps the most aggressive optimization introduced by TLS 1.3 is the provision for 0-RTT (Zero Round-Trip Time) resumption [cite: 10, 11, 12]. If a user returns to a previously visited server, the client and server can utilize retained session keys from the prior connection [cite: 10, 11]. This allows the client to send encrypted application data immediately upon reconnection, without waiting for the server to properly verify the client's identity through a full handshake [cite: 10, 11]. While 0-RTT resumption requires careful implementation to mitigate the risk of replay attacks, it effectively drops the connection setup latency to zero, enabling instantaneous data exchange for repeat visitors [cite: 10, 12, 13].

## What is the Difference Between Bandwidth and Latency?

When assessing why network handshakes dictate so much of the initial loading timeline, it is crucial to address the most pervasive misconception in computer networking: the conflation of bandwidth and latency. Internet service providers frequently market higher bandwidth as "faster internet," leading everyday consumers to believe that upgrading from a 100 Mbps broadband connection to a 1 Gbps fiber connection will instantly result in faster page load times. In reality, bandwidth and latency measure entirely different physical network phenomena [cite: 15, 16, 17, 18]. Both are vital to user experience, but their relative significance varies drastically depending on the specific networking task [cite: 15].

A highly accurate, real-world analogy compares network infrastructure to a physical highway system [cite: 16, 18]. Bandwidth dictates the width of the highway—the total number of lanes available for traffic [cite: 16]. Often measured in megabits per second (Mbps) or gigabits per second (Gbps), bandwidth defines the maximum volume of data that can be transferred over a network connection in a given period [cite: 16, 18]. A wider highway (higher bandwidth) allows more cars (data packets) to travel side-by-side simultaneously, supporting more simultaneous transmissions and reducing overall congestion [cite: 16]. If a user needs to download a massive 50-gigabyte high-definition video game or stream a 4K movie, a high-bandwidth connection is essential because it allows immense volumes of data to pass through the network infrastructure concurrently.

Latency, however, is the speed limit of that highway [cite: 17]. It measures the raw physical time it takes for a single car (a packet of data) to travel from the source (Point A) to the destination (Point B) [cite: 16, 18]. Upgrading bandwidth adds more lanes to the highway, but it does absolutely nothing to increase the speed limit of the vehicles traveling upon it [cite: 17]. Once a data packet hits the physical wire, it travels at a fixed speed governed entirely by the physical properties of the transmission medium and the laws of physics [cite: 17]. 

Because the initial 100 milliseconds of a webpage load primarily consist of tiny, sequential requests—DNS lookups, tiny SYN packets, and kilobytes of TLS certificates—the total volume of data being exchanged is minuscule. Thus, bandwidth is largely irrelevant in the first 100 milliseconds of connection setup. Latency, rather than bandwidth, is the sole performance bottleneck [cite: 19].

Furthermore, standard transmission protocols like TCP inherently struggle with high latency. TCP is an acknowledged protocol, meaning the sender must receive an acknowledgment (ACK) from the receiver before it can confidently send more data through the pipe [cite: 17]. High latency elongates this back-and-forth acknowledgment process, slowing down overall throughput and making it exceedingly difficult to fully utilize a high-bandwidth connection during the early phases of a data transfer [cite: 17].

### The Speed of Light Limit

The ultimate, unyielding governor of network latency is the speed of light. As outlined by Albert Einstein's theory of special relativity, the speed of light is the maximum speed at which all energy, matter, and information can travel across the universe [cite: 19]. In a perfect vacuum, light travels at an absolute speed limit of exactly $c = 299,792,458$ meters per second (approximately 186,282 miles per second) [cite: 19]. This fundamental observation places a hard, physical limit—a cosmic governor—on the minimum possible propagation time of any network packet [cite: 19]. 

However, internet traffic does not travel through a perfect vacuum. The backbone of global communications relies on thousands of miles of submarine and terrestrial fiber-optic cables [cite: 19]. Inside an optical fiber, light propagates through a core made of highly purified silica glass [cite: 20, 21]. This dense medium slows the light down due to its refractive index, which is typically around $n = 1.468$ for standard single-mode optical fibers [cite: 20]. The speed of light through this medium ($v$) is calculated by dividing the speed of light in a vacuum ($c$) by the refractive index of the glass ($n$):

$v = \frac{c}{n}$

Using an average refractive index of 1.45 to 1.47, the speed of light inside a fiber optic cable is reduced to approximately $204,218$ to $206,265$ kilometers per second [cite: 20, 21, 22]. This equates to about 68% of the speed of light in a vacuum [cite: 20]. Consequently, it takes a photon of light roughly 4.9 to 5.0 microseconds to traverse a single kilometer of fiber optic cable [cite: 22].

[image delta #2, 0 bytes]

 



This places a hard physical floor on internet performance that no amount of software optimization can bypass. For instance, the geodesic distance between Shanghai and New York is approximately 12,000 kilometers [cite: 20]. However, fiber routes are rarely perfectly straight. Submarine cables must zigzag to accommodate terrestrial topology, avoid active fault lines, and connect to strategic underwater repeaters and landing stations, resulting in an estimated actual cable length closer to 15,000 kilometers [cite: 20]. At roughly 5 microseconds per kilometer, a single pulse of light requires approximately 73.4 milliseconds just to make the one-way journey [cite: 20]. Therefore, the absolute physical minimum round-trip time (RTT) across this specific route is nearly 150 milliseconds [cite: 20].

## How Does Geographic Distance Alter the Timeline?

In practice, the theoretical propagation speeds calculated from raw fiber optics represent an impossible, frictionless ideal. As data packets travel from the client machine to the destination server, they do not remain safely nestled within a single, uninterrupted fiber line [cite: 19]. Instead, they must pass through numerous network intersections known as hops, navigating complex routing equipment, hardware firewalls, internet exchange points (IXPs), and undersea cable landing stations [cite: 15, 16, 19, 23]. 

Each time a packet enters an intermediate router, it incurs a series of inevitable hardware and processing penalties. First, the router must execute processing delay, reading the packet header to determine its correct destination [cite: 19]. If the network is experiencing high traffic volumes, the packet is placed into an incoming buffer, incurring queuing delay [cite: 15, 19]. Finally, the router must push the packet back onto the outbound wire, adding transmission delay [cite: 19]. Every packet traveling over the network will incur multiple instances of each of these delays, compounding rapidly over long distances [cite: 19]. Consequently, while the theoretical round-trip time governed by the speed of light from Shanghai to New York is roughly 150 milliseconds, real-world network latency usually measures between 200 and 250 milliseconds [cite: 20].

These geographic disparities fundamentally alter the user experience and dictate the baseline performance of any digital platform. Physical infrastructure, such as the location of servers and the length of undersea cables connecting a specific region, directly determines latency [cite: 24]. For example, the Middle East and North Africa (MENA) region possesses fewer hyper-scale server farms compared to Europe, forcing users in areas like the UAE to connect to European infrastructure, resulting in inherently slower baseline loading times due to the sheer physical distance the data must travel [cite: 24].

Consider the variations in global network latency when connecting from different origin points. Telecommunications infrastructure providers like Verizon and Zenlayer constantly measure the latency of core areas of their networks. 

| Route Origin | Route Destination | Average Round-Trip Time (RTT) | Context |
| :--- | :--- | :--- | :--- |
| **New York, USA** | **London, UK** | ~70 – 75 ms | Transatlantic fiber routes generally support excellent latency profiles, maintaining rapid connection speeds between financial hubs [cite: 25, 26]. |
| **New York, USA** | **Tokyo, Japan** | ~168 – 171 ms | The sheer distance across the Pacific Ocean drives baseline latency significantly higher [cite: 25, 26]. |
| **São Paulo, Brazil** | **Frankfurt, Germany** | ~180 – 185 ms | Traffic from South America to European servers incurs heavy physical distance penalties due to submarine routing paths [cite: 27, 28]. |
| **London, UK** | **Paris, France** | ~10 ms | Intra-European routing benefits from dense, highly localized terrestrial fiber infrastructure [cite: 25]. |

When combined with the sequential nature of a network connection, these geographic penalties compound aggressively. If a user in São Paulo attempts to connect to a server in Frankfurt (roughly 180 milliseconds RTT), the browser must complete the TCP handshake (1 RTT) and a legacy TLS 1.2 handshake (2 RTT) before it can even send the HTTP request [cite: 10, 27]. This means three complete round trips—totaling a massive 540 milliseconds—are wasted solely on connection setup before a single byte of actual webpage content is delivered [cite: 9, 29]. On a high-latency connection, making these network round trips creates a performance bottleneck that will cripple user engagement, as research consistently shows that delays of even half a second can result in a 20% decline in traffic [cite: 9, 14].

## How Do Content Delivery Networks (CDNs) Cheat Geography?

If the speed of light places a hard physical limit on data transmission, and network routers introduce unavoidable processing delays, the only viable way to reduce latency is to physically shorten the distance between the end-user and the requested data [cite: 19]. This physical distance reduction is the explicit purpose of a Content Delivery Network (CDN) [cite: 23]. 

A CDN is an extensive, globally distributed network of servers strategically positioned in data centers across the world, heavily concentrating on high-traffic metropolitan areas and Internet Exchange Points (IXPs) [cite: 23]. IXPs are the primary physical locations where different internet service providers link their networks together [cite: 23]. Rather than forcing a user in New York to fetch website data from an origin server located in Singapore—a staggering physical journey of over 9,520 miles that requires multiple hops and oceanic crossings—the CDN circumvents this bottleneck by caching copies of the website's static assets (such as HTML, CSS, JavaScript, and images) on localized edge servers situated right in Manhattan [cite: 23, 30]. 

When the New York user requests the webpage, the DNS resolves the request to the nearest CDN edge node rather than the distant origin server [cite: 30]. By intercepting the request locally, a well-configured CDN routinely delivers a Time to First Byte (TTFB) of under 100 milliseconds globally [cite: 27]. In the case of the New York-to-Singapore connection, fetching the content from a local edge node can eliminate over 1,900 milliseconds of transit time over the course of loading a full page, drastically reducing the total latency profile [cite: 23]. 

Beyond mere caching, modern CDNs provide advanced protocol optimizations and server-side infrastructure enhancements that origin servers frequently lack. CDN performance optimizations operate on several distinct levels to actively shrink the 100-millisecond timeline [cite: 23, 27]:

1. **Edge TLS Termination & Connection Reuse:** A modern CDN terminates the TLS connection close to the user at the edge node [cite: 27]. This means the user's browser only needs to perform the TCP and TLS handshakes with a server located a few miles away, dropping the handshake latency from hundreds of milliseconds to under 20 milliseconds [cite: 27, 31]. Furthermore, the CDN maintains persistent, warm connections (often called an origin shield) back to the main origin server, entirely eliminating the need for a three-way TCP handshake or a TLS handshake on the CDN-to-Origin leg of the journey [cite: 27]. 
2. **HTTP/3 and QUIC Implementation:** CDNs are at the forefront of adopting the next-generation HTTP/3 protocol, which utilizes the QUIC transport layer rather than traditional TCP [cite: 27, 29]. QUIC fundamentally alters the connection paradigm by combining the transport layer handshake and the TLS cryptographic handshake into a single round trip by default [cite: 29]. For returning visitors, QUIC supports native 0-RTT connection resumption, allowing clients to send data immediately without waiting for any handshake to complete, shaving crucial milliseconds off the initial connection [cite: 27, 29]. As of 2026, Chrome telemetry indicates that over 62% of CDN-served requests utilize QUIC [cite: 27].
3. **Reduced Data Transfer Payload:** CDNs employ aggressive techniques to shrink file sizes so that initial page loads occur rapidly [cite: 23]. They utilize automated minification—the process of removing unnecessary whitespace, comments, and formatting from code blocks without altering functionality—to reduce the payload [cite: 23]. Furthermore, CDNs automatically apply robust file compression algorithms, such as GZip or Brotli, which routinely reduce file sizes by 50% to 70% before transferring them across the internet, simultaneously lowering bandwidth consumption and reducing transmission latency [cite: 23].

However, CDNs are not a panacea for all performance issues. Adding a massive global network designed to speed up web traffic can paradoxically slow down a website if the configuration is flawed [cite: 30]. If a local business relies on an audience located entirely within a 20-mile radius of its host server, introducing a global CDN forces the visitor's browser to perform an extra DNS lookup to resolve the CDN's address, and the request might be routed through an edge node that is geographically further away than the actual origin server [cite: 30]. Furthermore, for highly dynamic, non-cacheable content, the CDN must still connect to the origin server to fetch the resource, which can occasionally increase server processing time if not paired with advanced routing optimizations like Cloudflare's Argo Smart Routing [cite: 27, 31, 32, 33].

## The First 100 Milliseconds: A Step-by-Step Breakdown

To fully contextualize the blistering speed of this invisible marathon, consider a highly optimized, hypothetical scenario. A user located in London navigates to a modern, well-architected website hosted behind a global CDN with an edge server physically located in the same city. The user relies on a fast fiber-to-the-premises broadband connection, yielding a very low local latency of around 15 milliseconds RTT to the edge server.

| Elapsed Time | Request Phase | Technical Action | Description of the Micro-Timeline |
| :--- | :--- | :--- | :--- |
| **0 ms** | User Input | Key Press | The user presses "Enter" on their keyboard to navigate to `https://example.com`. |
| **1 ms** | URL Parsing & Cache Check | Browser Internal | The browser parses the URL, recognizing the HTTPS protocol, and queries internal browser and local operating system DNS caches. |
| **2 ms** | DNS Resolution | Cache Hit | The local ISP cache returns the IP address for the CDN edge node instantly, successfully avoiding a full recursive global lookup across authoritative servers. |
| **2 ms – 10 ms** | TCP Handshake (SYN) | Network Transit | The browser dispatches a TCP SYN packet. It travels through local fiber optic lines, incurring minimal propagation delay to reach the London edge server. |
| **10 ms – 17 ms** | TCP Handshake (SYN-ACK) | Network Transit | The edge server receives the SYN, verifies available ports, and fires back a SYN-ACK packet. |
| **17 ms** | TCP Established (ACK) | Client Processing | The browser sends the final ACK packet. The TCP connection is formally established and reliable transport is secured. |
| **17 ms – 25 ms** | TLS 1.3 Handshake (Client Hello) | Network Transit | The browser immediately initiates encryption by sending a "Client Hello," its supported cipher suites, and key share guesses. |
| **25 ms – 32 ms** | TLS 1.3 Handshake (Server Hello) | Network Transit | The server responds with its certificate and a "Finished" message. The secure tunnel is established in a single RTT. |
| **32 ms – 40 ms** | HTTP Request | Network Transit | The browser dispatches the `GET / HTTP/1.1` request for the foundational HTML document. |
| **40 ms – 45 ms** | Server Processing | Edge Compute | The CDN edge server receives the request, identifies a cache hit, and instantly prepares the HTML response for transmission. |
| **45 ms – 52 ms** | Response Transit | Network Transit | The first chunks of the encrypted HTML response are transmitted back to the client over the fiber network. |
| **52 ms** | TTFB Achieved | Browser Internal | The browser receives the very first byte of data. The connection phase ends; the rendering phase begins. |
| **53 ms – 100 ms** | HTML Parsing & Early Requests | Critical Rendering Path | The browser begins parsing the HTML Document Object Model (DOM), identifies linked CSS and JavaScript, and dispatches early fetch requests. |

*Note: This timeline represents a highly optimal scenario utilizing localized DNS caching, a geographically proximate CDN edge node, and the modern TLS 1.3 standard. For international, non-cached requests navigating legacy protocols, this exact sequence can easily expand past 1,000 milliseconds.*

## Why Do Browsers Still Feel Slow If the Connection Is Fast?

The critical milestone reached at the 52-millisecond mark in the table above is formally known as the Time to First Byte (TTFB). TTFB is a foundational web performance metric that measures the precise time elapsed between the navigation start and the exact moment the first byte of the HTTP response arrives from the server [cite: 34]. Mathematically, TTFB is the sum of the redirect time, the DNS lookup duration, the TCP connection, the TLS negotiation, the request transit time, and the origin server's processing time [cite: 7, 34, 35].

Because TTFB precedes user-centric rendering metrics, it is an essential indicator of connection setup efficiency and web server responsiveness. Industry guidelines dictate that a good TTFB score should be 0.8 seconds or less, with highly optimized sites aiming for values between 200 and 500 milliseconds [cite: 34, 35]. If a TTFB turns out to be higher than 500 milliseconds, it generally indicates severe issues such as high latencies between global DNS servers, extreme load on the origin web server, or inefficient database queries delaying the page download [cite: 35].

However, while a fast TTFB is an absolute prerequisite for a fast website, it does not mean the user actually sees anything on their screen [cite: 34, 35]. The TTFB only indicates that the server has *begun* talking back. The server response time may be swift—comprising only a fraction of the overall TTFB—but if the HTML document it subsequently delivers is bloated with unoptimized code, heavy layout shifts, and massive render-blocking scripts, the user will still experience a sluggish, frustrating load [cite: 9, 36]. A large delta between the TTFB and the Time to Last Byte (TTLB) often points to geographic distance issues decreasing throughput, or unoptimized asset delivery [cite: 35]. When the first byte arrives, the real work of the browser—transforming dense raw code into visual pixels—has only just begun.

## What Role Do Ad-Blockers Play in the First 100 Milliseconds?

A major variable altering modern web performance within the first 100 milliseconds is the presence of third-party browser extensions, particularly content and ad-blockers. Extensions fundamentally modify how the browser processes incoming data and constructs the webpage, leading to a complex industry debate regarding the overhead they introduce versus the ultimate performance benefits they provide.

To interact with a web page, an extension must programmatically inject a "content script" [cite: 37, 38]. Content scripts are JavaScript files that run in the context of the webpages the browser visits [cite: 38]. Crucially, content scripts operate in "isolated worlds"—private execution environments that prevent their JavaScript variables from conflicting with the host page or other extensions' content scripts, a security measure originally introduced with the initial launch of Google Chrome [cite: 37]. 

This injection process inherently incurs a performance penalty. The browser must create a new V8 JavaScript execution context and run the extension's code alongside the page's native code [cite: 39]. Depending on how the extension is programmed and defined in its manifest file, this script injection can occur at `document_start` (before any CSS is processed or the DOM is constructed) or at `document_idle` (the default setting, occurring after the page has finished loading and the DOM is ready) [cite: 37, 38].

When tracking the absolute first 100 milliseconds of a page load, content scripts injected at `document_start` do add microscopic but measurable delays. Testing reveals that the setup cost of extension bindings and isolated worlds can add tens of milliseconds to the initial parsing phase [cite: 39]. This is especially detrimental because creating iframes—which are ubiquitous in digital advertising—forces the browser to miss rendering frames if content scripts must be injected into every nested frame [cite: 39]. Furthermore, poorly optimized extensions, particularly certain AI writing tools, password managers, or shopping assistants, run heavy synchronous code on every single page view, causing immense CPU processing delays of up to 1.5 to 2.3 seconds, completely ruining the initial load experience [cite: 40, 41].

However, well-engineered ad-blockers like uBlock Origin and Ghostery represent a unique paradigm in the browser ecosystem: they are extensions that actively *remove* functionality and network requests from the web page rather than adding to it [cite: 40, 41]. The internal processing efficiency of modern ad-blockers is staggering. Benchmarks show that sophisticated content-blockers evaluate network requests against tens of thousands of complex filter rules with a median decision time of less than 0.01 milliseconds per request [cite: 42]. For instance, Ghostery's blocking engine processes a request in a median time of 0.007 milliseconds, making it significantly faster than legacy blockers [cite: 42].



The microscopic, sub-millisecond overhead required to boot the ad-blocker is instantly dwarfed by the massive resource savings it provides [cite: 42, 43]. A typical modern news website triggers hundreds of network requests upon loading, downloading megabytes of third-party trackers, external advertising JavaScript libraries, and unoptimized high-resolution media [cite: 44]. Loading 119 popular news websites in the United States requires an astounding 35,603 network requests and consumes 689 megabytes of bandwidth [cite: 44]. 

By intercepting and blocking these requests at the network level, an ad-blocker prevents the browser from ever needing to open dozens of extraneous TCP connections, perform dozens of secondary TLS handshakes, and execute megabytes of render-blocking JavaScript [cite: 9, 45].

[image delta #3, 0 bytes]

 

| Performance Metric | Without Ad-Blocker (Baseline) | With uBlock Origin | Impact of Ad-Blocker |
| :--- | :--- | :--- | :--- |
| **Total CPU Processing Time** | ~57.0 seconds | ~4.0 seconds | Reduces processing time by preventing the execution of complex JavaScript ad logic and tracking scripts [cite: 40, 41]. |
| **Page Weight (Bandwidth)** | ~41.0 Megabytes | ~3.0 Megabytes | Slashes bandwidth consumption by dropping high-resolution ad media and third-party libraries [cite: 40, 41]. |
| **DOM Size & Styling Overhead** | Tens of thousands of dynamic nodes and CSS rules. | Streamlined, native DOM structure. | Legacy blockers like AdBlock Plus inject upwards of 14,000 CSS rules, causing massive CPU spikes; uBlock Origin avoids this, hiding elements 2 to 3 times faster [cite: 46]. |
| **Average Load Time (News Sites)** | 11.3 seconds | 6.2 seconds | Decreases the total load time by 45%, saving the average user an estimated two days of loading time annually [cite: 44]. |

Not all ad-blockers offer the same efficiency. AdBlock Plus, while popular, relies on older technology that carries a heavier drain on system resources, particularly memory, because it injects massive stylesheets to hide acceptable ads [cite: 46, 47]. Conversely, uBlock Origin utilizes a streamlined codebase with advanced filtering options that require significantly less RAM and CPU time to process the same lists [cite: 43, 46, 47, 48]. Ultimately, while an ad-blocker technically interrupts the very first milliseconds of script execution, it proactively clears the network highway of congestion, allowing the rest of the critical webpage to assemble exponentially faster [cite: 45, 49].

## How Does the Browser Paint the Screen?

As the first chunks of HTML data stream into the browser—perhaps just 60 to 80 milliseconds after the user pressed Enter—the browser kicks off the Critical Rendering Path (CRP) [cite: 50, 51]. The CRP is the highly complex sequence of steps the browser engine must execute to convert raw HTML, CSS, and JavaScript into the actual colored pixels that form a visual, interactive webpage on the user's screen [cite: 51]. The efficiency and speed at which the browser navigates the CRP directly determines critical user-centric performance metrics like First Contentful Paint (FCP), Largest Contentful Paint (LCP), and Time to Interactive (TTI) [cite: 50, 52].

The Critical Rendering Path consists of several distinct, interdependent phases:

1. **Document Object Model (DOM) Construction:** The browser reads the incoming HTML byte by byte. It tokenizes the data (identifying `startTag` and `endTag` tokens) and converts these tokens into nodes [cite: 51]. Every `<div>`, `<p>`, and `<img>` tag becomes a node containing relevant information about the HTML element [cite: 51]. These nodes are then connected into a hierarchical tree structure known as the DOM Tree [cite: 51]. The greater the number of nodes, the longer this parsing event takes, heavily impacting subsequent rendering steps [cite: 51].
2. **CSS Object Model (CSSOM) Construction:** Simultaneously, as the browser encounters links to Cascading Style Sheets (CSS), it dispatches network requests to fetch them and builds a parallel tree structure called the CSS Object Model (CSSOM) [cite: 51]. Because CSS dictates the visual layout and style of the page, it is fundamentally "render-blocking" [cite: 36, 50]. The browser will halt rendering and wait until the CSSOM is completely constructed [cite: 51]. If the browser painted the text before the CSS arrived, the user would experience a jarring "Flash of Unstyled Content" (FOUC), where a chaotic, unformatted wall of text suddenly snaps into a styled layout moments later. 
3. **The Render Tree:** Once both the DOM and CSSOM exist, the browser engine combines them into the Render Tree [cite: 51]. The Render Tree acts as a rigorous filter; it only captures content that will actually be visible on the screen [cite: 51]. The `<head>` section is excluded, and if a developer has applied a CSS rule of `display: none;` to a specific element, the browser intelligently excludes that element and all of its nested descendants from the Render Tree entirely, saving computational power [cite: 51].
4. **Layout (Reflow):** With the Render Tree finalized, the browser proceeds to the Layout phase (often called "Reflow" in certain browser engines) [cite: 51]. The layout engine calculates the exact geometric coordinates and dimensions of every single element in relation to the size of the viewport [cite: 51]. It determines that a sidebar takes up 20% of the viewport width, calculates the height of a text block based on the font size and line-wrapping, and stacks elements according to their margins and padding [cite: 51]. This is a computationally intensive mathematical process. Any time the Render Tree is modified—such as by added nodes, updated box models, or a user rotating their mobile device from portrait to landscape—the browser must instantly discard the old layout and trigger a reflow to recalculate the geometry for the entire page [cite: 51].
5. **Paint and Composite:** Finally, the browser arrives at the Paint stage [cite: 51]. Having calculated exactly where every element belongs geographically, the browser converts these geometric models into actual pixels on the screen [cite: 51]. It fills in background colors, renders text shadows, and draws borders [cite: 51]. Only at this point—which may occur 150 to 300 milliseconds after hitting Enter on an optimized site—does the user finally perceive that the website has loaded, achieving the First Contentful Paint (FCP) [cite: 50].

To optimize the Critical Rendering Path and ensure the browser paints the screen as early as possible, developers must minimize render-blocking resources [cite: 50]. This involves adopting code-splitting, deferring non-critical JavaScript, inlining critical CSS directly into the HTML `<head>`, and specifying explicit widths and heights for images to prevent chaotic Cumulative Layout Shifts (CLS) [cite: 50, 52]. Furthermore, utilizing resource hints like `preload` for key fonts or `preconnect` to important third-party origins ensures the browser anticipates required assets before it parses the entire DOM, keeping the rendering engine continuously fed with data [cite: 52].

## Bottom Line

The first 100 milliseconds of a web page load represent a staggering, microscopic orchestration of global network infrastructure, advanced quantum physics, and local software engineering. The process begins with a rapid, multi-tiered DNS lookup to translate a URL into an IP address, relying heavily on browser and ISP caches to avoid global routing delays. Because network latency is strictly and unyieldingly governed by the speed of light within silica glass fiber optic cables, physical geographic distance remains the ultimate performance bottleneck. This physical constraint mandates the use of global Content Delivery Networks (CDNs) to cache data locally, proxy connections, and shrink the physical journey of a packet.

Before any functional content is transmitted, the client and server must execute sequential handshakes to ensure reliable transport (TCP) and secure cryptography (TLS). The industry-wide shift to the modern TLS 1.3 protocol has dramatically compressed this setup time, enabling single-round-trip and even zero-round-trip encryption for returning visitors. Once the secure connection is open, the server's Time to First Byte (TTFB) signals the arrival of the HTML payload, allowing the browser to begin the computationally intense Critical Rendering Path—constructing the DOM, calculating layout geometry, and painting pixels. While third-party browser extensions like ad-blockers do inject a microscopic processing overhead into this early timeline, their ability to intercept megabytes of unoptimized network bloat drastically accelerates the final visual rendering of the page, proving that the fastest data is the data that never has to be downloaded at all.

**Sources:**
1. [amazon.com](https://vertexaisearch.cloud.google.com/grounding-api-redirect/AUZIYQHGoQPMv-wTy96Dcfq8c6T0KlKUXK2QhK7JERCcMBcfgyLUJ6APzllEeVyfbl5ot_ASD3wPXf5fpFNcT-XwnOTSfvrXzSOETO7w3VvpX4yu3ZT3GR11L7F1hPPozOZHp10vIZMsv2OtAHO_oV6hrQHMJUEz8upgYowpi90teLf3qGJo_LdHhu9D8S9gc1s=)
2. [mozilla.org](https://vertexaisearch.cloud.google.com/grounding-api-redirect/AUZIYQEi-1-7KVbCcunOsEke3SiI96BQmbKVAeuIGpAZc_ECgeQ8iBv-Wrxy-AcEB5lIralVQxZGJtm8YxUM-YoS2lsgqOSJwYWlS3bVDrcA5qbAYqHrN4vFJ3x_aMSVS6J6QUbvXZyNk3OLc8VUJh9G-Hq2hKfA3v2S-Ky0QTtQ5xuAjxlIZTjIRMSAzuntw3EAhG8XXmh6S9Y7tjwsSXtQNClxeEZFCQ==)
3. [jsmastery.com](https://vertexaisearch.cloud.google.com/grounding-api-redirect/AUZIYQH0yIP4ibjeqXWnOv97MHiSbcboyaXxIUooDPk14T8fKFzXiNmzXk9aJOIu8djVwxiKoB4fp0Jd6QGbJKykwj7uoyImzxeNM7Abv-oApnv4k95G3EAV6ZprXEknABQHy1qYnWJ7ROy3gHzDdp-p4YOnaT41Ig9TFZQck1LCXYhgwpu84Q==)
4. [medium.com](https://vertexaisearch.cloud.google.com/grounding-api-redirect/AUZIYQGf5yDPeAfCbxaA_Gn23hqFVSbidrw4k9UE3NJj98wekmOEv1rEnpqDt9C25KA4D5rLFAqSyWy_JYTDBctV3ZrJF21HdZyhgka1mzHVF4y-Ybvd-2fWHvZvY8AHpoyEcjfzfzb0UNyAn6IA9LqOgneZnLp2IautO3p5XXTRnE0EJ4mnGKJ6GkF2WjSv3SNfvQmYtPMeQZW_Ss89qvUa-fI=)
5. [codeburst.io](https://vertexaisearch.cloud.google.com/grounding-api-redirect/AUZIYQEKf21SfJbDeh1bBZqtukH95rW3Y-geUuwnO28q_QxSWm3CIz308xDtk0XQ8m9Vo-8pKVS4bPrfoM1f6Q97PLLjQqFlFa1B7q-wWjWZL9_FZVds2j-twbbhx5eQRaMnBPErsIJF_VdHCOVYn1vR-C2Eiw-O3lHIOYmOaif0pMlGv2xHRDO1Hzs3dH7J52RDkRiT8eJZGgF6fA==)
6. [cloudflare.com](https://vertexaisearch.cloud.google.com/grounding-api-redirect/AUZIYQF4UZd4458EyH_WqZvNBHrm4rJExkXKvUc7aU9AKrCz_Gbnb4LlfI25nEX7wVSFPPKw0eUggNiqwu9MhJwrKpMnXiNDnl4DiqWJfaiRK2C3B38u2OnZhYoSuddwB_DGUINql1vfLUIc)
7. [medium.com](https://vertexaisearch.cloud.google.com/grounding-api-redirect/AUZIYQEhrbAdO8fX8Iz8YvO7-m8kAR8cR4eXejlpYZqdK34KJOEGc5Lp131rjBQH8EltbT6N2X73_9ZUbgqBgN0ukbE29Wso_5-lwfvxyhWZ9RIHsQehJ7tzdfv2ugzJM3JJgGJ2CWd4Js9i6j6pUqWSucWQrnFQg5QZnOVQssiJGHZ_-pKMaElC99xftudHJx2gjJnIjxdgwxJU1cLT_FTR3xgE7A==)
8. [cloudflare.com](https://vertexaisearch.cloud.google.com/grounding-api-redirect/AUZIYQH_xShqTgybgeJ5-Ko_ciUW_wLcSKvQ8fwu8T9RauRejvSbm7FBAOrNyC48CQ54yhdBtZWaizCF9Ee6Pvgr-OBLHOi74lSX9UdfQ92z0pKDcPvR3GJbnc05_F6OKEbeVB7cHLHhStL_YXN3TBvU0P6RAYWPGp58lt6crw5ezMs=)
9. [smashingmagazine.com](https://vertexaisearch.cloud.google.com/grounding-api-redirect/AUZIYQHooXe-A3y-KpZs159ac4O_R6N0KuDJZbc9MJgCNOu4KlXzyoo0cNVSzyBVX-2x0VItdn-nlzoJeqCYFRdK6nBCgWzCOsnNh3D91HJQJ6TjHU77RuC1P8PCMcloCfMzACO5_5K2MdDwlxI-vct4whok21SifAr1-xh3-JIdMGQxMuvWeDbl0_EcdzkqUFJA)
10. [gcore.com](https://vertexaisearch.cloud.google.com/grounding-api-redirect/AUZIYQHmg7zyHiaNMsnRhNEi4-CeQ0capzDphoDBz8rfWY8HNk25du1AgWcUWOQ5v3MDPzsamq1TlxtD1p5kcAYu7DSDzRoAY94Q3cDLE8CC8nDcVHSLZ_foIG1_ak7GgYg=)
11. [catchpoint.com](https://vertexaisearch.cloud.google.com/grounding-api-redirect/AUZIYQE9AL5rgbDfRqIyoycDcqMjyR309AnZ7HoWjfZEb7rAkSI5h0jkeadbj3Y8lhM6gbgLqMsLLACiZ4PdcJft-HGRvmZTvTHpdgaZXanab3PudRozDBZCHC2stuaOf93rMFXbFjFYe4npkcjRbBst)
12. [encryptionconsulting.com](https://vertexaisearch.cloud.google.com/grounding-api-redirect/AUZIYQHTEtAzglWCruadCvyO_BNVKLPbJbwhFkDw23cGQFIRhBQ8ItEw5S1Ubb8h7j7LVBjBHliitCCrL380O0y_CxvCss9X5gtMpLkS2WG9VkBl-nzj6bAa440musTbpNPu8VwzTr_GlZQPEtY_dj3-TVg=)
13. [appviewx.com](https://vertexaisearch.cloud.google.com/grounding-api-redirect/AUZIYQEpAlZq7NMtRh9UskX_VL0lopREuLZBFWqG2eH_IjJGXTx11jwbJlm1SESKM0Ecsvzd1tpm5EluKuwMK3--G7EkyKhaPHGwxPnV6nmpOqKt3fWt-rjKkXf4oAM_TffppEj7OozdQX0mw9APV8hGfqCkIDGVo_A2Ubm2344wbtswjcsT)
14. [thesslstore.com](https://vertexaisearch.cloud.google.com/grounding-api-redirect/AUZIYQE3phWJ3YK4gs0pWyg_VD_8vaN45qukPTY8zk2ONiYjkg1oSzE_hHDAu8Q3UJ-eEWajabuyclr13KkT0BANYEzPltUE9bpq5XYjw4OLu9onywMKh5cDsJkxPyuR9nd1kg-HLbFELil9nRBlIQUzkihCyQ==)
15. [pingplotter.com](https://vertexaisearch.cloud.google.com/grounding-api-redirect/AUZIYQFMe73X4D9EfjuVJj2-NRb9oRuRIA_h2hnHr1fWeoPdK3seLNfnDyybZfVqUwD-604QLn5nx5BFZYvkEsmnERGJscOWMoL4JYonUvIYTOl-p2lGVFWFgS3j_BPXbpZgqM8nIfDNQidt13dih3PFBDwS03WMHKZY)
16. [fiberlight.com](https://vertexaisearch.cloud.google.com/grounding-api-redirect/AUZIYQE1pshaxASObwerQj_y6trAWXX854hj_aWzUGWB33otTr8ly9BVelTKZDwFTHfN2ezG24lnxv9yeVAfdaiypeyBttdjXdgnNd0Kpv7_PbIwfdsMUqWBsKUkWEQe6qau__d832UU89iKGq4qCklSAZdjjfJZHvV8vtSoGbuwynaJ5NwGGCgs3tDpC2f4TccFK8qLm3ONa3wapMw=)
17. [youtube.com](https://vertexaisearch.cloud.google.com/grounding-api-redirect/AUZIYQGwy3HRtPBYRBE4ysPOfZpUIk833A83PCekSv5u72ztvVzbcwRGrvQf4Z_pk7fY1smPyXqzqDROw8EUAjzAA04N0iU5yB-SIrLSov45Va336LSLXnLnQwgmxl8f4DE90rXA)
18. [earthlink.net](https://vertexaisearch.cloud.google.com/grounding-api-redirect/AUZIYQH8j8JuDcjLpwe-Dub9htg6-KJu-rpGADsdknaKrDt6c_t-U0zYeKJ9rmpMimlq5mDl94muQMM92tzz5qQbdZvdX28DA2TNRsZA5ezrf11ntNzeDro61ol77G91uB39tcBxddkD2-lyrqKl)
19. [hpbn.co](https://vertexaisearch.cloud.google.com/grounding-api-redirect/AUZIYQHYzPbZqb1JHl-n6nPsW8NjCUWPZdoaRswntMay9VQm6iZneoxARZgpVpDx9xIShHzrd2xxi9FnaotSpRXXQ_NWHK9rB6M9QzG1Zns5RjwMVpYm8V_OQX3AasHQY20AAuS6w24xfQo=)
20. [ofscn.net](https://vertexaisearch.cloud.google.com/grounding-api-redirect/AUZIYQFqavozt5LuvkYM16i9m2sCqDMi2muLag76FonxldFtYke9ffcABNz9cZIRToNWOBpsdk1rSjWtzuX9doPuvWF-MUNJ0YWRdaQDLc44SSkVcC1ukhM8_GyIBFSz-bJ9w_y0PmEl91z_PxLtzp3GtVTMl0yT_n7WEx2PZHMmHsCjtyZTAYgPAPU=)
21. [genuinemodules.com](https://vertexaisearch.cloud.google.com/grounding-api-redirect/AUZIYQHwqSeiypsw3lcnJp_5TcXg6bCJy0vKvSqhvKvFa7IMNmn_6c2TUuYsAqn3EYhbCznN2FC-AF2UZhXR_ipMGrM6fUy3e2QsRQ7LQFdpRqkky62YVCg5ZLy8z6bue21Aw2uKMigwMscflg2PFmo9M2xdepXq_UDrDMntFqOZNkreZl0upr0vo0DmUC5ZdIud91qY)
22. [m2optics.com](https://vertexaisearch.cloud.google.com/grounding-api-redirect/AUZIYQFoNrW-BTrVBmut9kFJhsjAY8JdoI5q3I_0O5NwjjIFHCLD98uoqCnaxQ7JAixAQsNi0qpRbbwk1yppbvLNvHKG9ka-P572KUyeHgRoR76wr6cbTYinhil3qSEjHPEAQvBn1v27gngbB6VuZCvUeFO_iwK4M7dO44IkN1Hc8ym4)
23. [cloudflare.com](https://vertexaisearch.cloud.google.com/grounding-api-redirect/AUZIYQEHHdZUYW4s969KlGpdQyVMa4GbK9AyqReOAq7EE9BAcnvL43cKUkASKJ--9OF8GRCkxmcY3qquKSGI_Nv2m6xF1MPtMsN8A4rPdSsEpqbrwWw5RyAzwf5M24_PbMVRsEyVWIcHkyRQUE7i)
24. [reffine.com](https://vertexaisearch.cloud.google.com/grounding-api-redirect/AUZIYQEQvxeF_xJ7io0kRIc2-fYXAZxtqsGDBDalbMg3W8GEgiuSvAZ2YBhV2_hLq8kHZGq2UXlgzwoHyVSFKBZBC0YeuqxbQKWP2wH-XpqkB9UNtbDXiLZNA8_NgYn4Ux2naK38IwaayXJw0hSRN8rmBr9aVNVoiYam8NpXboABQ-GNx_W0mAqJ57mPGSji5xvNHLK8GOSmNcag)
25. [wondernetwork.com](https://vertexaisearch.cloud.google.com/grounding-api-redirect/AUZIYQFNEeFJfbIcZeP1H84EU-8PC6LwfJKf8DG68VcSy-z3oYJHgE4B0XewPo8MHXKalGPqzRWJUzBpEweNNP3CAWKi1qQoU0IQhXEfTArtlrUh7oq5ToZO)
26. [verizon.com](https://vertexaisearch.cloud.google.com/grounding-api-redirect/AUZIYQE2eGiH0GLA0JQgNQ5zdEpknqPq6zH9X88nWT6hr1Pn4UljA7_XfVIYykmL4S9zMOn5vhHUWqFDhDBY211K2SlgON4Yp4sNc6x_q2WK7lHFmB0UffQAArJ0vGjlmIUTJLYKphgO8g==)
27. [blazingcdn.com](https://vertexaisearch.cloud.google.com/grounding-api-redirect/AUZIYQGavEhyX6GvNf3WFQ4WusxtP8V9aFrejP99goLZVTEBrWugYl88rhX9LGODnPPn2LJ1MNCRMU4hmVpB2Bw7LF6xoI5B6ukuW-cUJoaAD1j3fA4S_53tM1AP-kmYQ6p4SybNi91fT0-KQDtqNgcaSXNKifxi9N4IcdteWMh22UE=)
28. [zenlayer.com](https://vertexaisearch.cloud.google.com/grounding-api-redirect/AUZIYQE23gIF20dnOc6th3chqt4257mU-L1zPoO0Hqsc-KO7kFrMh1U0YL46vRouFG6yEZAXMe48WdqKYRAMkBXssZ05tr17_wLPDhoezbAHbNHdxp7BL2u84vDrOJ9UkS6IY3fcCE2VljdXjQ==)
29. [corewebvitals.io](https://vertexaisearch.cloud.google.com/grounding-api-redirect/AUZIYQEOXmo6Bc8Alc_YLy8TMA-GecLbOz-t8Qaqucer4J-JuKjMENtQ2M5UdPUR-SH8U0Mcv_HKI68cWva3azNGtKv6cXGOY3G3IX2rCMT9GhIAIaT-sjf1zkONEoPqNSPLIAuQDX8sap7StIWto9p2BLW0pnIX0adIrMzcT0e35NpmLtKF35CeM7tG)
30. [quora.com](https://vertexaisearch.cloud.google.com/grounding-api-redirect/AUZIYQH9W0FCOgIVlixdBbjWr69-IFt_tjCExxOWQdGgU7BQ9GfCriAQ6dKOa2cqAw7GjsbFroqnuUT969U9wUJQJ6RB8QH5-yL9froZscKGdhDJxYlv7BWs1_4TuVK6B11Xj3Qx0L3zzXcXInm1ZOf_TzCP8Ca0n6jg8Y036UE5mINaQoxPzpafqEC_pAj7MQiYcZH-nUnutN9KEUprT7rxMqbdlOgQxZoZCQuMU9NmXJIQbOTd)
31. [cloudflare.com](https://vertexaisearch.cloud.google.com/grounding-api-redirect/AUZIYQEUIU0RsOub98EoUGV1ZkemkecyDuzUo9-X1DAm3Ef3nfvD2QnJko1ZN3_QecfJZQlFerXj8JXJLKB1FPUjX1K3gJjptZZ3lMbZz8-XAb-Aj5bzKKhX2Vy57NZdyiO55Ekbx3MxSwAyS2IOAxN2Up0kEo8KUmNXjIX2QJVS0SgsuB_8f3l8d4ABO6SKy_DG2DhV8NgkM8aScKmi)
32. [cloudflare.com](https://vertexaisearch.cloud.google.com/grounding-api-redirect/AUZIYQH9Wv1RDMQHnMT6p2RxdpPaI7g0XUEEu-aeKAscjD7D8PaEPzYqThAZE3Puzw5FyCHODS6dwrNJA48SwQyzSn5UFlXPpOwFxjRTzMqhbmjBCJoQuOaGEo8YOM-7kni0EmezjpeAmeCq34VCDK5Qxp-vruFtddFlLL1u_NM=)
33. [reddit.com](https://vertexaisearch.cloud.google.com/grounding-api-redirect/AUZIYQFU2lNkROTCXyeWsaTx8TjZnzjo3YU-1tUVmVNfQpGilQyRYZ-yowySDlud6VKste9nN8yNLyO4iFJaglnmYmEQEuQISdtkgQGio6UhLzKHpWuDxqo66nvftC6uWjFEtAWATh9NbQ9Ve5I1mDan4iY-c9DKzhLyRCLauFnxn73LbDPkARZ--48gcH0ZW7AS_w==)
34. [web.dev](https://vertexaisearch.cloud.google.com/grounding-api-redirect/AUZIYQFaQYYNJh6X555o2H8lI8wU3DdQdLEdMZbDkVtPP7VKBFCG8OAg7xycDGlhaBPRlapetRRnVkL-H6w820-edxeDo_w0lqPTlqEvHhvHv5qYgQBZvg==)
35. [keycdn.com](https://vertexaisearch.cloud.google.com/grounding-api-redirect/AUZIYQG8R5z4RnkVPAPpT6X_tZYGTDrJ8j8YUTat5dWVKGxdbVVEIZvcS73cwTqbl19g2LHjUd_YPWIJ3w5cXFOPQoGzENKXil7MnspYTnSU1rGimnckrZZ3nrDF4Aa-zCoPQ7WS8oSTMCgSJbtUQOVQ55-CLHEljPMcfFA=)
36. [dev.to](https://vertexaisearch.cloud.google.com/grounding-api-redirect/AUZIYQGJbY73oXsxcXwLZAoEQdKkdgq5Mk402F6lwFFgRqyIgb2-Hrw4um1dn13BWmMjn27AD1RJR64BpPsbAwmpCSCcnS3krGrpERwpHWHp0DS5sxdRVSsvePALue5rRHX12MiGPOR4ZdY867BLZ7HrlnS3QRpdZavv_nyyHgjWQvA9XfT3LCXWGWU5BhE89qFIkVpL7asJFJAIyioEvQImkQ==)
37. [chrome.com](https://vertexaisearch.cloud.google.com/grounding-api-redirect/AUZIYQECzmVAEJLQyp07Lgrec5YSrLL_ipBi8pP1aGg5WRp0xKf3DfO3dZAvpt2FOGJ-FVbv-ktu9FnZPyVuWyV4OyKVjQ8xl3lx7I7ro-SnCr5g5wh_EcSn1KzfyfsXQhetT5qsUrq31coCkUdXFPD15VSqHmTh1ju42HNkwDVPxz1wEIMRkw==)
38. [microsoft.com](https://vertexaisearch.cloud.google.com/grounding-api-redirect/AUZIYQEwbIqTczOficB08pmTNaY5kiFH_GL6BwTcCkSF1pV4NbdQ9juExbHJ9cyN2_TZyxzElOLpID8PAm7axpV2z1bAiMbeNG31w63OzHs4hgy1A2aMj0iPx3YnAVXKLB67mmqUScuJZTERQOYRGOP45nKmZPopd0tM6TibwW_NU3wBh-GjcOuFmc0xA7a4rS74MMA_31BumgsmurFPXg1Otia_)
39. [chromium.org](https://vertexaisearch.cloud.google.com/grounding-api-redirect/AUZIYQEtpjcS2jzFv0le1x0sgHdo0clxT8lEpDKvT2qb6Xk1ZdIYRGcKDP857uqgh3AMZEPEwmAvnnO6l_Ndea-gsFxUCXfOSk-qN61jSW_FeNO16VdQ4tUdK_LrYxg=)
40. [cybernews.com](https://vertexaisearch.cloud.google.com/grounding-api-redirect/AUZIYQEczjw4z9WBZZ4yBtrYfz_fRiFud_xXYGjM1NOKslroCgPvyU-xyQ-qrShrj0czqoIONAViBS0o-HeeoPUWSiwM1AJhA-I5DTA71WzhiE-XWpBJeKWcUC4peWzqfgcsGTRKn1-V6jH0hJO_uoM6cLjZXCltONOWCygSOCHVFUjQgm1wGaqVIwg=)
41. [debugbear.com](https://vertexaisearch.cloud.google.com/grounding-api-redirect/AUZIYQE_EoAzet5sVE6Voh_LDMGjgU5lDKQB9rr0Rw1nkdjspEaojOtOh2AcZbTRMFBPoxX8A9iSdAm1P8Zfb_s0yLcgC-q1MnoSYItVoylFi2H-fQ-_5bphy53QZlHsfMA8vCP9Yq_29FN7wC1X4c53iHdhG_jw-I1sfP3c1Q==)
42. [github.io](https://vertexaisearch.cloud.google.com/grounding-api-redirect/AUZIYQGVidCAXh6VbZnURHKMYCzPXfESQ9kI7869FTjX4I34aR5v6KXKxE-m4jA1LEXG5ztjFbpLK-BQfXtxyGIWIlp1RyO4YB6sUeZtYtC7tbaLPf8JAjTmxuIv7yKYC-893tY92MXEitPqfkYnfOg7SSCI1yQbupOupA==)
43. [techjunkie.com](https://vertexaisearch.cloud.google.com/grounding-api-redirect/AUZIYQEQxuoYWiZGCIwXbNOB0gC6jYu4fcthvOmORSntSOXyRa-y7qXbt-TklX0aRqgnko-UR7fgf_Tooy-MS_WuIhS-hLUzesDtWTJ6ZEhEEQPRNWWtNLFcwmrOOQ3g9o_DKNdqZIsM3AuTmOvPtoapFOc=)
44. [cybernews.com](https://vertexaisearch.cloud.google.com/grounding-api-redirect/AUZIYQGt3w19VGIaMLdNpGbUB4VFr6DGX_vymMtvkZTpfhtKeWmGdIXSBLZteQgQo_0oogNibgFLkmHEZMtYjsDHh31W0RYZxmuU1i0CxUndL7ZmhXzXh48ZsL7CK4JsH4oEwzRqK3jikHdZaX4miqJe_aUMXzU_BofzjYef6rLr8m_O4KykvzqN7ow=)
45. [quora.com](https://vertexaisearch.cloud.google.com/grounding-api-redirect/AUZIYQEjlIoM29u-t5iy7LNH7HrolO0nWgNKX35rsv6TO8a5SNA0sEm1WY6FRbxqQpd8VAIxRJteX5NzTavFYwykBVK82xGVavOWJ2ionAyKP41bQp19zgumNQ9nEWLUC651tPN9kcFF-kLbRc93zl4aMwdhaI18Nr3zPg==)
46. [github.com](https://vertexaisearch.cloud.google.com/grounding-api-redirect/AUZIYQEmvAzvXMGZvJKQR-6dC3qSeBbrlXR-UXpmqx2gl790lBhFqBHjcSXMiFYZF0OxzR0RKDRh0pUhOFRKf58OcGtWhMjM0v-pODBQpuxie_eUpo0z6nr79-Cf9SSUWvewQbVmAxKeKqDF94JSXQF8yw3P31n8nSz20tyHRAML1UrT_w==)
47. [3dinsider.com](https://vertexaisearch.cloud.google.com/grounding-api-redirect/AUZIYQHuhhd3fzxGpsUVIik_-NMya880CoiEahaWkBrXtQEM7jKijkj9VbefotV2R0kz4P9Gtl-YSPyNNPBkauekaRFKsyJuK_CD7cRd4h3C61FFtrYJRcJLDP002dbmOzSbwFTLAaaxvqPqioU8)
48. [webxen.com](https://vertexaisearch.cloud.google.com/grounding-api-redirect/AUZIYQHSGU3oPvwhbsTsRLqIZsgDFhngdI7NjZrsT8_aY8lddRG8r0gCbBvhkEH-dZ2M0gWiOQZ4AcAlnu_F7Gbr7pkMWSn51tVehYpGti9ExikIFRUCKkd3kkcItMuTCS4EHXo2rJpFCczGTFnpGwW_8g==)
49. [alextechtalk.com](https://vertexaisearch.cloud.google.com/grounding-api-redirect/AUZIYQF3drRV3rGXQ7ylsBoV7rUk6csPKig1fbP8J4bbqYftT9sZK_T3nlgKcZ8K5LrIGD9i-m5A43ndrtJWcuFUiqti5jfmaAgkJdRgQFJD7oiOv6SXlgqVAzh-GFLyQjkX6Fi7RdfU1qovMJUUuFwJw4SRN_jbgFrEA58=)
50. [openreplay.com](https://vertexaisearch.cloud.google.com/grounding-api-redirect/AUZIYQGOMkCX5IphwPR4gVVLMOrvZBlf9MXG6Gf6lP0GpwF-hqDJArNpFq4KR7UeNqPBiQ0w6LLFbQIq4IssW_GnRjaJ25NLPfXpEB1JCl7pb4tGdPfl9nc-9O-uBCpeutk7NmlOvKPLZapeDom6SpfBrk5BWZBHbLouwkX28XZ6SQq-9dRikDQXhQqKbSsORQ==)
51. [mozilla.org](https://vertexaisearch.cloud.google.com/grounding-api-redirect/AUZIYQHysm7WcIJjqNIsDZ6chrS8sKIKB7pKKWSaMPZJcTsBnN_a9rcKM6zoJJO0S4fRRI-TCXSWB4I9tPkybDF32DxcmJnYYMwPuDyejtFG09W75DXm4XJhwSjmV5fvV0ooo5RdOBOw_OzVfM06eYxboIKNhhgxUelUnEZKFMJbZmxqcQwuilgGtwO4zTQc63c=)
52. [webeyez.com](https://vertexaisearch.cloud.google.com/grounding-api-redirect/AUZIYQGuyJzSS5xYjGa-SqCQEtYMy8Q0VU36iZ4D_CwMch3HqYQD7aykzVrSTYH3XurFUqTl2GpK5VOx8r5gactdu38yQp-i906uT35XEAHspLf3QTkWaMBYKYybWpg4mXvbWYDKojYFg6k61jiZpu8pK_dKOFK3rAvO48A6CWPcLw==)