 Hi, I'm Devin Mullins. For the past few years, I've been working on Google Search, launching tools to speed up the web using pre-fetching. For web developers, a successful strategy to improve performance should include several different techniques in combination. Cross-site pre-fetching is one such technique that has the potential to significantly speed up many of your visitors' page loads. First, let's talk about why it's worth enabling pre-fetching for your site. Improving web page speed not only benefits your user's experience, it can improve the metrics your business cares about. One study found a higher conversion rate for sites that load in two seconds or less. On the other hand, slow loading is a major contributor to user frustration. You've probably heard a lot about core web vitals. These are the metrics we think should be foremost on your mind when optimizing your user's page experience. In particular, largest contentful paint, or LCP, measures your page's loading performance by reporting the time it takes to display the largest text or image block that the user sees. To provide a good user experience, LCP should occur within 2.5 seconds of when the page first starts loading. Let's look at what contributes to the LCP of a typical page. When a user visits the page, the browser requests or fetches the HTML from the server. The server responds with the HTML, which gives the browser more hints on what to fetch next, including CSS, JavaScript, fonts, and images. Often this happens in several phases. For instance, the CSS file might reference an image file for the browser to download next. As these responses come back, the browser must also do some work to evaluate them and eventually lay out and paint components on the page. But the majority of time is spent waiting for those packets to travel from the device to the server and then back to the device. If you can prefetch all of these files, that is, fetch them before the user visits the page, then the only remaining task before displaying the page is the work the browser must do to evaluate, lay out, and paint. The result of a complete prefetch is a much faster page load. But even if you are able to prefetch some of these files, you can still see a significant improvement. Prefetching has been around for a while, but an additional consideration is warranted when prefetching pages from one site while the user is on another. Cross site prefetch is a special type of prefetch when a referrer site instructs the browser to prefetch a page on a different site. When the user clicks the link to the prefetched page, the page loads faster. But let's back up. What if the user never clicks that link? They probably wouldn't expect a linked website to learn that they were interested in this topic while they were browsing for it on the referrer site. On the other hand, once the user clicks the link, the destination site may want to know more about the visitor, for instance, to add personalized content to the page. A consequence of this requirement is that the prefetch requests can't include potentially identifying information like an IP address or cookies. How much can cross-site prefetching help? In a large-scale experiment, we looked at just the page loads where Google was able to prefetch the main HTML. We found that doing so increased the fraction of these page loads with good LCP by 14 percentage points. How much this could benefit your site depends on the fraction of your visits that are cross-site navigations. Before we dive into specific solutions to enable cross-site prefetching, let's talk about some decisions you can make. Cross-site prefetching is easy to enable for users who visit your site for the first time. For repeat visitors, some sites may take some extra development effort to personalize content. Recall that cross-site prefetching requests can't include cookies. First-time visitors have no cookies to begin with. You can enable cross-site prefetching for these users without any changes to your site. If you'd also like to enable cross-site prefetching for repeat visitors to your site and your site is personalized based on cookies, you will need to lazy-load any personalized elements after the user navigates. But what if you currently encode personalization directly in the HTML? If so, you may continue doing so when cookies are present. Lazy-loading can serve as a fallback for prefetched pages. There are some other general best practices for lazy-loading content. See this link for details. Let's look at another choice when enabling cross-site prefetching. If a referer prefetches your page but the user doesn't click on the link, that is additional traffic you must serve. To offset this, you could opt-in to additional caching. But caching content for too long could risk showing older information to your users. On the sliding scale between maximum freshness and minimal additional requests, where should you position your page? This is a choice that depends ultimately on the specific needs of your business and your users. Okay, so how do you enable cross-site prefetching? To address the need for private prefetching, new technology was necessary. I would like to introduce two solutions to this problem that you may take advantage of today. In the past couple of years, we have implemented private prefetch proxy and signed exchanges, two technologies that enable this prefetch while hiding potentially identifying visitor information until after the click. These solutions also ensure that your users see authentic content that is attributed to you. As an early adopter of these technologies, Google Search has already integrated with them so that sites may begin improving their LCP today. We introduced these technologies a few years ago and have been continuing to refine them in response to developer and user needs. We think both of these technologies are useful as they offer different trade-offs. Let's start with private prefetch proxy. When performing a cross-site prefetch using this solution, the browser encrypts the requests, sends them through an intermediate proxy server hiding the user's IP address. These requests omit credentials such as cookies. From the destination site's perspective, only the proxy requested this page. When the destination site sends encrypted responses back to the proxy, the proxy returns them to the browser because the proxy does not have the decryption key for these requests and responses. It only sees domain names. Finally, when the user clicks the link, these prefetched responses can be used to display the page. At this point, the page can establish a direct connection to the destination site for additional resources. The private prefetch proxy is currently being used by Google Search for Chrome users on Android. Efforts are underway to expand this to desktop and to other referrers. You do not need to do any additional work to enable this. You have the option to dial down how often your site is prefetched or opt out of it altogether. Pages prefetched using the private prefetch proxy are currently shown only to cookieless users for your site. Coming soon, there will be an option to support repeat visitors. Since these requests go to your server every time, they maximize the freshness of the content that you show your users. To minimize prefetched bytes, only the mainframe HTML is prefetched, not larger subresources like JavaScript or images. Also, you can adjust the fraction of prefetched requests that your site receives. See gu.gle slash p3-info for more info and updates on the options coming soon. Now let's talk about signed exchanges. With this solution, the prefetch process happens in two steps. First, the referrer site runs a cache server. This cache requests the page from the destination site and stores it temporarily. This cached page is also cryptographically signed by the original site so that the cache can't modify it. Later, when the referrer requests a cross-site prefetched, it requests a copy from its own cache. When responding to prefetched requests from the browser, the cache can reuse its stored copy without contacting the destination site, up until the page's expiration time. The signature helps ensure a chain of authenticity from the original server to the browser so that developers can be sure that visitors are seeing their content as written. When the user clicks the link, again, these prefetched responses can be used to display the page and the page can establish a direct connection to the destination site. Users of chromium-based browsers may see signed exchanges today. Google Search supports it for Android devices, but efforts are underway to expand this to desktop, and we're working with other referrers to provide support as well. To enable signed exchanges, if you use Cloudflare, click the Automatic Signed Exchanges checkbox in the dashboard. For other serving stacks, you can use one of several open-source tools. Prefetches include sub-resources indicated by a link rel preload tag or header, depending on the tool. By default, prefetching occurs for both first and repeat visitors, so you will want to lazy-load personalization. Alternatively, if lazy-loading isn't right for your site, there will soon be an option to enable signed exchanges only for first-time visitors. Since the referrer can cache prefetch requests, additional traffic to your server is reduced considerably. To increase freshness, you may lower the cache expiration time of your pages. Coming soon, there will be an API to request deletion from the cache. Both of these options may reduce the number of times that prefetching will be used. You might also increase freshness by lazy-loading updates after the page has loaded. See goo.gle slash sxg-info for more info and including updates. Okay, now let's talk about some early results. We've worked with a number of partners to enable these cross-site prefetching solutions and learn about their experiences. Here are some examples of companies that are interested in or have already started taking advantage of the technology. Early adopters have had success enabling this benefit for their users and their businesses. Cloudflare is a CDN that offers cross-site prefetching for its customers with just one click via their automatic signed exchanges feature. They have enabled over 12,000 sites to deliver a better web experience to their visitors. RebelMouse is a CMS that offers cross-site prefetching for its customers using Cloudflare's feature. One of their clients, Paper Magazine, saw a 27% increase in sessions per user for eligible users. Narcity observed a 41% improvement to LCP, an MLT blog benefited from a 21% reduction in page load time for eligible page loads. Agazeta, an early adopter, saw an immediate improvement to their LCP and in turn, their user's web experience. I hope I've inspired you to learn more about the potential for cross-site prefetching to improve your LCP and in turn, your business. I look forward to helping more people get involved in this exciting new technology. To learn more about how to integrate cross-site prefetching into your site, visit these links.