Properties of the Google Signed Exchange Cache

I work on the team that maintains both the Google AMP Cache and Google's recently launched cache for non-AMP signed exchanges (SXGs). I'm proud of the work we've done to enable advances in speed for mobile web publishers large and small. I've also done a lot of reading about what people dislike of AMP and, in particular, AMP caches, and I've taken it to heart. Regardless of whether I share a concern, or whether it is of a current aspect of the system or a hypothetical future aspect, I try to understand its axiomatic core and figure out what we can address.

As people discover more about the Google non-AMP SXG cache, I think it's only reasonable that they will begin to question whether their same concerns about AMP apply to non-AMP signed exchanges. I've thought a lot about it, and I think the new technology enables a deployment that guards against many of those concerns. I've tried to look at it through the lens of what properties people look for in HTTP caches.

In the following sections, I'll present my personal analysis of how the Google SXG cache deployment fares on each of these properties, and then synthesize that into a conclusion. I'm always trying to learn more, so I welcome any further discussion that adds more nuance to my own thinking.

Introduction 🔗

First, a quick refresher on the SXG specification. Quoting the web.dev article:

Signed Exchanges (SXGs) allow a site to cryptographically sign a request/response pair (an "HTTP exchange") in a way that makes it possible for the browser to verify the origin and integrity of the content independently of how the content was distributed. As a result, the browser can display the URL of the origin site in the address bar, rather than the URL of the server that delivered the content. Separating content attribution from content distribution advances a variety of use cases such as privacy-preserving prefetching, offline internet experiences, and serving content from third-party caches.

A short example:

$ curl -sH 'Accept: application/signed-exchange;v=b3' https://signed-exchange-testing.dev/sxgs/valid.html | cat -v
sxg1-b3^@^@3https://signed-exchange-testing.dev/sxgs/valid.html^@^Ai^@^@M-^Tlabel;cert-sha256=*Yovy1s8e5iMxifBErDnXPe/+bCwXqmhkaWT0fDbBxfo=*;cert-url="https://signed-exchange-testing.dev/certs/cert.cbor";date=1613088002;expires=1613174402;integrity="digest/mi-sha256-03";sig=*MEQCIFo7/B07Zu7bQv6knuU8PVrVhXNlXcJvzgCvVpvHT0v/AiA0tWchEDBP/UbId74wVA9vnTZPRoesH0sxlTSCoCvABA==*;validity-url="https://signed-exchange-testing.dev/validity.msg"M-$FdigestX9mi-sha256-03=LB7wdlHO51Z1Ze600lbYAEYsckWAJpdg8OW6P04MlDk=G:statusC200Lcontent-typeX^Xtext/html; charset=utf-8Pcontent-encodingLmi-sha256-03^@^@^@^@^@^@^P^@<!DOCTYPE html>...

When loading an SXG, the browser verifies that it hasn't expired, that the signature matches the rest of the SXG and its certificate, and that the certificate is valid. If verification fails, the browser fetches the resource from the original URL that was signed over.

To me, one important thing about this format is that it enables any distributor to serve it. In an ecosystem populated with signed exchanges, the speed and network resiliency benefits are potentially available to all referrers. But from here on, I'll limit my discussion to the Google SXG cache in particular, unless otherwise noted.

In the case of Google Search, when search results include an SXG result, that SXG is eligible for prefetching. Most search results cannot be prefetched because doing so would reveal the searcher's interest in a topic to a site before they navigate to that site; this is contrary to user expectations around sensitive information. However, using SXG, Google Search can prefetch its cached copy of the result. The request that Google issues in order to populate its cache is credentialless, from a Google egress IP, time-shifted, and possibly coalesced with neighboring requests. This SXG is then stored temporarily in the browser's prefetch cache, for use if the user subsequently clicks on the result link.

This technology enables two changes on Google Search:

AMP results can be delivered with the URLs (for display, bookmarking, and sharing) and origins (for cookies, localStorage, CORS, etc.) that the publishers intend.
The same private prefetch capability previously only available for AMP HTML pages is now available for all HTML pages.

Latency 🔗

Improving page speed is the primary reason to opt into the Google SXG cache. I think it's here that we provide the opportunity for a big net benefit to web publishers ("publishers" for short) and visitors, offsetting any of the potential costs outlined below.

Through the narrow lens of network latency, the cache does fairly well. However, through the broader lens of visitor-perceived latency (for example as measured by FCP and LCP), the cache greatly improves page speed on average, by enabling prefetch from Google Search.

If the only signed resource is the main HTML, this saves a network round trip (around 100ms) in discovering the first tier of the waterfall. However, there is the potential to save much more, by signing (and thus enabling prefetch for) all resources on the critical path to LCP. This may require some eng work to:

