- From: Yoav Weiss <yoavweiss@google.com>
- Date: Fri, 15 Oct 2021 11:35:09 +0200
- To: public-web-perf <public-web-perf@w3.org>
- Message-ID: <CAL5BFfXU=PnqxM7-m=QfySoeS34RbOmvasek583_Rub0kVXZLA@mail.gmail.com>
Minutes from yesterday's meeting are now published <https://w3c.github.io/web-performance/meetings/2021/2021-10-14/index.html>. Copying them here for convenience: WebPerfWG call - October 14 2021 Participants Patrick Meenan, Alex Christensen, Giacomo Zecchini, Nicolás Peña Moreno, Noam Rosenthal, Annie Sullivan, Benjamin De Kosnik, Ian Clelland, Corentin Pescheloche, Steven Bougon, Carine, Yoav Weiss, Nic Jansma, Cliff Crocker Next Meeting - TPAC! Oct 25-29 - November 18, 2021 Topics - RT entry’s alignment with Fetch/Response - Noam R - *Noam*: Comes from work with ResourceTiming and Fetch integration - … Found inconsistencies - … Are resources, fetches and responses the same? - - … A resource may have multiple fetches - … A video may fetch multiple segments with 206 Range requests - … Currently appears in ResourceTiming as a whole bunch of fetches with different body sizes - … Same goes for responses, ServiceWorkers can have multiple fetches or respond to many requests from a single resource - - … Responses are ephemeral things that get passed around, and requests our resources get them - … Even without ServiceWorkers, responses in the HTTP Cache. - … HTTP standard underspecifies this - … A response could be shared between two fetches before it was finished, and they got transferSize as 0 because one registered it as cached, even though it was fetched from network - … For video elements, we get a whole bunch of entries that look like video, don’t know they’re part of the same resource except by URL - … Added some WPT tests to see what happens in some of these scenarios - - … Tests redirects in a service worker - … Chrome, Firefox, Safari have different behaviors - … People who want to rely on those measurements (in environment with serviceworkers, or HTTP caching) would be utterly confused and would have to write different code for each browser - … Two main suggestions: One is that ResourceEntry would represent a fetch 1:1, so redirects within the fetch you would not see in final entry - … Second option is only connection info would be forwarded, but not redirects - … Logic is if you’re using SW you wouldn’t have connection info yourself from outside, so getting that doesn’t interfere with any other information - … Could be redirects that come before the SW and could be mixed up with redirects happening in SW - *Yoav*: Clarify what you mean by redirects in SW? - *Noam*: URL handled by SW. The SW takes the Fetch event, handles it, and does a respondWith(). That leads to something with a redirect. They both have PT entries and objects. Some browsers mix them differently in the client. - *Yoav*: One thing that stands out is generally 1:1 relationship with Fetch makes sense. - … Also seems like something that's closest to implemented reality although you've found discrepancies - … Like for VIDEO, each range request is a different Fetch request -- matches reality - … The bit that I’m hesitant is that there’s a feature request we’ve talked about - how we’d expose multi-request RT entries and redirects in the future, and this goes against being able to do that - *Noam*: I wouldn’t say it goes against that. The redirect response sequences are in the Fetch, properties of the Fetch. They could have their own RT entries (and it goes against that a bit), they’re not a Fetch in themselves though. - *Yoav*: Yeah if we have 1:1 RT:Fetch, then we wouldn’t expose them as a separate entry. Though at the same time I’m not sure there’s a strong use case for multiple RT entries for redirects. - *Noam*: Redirects don’t have to be a resource, they could be a sub-resource - *Yoav*: We could have a RedirectTimingEntry if we wanted them I guess - … It would influence the shape of that solution if we went that route. - … In the context of PRs for defining Preload cache, how would that 1:1 relationship work? - *Noam*: Since Preload is a lot more complicated and needs definition, we can derive from that how RT or timing entries for Preload would look like. Preload is a feature in itself and RT should measure it somehow. - *Yoav*: If we define Preload cache above Fetch, this would still work. Preload would trigger a fetch and second one would be preempted. - … That’s what happens today for RT entries for Preload - *Noam*: All of that is solvable, important to have a definition of it instead of relying on existing implementation decisions - … Issue open about this - https://github.com/whatwg/fetch/issues/1208 <https://www.google.com/url?q=https://github.com/whatwg/fetch/issues/1208&sa=D&source=editors&ust=1634293489579000&usg=AOvVaw0L52dWmzvvHJrcRhNjw8sz> - *Nic*: From our RUM point of view, no customer complaints, but maybe beyond their ability to measure. Limited to SW cases. - *Noam*: Also impacts the HTTP cache. E.g. a cached response shows the old connection info - *Nic*: We do see weird data all the time, and it’s hard to know why an attribute is different than expected. Precise definition is good. - *Yoav*: In terms of alignment from other implementers, some implementations would need to change - *Noam*: All of them will need to change, differently - *Alex*: I don’t think we’ve arrived at the perfect solution yet, but I’m willing to make changes as long as they don’t affect privacy - … Sounds like it’s heading in a reasonable direction - *Nicolás*: Sounds like this would change the API a lot potentially, in terms of kinds of entries retrieved? - *Noam*: It will erase timings for things coming from SW and HTTP Cache, if that particular fetch is not the one causing the redirect. - *Pat*: It will hide it at the page level, but you can get it from the SW that actually did it, which feels like the right separation - *Nicolás*: I had the impression that it would be more breaking, but if it’s just moving them around to other places that makes sense - *Nic*: Is anyone aware of use counters of PerfTimeline in SW? - *Yoav*: Not aware of any stats right now - (followup: there are Chrome stats on Observer use in workers <https://www.google.com/url?q=https://chromestatus.com/metrics/feature/timeline/popularity/2189&sa=D&source=editors&ust=1634293489582000&usg=AOvVaw02i6RkZKK6ijbCpJ8AV82o>, but not on PerformanceTimeline) - *Benjamin*: So can you clarify what the end results with HTTP cache are? - *Noam*: If we go down this result, then a RT entry is a fetch - *Benjamin*: OK, that makes HTTP cache better, thanks - Priority Hints and responsive images - Patrick Meenan - *Pat*: We have both lazyload and Priority Hints are making image decisions in the markup - … Some of the early feedback we have is it’s difficult on responsive sites - … Depending on the viewport if it’s in the view or not - … In Preload you can use media queries to toggle whether or not Priority Hints will be applied - … Lazy load can only be applied to <img> itself - … Suggestion is to tweak the Picture element so individual sources would have lazyload or importance attribute - … And if individual source has it, it would override what is on the <img> tag - … So you could choose to have an overall <picture> image that would lazyload, but <source> could load eager or have different importance or other basis - … Not perfect since you don't have CSS way of doing this - … In straight HTML seems like the best place you’ve got to make responsive features available - *Michal*: If you can’t do it from CSS since you need to do it during parsing, but if it’s a responsive problem, dont you have a chicken-and-egg problem - *Pat*: <picture> is a bit of a responsive element, so it handles media queries at parse time - … You can’t make the full decision as in the CSS file - *Yoav*: Parse time media attributes are not just for responsive images, but also for loading priority of styles, that are not applied if the media attribute mismatches - … We have the ability in HTML to apply some CSS media condition rules but it all happens before layout is applied, before all CSS from all HEAD is downloaded - *Pat*: It’s not breaking in any direction if it’s guessed wrong, as lazyload/important is a priorization thing - … Want to avoid developers having to decide if they prioritize desktop or mobile, if <picture> is the knob where they can make that tweak or not - *Yoav*: I would love to see examples of real-life sites where that would look like - … And examples to lazyload and prioritize in some viewports and not others - … e.g. image is not visible in viewport in some cases where it’s not others - *Pat*: Grid vs. vertical scroll layout too - *Yoav*: Makes sense, also matches recent change for width and height to be applicable for sources and override ones from <img> to enable responsive images to take up their allotted space ahead of time before layout happens before dimensions are known - *Pat*: Worst-case hopefully it’s better than current situation even if it’s not perfect - … Will start work on documenting it at least, then see about implementing it - NavigationStart and cross-origin redirects <https://www.google.com/url?q=https://github.com/w3c/navigation-timing/issues/160&sa=D&source=editors&ust=1634293489588000&usg=AOvVaw11W2ZLgcLwPjcq4kzQM-JF> - Noam R - *Noam*: Simple topic but has a big implications I believe - … Did a very minimal demo to show problem - … [demo] - … We are on a page, localhost = domain A - … I have a form for with a checkbox for subscribing to a newsletter - … Click on button, some time passes, I’m on domain B, which tells me I’m subscribed to a newsletter from A - … If I go back and don’t click it, it goes to domain B where I didn’t subscribe to newsletter - … I have a HTTP post from a form to my own domain, and in my own domain I do something that takes a while if I subscribe to newsletter, then I redirect to a new domain - … How did domain B find out domain A took longer time to do something - … Because navigationStart, our epoch / zero time for all timing entries - … navigationStart starts before unload or wherever you can from beginning - … Could be cross-origin redirects, doesn’t have to be a third-party in between, could be just two origins - … Could be click to on SERP and it goes to final domain - … From final domain you can see a bunch of time passed, know about it from user on your domain - … Proposal is to put navigationStart to be first redirect in our domain or fetchStart of our current document - … Other option is to use TAO or other permission approach - … Problem with headers is we tend to overload meaning on them after we publish them - … Problematic who gives that header, only the domain who can give permission is the last website - … We have a mechanism called <a ping> which allows us to send whatever we want to the final domain, how many ever redirects - … I’m suggesting that as one option for how to grant information - *Pat*: On the information leak side of things, is the concern only that the timing information is available, or is it linked to referrer stuff - … Feels like without referrer information, timing information isn't as useful and maybe it’s a referrer problem - *Noam*: I wouldn’t underestimate this timing information to know whether you’re logged in to other sites - … Problem is bigger when you’re talking about referrers - *Pat*: Don’t want to lose track of the user’s full experience - … First part of that window isn’t the problem of the destination site, the unload and redirects may be part of the timing of the site you’re coming from - *Yoav*: I think it might make sense to use some sort of Reporting API to get that information back to the refererer site, right now it’s sent to a site that can’t do anything about it - *Pat*: Scenario? - *Yoav*: If you have a search engine going to publisher with a click tracker in between. If click tracking takes a while, the search engine should know about it. - *Pat*: Maybe it’s the publisher that put in a click tracker, in which case the publisher should be alerted - *Noam*: Problem for the user, user should know they’re no longer in search engine and not yet on publisher, something else is taking their time - *Pat*: We don’t want them to be blind where this timing is going - *Noam*: I think they should share that information between them, e.g. via <a ping> - … It’s not up to the browser to give that information to either or both of them - … User owns that information, not the sites - *Yoav*: Beyond Q about how we gain back information, consensus on the thread that this is information we should stop exposing by default - … Implications are that every site that starts out with X-O redirect will have their performance metrics moved by the amount it takes to redirect - … navStart point is also time origin for PT - … All metrics that RUM providers give will change - *Michal*: Perf Win! One weird trick! Ship it! - *Noam*: Can create interesting scenarios where websites try to game this - … Slot for this at TPAC, I’m not sure if there’s more to discuss here, I don’t know how to proceed - *Nic*: We have based all of our metrics on navStart, all metrics are keyed on how long navStart was. - … Some customers noticed that this can be a challenge, so had some customers create their own custom timers, as a way to reduce the noise of the things they can’t affect. - … So changed their timeOrigin with their custom timers - … So we have some evidence that it makes sense to remove the navStart from there - … But concern about changing the baseline of all metrics, as it typically leads to confusion - … Would create communication challenges. - … So something to think about a little bit more. Let’s followup at TPAC - … We generally argue to not change the timing definition On Wed, Oct 13, 2021 at 6:27 PM Yoav Weiss <yoavweiss@google.com> wrote: > Hey folks! > > Let's talk <https://meet.google.com/agz-fbji-spp> about WebPerf issues! > > On the agenda <http://public-web-perf@w3.org> we have Navigation Timing > and cross-origin redirects, Resource Timing entries and their alignment > with Fetch spec concepts, as well as Priority Hints and responsive images. > > The call will not be recorded. > > Cheers :) > Yoav > > >
Received on Friday, 15 October 2021 09:35:53 UTC