Forem: Paweł Pokrywka

How fast do websites load from Google Search? Comparing various prefetching and on-demand load methods.

Paweł Pokrywka — Sat, 13 Sep 2025 17:20:21 +0000

In the previous part, we saw that a website can load in 15 different ways when visited from the Google results page and how to measure the performance impact of each load type.

In this post, I will share the results of my website's performance measurement, along with my comments.

I assume you are familiar with the differences between various page load types. If you need a refresher, please read the previous post.

This post is part of a series on Signed Exchanges (SXG). To assess SXG’s impact, I measured the performance of different page load types. This article is based on my research and summarizes my findings.

SXG is a technology to make your website load faster for Google-referred users. If you want to implement it on your website, start here.

TL;DR

For the impatient, here are the results showing the Largest Contentful Paint (LCP) 75th percentiles I measured (or estimated as stated in the labels and explained later in the text).

I show that it’s possible to go below half a second, but SXG side effects may worsen the experience for some users. HTML-only prefetching improved the performance, but sometimes only slightly.

P75 LCP comparison between page load types. The less, the better. Some values were estimated as stated in the labels.

Your mileage may vary

These results are based on real user data from my specific website, measured from Polish users. Your results may vary significantly based on your website's architecture, user geography, CDN configuration, and other factors. The patterns I observed, particularly the desktop TTFB issues, may be unique to my setup.

Methodology

Measured pages

I share my findings focusing on a specific section of my website: the vendor index page (similar to a product index page in e-commerce). While I measured other sections as well, including them here would add length and complexity without providing significant additional value.

The vendor index page receives significant traffic from Google and has strong performance metrics, making it an ideal candidate for comparison testing.

Chosen page load types

The results include all the page load types I identified in the previous post, except for types related to:

Accelerated Mobile Pages (AMP), as my website doesn’t use it
Google Ads (no ad campaigns for the measured section of the website at the moment of data collection)
Early Hints , because my website uses HTML edge caching (more on this later)

Data collection conditions

I collected data only from visits that met the following conditions. For the explanation of why these specific conditions were necessary, see my previous post.

It’s a Google-referred visit
The user visited the website for the first time (checked with a local storage marker item)
The page has been opened in an existing tab
The browser supported SXG

All of the above data was sent to DebugBear, a monitoring platform.

Filters applied to collected data

Then I used its filtering functionality to include only:

Users visiting the website from Poland , as Polish users are my target population, so I wanted to understand how they experience website performance.

Additionally, filtering by location helps exclude bots that typically visit my website from other countries.
Visits not using cached assets , as the local storage check (described above) did not always work properly.
Visits with Time To First Byte (TTFB) equaling zero for load types not involving prefetching. It’s practically impossible to receive the first byte of the response below 1 millisecond; therefore, I treated those samples as invalid.
Page load types that can be reliably measured by excluding SXG redirects. I'll explain this exclusion later.

After the above filtering, I was left with over 14k data points.

Obtained performance metrics

I segmented the data by page load type and device category to generate LCP histograms and calculate 75th percentiles and averages for each combination.

For calculating averages, I removed outliers by excluding visits with LCP over 5 seconds.

I rely on 75th percentiles by default. When using averages, I always explicitly mention it.

Estimations

I estimated LCP for page load types that use SXG redirects:

When estimating averages, I added a bias correction—which I determined was necessary for accuracy—to the reference average.
For estimating 75th percentiles, I observed a correlation between percentiles and averages. I then leveraged this relationship to calculate missing percentiles from the available averages.

Note that the estimated percentiles were derived from estimated averages, creating a dependency chain in the calculations.

I’ll provide more details later in the text.

Spreadsheet with data

The spreadsheet below contains the LCP data I collected from DebugBear, along with comparison charts. It’s composed of 2 worksheets for:

75th percentiles
averages

Each worksheet contains a configuration section where you can experiment with the estimation parameters to see how the results change.

Download LCP analysis of page load types

Disclaimer

I’m not a data scientist, but I did my best to ensure the data is reliable and the conclusions sound.

LCP results

Below, you can see the comparison of the speed (LCP) of page load types. It’s the same chart as the one at the beginning of this post. I put it here, so you can reference it easily while reading my observations.

P75 LCP comparison between page load types. The less, the better. Some values were estimated as stated in the labels.

Desktop vs mobile

Looking at the chart, you can see that half of the page load types work better on desktop, while the other half works better on mobile:

When the page was loaded from Google (SXG On-Demand Load) or prefetched, the desktop won.
When the browser was talking to Cloudflare (Server Load, Edge Cache Load, and both SXG Redirects), mobile came out on top.

I thought desktop users should have a better experience than mobile users because of better connection quality and more CPU power. Why then it’s not universally applicable to all page load types?

TTFB component of LCP