Switch any render-blocking subresources to non-render-blocking variants where possible.
Add a <link rel=preload> for any remaining render-blocking subresources (such as the CSS and the hero image).

An early tester of this integration saw 300ms improvement in LCP at the 75th percentile on Android Chromium browsers, and expects that significantly more improvement is possible with further optimization.

In cases where the page is prefetched, this provides publishers a tool to enable near-instantaneous loading, by eliminating network latency as a factor in page speed. However, not all situations are the same. Publishers should measure the impact of the cache on their metrics to verify that prefetching brings their visitors a net benefit.

Cost 🔗

Cost has several components, including:

monetary price
cost of meeting the cache's requirements for ingest
- matching the required output format
- serving the cache's requests for content

As an output format, signed exchanges require minimal divergence from the technologies that web developers are familiar with. They allow signing of almost any arbitrary resource (including HTML, JS, CSS, images, fonts) along with its URL and response headers. While there are some limits imposed by the spec and the Google SXG cache, it is possible to meet most of them via an automated transformation on top of an existing build pipeline. The end result should be that publishers have minimal ongoing cost in build pipeline maintenance and internal training, and minimal opportunity cost in terms of talent acquisition.

Pages opting into the cache will need to be fetched from the cache's egress points. These requests have an associated cost, as the origin needs to spend machine resources to serve it. The Google SXG cache is designed not to significantly affect the amount of traffic that sites need to serve.

A cache hit may result in an asynchronous, credentialless fetch for an update—this is equivalent to the request that publishers would have needed to serve on cache miss. Fetches may be coalesced in the event of frequent visits or publisher-set crawl budget limits. The result is a relative decrease in fetches compared to non-cached content.
A cache miss will result in an asynchronous, credentialless fetch for content, plus a redirect of the visitor's browser to the publisher origin. The result is a relative increase in fetches compared to non-cached content. However, publishers may choose not to serve an SXG cache request if they believe the expected benefit is less than the cost. An alternative to this approach would be to implement a read-through cache; this would offer less flexibility to the publisher, as they would have to serve the cache request in order to meet the needs of their visitors. Such a requirement would result in an increase in requests, as not every prefetch is followed by a navigation.

Freshness 🔗

There are various strategies to caching content that is expected to change over time:

expiration
asynchronous updates
cache invalidation / purge APIs
post-load content updates (e.g. revalidation in JS)

The Google SXG cache aims to conform to the cache-control specifications as closely as possible. However, the publisher needn't trust SXG caches' behavior. Signed exchanges provide an additional expiration mechanism that is enforced by the browser.

The cache additionally provides a heuristic asynchronous update mechanism for entries that have not yet expired. This provides an additional guard against cache-control misconfiguration or unexpected changes in circumstances that require more freshness for a particular resource.

Implementing a cache purge API is on our roadmap and we are eager to complete it.

The cache, in accepting arbitrary signed exchanges, allows use of JS to revalidate the freshness of the page, as a supplement to the above techniques. It is not a perfect solution; in the event the page needs a post-load update, this could result in a flash of stale content or a hit to page speed.

Personalization 🔗

On a per-resource basis, it is infeasible to cache a resource if it varies for each visitor.

However, at the page-level, a personalized experience can be delivered via cache through a few different mechanisms. For instance:

A script on a cache-delivered page could render cache-delivered templates based on the contents of client-side storage (e.g. cookies or localStorage). Here, network could be eliminated from the critical path, but at the expense of increased CPU.
A cache-delivered main resource could incorporate post-load updates of non-cached content (i.e. lazy loading). Here, TTFB would not be eliminated from the critical path, but TTLB would be greatly reduced, by minimizing the non-cached resources to only the personalized aspects of the page.

The Google SXG cache, in allowing arbitrary signed exchanges, enables both of these strategies.

Content negotiation 🔗

Proactive content negotiation requires knowing both what variants a user agent accepts and what variants a server provides for a given resource. The HTTP specification only provides for the former, leaving the latter up to the server to determine. Traditionally, this has meant that origin servers would perform proactive content negotiation. In order for an intermediary to cache these resources effectively, two problems need to be overcome:

The intermediary does not know the full set of variants that a given resource has, at origin.
The request headers used for proactive content negotiation are high-entropy relative to the typical number of variants, and thus need a mapping to a more cache-efficient secondary key.

However, there are various avenues to constrain the problem in order to make the solution cache-friendly.

We are working on implementing a supported-media spec to enable the common use case of varying by the user agent's form factor (e.g. mobile / desktop) without the need for responsive design.

Additionally, the Variants spec enables cache-side variance on a few different headers; if there is significant interest, it could be worthwhile for the Google SXG cache to add Variants support for Accept, Accept-Encoding, and Accept-Language.

Integrity 🔗

Both publishers and visitors want a guarantee that what visitors see is what the publisher intends. HTTPS provides some guarantees, but they are not without limitations, e.g.:

