[MUSIC PLAYING] BARRY POLLARD: Hello, everybody. My name is Barry Pollard. I'm in the Chrome
Developer Relations team here at Google, specializing
in web performance. And I'm here to talk to
you about a new feature that we've been adding to Chrome
over the last couple of years that has potential to
dramatically improve the performance of your website,
to move it from not just loading fast but to loading instantly
because, let's be honest. Web performance can be tough. There's a lot to learn
and a lot to understand. And in part, this is due to
the inherent nature of the web. The web is a globally
distributed platform and requires sending requests
back and forth across, potentially, large distances to
get content for that web page. And that is limited by
some fundamental physics. We can't go faster than
the speed of light. And believe it or not,
electricity and network requests are not that far off
the speed of light. As you navigate around
the site, more requests have to make that same
travel back and forth across those distances. And expectations
from visitors only go up for navigations
around the same site. You'll get a little
bit of leeway if people click
to go to your site while they wait for
the site to load. But once it's loaded, to click
within that site, if it is slow, they will 100% blame your
site for not being fast. Four years ago, Google
introduced the Core Web Vitals, which consists of three
metrics to broadly measure the three different aspects
of the user experience. One of these measures--
page load speed, which is represented by the
Largest Contentful Paint metric, or LCP for short. LCP measures the time
from when the user started clicking on a link until
the largest bit of content from the page was
displayed, typically a hero image, the H1 element. Each of the Core Web
Vitals has thresholds. And for LCP, that's 2.5 seconds,
under which it's seen as good, or four seconds, over
which it's seen as poor. And anything in between
is meh, needs improvement. We recommend measuring
these thresholds at the 75th percentile to ensure they are
reflective of the majority of page visits. And we've seen huge
improvements in how websites perform in this
metric since introducing LCP. Over 70% of desktop sites
now meet the good threshold for the majority of
their page views. And nearly 60% of mobile
websites do the same. Since the introduction
of the LCP metric, both measurements have increased
by over 36%, increases of 19 and 16 percentage
points respectively. The 2.5-second threshold was
set with a combination of user experience, research, but
also, achievability in mind. There's little point in
setting a threshold that is simply unattainable for
the vast majority of sites. We wanted to set
a threshold that would encourage sites to
improve their performance but not discourage them
from even starting. And we think we got
that threshold right. But while 2.5 seconds
does represent a good user experience, a
faster load would be even better because 2.5 seconds
is still quite a long time. 1, 2, 2 and a half. Stepping out of the
web context, if you're reading a book or an
ebook in these times, you'd be frustrated if it
took more than two seconds to actually turn the page. Or I don't know about you. If you've got a television
and you change channels and you're flicking up, whenever
that's more than a few seconds, that's really
noticeable and lagging. It's quite irritating. But the web has these
built-in limitations I talked about before. So we can't consistently get
faster than this 2.5 seconds. There is no magic solution
to web performance. Or is there? To improve loading
speed, we normally try to concentrate on just
making sites load faster. Easy, yeah? And we focused a
lot on this option, helping developers
optimize their page to load the right resources
in the right order. But there's always going
to be limits to how much you can optimize here. An alternative optimization
is to load in advance. That way, the user doesn't pay
the full cost of that navigation as they navigate. And the user
experiences a fast site. And recently, we
spent a lot of time looking at this second option,
and we want to make that easier. And we're pleased to be able
to present this work here. The Speculation Rules API is
a new API from the Chrome team that allows you to
speculatively load the next content,
the next navigation, in advance of the user
actually navigating there. It allows you to prefetch
or even fully prerender a future navigation. So when the user clicks on
that link, it's just quicker. How much quicker? Well, with a full
prerender, this allows a dream of
instant navigations. In the field, one site has
seen a 20-millisecond LCP, which is pretty much
indistinguishable from instant. And that's a real field number. It's not some hypothetical
lab simulation. And I'll talk about
some more results on sites I've seen later on. So just take that as a little
taster of the possibilities with this API. And this is similar
to the improvements we've seen with the
back-forward cash or Bfcache. We've been advocating that
as a performance improvement for the last couple of years. And it's recommended to
optimize for the Bfcache. But that only helps
with revisiting pages. Speculative navigation
deals with future navigations and so complements
the Bfcache very well. And the Chrome browser
also speculates using the same technology
as Speculation Rules. When you type common URLs as you
navigate around into the address bar or when you use
the Bookmarks bar, Chrome is speculative
prerendering those pages so that they load quicker. You may have noticed
over the last year using your Bookmarks bar has
got a lot quicker in Chrome. And these are all
ways to achieve instant-navigation experiences. Now, an important
point for this API is it's for full
page navigations as controlled by the browser. Single Page
Applications, or SPAs, have their own
methods of updating only the content that
is changed and are not in scope for this API. This API allows us to bridge-- [COUGHS] this API
allows us to bridge the potential gap
between a multi-page app or a web page and
a performant SPA. Saying that, SPAs can still
benefit from this API, as the SPA itself can be
prerendered from another page and potentially avoid any
of those frustrating loading experience-- loading spinners
that we all experience. We've worked really hard to make
this API as simple as possible but also leave open the option
for more advanced use cases. Let's delve a little
deeper into how it works. Web developers have had the
ability to preload and prefetch in the past using
the link rel syntax, but often, those were used more
for subresources, JavaScript, CSS, images that you
want to load quickly. They don't particularly work
well for navigation resources, the HTML documents themselves. They have a number of
interoperability issues where they look like they're
working, but often they don't. So we avoid-- we recommend
avoid using them for these. Chrome has also experimented
with full prerendering before with a link rel=prerender. But that was kind of
a basic implementation with a number of issues. We removed the prerendering
ability a few years ago, and we kind of consider
this API deprecated. Speculation Rules is link
rel=prerender done right with lots of considerations of
when it should trigger, and just as importantly,
when it should not trigger. We've also carefully
considered what happens for certain APIs
that don't make sense during a prerendering stage. Autoplaying videos
and pop-ups, these are held back until the page
is navigated and activated. Rather than build on
the link rel syntax, Speculation Rules is a more
expressive JSON-based API. At its most basic,
the API simply requires adding a JSON
object in a script element with a type Speculation
Rules containing a list of same-origin URLs
on the page to prerender. This example asks the browser
to prerender two URLs-- next.html and next2.html. Chrome can then start up
two background processes for those two links. Think of it like having two
hidden background tabs working in advance behind the scenes. Then, if the user clicks
on one of those links, the prerendered page is swapped
in for the current page. To the user, nothing
is different. The page just loaded faster. The API also supports
prefetching navigations. That is fetching
the document itself without all the subresources
and without rendering it. This can be a good
starting point for those wanting to be a
bit more cautious when first starting out with this API. Later, we'll talk about
some of the considerations some sites, particularly
the more complex ones, may need to be aware of,
which might make prefetch more attractive initially. And as you can see, prefetch
has the exact same syntax as prerender. URLs to speculate can be
included in specific page types for common URLs that are
likely to be navigated to next. On pages with a series of steps,
a learning course, for example, you could prefetch or
prerender the next step of the course, as
there's a high likelihood of the user navigating to that. Or on a new site, you may
want to prefetch or prerender the headline article if many
users typically click on that. URLs can also be
injected into pages by adding the JSON
declaration through JavaScript for more powerful use cases. How the list of URLs
to inject is determined is entirely up to you. Perhaps it will depend on how
the user interacts with the page or be based on analytics of what
typical users do to this page next. Machine learning also
has huge potential here, and we have some examples
of that coming up later. The JavaScript
option also allows you to update the list of URLs
throughout the page lifetime as more indicators are received
to the best pages to speculate. And this is done through
standard Dom manipulation. Multiple Speculation Rules
on a page are supported. So new speculation rule
sets can be injected, and old rule sets
can simply just be removed, which will cancel
any speculations for that rule set. The Speculation Rules API is
available today in Chrome, and you can add it to many
existing pages right now. And this API is a
progressive enhancement. For browsers that do
not support the API, they'll simply ignore it as
an unrecognized script type. You don't need to
completely rewrite your web page to a new stack. You don't need to use
a particular framework or platform. You just add script
element to existing pages. In fact, you may not even need
to change your page at all. Most CDNs these days allow you
to inject content or headers at the edge. Edge workers can be used to
inject the JSON declaration onto the page itself based
on whatever logic we see fit or that the CDN might know. And the API even supports
referencing the JSON declaration through a URL provided
as an HTTP header. Speculation by its very nature
means taking an educated guess as to what page the user
might navigate to next. To reduce the
guesswork, we can wait until the user gives
us a hint as to what they want to navigate to. There are JavaScript
libraries that do that. And when the user
hovers over a link or starts to mouse down on
it, they spring into action and attempt to prefetch that
link and give you a head start. And even that small gap
between the pointer down event and the click event is usually
enough to get a head start and give a little bit of
a performance improvement. The Speculation Rules API
builds these types of heuristics right into the browser. So you can run this
without JavaScript. Earlier this year, we launched
a new feature in the Speculation Rules API called document
rules to handle this common use case of hovering or
starting to click on any link in the document. Documentary rules
allows you to tell Chrome what links
on the page are eligible to be
prefetched or prerendered based on URL patterns
or CSS selectors. And it also allows
you to tell when to trigger those speculations. To tell Chrome what
links to consider, you specify a where object
instead of a list of URLs. In the first
example on the left, it says "all same origin links
are eligible for prerendering." I'll get into when they're
prerendered in a second. The second example on the right
only says "only those links which are specifically marked
with a prerender class are eligible." And you can change this
class to whatever suits you. You can build up more
complex "where" patterns, including exceptions
using the "and" or "not" keys to exclude certain URLs,
as shown in this example. Here, we're excluding
the WP admin page used for WordPress
administration, and links specifically marked
with a do not prerender class, or links marked
with a rel-nofollow because typically, you
don't want those ones to be seen in advance. We've also added an
eagerness setting to decide when to prefetch or prerender. And this can be set
to conservative, only on pointer down when
the user actually starts clicking on
the link, or moderate, which is on click,
on pointer down, but also, when the user
starts hovering over the link and has been hovering over
for 200 milliseconds or more, and finally, immediate
or eager, both of which prefetch or prerender
as soon as possible. At present, this
option is usually better suited for a list of
URLs rather than document URLs. And the reason, by the way, that
we have two identical settings at the minute is we
plan to separate these out in the future because
the Chrome team is working on improving the precision
of some of these settings with more advanced heuristics
beyond hovering or pointer down, especially for the mobile
case where hover is generally not an option. So watch this space
as we improve this. Document rules with
eagerness means that the same
Speculation Rules can be added to any site in the page. You don't need to decide per
page which URLs to add in there. This greatly simplifies
the deployment of this API. The example here is a
simple but powerful rule set that would likely benefit many
websites with little downside. Alternatively, sites can
mix and match rules here, perhaps always prerendering
the most common link in advance with a high-eagerness
setting but still covering the other links in the documents
with a more moderate setting. Document rules, again,
are available today in Chrome and
Chromium-based browsers. They're not behind a flag. They're not anything
you need to enable. These are in production
and ready to use. OK, next I want to talk
about DevTools support because this is fantastic. The Chrome team has
done a lot of work to give developers
all the tools they need to fully understand this
API and see what it's doing. So let's see these
tools in action. We'll use a demo site. I know. I know. We'll get to a real
site in a second, but we'll start
with a demo site. So bear with me here. So we load the demo site, and
we're going to go into DevTools. What we've done is we've
added three new panels under the Application tab to
control Speculation Rules. And when you load a page
with Speculation Rules, in the top right, you can
see whether the page itself was loaded with the
API and then also what URLs it has speculated. Here, we can see 18
speculations have been initiated by this page, and that
corresponds to the 18 fruits that you see on the left. Now, some of you might
say there's 19 fruits, but one of them is repeated. So the API is clever enough
not to prerender the same URL. And if we look at
the Rules panel, we can actually see
the JSON declaration. So as I say, you can have
multiple JSON declarations. We've only got one on this page. And this is the JSON. So we're basically
using Document Rules. And this, by the way,
is the same thing that you'll see in the Dom. So you can actually move
up to the Elements panel, and you can hunt around and
find out where you injected it. But to save you
that hassle, we just make it available nice and
simply within these application panels. So yeah, Document Rules,
we're matching all the URLs. That's why you see all
the 18 fruits eligible. But we've also added this
"not" clause here to say, "don't include
recipes in there." And if we scroll down
the page, there's some recipes here-- banana
split, blueberry smoothies. They're not eligible to
prerender for whatever reason. Maybe they do more
complex things. We've also set the eagerness
setting to moderate. So that's the hover activity. So as we hover over a page-- let's do that now. We'll hover over
one of these links. In the top right, you
can see 18 not triggered. But when we hover over
the links, we go to 17 not triggered and 1 ready. Then, if we move into
the Speculations panel, we can, again, see all the
eligible links, one of which is ready. And as we hover
over other links, we suddenly see
them become ready. Now, importantly, Chrome
only holds two in memory at once for this
moderate setting. So as we hover over the
kiwi link, we eject Apple and say it's no longer
eligible just to save memory. And if we hover over
pineapple, we'll eject the next-oldest link,
which, in this case, is orange. And you can
respeculate, by the way. So if we hover over
apple and orange again and then if we
actually look at orange, you can use this panel to
get some more information. So we can click on it. It will tell you if the
Speculation succeeded or if it failed
and why it failed. And this is the
really clever bit. You can actually switch
DevTools to have a look at these background pages. So if we flip to orange and
go to the Elements panel, this is the Elements panel, the
full Dom of that orange page. You can see the H1 shows orange. We can flick it back to the
page that we're actually viewing where we've got common fruits. So you've got the full
DevTools experience lab. Similarly, in the Console, we've
got the Console logs of that. And again, flip back and
forth to the main panel and to ourselves. The Sources panel, as well,
is the full Sources panel of what that page is loading. The Network panel, you can
go to your HTTP headers exactly what's going on. Images, you want to
actually see the images? You can see them. Flicking back to the
Application panel, and at the minute we're not-- I'll go to Speculative
Load Summary panel. We're not showing
anything on this page, but if we go back
to the main one, we can see that we have 14
URLs that are not triggered, two URLs at success-- that's the apple
and the orange-- and two URLs that have failed. They haven't really failed. They prerendered
earlier, but then we evicted them from
the cache whenever we [? recreated ?] those. We click on the orange, we get
the success in the top right, but more importantly, an
LCP time of 78 milliseconds. And I'm going to stop there and
give you the round of applause I know you want to give for that. [APPLAUSE] Seriously, though, 18 millis-- sorry, 78 milliseconds,
that is, like, unbelievable. Just to actually draw the pixels
on the screen in that time is impressive. So this really is
instant browsing. OK, enough talk. Let's see this in action
on a real website. Ray-Ban implemented Speculation
Rules in their website. And as you'll see, this is a
media-rich interactive website. It's Ray-Ban. So I guess we'll
look at sunglasses. If we load up the
sunglasses, I've got DevTools open in the
bottom you can see here. And as we're hovering over
the various sunglasses, we can see those prerendering,
much like we seen in the demo. And when we click on the
page, it loads instantly. And this is a rich, complex
page that would normally take a little bit of time to render. And it also prerenders the next
page, the Customize It page. And again, you can see,
just clicking on it, it loads instantly. Now, that was pretty quick. So let's just watch
it one more time. We go into Sunglasses. We do there. And even this fast connection,
you see the Sunglasses page itself, which doesn't use it, it
takes a little bit time to load. But we're hovering here. We're prerendering. We click, and
boom, instant load. Now, here, you
might notice, we're already-- we've gone with a
higher eagerness setting here because this is quite
a complicated page. So it's already speculated that
customized link in advance. And it's giving a lot more
lead time to go there. And when we click
on it, it's there. And again, this was achieved
with a simple insertion of a Speculation Rules
JSON object onto the page without any other
changes to the page. Ray-Ban have implemented
this for their US visitors, and they're rolling out to
the rest of the countries as we speak. Tokopedia was another early
tester of Speculation Rules. Tokopedia is an Indonesian
technology company with a leading
e-commerce platform with more than 1.8 billion
registered products on its marketplace. Now, in this
side-by-side example, you can see the impact
of prerendering leading to a much faster load time even
when using a slow connection and even when the browser
cache isn't primed. Now, while this
particular example may be an extreme
example, overall, they saw 4.8 times better LCP of
their product-description page which used Speculation Rules. Now, one of the main concerns
that we're very conscious of is that speculative
navigations do have a cost. It does take extra bandwidth and
CPU to prefetch and prerender these pages. And it's not just users
that bear the costs. Site owners don't really
want every page view to result in double, or
triple, or much worse infrastructure costs either. So the Chrome team
has thought very hard about minimizing these
speculation costs. So let's talk about
some of the ways that we're trying
to reduce that risk. Document rules and
the eagerness setting that I talked about
earlier allows the browser to avoid speculating
until the user gives a clear indication that
they intend to visit the URL. This alone can
drastically reduce the chances of overspeculating. On top of this, Chrome
has added limits to the amount of
speculations that can be completed per page
depending on the eagerness setting. For prefetches, Chrome allows
up to 50 speculative navigations per page load. That seems high. I'll talk about in a
minute about why we allow such a high number there. For prerender, there's a
more conservative limit of 10 prerenders per
page load, as they'll fetch subresources and also
use a bit of memory and CPU. Now, these limits
are upper limits to really prevent
overuse of this API. They're not targets, and
speculations should only be used when they make sense. With lower eagerness
Settings, Chrome-- this is the one where
Chrome will only speculate when the user
gives an intent with a hover or the mouse-down action. In these cases, it's even
possible for the browser, as you saw, to change the
links that are speculated. Therefore, as the browser
can act on these signals, it's possible to use much lower
limits with a FIFO-based queue to really conserve memory. And that's what we saw
earlier in those demos. With the browser in
control, it can also avoid speculative navigations
in certain circumstances. Chrome avoids speculation
in the following conditions, thus reducing the impact
of spending resources on speculations. It won't speculate when
save data is turned on, when energy saver is
triggered due to low battery, when Chrome detects it's under
memory pressure, when pages are opened in background tabs, or
when the user has turned off preloads in their settings. Additionally,
cross-origin iframes are not loaded during
the prerendering stage and are held back until the
page is activated by the user. I'll talk more about
that one in a minute. Speculation rules also makes
efficient use of the HTTP cache. Navigation speculations
are primarily intended for
same-origin navigations. For these, there is
often a large amount of reuse between
different pages. Many pages within a site
will reuse the same assets from site-wide CSS, JavaScript,
icons, logos, imagery. The API both fetches
from the cache but also saves any resources
it has to fetch into the cache. So even when a speculation
is not ultimately used, its assets are still
stored in the HTTP cache and may benefit
future navigations whether prerendered or not. For example, if you
prerender a product page on an e-commerce site or
an article in a news or a blog, you're likely loading
a lot of assets that will be used
by other product pages and other articles. So that previous speculation,
even if it's not used, it's not entirely
wasted, and you often benefit future
navigations anyway if you go to a different
product or a different article. You'll have the JavaScript and
the other access for that page type cached. OK, that leaves the HTML
document itself and the media, the images, and so on. So HTML documents
are actually often a lot smaller than people think. According to the HTTP archive,
the median HTML document is only 30 kilobytes in size. Even going all the way up
to the 90th percentile, documents are less
than 150 kilobytes-- not small, but not as
large as many people think. For the images, lazy loading has
also become incredibly popular on the web with 30% of sites
using native lazy loading in their images, again,
according to the HTTP archive. And for these sites,
images well below the fold will not be loaded during
the speculative loads. And as I mentioned earlier,
for speculative loads, cross-origin iframes are not
loaded during prerendering. And this can often be heavier
content like videos, map embeds, and they're not loaded
until the page is activated. So this is a really
enhanced lazy loading where even the above-the-fold
frames are not loaded during the prerendering phase. And all that's by
default, by the way. There are APIs that
site owners can also use to delay certain activities
until after activation. This example calls a function
after the prerendering change event is detected. And that's a new event that
we've added specifically for this API. You can use it to take care
of activities you may not want to happen until after
the page is activated, for example, starting
an animation, or fetching large resources,
or connecting to a chat server, whatever. Analytics is one such activity
that usually makes more sense to happen after activation. You want to measure actual
real-user visits, not potential visits that they
may or may not click on. Now, Google Analytics
does this automatically. You don't need to do this. But other analytics providers
may not do this yet, as this is a fairly new API. So you can use those
same APIs to delay those. This example uses a
promise-based methodology to make it easier to
slot into existing code. And ads are similar. Like Google analytics,
Google Publisher Tag, or GPT, and Google AdWords already
delay automatically with knowledge of this API. But again, other ad providers
may not do this, though, as ads are often served
in cross-origin iframes, the display of those ads and
any analytics from those display will not be delayed until after
activation happens anyway. And with prefetch or even with
prerender on a lower setting, these examples may
be less of a concern as there's a much, much higher
chance that the page will actually be visited by the user. So that's why those modes
can be a good stepping stone into this API while you update
your code to add these wrappers. So speculative navigations
do have a cost, but that cost may well
be lower than you think. It pays to be mindful of the
cost of navigation speculations, but at the same time, be aware
of some of the mitigations that reduce this cost. In many cases, it's the cost of
loading a single extra iframe onto a page, and many pages
load many iframes as it is. OK so we're pretty excited about
the potential for Speculation Rules, and we're already seeing
a great uptake for this API from the ecosystem with
various platforms and partners that we work with. WordPress powers
well over a third of all the sites in
the web, and it's often used for static websites
where Speculation Rules can be a low-risk, easy win. As part of Google's work on
the WordPress Performance Team, we've written a plugin to
make, enabling this as simple as possible. By default, it prerenders most
URLs with a moderate eagerness as soon as the
plugin is activated. But I'd offer some settings to
allow you to change this default should a site wish. We saw 10,000 installs of this
plugin in the first few weeks after it was announced. That's 10,000 sites
benefiting from Speculation Rules' performance gains. We've also seen numerous pieces
of very positive feedback from the WordPress
community for this plugin. And although those plugins
and experiment are present, we'd love to be able
to integrate this into WordPress core should
it prove successful. Akamai is one of the
world's leading CDNs and has seen some
impressive results from implementing
Speculation Rules, including a 25% improvement
on an already highly optimized site. They've also documented
how their Akamai customers can enable Speculation
Rules through the CDN using a special HTTP header and
are working with customers to roll this out further. NitroPack are a
web-performance company that started experimenting
with Speculation Rules since the API became available. And as you may have heard
during the developer keynote, NitroPack implemented
Speculation Rules in conjunction with their own custom
machine-learning models. They were able to
shave nearly 40 seconds off the sitewide page-load
time through the use of their navigation AI product. They saw a 75% improvement to
LCP from Speculation Rules alone and an extra 20% of that
on navigation AI offering. And it wasn't just
LCP that benefited. NitroPack saw an 80%
improvement to CLS for pages that were prerendered. You often see layout shifts
as the page is loading. So by doing that
in the background before the display to the user,
you see that CLS, and the metric understands that
and measures that. Cloudflare is another
CDN experimenting with Speculation Rules. And Cloudflare powers
approximately 20% of all websites. They've been working on a
machine-learning prediction model using the site-traffic
analysis of those using the Cloudflare network
that iterates in real time as more traffic is seen. Using this, they've
managed to see up to a 98.9% accuracy
in predicting the next navigation in the lab. They're just completing
lab testing now and are starting to roll
Speculation Rules out to customers with the ultimate
aim of rolling this out to a large percentage
of their customer base. And those are just some
of the success stories we've seen with this API. We have many such
success stories with a growing number of
platforms and companies that have integrated support for
Speculation Rules either already or coming soon. And if you're interested
in implementing it into your platform
or frameworks, come and speak to me afterwards. But why are we so obsessed
with shaving off more time? Isn't 2.5 seconds good enough? Well, another exciting
thing about this API, on top of the
web-performance gains, is the new opportunities
that it can lead to. The View Transitions
API is a new API to allow developers to more
easily animate between pages. Last year, we launched the
same Document View Transitions for SPAs. And soon, we'll launch
Cross-Document View Transitions for multi-page sites. For a view transition
to be really effective, sites need to reduce any delay
getting that new page ready so the browser can start the
transition as early as possible. And one of the best
ways of doing this is with Speculation Rules. Cross-document View Transitions
and prerender really are a match made in heaven. In this demo, you can
clearly see the difference between the View Transition
without prerender on the left and with prerender on the right. They both have the
same transition effect between the pages, but even
that small delay on the left pull you out of the
experience a little bit, whereas on the right
with prerender, the same transition starts as
soon as the link is clicked, and it feels much more smooth. Now, if you want to know
more about View Transitions, check out Ramsey's talk at this
Google I/O for more information. And this is just one example
of the Speculation Rules API enabling new opportunities by
just taking the performance issue off the table. We're really excited about
the Speculation Rules API, and we're expecting to see
a lot of growth of this API in 2024 and beyond. Hopefully, this talk has given
you a little taste of the API, and you're eager
to give it a spin. Well, everything I've
talked about today is available in
Chrome right now. You can start
using this API now, and your users can benefit
from it right away. Check out our documentation
on developer.chrome.com at this short link to
answer any questions. And it's also been documented
on NDN if you prefer. And we'd love to hear your
feedback on how you're getting on with this API. There's details of how
to provide that feedback at the bottom of that link. And for Google I/O, we've
also published a codelab to walk you through adding
this API to your site in a step-by-step manner. Thank you for your attention,
and I look forward to 2024 being the year of more
instant navigations. [APPLAUSE] [MUSIC PLAYING]