When I dug deeper into the data, I found that for Cloudflare loads, on desktop, TTFB contributed to 36-51% of LCP, while on mobile, it accounted for 22-33%. Compare the TTFB histograms below—mobile looks much better:

The TTFB histogram for the Edge Cache Load on mobile. The green, dashed line marks the 75th percentile.

The TTFB histogram for the Edge Cache Load on desktop. The green, dashed line marks the 75th percentile.

For prefetched pages, TTFB is zero or near zero, so it’s useless for comparisons. But when the pages were loaded from Google SXG cache on demand, the TTFB was better on desktop (the opposite of the previous case). On desktop, TTFB contributed to 25% of LCP, while on mobile, it accounted for 30%.

The TTFB histogram for the SXG On-Demand Load on mobile. The green, dashed line marks the 75th percentile.

The TTFB histogram for the SXG On-Demand Load on desktop. The green, dashed line marks the 75th percentile.

Why did waiting for the first byte take longer on a desktop than on a mobile for Cloudflare loads?

I hypothesize that in Poland, Cloudflare edge servers have better network connectivity with mobile ISPs than with residential ones. This could be because there are only a few major mobile operators, while many residential ISPs exist.

From Cloudflare's perspective as a global infrastructure provider, Poland might be considered a relatively small market, leading them to potentially prioritize peering agreements with the larger operators.

Note that this is specific to my measurements in Poland and may not apply elsewhere.

If you have a better explanation, drop a comment below.

Reference page load type for comparisons

In this post, I compare the P75 LCP of each page load type to that of a baseline on-demand page load from the server:

Mobile: 1.43 seconds
Desktop: 1.82 seconds

The gap between mobile and desktop is 390 ms.

Keep in mind that the desktop LCP in this study is heavily impacted by the increased TTFB, as discussed above. This impact may not be present in different countries and/or in the future. This makes it difficult to draw general conclusions (i.e., unrelated to my specific website) based on comparisons of page load types on desktop and between device categories.

On the other hand, the mobile performance characteristics should be fairly universal.

Below, you can see the LCP histograms with the TTFB impact on desktop clearly visible:

The LCP histogram for the Server Load on mobile. The green, dashed line marks the 75th percentile.

The LCP histogram for the Server Load on desktop. The green, dashed line marks the 75th percentile.

SXG prefetching with subresources is unbeatable

You probably won’t be surprised that prefetching the entire website (document and subresources) using SXG is a definitive winner in terms of performance. Compared to the reference, on-demand load from the server:

Mobile: -846 ms
Desktop: -1356 ms

As you observed above, I mark LCP improvements with a minus sign (LCP decrease, which is what we want). I use plus sign for LCP degradations (LCP increases, which we should avoid). I don’t use signs before absolute values, as you can see below.

As a result, the LCP is as low as:

Mobile: 584 ms
Desktop: 464 ms

A half-second LCP feels almost unreal? If you’d like more insights like this, subscribe to my newsletter.

Below you will find LCP histograms. Please note that the data points with values higher than 1.5 seconds are almost non-existent!

The LCP histogram for the SXG Prefetch with Subresources on mobile. The green, dashed line marks the 75th percentile.

The LCP histogram for the SXG Prefetch with Subresources on desktop. The green, dashed line marks the 75th percentile.

Can this be improved even further?

My data shows that for SXG-prefetched pages with subresources, 95% of LCP time is spent on rendering.