BGP/DNS/HTTP cache poisoning
software vulnerability or insider threat in authoring, build, or delivery chain
malicious client-side software
unofficial mirrors that gain traffic via search engines, social media, or any other referral

Any additional link in the chain from the author to the reader introduces some risk. Signed exchanges set a browser-enforced limit to the amount of risk introduced by cross-origin caching: the Google SXG cache is not able to serve a modification of a signed exchange and have a browser display it.

The remaining risk is that the cache may serve a previously-fetched version of the resource, as long as it is within the expiration window. I think that the options in Freshness provide sufficient mitigation for most use cases, but I am open to hearing of others.

Privacy 🔗

Visitors want their visits not to be tracked by unauthorized intermediaries, and publishers want their valuable business data not to be exfiltrated. While many pages involve lots of third parties, I believe that the Google SXG cache's usage is of very low risk to these properties.

The cache will be aware of the initial visit, as cache request URLs can easily be decoded to corresponding publisher URLs. We do not set any cookies on the cache domain.

Where the referrer and the cache are co-owned, I don't believe this decreases privacy. Methods (such as joining by IP+timestamp with cookieful referrer requests) are available for re-identifying cache requests. However, these methods are harder than click-tracking on the referring page itself, through JS or redirects.
Where the referrer and the cache are separate, this increases the sphere of knowledge of credentialless visit distribution from the referrer. I would advise referrers to think carefully about how linking to the Google SXG cache affects their privacy guarantees. As I understand it, credentialless data is not necessarily anonymous without protections such as k-anonymity and differential privacy; indiscriminate referral to the cache could reveal private URLs to Google, or sessions of several public URL visits could be identifying.

When a browser requests a cache entry, the request is to the cache origin, and thus contains no credentials for the publisher origin. The cache may make a downstream request to the publisher for the corresponding signed content; this request is credentialless, IP-shifted, time-shifted, and possibly coalesced. Because the cache is the HTTPS client, it can read the contents of the signed exchange; SXG offers no additional encryption. However, I don't believe this decreases privacy, for the following reasons:

When the referrer and the cache are co-owned, this cache entry request is for a URL previously known to the referrer. Lacking SXG, the referrer would have otherwise obtained a similarly credentialless response (without a signature).
When the referrer and the cache are separate, the cache may learn the contents of a URL not intended for sharing. This is not a new risk; lacking SXG, a third-party could introduce this URL to the cache's co-owned referrer by linking to it. It is likely not an increased risk, as linking on the web is easy, and the existing risk does not require that a publisher sign its responses. Publishers can protect against this risk through additional mechanisms beyond URL obfuscation.

The Google SXG cache doesn't mandate the inclusion of any JS that could track visitor behavior on the page, and similarly doesn't require that any outgoing links point to the cache.

SXG guarantees that any client-side state associated with the page's origin or domain, such as cookies, localStorage, and IndexedDB, is assigned to the page’s origin, and not to the cache's.

Availability 🔗

Through a narrow lens of network availability, the Google SXG cache is running on much of the same infrastructure that serves many Google sites. It is thus very available.

However, it's worth looking at availability through a broader lens of content availability, and how opting into a cache affects a publisher's ability to meet their own availability goals:

If a publisher serves a non-functional version of a resource to the cache ingestion process, how quickly can they fix it? I'll again lean on the options in Freshness to address this.
If a publisher serves a resource that doesn't meet the cache's requirements, what is the impact to visitors' experience? Here, publishers need to be aware of two classes of errors:

SXGs that Google considers malformed will impede Search's ability to trust the content it crawled, and thus index the page. The errors in this category are the same as for AMP SXGs; see the last 3 error types here. Google will retry the fetch with a lower q-value for application/signed-exchange;v=b3 in its Accept header. Per our content negotiation recommendations, servers should respond with a non-SXG in this case in order to avoid impact to their availability.
SXGs that Google considers well-formed but invalid will not be stored in the cache. Search results will link directly to the publisher's origin.

Here, the Google SXG cache does well, but there is room for improvement. We are working to lessen the impact of malformed SXGs, by narrowing their definition, and by allowing some fallback behaviors.

Metrics 🔗

Publishers want to measure the usage and behavior (e.g. LCP) of their pages. The Google SXG cache allows SXGs to include any JS; this can include a client-side pingback of any relevant information to their origin, such as Navigation Timing metrics or a session ID.

Publication intermediaries (e.g. CDNs and hosted CMS frontends) may want to measure this usage too, e.g. in order to provide their customers a reporting service as a value-add. They may want to do so while also guaranteeing not to modify the publisher-provided HTML. HTTP server log analysis does not work well for SXGs intended for referrer prefetch; because the requests mentioned in Cost are credentialless and eligible for coalescence, server log analysis is made less accurate and precise by the introduction of caching.

