Alright, let's get started. So I'd like to introduce Barry Pollard.
Hi everyone, thanks for coming. My name is Barry. I'm a web performance developer advocate
in the Google Chrome team. I work on the Core Web Vitals initiative. I look after the web
Vitals.js library, crux, lighthouse, Chrome DevTools, all sorts of things that work about.
Today I'm going to be talking about better than loading fast is loading instant. I'm
going to talk about a new feature that we've added to Google Chrome very recently. So show
of hands. I'd like to answer this question. So who here? No one? No one? No one? No one?
Oh, oh, look what happened there. Like nobody likes that, do they? Nobody likes staring
at a blank white screen for ages. It's even worse whenever it seems to have loaded but
nothing works and then something else comes in. So hopefully you're all here at the web
performance track because you actually want websites to be fast. And Google tried pushing
this initiative quite hard a couple of years ago. So we launched this Core Web Vitals initiative.
Show of hands of no tricks this time. Anyone heard of the Core Web Vitals initiative here?
Okay, good. Sometimes I ask this question and nobody has. So we released these three metrics
and we measure them in Chromium, which means they're available in Google Chrome and Edge
and all the derivatives and that sort of thing. Recently Firefox launched LCP. Yay. So we're
hopefully starting to get cross-browser support for them. But there are three metrics that
are supposed to measure three different facets of the user experience. And we give recommended
targets and say whether you're good, whether you're poor or somewhere in between needs improvements.
There is a change happening, by the way. We're changing one of the metrics. FID is dying,
resting peace. We're going to be using it with IMP. I'm not going to talk about that
now. I would love to talk about that. So if you want to grab me afterwards, because there's
a lot going on there, but that's the whole subject of a whole other talk. What we are
going to be talking about mostly is the first metric, largest contentful paint. And it's
a measure of when you click on a link until the largest content appears on the new page,
which is supposed to be representative of the pages mostly loaded. Maybe there's some
other little bits still coming in there, but it's generally the pages pretty much there
and the user can start using it and stuff like that. In this, we said 2.5 seconds is
seen as good. Anything above four seconds is seen as poor and as I say, somewhere in
between that, it's like, eh, could do as I'm improving. And 2.5 seconds sounds like a lot.
I see a lot of people in the forums never read the comments, but I occasionally read
them and they're like, oh, 2.5 seconds. Google thinks that's fast. That's terrible. And you
think computers measure things in microseconds or milliseconds, stuff like that. 2.5 seconds
seems really poor. But the truth is that's actually quite a difficult metric. Meeting
two-thirds of websites don't meet that, because there's a lot that happens whenever you click
on the website. We'll talk about that in a minute. So getting 2.5 seconds is a tough enough
target. But to me, I'm looking beyond that and I'm saying, can we do better than good?
How can we do better than 2.5 seconds? How can we get instant? And that is very difficult
on the web, because the website, it's got an inherent slowness to it. It's a distributed
system. The internet is a network of computers and you sit on the browser at one end, you
make a request, has to go to a server, and then this other request has to come back.
This is different than traditional software before the web came along, where you download
it or throw in 18 different floppy disks or get that free CD-ROM that you got in the magazine
and actually install it locally and nearly everything's available locally. The web, nothing's
available locally, not even the program. Okay, the browser is, but after that, everything
that you want gets there. And this, by the way, is the best case scenario. The reality
is more like this. You connect to something, maybe you're on a mobile and it's a mobile
network or an ISP and it's going through a million different switches and stuff, not
even the server gets to some load balancer which connects to a server which then has
to connect to a database which then has to get some of the stuff. The last talk talked
about connecting to a database and doing that and gathering information and sending it back.
So websites cannot be fast, or so you think. The SBA is one attempt to work around this,
so it tries to load a lot of stuff up front, maybe prefetch some stuff and get stuff and
do that. But that often results in this guy. Anyone seen this sort of thing before in the
web? Oh, sorry, by the way, do we all know what an SBA stands for? Yeah? That's right.
Spinner page application. So this has become far too common on the web where you take that
hit up front, but to a worse degree. Like it's kind of expected with app installs. You
sit there and you wait and you see the loading bar going on the web. You don't expect that.
You're not doing that. Particularly if you're going to look at one thing, I want to know
what time Barry's fantastic talk is. And you go there and you get this, you don't when
the first time website, they don't use an SBA, by the way. But still, this happens too often.
And do you know what it reminds me of, actually? It reminds me of growing up in the 80s, where
you used to get this whenever you load stuff from a set desk and usually some funky music.
Some of them even gave you games while they were loading the main game, because it took
a while. And like the 80s was 10 years, twi... All right, I just realised how old I am.
The 80s was a long time ago. And the fact that we're still dealing with this is kind
of depressing. And that's before you even get to the browser. So once stuff gets to
the browser, then it has to run that JavaScript. And that's where you see the spinny sort of
stuff. It has to do style and layout. It has to do paint. It has to do composite. These
are all different parts of the browser just creating the website once you get the code.
And that takes quite a long time. And again, this is usually measured in milliseconds, but
paints and composite and stuff like that can take an awful lot of time to actually do that.
And particularly with, again, sorry to dunk on SPAs, but they end up re-rendering the
page multiple times at quite a high cost. And you quite often end up with this. You
get a beautiful picture of your webpage, but do not touch it. You can't interact with
it for another couple of seconds. You know, you sit there and you click on something,
nothing happens. And then suddenly the menu opens and you lose a 16 time and you're like,
what the hell is going on? So to deliver instant loading experience, we need to be less reliant
on both the network and the client side processing. So just solving the network doesn't really
fully answer the question because of all that stuff that has to happen once you have it.
So you've been asking, how can the browser help with this? And there's a couple of things
to do about it. They all basically fall into these two categories. You can prefetch stuff
in advance. So get it before you need it rather than waiting for the user to ask for it. You
sit there and say, I'm going to try and get it in advance. Or take it a step further and
actually pre-render the whole thing. So not only do you get the resources, but you actually
do a lot of that browser work and actually lay it out, actually sit there and render
it almost like we do this ourselves sometimes. I don't know about you, but I right click
on a link and say open in another tab because I know it's going to take a while. I've been
at this website before. Let that load in the background and eventually go there.
Prefetch, been there a while. Service workers are shown as great things. They can go ahead
and prefetch stuff, which is great for next navigation. It's also good for offline stuff.
SBAs, as I said, I gave them a bit of abuse earlier, but they're quite good. Sometimes
some SBAs in the boot right is trying to get you next stuff whenever it goes there.
The browser has an inbuilt, HTML is an inbuilt decorative API where you can just do link
rel prefetch, say I want this JavaScript as script. There's a new speculation rules
API that I'm going to perform the basis of this talk. Prefetch, basic concept, this is
from a site I used to work at. We're on a login screen. I'm pretty sure I know where
the next page is going to be. Most people that come to this login screen are going to
log in, hopefully, and they're going to want the app loaded. We go ahead here and we load
the actual area. It's a client-select rendered app, one of those spinny things because how
everyone was doing it at the time. We load the app itself, the CSS, the JavaScript. We
load a couple of static resources, a list of town and counties, some banner images and
stuff like that. We can't load anything for the user because we don't know what the user
is yet, but we can at least get some of the stuff up front. Go ahead there.
Safari Sense has pretty good support. Firefox were the first support in 2006, which is coming
up 20 years ago. Chrome Edge and all that, they've had it since about 2010. Safari have
had it behind the flag for four years and I have no idea why and why they won't enable
it, but anyway. Safari users don't benefit from this. I wish they would do it, but I'm
okay using this anyway because Safari users, and I'm an iOS user myself, typically are
using an higher end device, not often with better networks and stuff like that. I won't
not use this because they don't support it. I still think it's a good API for that sort
of thing. Prefects can help improve future web page performance, but it gets it slightly
better. It's when we're talking about taking that 2.5 seconds down to 2.2 seconds or something
like that. It doesn't give you that instant feel. The options for that are pre-render,
some of you might be aware there was a very similar API to Prefects where you could do
link rel pre-render and the speculation rules that I'm holding off, I still haven't told
you about. Pre-render has less support. Chrome's had it for a while. Safari and Firefox basically
never implemented it. To be honest, I don't blame them. There was a lot of problems with
it whenever we put it in there, used a lot of memories, we didn't specify it entirely
properly. We've actually taken it away in Chrome. If you do link rel pre-render, and
you're like, oh great, this is going to pre-render, it doesn't actually do that anymore. Despite
its name, what it does is we call it no state prefetch. It scans through it and gets all
the links in the document that you know, CSS, JavaScript, stuff like that. It doesn't do
anything with them. It doesn't actually pre-render anymore. That was kind of because we hadn't
couldn't solve some of the things. We were like, there's a bit of a footgun, people were
doing it wrong and that sort of thing, causing more performance problems than solving it.
We don't recommend this anymore. It's still supported. I think we're going to remove it
at some point. It's deprecated. Don't use it. Because we have replaced it with a new
thing. This page, the slides, I'll give you a link afterwards. We have a new way of doing
pre-render called the speculation rules API. There's documentation written by myself.
I'm going to give you the gist of this talk. It's basically, again, you put something you
put in HTML. It's a JSON-based format. You sit there and say, I want to pre-render the
source here. Pre-render, you can also do prefetch, by the way. That can be a good way of starting
into this. But getting pre-render at the end is really, to me, the ultimate goal. You have
a source list. To be honest, we made this optional in the next version of Chrome because
we've given you a list. It's kind of obvious a list. Why do you need to tell us it's a
list? You say source list and you give it a couple of URLs. This will, in effect, load
up next.html in a hidden background tab that the user doesn't see and next.html. If they
click on that, then it will swap it in with the current tab seamlessly without using it
and you get that instant page experience. But how can you know where the user is going
to go next? That's the real difficulty problem. Baz gave a great talk to open this to talk
about the cost of internet browsing, particularly in other parts of the world, where we can't
guarantee and maybe users don't want us to use up their bandwidth and stuff like that.
It can be very wasteful doing this. In certain scenarios, you've got a pretty good confidence
level of where people are going or the costs are lower and you're happy to do it. In other
scenarios, that might be less what you actually want to do. Chrome does put some certain things
if you save data on, if you're in low bandwidth connection, it won't do this sort of stuff.
Still, you don't really want to do that. Even for yourselves, you don't want to say that
every web page load now costs 10 loads in your backend server. That can cost you quite a bit
and so on. We've introduced a new thing called document rules. Source instead of being a
list is a document. Again, we're going to make this option obvious because we've got
a where object. In this case, we're saying any link with the href matches the slash star,
i.e. any internal link, and that includes if you've fully qualified it because it will
figure out that it's actually an internal, except certain things. You can put an exception
in here and say log out. Log out. We don't want to pre-render for whatever reason that
will log you out. Most links are actually safe to render. There's websites crawlers,
Googlebot, some of you might have heard of and so on. Putting things where clicking on
a link causes a problem is a very bad practice and shouldn't really be done anyway. But there
are certain times we do things we know we're not supposed to do. There is a facility to
say don't pre-render certain things. There's an eagerness field where you can sit there
and say I want to pre-render it since the page loads, which is over where you go to
me. This one is the one that I'm talking about here. This is moderate. This means if you hover
over a link or you actually start clicking it, when you click a link, there's a lot of
things that happens. There's a mouse down event, then there's a mouse up event, then
there's a click event, then it runs some unload pages and then eventually it loads the page.
Just by doing it on that mouse down or touch down on screens, you get a little bit of
a head start, 50 milliseconds, 100 milliseconds, and that can do it. If you do it on hover,
you get a lot of head start because quite a few people were hovering over and then
they're like, yes, you can use that time to actually go ahead and get it. There's a lot
of JavaScript libraries that have done this, but this is now built into the browser. It's
available right now in Chrome 121. It's not behind a flag, it's not behind an origin
trial. We've been through that process and it's actually available for people to use.
Let's try and do a live demo. This is not going to go badly at all, is it?
Okay. We have lots of DevTools built for this. My application. Okay.
So when I run this, this is the original version. I have two links up here, Apple and Orange,
and I have a third link Kiwi. By the way, I've misspelled in my rules. So you can see
it has pre-rendered Apple, pre-rendered Orange, and then it's failed to pre-render Kawa because
I misspelled it deliberately to show you what would happen here. So you can see two of these
are ready. Now, if I click on this, now, I'm going to zoom in here. This is the magic thing.
And I think an LCP of zero milliseconds deserves a round of applause, but obviously nobody else.
So we're not talking about making it a little bit faster. We are talking about making it instant,
where you literally get a zero millisecond. There's nothing better than that. That go negative LCP time.
Though thinking about it, I'm sure there's something we can work with it. I just prove
I'm not just doing it. Like, listen, it's not the most complicated app. It doesn't take a while to do it.
But if I take Kiwi, which wasn't rendered, 120 milliseconds, I'd say it's a very simple app.
And we've got very good Wi-Fi here, which is going to screw up my next demo with something shocking.
But anyway, so if you think about that, this is instant. This is a very fascinating network
and stuff like that. I haven't slowed it down. But multiply that up if you're on a mobile network
and slower. Again, you might not get the zero milliseconds, but in most cases you will,
depending on how much they hover over it and so on. Sorry, that was the immediate load.
If I go back to the hover over version, again, let me zoom in here.
So it finds all these URLs. None of them are triggered yet. So it's found all these URLs as
potentially ones to pre-render. And if I hover over it, you see it changes. So Apple is now ready.
Orange is now ready. Kiwi, I think, having this one. So what it does is it works in a FIFO,
first in, first out thing. So it's got rid of Apple and said, I want to keep two in there.
Because again, there's memory usage by this. Effectively, you've got two more tabs open.
So as you do, move around. If I do Apple again, it will pre-render Apple and it will knock
the next oldest down to the bottom. At this point, I've already fixed everything. Everything's in
the HTTP cache. So I'm not causing any network costs here. There is a little bit more CPU costs,
so there would. But again, we're not thinking, and some people do read like that, by the way,
but most people only hover over a link whenever they're actually going for it. And again, I click
on it and you get that zero milliseconds LCP. So the demo works. And I don't know what you
might be thinking. Okay, that doesn't fix the first page load. That's great once you're in
an application and moving around. But quite often, it's the first one that's actually most of the
problem. Excuse me, dry mouth. And that's true. But there's not much you can do for that first
page load because you haven't even gone there. We can't do anything like that. But the browser can.
So Chrome can look at this. And if you look at Chrome colon slash that predictors,
you can actually see what the user does, what the browser does based on your past history.
So I cleared my history down to get rid of all the sites I didn't want you to see here.
But if I type in d e d e v e, at this point, it's got 100% confidence that I'm going to developer
dot chrome dot com because I visit that site a lot. So before that, it was amber. I have a little bit
of confidence there. Once it gets a think above 60% it will pre fetch the document and go there.
Once it gives above 80%, it will say, okay, Barry is definitely going there. And I'll actually
pre render the document. And you may have noticed whenever you click on Chrome, it will actually
then be an instant page load. So that's a nice way we can use this. You don't need to do anything
about it. So if you're worried that preender not everyone's ready for it, the browser is actually
doing this. So you better be ready for it. And look at it. And there's various things analytic
fighters can do and Google Analytics does and Google to ads do that they don't actually register
until the page becomes active. And I might ask why am I so obsessed about instant?
Like surely fast is good enough. And I think it introduces new options for web developers.
Like, has anyone heard of view transitions here? Okay, a couple of you. So view transitions is a
new API where you can do things like this. This is shamelessly stolen from the call well ex-colleague
Jake Archibald moved on dammit. He created this nice little demo. And what does you click on
something and it does this nice transition effect as you move around your website. That's
used to be possible with bucket loads of JavaScript. We've now made it a little bit of CSS. And it's
a lot easier and a lot lighter. The browser does most of the work on it. That works in single page
apps. But what we're really hoping to do is launch it for I hate the term multi page apps. I like
to call them web pages. But anyway, and yeah, let's try that on this one. Let's say this works
really well as long as the Wi-Fi isn't amazingly good as it is here. So this is a multi page app
version of that same demo. And if I click on any of the sort of links, you might have noticed a
little bit of a delay there. Not much because I say the Wi-Fi is really good, but it definitely
takes away from the experience. And I also knocked the network down to 3G, which
can't see. But anyway, yeah, there's definitely a little bit of a
jarring effect there, which it's not the worst thing in the world, but it takes out that magical
view transitions effect. If you go to the same demo with literally just that Jason block button,
other than that, it's the exact same code. I can't code this stuff. Jake can. So I just stole his.
And you can see again, we got the list of the potential links. And if I hover over this,
you see it's running. It's now ready. I click on it. It does that nice effect there. There's not a
one second, two second pause before it does that effect. So things like this,
you might consider not using them on a multi page app or a non SPAR, or you might even consider
using SPAR architecture because it doesn't, you can't get things like this. Well, now, hopefully,
you can. That's available behind the flag at the minute. We're still working on that one.
But that was a real life demo on the real life Chrome. You can test these links yourself afterwards.
So finally, what's all it's got to do with open source? Very good Chrome. Look at you,
done it. You're multi billion dollar company and you can do this. Congratulations. Your
thoughts down here were a little bit lower key. If you've got an open source project,
I would like to ask you to consider adding sport for this. I think it's a very easy thing that
you can do. I say there's a lot of libraries that do that lover link over effect. And they do that
if you run a framework, Astro is one framework that's done that they've added support for this.
So you can go in there using some weird JavaScript Astro config and it'll do it word press. And
I'm really excited about this. So on the Google Chrome team built a WordPress plugin. It's got two
options. Do you want to prefetch? Do you want to pre render? And which of these options do you want
to use? And we can suddenly give this to millions of WordPress sites. So WordPress is powers a third
of websites at the minute. Just by installing this plugin, they can go ahead and just get instant
navigation. And I think it's worked really well for the WordPress type thing, which is typically
static websites, blog posts or articles or brochure sites and stuff like that. So yeah,
let's make 2024 the year of instant navigations. And here is a link to slides, QR codes, stuff like
or I'm around. I've got a couple of minutes for questions.
Yes in the middle.
Yeah. So on mobile, sorry, the question was if it renders and hover, how do you handle it on
mobile? So moderate was render on hover or milestone. Conservative is measuring my style only
mobile because there is no hover at the minute. It only falls back to effectively the conservative
option there. Now there's an argument for and against in some ways, mobiles quite often the
one that would benefit the most from this sort of thing. In other ways, mobiles often more constrained
and you don't want to use it. So maybe not overly using this API until we're more sure
isn't a bad thing on mobile. But yet trick of that is other things we can do. People can use the
list URL if a library wants to build it. As you scroll and viewport. And if it stops scrolling,
maybe that's an option. Maybe that's something we'll bring to Chrome and so on. But the minute
it's a little bit slow in desktop. I think there's someone up back there, sure.
So question is if they're a way to protect, if it's preloading, is there a way to deny it? Yes.
So there's two ways. One, we send an extra HTTP header sec purpose, which is either prefetch or
prefetch and pre-render. And your server, if you send back a non successful status code, so if you
send back a 500 or a full award or whatever, Chrome will go, okay, they don't want me to pre-render
this, I'll leave it alone. And similarly on the page, there's API you can check, am I in the middle
of pre-rendering? Or have I been activated? In which case, maybe don't fire analytics, maybe don't
load this, maybe don't load that, whatever, and you can choose to do that. So we're over here.
Second rule.
So if you open a pre-render page in a new tab, at the moment it won't use a pre-render, it will go
and render it separately. So it's linked to the page. Similarly, if you go away from that page,
it discards the old pre-renders. So it is linked to the current tab at the moment.
At the front.
Are there any attempts to put this in a common standard?
There is. It's going through. It's part of WCAG at the moment. We've asked the other browsers for
their feedback. I say none of them implemented pre-render first. We think we've done a better
job with this. We've got a proper spec for it. We've got lots of things we consider. If the video
is playing, should it play? If this API is used and so on. So yes, it's going through this under
theization process. That's not to say other browsers will definitely like it. But we're
definitely at least trying to do our part to push it out there.
At the front. I'm probably running out of time, but go ahead.
Sorry.
The service, well, the speculation rules allows the rendering, which,
oh, good point. The question is, if you use something like service worker to prefetch stuff,
how does that compare with speculation rules? Service worker is pretty good about getting
resources. Speculation rules is more about getting the actual document itself. As I said earlier,
it sends headers. In certain scenarios, you can reject and say, hey, this is one that's live up
to date. Must be live information. Don't do anything with it. There's more obvious to the
server side. And it also offers the pre-render option there. Saying that, service workers are
still very good for getting the sub resources. And even with pre-render, if you've got service
worker back on, maybe the pre-render happens faster rather than only being half pre-rendered
than it goes there. I'm not sure how the time is. No, I'm afraid we're out. I'm
feel free to grab me. I have chrome stickers, little dinosaurs, by the way. Anyone want some?
Sorry. Anyone else? Are you all ready for it? Thank you very much.