For extremely low LCP: use large images or videos freely (they're prefetched anyway) and keep your page structure lean and simple (to minimize rendering). The first won't hurt; the second fixes the real bottleneck.

Second place belongs to HTML-only prefetching

While this may seem obvious, it's worth stating clearly: prefetching improves performance regardless of whether you use Speculation Rules or SXG, even when only the HTML document is prefetched. Compared to the reference on-demand load from the server, HTML-only prefetching is faster by:

Mobile: from -20 to -100 ms
Desktop: from -670 to -740 ms

The mobile results appear subpar, but they align roughly with the results reported by Google itself. The desktop performance improvement is significant, mostly because prefetching is a workaround for Cloudflare’s TTFB issue.

I believe inlining critical subresources, such as important CSS fragments, should make HTML-only prefetching more performant. However, I haven’t implemented it on my website (yet).

Speculation Rules are slightly better than SXG for prefetching HTML

A page prefetched using Speculation Rules loads a bit faster than the one prefetched using SXG without subresources. That’s interesting, since both methods technically do the same thing.

On the histograms below, you can see that SXG has more extreme samples (below 250 milliseconds and 5+ seconds), while Speculation Rules’ samples are much more concentrated below 1 second.

I suspect the difference may be explained in part by the cryptography-related CPU overhead of SXG.

Mobile histograms

The LCP histogram for the Speculation Rules Prefetch on mobile. The green, dashed line marks the 75th percentile.

The LCP histogram for the SXG Prefetch without Subresources on mobile. The green, dashed line marks the 75th percentile.

Desktop histograms

The LCP histogram for the Speculation Rules Prefetch on desktop. The green, dashed line marks the 75th percentile.

The LCP histogram for the SXG Prefetch without Subresources on desktop. The green, dashed line marks the 75th percentile.

Edge caching was worth it

Introducing HTML edge caching lets me skip processing frequently accessed pages on my server. Also, as Cloudflare works as a reverse proxy, these pages don’t need to be transferred between my server and Cloudflare on each request. They are kept on an optimized infrastructure and retrieved in milliseconds.

This is visible in LCP measurements, when comparing on-demand page loads from the server and the edge cache:

Mobile: -120 ms
Desktop: -350 ms

Given that edge caching improves all the traffic, not only Google-referred, I think the improvement is satisfactory, especially on desktop.

The LCP histogram for the Edge Cache Load on mobile. The green, dashed line marks the 75th percentile.

The LCP histogram for the Edge Cache Load on desktop. The green, dashed line marks the 75th percentile.

On the histogram above, you can see the absolute LCP values:

Mobile: 1.31 seconds
Desktop: 1.47 seconds

This time, the gap between mobile and desktop is 160 ms—a 2.5x decrease compared to the reference Server Load. I found it’s caused by TTFB again, but why there is less difference now?

I don’t know. If you have an explanation, drop a comment below.

Proper HTML edge caching makes Early Hints' impact negligible

As I mentioned at the beginning, I didn't include measurements for the Early Hints page load type.

Cloudflare caches the Link HTTP header from the server’s first response and then reuses it to send Early Hints in later responses for the same URL.

However, when the edge cache is in use, then not only the Link header, but the entire HTTP response is cached. In effect, those later responses almost always include the full page directly from the cache. In that case, the origin server is never contacted, so there’s no gap between sending Early Hints and delivering the complete response. As a result, Early Hints provide no performance benefit.

Because of this, I wasn’t able to collect enough samples of requests that actually went to the origin server, where Early Hints could make a difference.

SXG On-Demand Load impact varies between device categories

When the SXG version of a page isn't prefetched, it must be fetched on demand. The reasons for this were explained in the previous part.

In this scenario, compared to the reference, the LCP difference was as follows:

Mobile: +240 ms
Desktop: -210 ms

Mobile

The slowdown on mobile can be attributed to the network overhead of downloading SXG subresources on demand. Each subresource may require its own certificate file to be fetched, which in the worst case can double the number of files that need to be downloaded. The higher latency of mobile connections makes this effect more visible.

Also, SXG processing requires performing cryptographic operations. Mobile CPUs often have less processing power, which can make the overhead more visible and further contribute to LCP degradation.

The LCP histogram for the SXG On-Demand Load on mobile. The green, dashed line marks the 75th percentile.

Desktop

I attribute the desktop LCP improvement to the TTFB issue, as explained earlier. Normally, I would expect a slight performance degradation.

The LCP histogram for the SXG On-Demand Load on desktop. The green, dashed line marks the 75th percentile.

The dark side of SXG

As you have seen above, loading the page on demand from the Google SXG cache is not optimal, at least on mobile devices. That’s not good for the technology that promised to improve page load speed. But the real problem is much worse.

SXG fallback client-side redirect

It occurs when the page is missing from Google’s SXG cache. When the user decides to navigate to the target page, the SXG cache serves a fallback page to the browser. This page contains a client-side JavaScript code that redirects the browser to the target page.

It would be interesting to know how much this degrades performance!

RUM tools blind you to the SXG performance problems users experience

I collected many samples with detailed performance measurements for page loads redirected from the Google SXG cache. Unfortunately, I decided to throw them out entirely.

I noticed they don’t make sense at all: they seemed to have no impact on LCP. No improvement (that’s obvious), but also no expected degradation.

Why? The answer is straightforward; however, it took me a while to understand. The bottom line is that it's impossible to measure this in production. No matter which Real User Monitoring (RUM) solution you use, you won’t be able to say if you have a performance issue!

Start of navigation bias

When a user is on page A and clicks a standard link to page B, LCP measurement begins at the moment of the click. This way, the LCP value reflects the entire wait time for the largest element on the target page, including network delays, HTTP redirects, and other overhead.

The situation changes when an SXG-fallback intermediary page uses JavaScript to redirect the user to the target page. In this case, the browser cannot distinguish whether the redirect was triggered by the user or automatically. It assumes a user action and starts measuring time only from the moment the client-side redirect occurs—not from the original click on the Google search results page.

This means the interval between the click and the client-side redirect—I'll call this click-to-redirect—is invisible to the browser. And that gap can be significant. In my tests, it ranged anywhere from 50 to 2000 ms, depending on the device, browser, connection type, and likely other factors.

I built a SXG fallback redirect demo so you can try this yourself and see the difference. The demo also lets you simulate SXG and Speculation Rules prefetching, but in my testing, those didn’t affect the results.

Estimating the average SXG fallback LCP

The LCP of a page loaded using SXG fallback redirect should be a sum of the LCP of the underlying page load type (Server Load or Edge Cache Load) and the click-to-redirect time.

The HTML of the SXG fallback redirect page is under 350 bytes, so the time it takes for the page to load and start the redirect is almost the same as its TTFB.

If the TTFB of the fallback page is similar to the TTFB of SXG On-Demand Load (which it should be, since both responses are generated by the same system), I could use the already collected data.

I prepared a demo that measures TTFB of a SXG On-Demand Load. In my tests, I could confirm that the TTFB roughly equals click-to-redirect time. You can check it by yourself here and compare the result with the measurement from the previous demo.

For the initial estimation, I will use averages because they are easier to work with than percentiles.

The TTFB histogram for the SXG On-Demand Load on mobile. The green, dashed line marks the average. TTFB measurements corresponding to LCP measurements exceeding 5 seconds are not included, as explained in the methodology section.

The TTFB histogram for the SXG On-Demand Load on desktop. The green, dashed line marks the average. TTFB measurements corresponding to LCP measurements exceeding 5 seconds are not included, as explained in the methodology section.

The average click-to-redirect delay that should be added to the underlying, average page load type LCP is:

Mobile : +403 ms
Desktop : +311 ms

You can find the estimated absolute average LCP values in the spreadsheet mentioned earlier. Below is a chart comparing the average LCP for each page load type. The conclusions are roughly similar to those for the 75th percentile.

Average LCP comparison between page load types. The less, the better. Some values were estimated as stated in the labels.

Estimating the 75th percentile LCP for SXG fallback

I see the 75th percentile as the standard way of assessing LCP performance. It's used by the Chrome User Experience Report (CrUX). Therefore, we should estimate it for SXG fallback page load types.

In the case of my data, I found that for each page load type, its 75th percentile can be calculated by increasing the average by 20-40%. Therefore, I assumed that the missing 75th percentile for SXG Redirect loads can be estimated using this method. For the exact calculations, see the spreadsheet included earlier.

SXG fallback significantly hurts performance

Below, you can see how the P75 LCP degrades when the page loads using SXG fallback compared to the reference:

For Server Load
For Edge Cache Load

The LCP increase for the Edge Cache Load on desktop doesn’t seem much, but keep in mind that it has erased all the edge caching gains.

In my opinion, the performance degradation for pages loaded using SXG fallback is substantial. And neither Google nor Cloudflare documentation will tell you this.

While these specific performance numbers are from my website, the measurement blind spot I've identified is a fundamental issue that affects all SXG implementations.

Enjoy uncovering hidden insights? I share experiments, lessons learned, and surprising discoveries from the problems I dig into. If you like finding out what others overlook, you’ll enjoy my newsletter.

SEO is not impacted

There’s an interesting side effect of the fact that LCP for SXG fallbacks cannot be measured accurately in production.

Chrome browsers continuously report LCP (along with the other Core Web Vitals) to Google, which then publishes the aggregated data as CrUX.

In my experiment, Chrome reported incomplete LCP data to Google when a page was loaded via an SXG fallback redirect. I throttled the network to 3G and simulated the fallback. The LCP shown in Chrome DevTools’ Performance panel (screenshot below, left) matched what Chrome reported to Google (screenshot below, right). Neither measurement included the click-to-redirect delay.

Left: LCP measured in Chrome DevTools’ Performance panel. Right: Chrome’s URL-Keyed Metrics (UKM) page showing the values that will be uploaded to Google.

As you know, LCP is a ranking factor: a good score (≤ 2.5 seconds) should boost your SERP positions. And how does Google get that data? From CrUX.

Now imagine this scenario: your LCP sits right at 2.5 seconds. You enable SXG, but don’t configure it properly. As a result, most of your pages load through a fallback redirect. Your real LCP rises above 2.5 seconds, degrading UX. But Google still sees the optimistic value from CrUX and continues to treat your site as if it had a good LCP—effectively ranking you higher than it should.

The SXG Tradeoff

Website loading speed depends heavily on how pages are delivered. Techniques like SXG and Speculation Rules, combined with edge caching, can dramatically improve LCP. At the same time, the very SXG mechanism that enables sub-second page loads can also introduce scenarios where performance suffers.

This raises an important question: Is it acceptable to sacrifice the experience of some visitors so that others enjoy a much faster site? The answer likely depends on the ratio between those who benefit and those who are negatively affected.

The key questions are:

How many visitors experience degraded performance when SXG is enabled?
What strategies can reduce or eliminate those negative effects?
When we balance the wins against the drawbacks, is SXG’s overall impact on LCP positive or negative?

I’ll explore these questions in the next part of this series.

If you’d like to be notified when it’s published—and get more insights on performance experiments like this—make sure to follow me or subscribe to my newsletter.

Thanks

A special thanks to Michał Pokrywka and Maciej Woźny for their valuable comments.

I'd also like to thank Matt Zeunert and the DebugBear team for providing me with access to their web performance monitoring service.

And thank you for reading. I hope you enjoyed it!

I'm researching Signed Exchanges extensively - connect with me here or on my blog for more insights.

15 ways your website loads from Google Search and how to measure each one

Paweł Pokrywka — Sat, 06 Sep 2025 07:37:00 +0000

When you find a page on Google, you probably don't think much about what happens before you click it. Perhaps you've heard about prefetching, but did you know that Google employs 5 or more methods (depending on how you classify them) for loading pages? Each technique has distinct performance characteristics.

This post is a part of a series about Signed Exchanges (SXG). In an attempt to measure how SXG impacts page loading speed I needed to distinguish between different page load types. This article is based on my research and summarizes my findings.
SXG is a technology to make your website load faster for Google-referred users. If you want to implement it on your website, start here.

Main page load type categories

(Plain old) on-demand document loading

Let’s start with the obvious way of loading the page. It was there from the beginning of the web.

When the user clicks a link, the browser fetches the HTML. Then the browser fetches all the assets required for the document to display.

It’s simple and it works. However, if the server hosting the page is slow or overloaded, the user will experience a delay, which could lead to a poor experience.

To improve the situation, Google rewards websites that load quickly with better search results positions. However, Google knows that not every website in the world can become fast.

That is probably one of the reasons Google implemented prefetching.

Prefetching the document (Speculation Rules)

The idea is to download the page before the user decides to click on it. When they do, the page HTML is ready.

For the vast majority of Google results, prefetching is implemented using Speculation Rules and a private prefetch proxy.

This feature is supported on Chromium-based browsers, but support from other browsers may follow.

HTML prefetching greatly improves user experience and works with most websites out of the box, but it comes with a limitation. It doesn’t prefetch assets such as CSS styles, images, and fonts.

Prefetching the complete page (Signed Exchanges)

It is possible to have the whole page (including assets) prefetched on Google results. When the user clicks the result, the browser starts rendering the page immediately without the need to download assets first.

To achieve this, the website owner has to implement Signed Exchanges (SXG). This technology was integrated into Google search even before the HTML prefetching I described above.

It’s worth noting that only Chromium-based browsers implement SXG.

Prerendering (Accelerated Mobile Pages)

Probably the fastest way to display a page is to use Accelerated Mobile Pages (AMP). That’s because Google prerenders websites built using this technology, so when the user clicks, the page is not only prefetched but also fully rendered. It’s hard to imagine a better user experience.

On the downside, AMP has severe restrictions. Developers are forced to use a subset of HTML, JavaScript is constrained, and many other limitations apply.

It works only on mobile devices using Chromium-based browsers.

The other problem with AMP is a centralized cache fully controlled by Google. It means Google effectively became a hosting company for every possible AMP page on the Internet. Quite dystopian, if you ask me.

As AMP pages are hosted on Google, your website becomes a subpage of google.com. Your URL will look like below:

https://www.google.com/amp/s/www-yourdomain-com/yourpage

There is a way to deal with the last two problems by introducing SXG to the mix. Cloudflare even has a switch for that. But when I was writing this post, I tried hard but failed to find any example of an AMP website using it.

On-demand loading with server-side redirection (ads)

The last category describes how a page is loaded when the user clicks a Google ad. The document is loaded on demand, but with an additional HTTP/302 redirect for registering the click, which adds latency.

No prefetching. Ironically, Google’s paying customers get the worst possible page load method. If you use Google Ads, make sure your page is optimized to load fast to neutralize the latency added by Google. Another potential solution is to use AMP on your ad landing page for mobile users; however, I was unable to find an example in the wild.

Conditions, edge cases, and quirks

The above categories are just scratching the surface of a full list of possible ways the page can load when referred from Google. That’s because various factors can improve or degrade page load efficiency, and some page load types impact others.

Signed Exchanges

When mentioning prefetching the entire page using SXG above, I described the best possible scenario: the HTML and all the required assets (or subresources) are being prefetched. That’s the goal, but in the real world, things don’t always go smoothly.

Various factors can influence how the page is loaded, and they greatly impact performance. Here are the possible SXG page load types I identified:

Page prefetched with subresources

If most of your SXG-enabled page views are prefetched with subresources, you did a great job optimizing your website!

However, despite your efforts, you will notice other, less efficient page loads.

Page prefetched without subresources

The browser will use subresources only if all of them were successfully prefetched. The all-or-nothing principle states that even if one subresource fails to prefetch, when the user visits the page, all of the subresources will need to be downloaded again.

Here are the causes of missing subresources I identified:

SXG implementation errors (should not happen if you followed my previous SXG posts carefully)
Global Google SXG cache issues (very rare)
Google SXG cache housekeeping and temporary errors (happens regularly, but impacts only a small portion of page loads)
The user not spending enough time on the search results page for the prefetching to complete
User opening the page in a new tab (more on this later)

As you can see, apart from the first, the remaining factors are beyond your control.

But still, at least the HTML was prefetched, and it’s a win for performance when compared to vanilla, on-demand page load.

Page loaded on-demand using client-side redirect fallback

Sometimes the target page is unavailable in Google SXG cache. The browser will still try to prefetch it (it signals Google to populate the SXG cache with this page when possible), but will fail.

When the user finally decides to click the result, the browser will once again try to load the cached page from the SXG cache. The cache response will include a simple HTML document with a client-side JavaScript redirect. The browser will follow this redirect, loading the target page.

It’s worth noting, the redirect document introduces additional latency caused by another HTTP request, HTML parsing, and JavaScript execution.

Page loaded on-demand from Google SXG cache

Sometimes the browser doesn’t prefetch the page, but loads its SXG version on demand when the user navigates to it. I found 2 reasons for that:

Google prefetches only 1 SXG result on a page. I don’t know how Google determines which SXG result to prefetch, but it’s not always the first result for sure. If the user chooses to click the one that was not prefetched, it is loaded on demand, but still via SXG.
Google tried to prefetch the SXG page and failed. However, the user stayed long enough for the Google SXG cache to become populated. Now, when the user clicks the result, it’s loaded—on demand—from the SXG cache instead of the fallback document mentioned above.

Loading the SXG version of the page on demand introduces cryptography overhead. I suspect it comes mostly from additional requests required to download certificates for signature verification. I don’t think the CPU overhead plays a big role, because cryptography operations are cheap nowadays.

Speculation Rules

Currently, Google prefetches the page with Speculation Rules if all of the following conditions apply:

The target page is in the top 2 results, or the user hovered over the result (on desktop only).
The browser doesn’t hold any cookies for the target website. In most cases, this means the user hasn't visited the site before.
The device has enough capacity in terms of memory, network, and battery. For example, using battery-saving mode on a mobile will deactivate prefetching.
Prefetching is not disabled by browser extensions; for example, Privacy Badger by default disables prefetching.
The target website doesn’t disallow prefetching (by default, prefetching is allowed).

It’s worth noting that none of the above conditions apply to SXG prefetching.

AMP prerendering

Similarly to SXG, only one of the AMP results is prerendered. Others need to be loaded on demand from the AMP cache.

The AMP viewer is shared between the prerendered page and the others; therefore, it loads instantly every time. However, the user needs to wait for the non-prerendered pages to load in the viewer.

There are likely other edge cases when loading AMP pages, such as missing AMP cache entries during prerendering or on-demand loading.
Replicating them manually would require creating test pages, waiting for Google to index them, searching for them in Google, and hoping that edge cases manifest themselves.
I couldn’t find any tools that would make it less difficult and time-consuming. Therefore, I chose not to research these cases. If you have additional information on this topic, please leave a comment below.

Opening the page in a new tab

Most of the time, when the user opens the page in a new tab, it is loaded in the background. The user will likely switch to the tab after some time, giving it a chance to render fully, while they are still interacting with the referrer website. Therefore, I believe the page load speed is far less critical in these cases. Your performance optimizations are aimed mostly at people opening the page in an existing tab.

However, it’s good to know that opening the page in a new tab degrades performance:

Already prefetched SXG subresources are not used as mentioned previously.
The prefetched SXG HTML is also discarded, unless the CTRL+click method is used (only on desktop). I explained why in the previous part.
AMP pages have to be loaded on demand. No prerendering or prefetching.

On the other hand, Speculation Rules prefetching handles new tabs extremely reliably. It just works, regardless of how the tab is opened, on both desktop and mobile.

Duplicate prefetching

If the given page implements SXG, Google prefetches its SXG version, but at the same time uses Speculation Rules prefetching for the normal version. In my tests, I observed this phenomenon on the desktop only.

Seems like a waste of the user’s bandwidth (it is!), but it has a bright side too. If the user decides to open the page in a new tab (using a right-click menu, not CTRL+click), then the prefetched SXG version is discarded, but the normal version prefetched with Speculation Rules is used instead. Subresources have to be loaded normally, but at least the document is ready quickly.

Generic techniques for improving page load speed

If you want to compare various methods used to load a page when referred from Google, you should also consider techniques that improve performance and are not specific to Google.

You should segment your results by the technique applied for a given page load. That’s because each page load may use a different set of techniques. Mixing high- and low-performance loads in measurements increases the variance of the results, thus making it harder to analyze.

Early Hints

Early Hints allow the browser to begin fetching subresources even before the main document starts to load. This can improve the performance, especially for the pages that take time to render on the server.

Caching at the edge

If you cache HTML at the edge, such as when using Cloudflare cache, then it should be measured as a different category of page loads for the same reason as above.

If the page is delivered from the edge cache, it results in:

Subresources start loading immediately, especially if they were listed in the Link header of the response. The benefits are similar to Early Hints.

HTML becomes available much earlier than if it had to be delivered from the origin.

The cached page can use Early Hints, but I don’t see any performance benefits.

No impact on prefetching

The above page load types affect only the on-demand category of page loads. If the page is prefetched, it doesn’t matter if it was served with Early Hints or using edge cache.

Browser caching

If the user has visited the given website in the past, when they visit it again, the browser cache may contain some subresources, such as the website logo, ready to be used. If the website uses client-side HTML-caching, even the document could be saved in the browser cache, making subsequent visits instant.

When measuring the performance of various page loads, cached visits should be separated into a different category. Later, it may be included or excluded from the analysis.

Personally, I exclude it because returning users behave differently and may be less sensitive to page load speed because they know the site already.

Probably an incomplete list of page load types

Combining all the scenarios described above results in the following list of page load types. The list excludes scenarios involving a returning user and opening the page in a new tab, as those are not very useful in performance analysis.

Server Load
Server Load with Early Hints
Edge Cache Load
Speculation Rules Prefetch
SXG Prefetch with Subresources
SXG Prefetch without Subresources
SXG On-Demand Load
Server Load via SXG Redirect
Server Load with Early Hints via SXG Redirect
Edge Cache Load via SXG Redirect
AMP Prerender
AMP On-Demand Load
Server Load via Ad Redirect
Server Load with Early Hints via Ad Redirect
Edge Cache Load via Ad Redirect

That’s a lot of possibilities! I started preparing a flowchart describing the conditions needed for each page load type. However, it quickly became too complex, so I ditched this idea.

Comparison of various page load types

At first, I thought to sort all the load types by the speed, measured by Largest Contentful Paint (LCP), that they should (hypothetically) offer. It’s easy for top performers:

AMP Prerender (fastest)
SXG Prefetch with Subresources
Speculation Rules Prefetch
SXG Prefetch without Subresources (slowest)

The AMP Load is very hard to grade because it’s totally different and potentially leaner than a full page. Therefore, it may, in some conditions, load even faster than the full page with a prefetched HTML. On the other hand, if the prefetched page is optimized, AMP Load will load more slowly.

In the on-demand category, there are various ways to fetch data. I sorted them by speed:

Edge Cache Load (fastest)
Server Load with Early Hints
Server Load (slowest)

But there is one more - SXG On-Demand Load. It’s challenging to rank due to the SXG overhead and other individual factors, such as your server speed and connectivity.

The other dimension is the redirection method used. It may be ordered like this:

No redirection (fastest).
Server-side redirection (Google Ads).
Client-side redirection (SXG fallback, slowest).

How to measure different page load types in real life

Now, when you understand the difference between various page load types, it’s time to measure how they compare in terms of performance under real-world conditions. I will show you how I did it on my website.

The first thing that’s needed is a method to differentiate page load types. I created a JavaScript library page-load-type just for that.

It uses a variety of techniques to determine how the page was loaded and supports most of the load types described in this post, except AMP and Google Ads (both were not used on my website during the measurement).

Requirements

Measuring every page load doesn’t make sense. The visit should be collected only when all of the following requirements are met:

The user comes from Google. It’s easy to overlook a special case involving the SXG cache. Read on.
The browser cache doesn’t contain entries for the measured website. Otherwise, some assets may be fetched from the cache, which improves load time, but pollutes the measurement data, making it overly optimistic.
The page isn’t opened in a new tab. As discussed earlier in this post, it breaks some prefetching/prerendering methods, and at the same time, decreases the performance sensitivity of the user.

If the website, such as mine, implements SXG, additional requirements follow:

The current page supports SXG. It is perfectly fine if some of your pages, particularly non-performance-critical ones, don’t support SXG. Examples include Terms and Conditions and Privacy Policy. Make sure to insert the JavaScript measurement code only on pages with SXG implemented.
The browser supports SXG. It doesn’t make sense to include Firefox visits, for example, because Mozilla doesn’t like SXG.

Detecting Google-referred visits

To determine if a user is Google-referred, the easiest method is to check the referrer for Google domains. However, as I wrote earlier, when the SXG fallback is used, the referrer is set to the Google SXG cache (your-domain-com.webpkgcache.com). Taking everything into account, the final JavaScript function could look like this:

function isFromGoogle() {
  if (!document.referrer) return false;

  const regex = /(^|\.)((google\.[a-z]{2,3}(?:\.[a-z]{2})?)|(webpkgcache\.com))$/i;

  try {
    const referrer = new URL(document.referrer);
    return regex.test(referrer.hostname);
  } catch (e) {
    return false;
  }
}

Checking the browser cache

The simplest way to ensure the cache is empty is to check whether the visitor is accessing the page for the first time.

In most cases, this can be done by checking for the presence of a cookie or local storage entry and then immediately setting it for future visits¹:

function isFirstVisit() {
  const returning = localStorage.getItem('returning');
  localStorage.setItem('returning', 'true');
  return !returning;
}

Detecting a new tab

When navigating between pages, the browser maintains the history of visited pages. However, when the page is opened in a new tab (or new window), the history is not preserved. This browser behavior can be used to detect how the page was opened.

function isOpenedInNewTab() {
  return(!window.history || window.history.length === 1);
}

SXG support in the browser

I couldn’t find a direct way to query the browser for SXG support from JavaScript. As the SXG is implemented only in Chromium, the naive approach is to parse the User Agent.

However, on iOS devices, Chromium uses WebKit, which doesn’t support SXG. Also, some Chromium-based browsers, such as Brave, intentionally disable SXG. In some cases, the browser may spoof the User Agent to look like Google Chrome. All of this makes it impossible to reliably detect SXG support by parsing the User Agent.

Accept header to the rescue

When loading a page, the browser includes the Accept header in the request. It contains the application/signed-exchange substring if the browser supports SXG.

However, the Accept header is accessible only on the server. Therefore, the detection of SXG support should be implemented in the app or some form of middleware. Probably one of the simplest methods is to include a server-side generated <script> tag near the top of the HTML, looking like this:

<script id="sxgSupportScript">window.sxgSupport = false</script>

The global sxgSupport constant can be accessed later in the frontend code.

HTML caching introduces a challenge

Things become more complex when HTML caching on the edge becomes involved. Let’s say your server generated an HTML with the sxgSupport constant set to true, which was correct for the Chrome browser requesting the page at this moment. But the page has been cached, the sxgSupport is frozen to true, and when Firefox requests the page, it gets the incorrect value of sxgSupport.

The solution is to set the sxgSupport constant after it’s retrieved from the cache. It’s a perfect task for a Cloudflare worker, which could look like this:

export default {
  async fetch(request) {
    // Get the original response
    const response = await fetch(request);

    // Check the SXG support
    const acceptHeader = request.headers.get('accept') || '';
    const supportsSXG = acceptHeader.includes('application/signed-exchange');

    // Only process HTML responses
    const contentType = response.headers.get('content-type') || '';
    if (!contentType.includes('text/html')) return response;

    // Create HTMLRewriter to modify the script element
    const rewriter = new HTMLRewriter()
      .on('script#sxgSupportScript', {
        text(text) {
          // Replace the entire content of the script tag
          text.replace(`window.sxgSupport = ${supportsSXG}`);
        }
      });

    // Apply the rewriter and return the modified response
    return rewriter.transform(response);

    // For more information, see the following blog post:
    // https://www.pawelpokrywka.com/p/different-methods-of-prefetching
  }
};

For the instructions on how to set up and deploy Cloudflare workers, see my earlier blog post.

Including the page load type in the measurements

If you implemented all of the above and properly installed the page-load-type library in your project, the measurement code should look like this:

// If you use SXG, this code should be run only on SXG-enabled pages.
// If you don't use SXG you can skip checking for window.sxgSupport.

import getPageLoadType from "page-load-type";

if (isFromGoogle() &&
    isFirstVisit() &&
    !isOpenedInNewTab() &&
    window.sxgSupport) {

    const loadType = await getPageLoadType();

    // Run measurement code when loadType becomes available
}

For LCP measurement, I used DebugBear, a frontend performance monitoring tool. I added the DebugBear snippet to the <head> section and implemented page load type tracking. Here is the resulting code, with boring fragments replaced by [...] marks.

[...]

if (isFromGoogle() && [...]) {
  const loadType = await getPageLoadType();

  // Record page load type
  window.dbbRum.push(["tag1", loadType])
}

Shortly after deployment, I began receiving performance reports for each qualifying Google-referred visit, along with the page load type.

Page view details as presented in DebugBear UI. As you can see, I track more dimensions than page load type, but that’s irrelevant to this article.

I measured user engagement metrics in Google Analytics by firing a custom event within the same if condition:

gtag('event', 'google_visit', {page_load_type: loadType});

After creating a custom, event-based dimension and waiting 24 hours, I was able to use the page load type in my reports.

Results

You learned about the various methods Google uses to load your page, how to differentiate between them, and how to set up performance measurement.

Performance measurements will vary across websites, but seeing a real-life case study can help you decide whether and how SXG could improve your site's performance.

Therefore, I'll present the results for my website in the upcoming part of the series.

Thanks

Thank you for reading this post. I hope you found it useful.

I'm researching Signed Exchanges extensively - connect with me here or on my blog for more insights.

If the user clears browser storage and returns to the page, this method will falsely indicate that it's their first visit. The same will happen if the browser clears its storage by itself. ↩