One partial solution to the needs of such intermediaries would be to make the asynchronous fetch non-coalesced (albeit still credentialless, since it happens during prefetch). Another would be to provide domain owners with an API to query their metrics. Both of these require publishers to depend on the cache to deliver this information quickly and accurately.

I think the best approach may be the use of an HTTP header to induce a secondary load only on navigation. This way, publishers can depend on browser behavior, which is more easily verifiable than cache behavior, and more malleable through standards and open source processes.

Link: rel=preload headers are followed at prefetch time. Because of the privacy requirements of Google Search's usage, we've needed to limit their usage to signed subresources that may be cache-served.
If implemented, crbug.com/1166059 would enable sites to set an NEL header that addresses this need.
Perhaps there is already a header that behaves in this way? I would love to discover this.

Web ecosystem health 🔗

One concern I've heard is that web developers might spend less effort on the performance of non-cached content, as their needs are met by cross-origin prefetching. I believe that the impact of the Google SXG cache would be negligible:

Prefetch traffic is limited by several factors (e.g. user agent support, fraction of referrals that are from Google Search, fraction of outlinks that Google Search prefetches, etc.).
Prefetch only reduces the network latency; pages will still need to optimize other sources of latency such as CPU usage.
Changes that improve the performance of prefetched pages often correlate with improving the non-prefetched performance. For instance:

SXG prefetches only succeed if all signed subresources have finished loading before navigation. Thus, reducing payload size benefits both prefetched and non-prefetched views.
The performance of a prefetched page view may be limited by non-preloaded render-blocking subresources. While this could be addressed by signing and preloading the subresources, often an easier solution is to take them off the critical path. This also benefits non-prefetched page speed.

I think there is potential for positive impact to web ecosystem health to offset the above potential risk. For instance:

By providing more options to reduce network latency, the Google SXG cache lowers the effective cost for publishers to meet their performance goals. This, in turn, could lead to more sites meeting visitors' performance expectations, and thus increased usage of the web.
Looking beyond Google's deployment of SXG, there is potential for deployments to provide network resiliency benefits in low connectivity environments. This, in turn, could lead to more viewership of and contribution to the web.

There may be other concerns around web ecosystem health; I'm interested in learning more.

Conclusion 🔗

Mirroring of content enables publishers to achieve dramatic improvements in aggregate page speed, by allowing network latency to be eliminated in cases where the referrer predicts that prefetching is net beneficial. But mirroring of arbitrary unsigned content is impractical; there are hurdles to overcome in meeting publishers' and visitors' standards of usability, functionality, privacy, and security.

Signed exchanges make this practical, by enabling the browser to protect pages against many potential risks associated with mirroring of their content. They provide a useful check against potential misbehavior by caches. With their deployment, we believe we can deliver a service that meets the modern needs that publishers and visitors have of caches, while also enabling a novel, but complementary, approach to improving page speed.

However, these browser-enforced protections are not iron-clad. As I've enumerated above, delivering on modern expectations of HTTP caches depends in part on the SXG spec, and in part on proper deployment of the technology. Compared to caching of non-signed content, SXG reduces the amount of trust that publishers and visitors need to place in caches to deliver on these expectations (whether on-path or off-path). It is not a zero-trust system. I hope we can earn your trust through the sum of our actions.

The AMP Project has been working hard to break apart AMP's individual components and allow each publisher to adopt only the pieces that work for them, and we are beginning to see that come to fruition. For instance:

Off-cache will allow publishers to adopt AMP without AMP caching.
Bento will allow publishers to mix AMP and non-AMP on the same page.
Self-hosting will allow publishers to adopt AMP without depending on the AMP Project's JS CDN.

Google Search has also been working towards the goal of enabling publishers to adopt any combination of technologies, though a combination of:

SXG, which allows publishers to see improved LCP from privacy-preserving prefetching without building AMP.
Page experience, whose component signals are designed to be irrespective of the web technology used to achieve them.

Though a bit of an oversimplification, I like to think of this collection of technologies as part of a continuum between maximal performance and maximal flexibility. Most engineering decisions involve trade-offs, and I would rather publishers choose where to land in the trade-off space.

I am excited to be a part of this progress. I think a world in which these technologies are available for anybody to use is better than a world without them.

In the meantime, it's possible that I missed some concerns, or that the above concerns weren't sufficiently addressed. Where that's the case, I am eager to figure out the details, because I want to figure out how to address concerns and then advocate for that.

I'm also always on the lookout for new technologies that address the same needs. There are several existing and upcoming specifications in this same space, and while no one technology perfectly meets the needs of all of its users and stakeholders, some of them land at another useful point in the trade-off space. I hope to see further exploration into the set of technologies that best balances simplicity and flexibility of the web platform in the long run.