W3C Web Performance WG, 31 Mar 2022

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: WebPerfWG call 2022 03 31 - BFCache NotRestoredReasons

Description

No description was provided for this meeting.
If this is YOUR meeting, an easy way to fix this is to add a description to your video, wherever mtngs.io found it (probably YouTube).

A

Cool um so today, oh this is izu from chromium, bf, cache team back forward cache team, and today I'm going to present the proposal for not restored reason api for bf cache.

A

So for those who might not know about barcode cache, backfired cache basically improves the performance of history navigations and it becomes instant basically by freezing the page and keeping it around and restored upon restore. We um just resume the page and we're aiming for more than like 50 plus um coverage hit rate um from next for this year. So that's what we are aiming for, but we cannot catch older pages at the moment and um even if we, um if, even if chromium, implement um a lot of things, we are um working on still.

A

We cannot like cover everything and we need websites um help um to make the pages vf cachable, like bf cache eligible. So this api. Our proposal is to help us. Let the sites know why the pages are not getting bf cached. So um there's a explainer here. um I actually have a link to yoaf.

A

I think- and there is a github issue also- and we are currently proposing to extend the navigation timing api, to include the why the page is not bf cached and our proposal is to expose a tree of frames with the information of whether or not the frame blocked, bf cache like true or false, and then, um if true like reasons, what exactly is blocking bf cache and this can be empty.

A

If the first item is false and I used my id and source attribute of the frame so that the web authors can identify the frame that it's talking about and the current location of the frame and the child frames and those last two items are only exposed if the um if its frame is the same origin with the mainframe, I'm gonna explain it um more in the next slide.

A

So yeah. There is a concern about um exposing cross-origin iframe information, but um we think it's um fine as long as we mask the subtree of the cross-origin subtree.

A

So basically, our proposal is to only report if the subtree that cross-origin sub-tree is blocking bf, cache or not, and exposing. That fact is already it's already kind of exposed and you can easily figure that out.

A

So our um theory is that that's okay, to expose the fact that it's bf cachable or not, and we're not going to report the reasons why b.com is locking um what what exactly is blocking bf cache here or we not going to report any child frames like if, even if there are like child frames, like underbe.com they're, not gonna report that so basically masking the subtree and we're also gonna report at the uh at the point of navigating away from the page.

A

So if the subframe navigates from b.com to c.com we're going to only report the information of c.com, so that's our proposal and yeah. As I said, we are proposing to extend navigation timing api and I filed an issue in the navigation timing, api um github. So um it would look something like this. um Maybe something like this like perform.

A

One of the performance entry will have like not restored reason category and they will report the hashmap um of like url like id and whether it's blocking bfcash or not, and if true, like reasons like hash array of reasons and children frames, if any.

A

So, if everything is same site, it's gonna, be it's gonna. Look like this, like url source attribute like id like x, and if it's blocking or not and reasons and children will have like the similar.

A

The same information like this, and if it's, if, um if a frame is blocking, we have cache it's going to have a reason like this and if it's cross site, um you can see here like if b.com, even if b.com is blocking um the f cache we're not going to report any reasons we were discussing, whether it should be just an empty array or null we haven't figured out, but um even if it has children, child iframes, it's going to be empty, children will be empty and url will be also masked.

A

So yeah, that's our proposal and another point here um to discuss. Maybe is um whether or not we should like standardize reasons and um because um if we don't standardize reasons, it's gonna confuse developers like if um chromium, just ripples our broadcast channel and safari says like broadcast channel. That would be like very confusing. So maybe we should like um make a pull request and standardize um before adding any new reason.

A

So um that's like one idea and but then like that, might not be sufficient because um we might want to add more um detailed reasons for um standardized name like even for like broadcast channel. It can be just an open connection or like messaging and like we, um the browser might want to know the breakdowns of those reasons. So we could probably like add um detailed um explanation here, like extension inside of extension, it can be like messaging or something else so yeah, I think that's all. I have for slice.

A

Okay, let me stop the recording.