From fast loading to instant loading
HTML-код
- Опубликовано: 15 май 2024
- In this talk, we'll share how Chrome and the web platform can achieve near-instant page loads using the new Speculation Rules API. Web developers can learn how to accelerate page loads on their own sites with easy to use APIs and gain insights to drive user and business impact from case studies with well-known partners.
Prerender pages in Chrome → goo.gle/prerender
Debugging speculation rules → goo.gle/debugging-speculation...
Speculation Rules API Improvements → goo.gle/speculation-api-impro...
Speakers: Barry Pollard
Watch more:
Check out all the Web videos at Google I/O 2024 → goo.gle/io24-web-yt
Subscribe to Google Chrome Developers → goo.gle/ChromeDevs
#GoogleIO
Event: Google I/O 2024 
Наука
Check out all the web sessions at Google I/O → goo.gle/io24-web-yt
Really interesting, thanks Barry!
Does anyone know the name of the code editor theme used in the presentation?
Advertisers and trackers are going to love this
As explained in the video, Google Analytics, GPT, and Google AdWords already support this API and will hold of registering views until the page is activated. As usage of this API grows we envisage other analytics and ad providers doing similar by default, but in the meantime these can be manually delayed with the APIs discussed in the video. Additionally, third-party s not being loaded during the prerendering phase will also help.
Matomo > Google Analytics
nice job yeah i immediattely thought about preloading my huge spa when the user hits the index page
at 15:10 you show an example of multiple prerender rules, but show a single object with the "prerender" key set twice. Surely that can't be right? I assume there should be one "prerender" key whose value is an array of rule objects?
That works too! There are quite a few ways to include multiple rules: developer.chrome.com/docs/web-platform/prerender-pages#multiple-speculation-rules
Actually sorry, you're right. That only works with different keys (prefetch and prerender)! There's also quite a few other things wrong with that slide (url should be urls, and single quotes should be double quotes). Shouldn't have done this last minute addition!!
Very awesome talk!
can't wait to see more of what Cloudflare is going to do with ML & spec rules. reminds me of guess.js, just a 2024 variant of it
Wonderful ❤❤
Combine this with htmx and a server side framework like Django or spring you are good to go.
Sveltekit already does this by default. It's nice to see chrome is keeping notes.
Not in USA, access ray-ban still now shows speculation rules. Does any other pages we can see it in real world? or demo page
Try the demo page at 18:20 (can't seem to post the link without my reply being swallowed up!)
Users with slow connection or who are charged by traffic give it a standing ovation.
Slow connections is an interesting one. In some ways those are the very connections that can benefit most from this (providing they don't contend with the current navigation). As to the charges concern, the Speculation Rules API honours the Save-Data setting, and also Preloading can be turned off plus, as noted in the talk, the cost of these navigations of often less than you think for various reasons I cover. Using a standardised API allows the user-agent to be more of an "agent for the user" for these features.
@@tunetheweb “ Preloading can be turned off”. - How? How do you expect a housewife and 99% of other users to get into browser settings and change something?
Let's imagine a user on 3G or satellite internet with distribution via WiFi with a tariff of $80 for 1Gb, who visited a page, and the owner of that website immediately without asking for permission starts loading on his device half of his site, completely clogging the channel and CPU (rendering).
You think about developers and users with good internet, and you are killing users with not so good or expensive internet, and there are a lot of them.
Speculation rules for flutter web?
Indonesia mentioned, wellplayed Tokopedia
22:50 - shouldn't these really be in MB of data instead? You could do very little with 50 or a lot of damage with just 2
An interesting idea! As discussed in the talk, the various precautions we have added to Chrome (using the HTTP Cache, this being primarily for same-origin, not loading cross-orgin s which are often heavier content...etc.) means that the cost is often smaller than you think. But even without a heavy network cost, there can be CPU cost so I think a limit on the number of navigations makes sense, but maybe there should also be a MB cap? You could suggest that here: github.com/WICG/nav-speculation/issues
25:32 - What happened in February of 2022?
Not sure to be honest. Please raise an issue at github.com/HTTPArchive/httparchive.org if you want this investigated further.
I am curious why they choose for the script tag and not just put it somewhere in the head of the document seems to me to be more logical to me.
And also isn’t this just going to nuke performance.
because a lot of low end pc’s and phones can beryl handle some modern websites. And how is this going to interact with the JavaScript you already have to do updates or others stuff?
And I often times see more issues in the network stack because of WiFi and others than this.
The script element can go in the head.
A prerender happens in a separate process, so a separate main thread. And on low-end devices and with certain settings, speculations will not be enabled-as mentioned in the video.
@@tunetheweb yes you’re are correct but I was more thinking of like a meta tag why not that.
And I am curious how can a server know if the users supports the feature or do you just have to look against the browser version
@@lenn1440 That has been suggested: github.com/WICG/nav-speculation/issues/307. Personally I prefer the JSON syntax and find it easier to read-particularly for complex rules. and meta tags are fine for simple declarations, but quickly become unwieldy for more complex ones. But follow along with that issue to see if we change approach on that.
The server can know with a header when a speculation happens (developer.chrome.com/docs/web-platform/prerender-pages#detect-server-side) but doesn't know before it happens, and to be honest, doesn't really need to know-just serve the speculation rules anyway.
@@tunetheweb hi I am going to track the issue you linked and I might comment at some point if something interesting happens.
I think I prefer the html syntax more just because most of the stuff I build is just html with a little js
What about the increase of data transfer on the CDN's? It's worth ?
Nonesense. It is worth it because I prefer client devices to handle all prerendering than paying to server companies
@@ozgurNY What I mean is that when I tested the speculation rules, instantly our CDN data transfer increased very significantly.
@@francescinvernon Definitely should try to only prerender when theres a high probability of user actually visiting that page (in which case there should be little increase in costs since it was costs you were going to pay anyway). Document rules with a moderate/conservative eagerness is one of the easiest ways of doing this but with less of a lead time. Also ensure your resources (including the pages themselves!) are cacheable to avoid having to refetch from CDN each time.
@@tunetheweb ok i'l try with moderate/conservative eagerness and test the CDN thankss !
Man, so nice to see Victor Orban switching to tech
This is just his hobby. Pure genius.
21:50 - this example is only valid if the user spent more than 11.460s on the previous page. Who would really do that (in most cases) though?
I don't think this is an unrealistic example for a large listing page with eager preloading (as Tokopedia do). And the API picks up where the user left off so if you get a 5 second head start, then you go from an 11 second render to a 6 second render-still a much better user experience. Additionally, this extreme example (as noted in the video) is over 3G. With a faster network the load time will be less.
@@tunetheweb Thanks for responding to all the questions here
I wish the mobile story was talked about. There is no hover on mobile. I am doubtful this has any benefits for mobile.
As noted in the video we are working on better heuristics for mobile. For URLs with a high probability of being visited these can be loaded eagerly. Where that's not possible even the small time between touch down and the navigation starting DOES improve loading speed on mobile. Not as much as hover of course, but given how simple it can be to implement the API, even a small head start is useful.
@@tunetheweb Wow, thank you so much! I am sorry I must have missed it. That is really cool. Thank you!
why are we cheering about 78ms !?
the page is already PRE RENDERED how is it not like ... idk, 0ms?
It's about as close as you're going to get! You still need to swap the old page for the new page AND actually paint the pixels. 78ms is 0.078 seconds-literally less than the blink of an eye!
@@tunetheweb i guess web people aren't familiar with how a computer works. but you can calculate and paint all the pixels of a complex 3d environment on a 4k monitor in like what, 4ms? just look at any video game
Terrible sound
cls ...something that really annoys me ...
My users didn't really care when I improved my site speed. It was barely noticeable. If your site loads within 5seconds max, you're fine.
5 seconds is HUGE. What was your user base like?
nice feature, worst naming
Why are you presenting it like a new thing you've invented? You're just implementing this "tech" that devs have been using for probably at least 5-10 years since jQuery days... Preloading next content ain't new! Congrats for catching up and implementing it as a standard. But too little too late. People have moved on to frameworks that solve this in a much more seamless way with their framework of choice (eg. next/remix, I'm sure there are others)
It's not about being the first, it's about having a better solution to the same problem.
Because this is the first time this functionality is being exposed as a Web Standard Browser API.
As mentioned in the video, you are right that we HAVE had ways to prefetch content before, but not really for full navigations, and not for full prerendering (except for one earlier iteration in Chrome that no longer works for this). Frameworks can't prerender either (when they say "prerender" they mean "create the DOM server-side" rather than actually do the full browser prerender).
because frontend guys these days are just reinventing the wheel over and over. don't worry, there will be a new framework next week
@@user-tz9jh6pv2j There's a big difference between "frontend guys" and the people who design Web APIs and build them into browsers.
Will this not increase the carbon footprint? Imagine millions of websites implementing this and prefetching stuff that in the end will not get shown, since the user changed their mind.
honestly I do not see value in this. This is going to die in the next 2 years as usual.