I’m Firat, the Product Manager for Automatic Signed Exchanges (SXGs). We’re excited to announce that, starting today, Cloudflare customers will be able to generate signed exchanges (SXGs) for Google Search with just one click.
You can enable SXGs Beta for your zones with a Pro or Higher plan, or for your zones with the APO subscription, by visiting the Speed tab in your dashboard:
- Dashboard > Speed > Optimization > Automatic Signed Exchanges (SXGs)
Note: There are some requirements / limitations surrounding this Beta launch [ you can read about them below ]: we kindly ask you to keep those in mind.
Signed HTTP exchanges are an open, standard delivery mechanism that make it possible to authenticate the origin of a resource, independent of how it was delivered — enabling massively faster delivery of a website from a third party, such as Google itself from its search results page, or from a news aggregator that is linking out to other sites. This decoupling enables a variety of use cases, such as prefetching, offline Internet experiences, and serving from third-party caches. It does so in a secure and privacy-preserving manner, and Cloudflare automatically handles all packaging and certificate handling.
The advantage to you as a website owner? You can improve your website’s performance by making cacheable resources available on Google’s Signed Exchanges, enable Chromium based browsers to prefetch your website on Google’s search results page and make your website faster. You can also improve the Largest Contentful Paint (LCP) which is part of the Core Web Vitals and increase your SEO ranking.
Now, imagine yourself as the ruler of your kingdom with an important message to deliver to all your subjects. You have too many people to reach, so you can’t do it alone:
You decide to enlist your trusty knights to ride out with large chests filled with copies of your message. There are villains everywhere that would love to take these messages and modify them for their own nefarious machinations for their own profit.
You, being the wise ruler you are, have a crafty plan: you have a very special stamp made that can imprint a seal that everyone can recognize, yet no one can recreate. With this wondrous seal, no one can tamper with the messages without breaking the seal and proving the forgery for all to see.
Now, your knights can bring these chests to all corners of the kingdom and hand out the messages to the masses, and your subjects can trust that the message came from you. There is a side benefit for your people, too. They can come whenever they want to pick up the message without your watchful eye, so they’re more inclined to read it at their leisure.
Maybe this is stretching the analogy a bit, but in the case of signed exchanges, a cryptographic signature on a digest of the response and headers acts as the tamper proof seal for the message. Fast forwarding our example to the present day: you want to get your newest web experience out to global distribution with the understanding that just about everyone will come through a search engine or aggregator site. Ahead of time, when you publish your content, the search engine crawls your site for content, but instead of delivering the raw content, you negotiate the delivery of the signed exchange. (This is accomplished simply through additional “Accept: application/signed-exchange;v=” request headers from the crawler that announces the preference for signed exchanges).
Then Cloudflare generates the signed exchange, using the following process:
- Cloudflare fetches the original content that you want to sign, including the response headers.
- An additional Digest header is added that uses Merkle Integrity Content Encoding to support the progressive detection of data modification/corruption.
- We also strip out headers that don’t make sense within the context of signed exchanges (like Connection, Keep-Alive, etc.) as well as security sensitive headers (Set-Cookie, Authentication-Info, etc.).
- Then these headers, including the digest, along with additional metadata, like request URL, URL of the certificate, hash of the certificate, expiration time, etc., are all chained together into a stream that is used to calculate the final signature.
- The original content, along with the headers, signature, and a fallback URL are then packed into a final binary for delivery.
This signed exchange is then cached and sent to the crawler, which also stores the signed exchange. After indexing the content, it can now show up in searches. The user then discovers the link to your content in the search results. The search engine also preloads the signed exchange for your content in the background in the meantime, effectively pre-filling the cache in the client’s browser. This exchange was delivered from the search engine, so no signal has gone to the origin yet. Thus, the search intent of the user isn’t leaked to the origin. Since the exchange is signed and validated against your certificate, the browser trusts the contents and can display the content with attribution to the original URL. Now, when the user clicks on the link to view the contents, it magically loads instantaneously from the local cache.
There are many resources on the web available that go into detail about the specific format of signed exchanges, so we won’t rehash them here in detail. But one important aspect that isn’t obvious at first glance is the complexity of managing the signing process itself. The many details involve:
- The inclusion of the atypical CanSignHttpExchanges extension to your certificate.
- The requirement to deliver your certificates in a specific CBOR (like binary JSON) format.
- OCSP stapling to ensure the validity of the certificates is required.
- Renewals of these certificates on a more frequent basis (i.e. requires automation).
- Caching of the generated signed exchanges, since they can be expensive to generate.
Luckily, all of these are in Cloudflare’s wheelhouse, since we already have deep expertise in Certificate Management and TLS delivery infrastructure. By partnering with Google on the signed exchange implementation, we can ensure the consistency of implementation, but improve the simplicity of integrating the technology with the single push of a button.
The broader implication of SXGs is that they make content portable: content delivered via an SXG can be easily distributed by third parties while maintaining full assurance and attribution of its origin. Historically, the only way for a site to use a third party to distribute its content while maintaining attribution has been for the site to share its SSL certificates with the distributor. This has security drawbacks. Moreover, it is a far stretch from making content truly portable.
In the long-term, truly portable content can be used to achieve use cases like fully offline experiences. In the immediate term, the primary use case of SXGs is the delivery of faster user experiences by providing content in an easily cacheable format. Specifically, Google Search will cache and sometimes prefetch SXGs. For sites that receive a large portion of their traffic from Google Search, SXGs can be an important tool for delivering faster page loads to users.
It’s also possible that all sites could eventually support this standard. Every time a site is loaded, all the linked articles could be pre-loaded. Web speeds across the board would be dramatically increased. Matthew’s blog post talks more about this possibility.
- Automatic Signed Exchanges (SXGs) is available for the zones with a Pro or Higher plan, or for the zones with the APO subscription.
- SXGs only works with zones that are using Cloudflare Nameservers with orange clouded DNS records.
Note: To change your domain nameservers, please follow the instructions in this article. Then, turn on the Cloudflare proxy (orange cloud) for any relevant DNS record.
- The certificates for the zone need to be managed by Cloudflare.
Note: To obtain an SXG certificate, you need to add a CAA Record for issuance of the certificate from the Certificate Authority. Cloudflare adds the corresponding CAA records in DNS on behalf of users after they enable SXGs, to make sure issuance is not blocked. If you would like to obtain SSL certificates thatare issued by other CAs, please ensure that you add the CAA records for the CAs after enabling SXGs.
- Content needs to be cached every 120 seconds or longer.
Note: Google checks to make sure that content is cached over two minutes to generate an SXG. Please ensure that content is cached every two minutes or longer:
Dashboard > Caching > Configuration > Browser Cache TTL
- AMP Real URL needs to be disabled if SXGs is enabled:
Dashboard > Speed > Optimization > AMP Real URL
- Currently, signed exchanges are used by Google for Android search.
- Google does not load signed exchanges for all search results on a page, only a selection.
- Signed exchanges can strip out certain cookies and headers, and create problems with dynamic content. The following hop-by-hop and other uncached headers will be stripped during the signed exchange generation:
- Hop-by-hop header fields listed in the Connection header field (Section 6.1 of [RFC7230]).
- Header fields listed in the no-cache response directive in the Cache-Control header field (Section 22.214.171.124 of [RFC7234]).
- Header fields defined as hop-by-hop:
Connection, Keep-Alive, Proxy-Connection Trailer, Transfer-Encoding, Upgrade
- Since Cloudflare cannot be sure whether a signed exchange does or does not include private information, a signed exchange will not be generated in the presence of the following headers:
Authentication-Control, Authentication-Info, Clear-Site-Data, Optional-WWW-Authenticate, Proxy-Authenticate, Proxy-Authentication-Info, Public-Key-Pins, Sec-WebSocket-Accept, Set-Cookie, Set-Cookie2, SetProfile, Strict-Transport-Security, Vary, WWW-Authenticate
There are a couple of ways to ensure that SXGs is working properly for your zone:
- Run the following command in your terminal:
curl -svo /dev/null https://example.com -H "Accept: application/signed-exchange;v=b3"
- Verify that
the Content-Typeis set to
- On desktop, open Chrome and click on F12.
- Select an Android phone via the Device Mode.
- Navigate to the Network tab.
- Search for your zone in a way that it appears as a top result. For example, yourdomain.com + website
- Under Type, you should see the result with signed-exchange / Redirect.
- Open Google Search Console
- Do a Mobile Usability URL Live Inspection of a URL link on your site
- Inspect the MORE INFO → HTTP Response
- If content-encoding: mi-sha256-03 is displayed, it means SXGs is working properly for your zone.
- For a list of tools that you can use to debug SXGs, please check out web.dev’s guide to SXG tools.
- If it’s an AMP page, you can check out the AMP status report - Search Console Help, which explains the impact.
- For non-AMP cases, or non-AMP SXGs customers, unfortunately, a help page doesn’t exist yet which would describe the error type breakdown, but if there are any critical errors that would warrant disabling SXGs:
- To ensure that Googlebot is able to crawl and index a page served by SXGs, take these steps:
- Verify that the Content-Type is set to application/signed-exchange;v=b3.
- Make sure that the dump-signedexchange command succeeds.
- Check that the signed URL matches the request URL exactly.
I am getting the following error in the Search Console (AMP pages): “The dates for the signed exchange are invalid.”. Is this a problem?
No. Google can still parse the signed exchange and treat it like normal HTML, so it falls back to earlier behavior. In this case, it’s an AMP page, so it should fall back to AMP behavior.
We use Digicert for SXGs certificate issuance, and once SXGs is enabled, we add the CAA records on behalf of the zones:
% dig example.com caa
> ;; ANSWER SECTION: > example.com. XXXX IN CAA 0 issue "digicert.com; cansignhttpexchanges=yes" > example.com. XXXX IN CAA 0 issuewild "digicert.com; cansignhttpexchanges=yes"
There are requests from the “/.well-known/sxg-map” path that I am not familiar with. Should I be concerned?
No. This is for an unreleased/in-development feature. It’s safe to block those requests, and the Users can ignore them.
There are “Content type of cert-url must be application/cert-chain+cbor” errors in my console. Is this a problem?
No. It represents a cache miss when the website gets a 200 with a Location header and without a Warning header; it should be temporary.
Please let us know if you have any questions.
Thanks again for choosing Cloudflare!