- From: Nic Jansma <nic@nicj.net>
- Date: Wed, 13 May 2020 14:18:36 -0400
- To: "public-web-perf@w3.org" <public-web-perf@w3.org>
- Cc: Ilya Grigorik <igrigorik@google.com>, Yoav Weiss <yoavweiss@google.com>, Philippe Le Hegaret <plh@w3.org>
- Message-ID: <CAALun4tit+teGoAxZ-qy5ip3u4MnLW0xHJMxOG00W06R+YfZCw@mail.gmail.com>
Minutes <https://docs.google.com/document/d/1ObF2KTuurickhp4-tgVvUCRh1BY_c9WIm7vG7lsubL4> and recording <https://youtu.be/TOyympEtwjk> from last week's call are now available. Copy of minutes: Participants Gilles Dubuc, Yoav Weiss, Nic Jansma, Michal Mocny, Benjamin De Kosnik, Nicolas Pena, Marcus Armstrong, Annie Sullivan, Philippe Le Hegaret, Philip Walton Next Call - Tues May 19th @ 10am PST / 1pm EST DiscussionsEventTiming Updates - Nicolas: Added a method that looks at the dictionary of the .observe() call and if there’s a duration threshold, and smaller delays than the threshold aren’t sent to the observer. - … Also, there’s no way to determine which entries to add to the buffer in PerformanceTimeline. - … On the last call we talked about adding only entries with a duration over a hundred, even though we support observing entries of 16ms or more. - … Maybe we can hack “should add entry” and make it also about the performance timeline only. - Nic: So the buffer would have a different threshold? - Nicolas: We can do that or accumulate everything. - Yoav: Buffering “everything” runs a risk accumulating entries for every single input event, of bloating memory. Where if it’s just for “slow” events, it’s not as big of a deal. - Nicolas: True, but there is also a buffer limit. - Nic: I would want to make sure it’s called out in the spec that the .observe() and PerformanceTimeline have different thresholds for what shows up. - Nicolas: Worried it would be confusing with the buffered entries having a different threshold. - … The default for duration would be the slow entries, and duration threshold enables you to get more than that. - Nic: Just to restate what you said: So only buffer events at 100ms and that would be the default, but the observer can go below that using the duration threshold? - Nicolas: Yeah. Interested in feedback about this threshold, and general feedback about EventTiming would be good, because Chrome is interested in shipping it. - Nic: From Akamai’s perspective, hoping to collect data to supplement existing polyfill. - Nicolas: Would be great to compare polyfill to native implementation. - Nic: We should have that data, so can verify that at some point. - Nicolas: How do you verify that there’s a handler at the beginning of the page load? - Nic: That’s one of the downsides with our polyfill right now, is we don’t. - Nicolas: I’d expect native times (especially for event processing time) to be larger. - Nic: We’re telling customers we’re expecting differences. - Yoav: Any other API feedback? - Steven: Looks good, we’ll use it. - Nicolas: User input in general doesn’t occur early on, so most entries won’t be buffered, so buffering only the slow ones shouldn’t have a huge impact. Resource Timing - https://github.com/w3c/resource-timing/issues/71 <https://www.google.com/url?q=https://github.com/w3c/resource-timing/issues/71&sa=D&ust=1589397392588000> - Transition Level 2 to CR - Nic: Tracking to get to CR - … List of issues needed for Level 2 - … List of open test bugs - AI: Yoav to update - https://github.com/w3c/resource-timing/issues/198 <https://www.google.com/url?q=https://github.com/w3c/resource-timing/issues/198&sa=D&ust=1589397392590000> - Register TAO as Permanent Message Header Field Name - Nic: Register TAO headers once we hit PR - … Can’t make progress yet, so skipping - https://github.com/w3c/resource-timing/issues/200 <https://www.google.com/url?q=https://github.com/w3c/resource-timing/issues/200&sa=D&ust=1589397392591000> - Be a bit more explicit about which subresources are to be ignored from stylesheets - Nic: What do we do about grandchildren resources. - Yoav: How to describe everything in that dependency tree should be invisible? Without having to describe a dependency tree - … I need to figure out language, it might be hand-wavy, but we can then wait for when CSS integrates with fetch to be able to better describe it (i.e. the ancestry relationship in fetch). - … As long as CSS is not integrated into fetch, no point in even going that route because it won’t help us here - Nic: So hand-wavey text for now? - Yoav: I think that’s the best we can do - ... We’ll also need tests, I don’t think any implementation follows this - Nic: Besides those L2 issues, we have some tests <https://www.google.com/url?q=https://github.com/w3c/resource-timing/issues/71%23issuecomment-462167655&sa=D&ust=1589397392593000> that need to be addressed - Yoav: I’ll take an action item to re-look at where tests are - Nic: Next are untriaged issues, let’s find a milestone for them - https://github.com/w3c/resource-timing/issues/226 <https://www.google.com/url?q=https://github.com/w3c/resource-timing/issues/226&sa=D&ust=1589397392594000> - Pass realm when creating PerformanceResourceTiming - Nicolas: Unclear what’s the right answer, can wait for Fetch integration. Not high priority - .... Fetch integration would be Level 3 - Yoav: I don’t think a change here is highly observable or likely to affect the API shape, we just need to properly define it and it would be hard to do that before Fetch integration. - … So it can wait - https://github.com/w3c/resource-timing/issues/220 <https://www.google.com/url?q=https://github.com/w3c/resource-timing/issues/220&sa=D&ust=1589397392595000> - Provide a TAO-bypass for Navigation timing - Nic: NavTiming entries are not gated by TAO while RT is. Mostly an editorial change - Yoav: Some timestamps are related to current document (e.g. current pages’ DNS / TCP). - … Things that concern the document being fetched, so are always same-origin (to itself) - … But there are other timestamps related to the unload of the previous page (e.g. unloadEventStart) that shouldn’t be TAO bound but just same-origin bound - … We had discussed all of these at the latest Face-to-Face and so don’t need to be clarified but just editorial changes - ... Make sure these changes are tested - Nic: 3x issues from PING - Yoav: Let’s dive into each individually - https://github.com/w3c/resource-timing/issues/221 <https://www.google.com/url?q=https://github.com/w3c/resource-timing/issues/221&sa=D&ust=1589397392596000> - Yoav: nextHopProtocol is exposing unique information that the visitor is behind - ... Could expose if user is behind a proxy, or VPN or has Anti-Virus installed - … Many things that can change that first hop - ... nextHopProtocol is not TAO bound, and maybe it should be? But that could be tangential to this question - Nicolas: Are we OK with exposing VPN/Proxy usage or do we need to re-evaluate the attribute - Yoav: My thinking is that it doesn’t expose anything specific -- it says “supports H2” or “not H2” etc, and these are all things that are already somewhat observable, e.g. very clear request patterns (from ResourceTiming) where you can tell the difference between H1 and H2 - ... My claim is this information is already exposed - ... Proxies that are privacy-aware could support H2/H3, and try to mirror the origin - Nic: Proxy would have a hard time knowing origin protocol until client already connected with their preferred protocol - Yoav: Good point. Generally, we think this is a consideration we took into account when we shipped nextHopProtocol. - Benjamin: We’re concerned about this, PING pointed out a valid issue here - Nicolas: Could you clarify how this information is already exposed - Yoav: If you look at multiple connections to the same host, and you have connect time for only the first one, and the rest seemingly use the connection. For H1 you’d expect up to 6 total connections with distinct timings. Where H2 is not. - … For H2 vs H3 the differences are more subtle and it could be a bit harder. For H1 vs H2 it’s easy to write a script that finds that distinction. - ... Not sure what the real privacy benefits would be - ... Will run it by Chrome and Google privacy folks to get their take - Benjamin: What are the risks to doing what they ask, i.e. what is the harm in conceding to their request - Yoav: Harm of removing nextHopProtocol: Won’t be able to easily segment the impact of underlying protocol rollouts on traffic. H1 to H2 rollout is not done. Properties are making that transition and they want to prove to themselves that it’s a worthy one and this allows them to measure that. H2 to H3 allows them to switch some percent of their protocol, and measure the differences. - … When we shipped nextHopProtocol, we didn’t have ServerTiming. Can this be exposed via that? - Nic: From Akamai’s perspective and its customers, it has been invaluable. For rollouts, our customers can segment and measure their traffic. - … As well as internally, when we’re deploying new protocols at Akamai, we can measure the impact. - .... If it can be done with server timing? ST can come from multiple hops, where we’re mostly interested in last hop. - Yoav: One problem is that Server-Timing is set at the application layer, done independently to the layer making the decision on the protocol. It would require the network layer mark the protocol to the application layer who would mark it via Server-Timing headers going down - AI: Yoav to talk to privacy folks to see if the user impact is meaningful and Nic/Yoav to talk to ops folks to see if ST can be a replacement. - There are two other related one around TAO, but we’ll talk about these at a later date - https://github.com/w3c/resource-timing/issues/222 <https://www.google.com/url?q=https://github.com/w3c/resource-timing/issues/222&sa=D&ust=1589397392600000> - https://github.com/w3c/resource-timing/issues/223 <https://www.google.com/url?q=https://github.com/w3c/resource-timing/issues/223&sa=D&ust=1589397392600000> Page Visibility / Paint Timing issues - https://github.com/w3c/page-visibility/issues/29 <https://www.google.com/url?q=https://github.com/w3c/page-visibility/issues/29&sa=D&ust=1589397392601000> - https://github.com/w3c/paint-timing/issues/40 <https://www.google.com/url?q=https://github.com/w3c/paint-timing/issues/40&sa=D&ust=1589397392601000> - Log if a page was ever visible - Nicolas: Two options for determining if a page was visible before - … You can listen to event handler to get state changes but that doesn’t work for later-loading scripts - … First option is to have a flag on events that notes if the page was hidden previously - … Second option is to have an observer so you can see the entire state of page visibility changes - … Developers on public-webperf mailing list generally preferred the second option, Page Vis Observer (PVO), but there is some feedback in Github issue around discoverability that this could be important - Philip: Issue is more about discoverability that would have to know that Page Visibility affects Paint Timing. Could be easier for developers to discover this if it was on the entry - ... We see many cases on the internet where people are not checking this case (that visibility affected the paint timing entry) - … Having something as simple as possible would be ideal. - ... The other concern I have is if the PVO is async and the Paint Timing Observer (PTO) is async you need to wait a bit to check both of them. So it’s a little bit awkward. - ... My thought is that we should do both -- PVO is useful, but a flag is also useful. “The user thinks maybe you shouldn’t trust this entry because X,Y,Z”. There are many possible reasons in the future why having it on the entry may be useful - Yoav: PVO will give us a full picture of how impacted the resource is, and give developers the option to still count the experience, or segment it. Visibility is possibly not the only thing that would cause tainting. Having both is a matter of resources and but both seems valuable - Nicolas: Right now we would only have one tainted reason (background) -- we’re not ready to have other interoperable reasons for tainted - Philip: Do we need a reason, versus just a boolean? - Nicolas: Github issue requests there’s a string reason instead of just a boolean - Yoav: In the future we may have other reasons that affect events. E.g. during a Long Task. Right now it’s mostly related to visibility, but in the future may find additional events that impact entry types. - Philip: Layout Shifts has a flag that mentions input happened recently - Nic: We may then want to have an array of tainted reasons. Starts going down a rabbit hole a little bit. - Nicolas: Initially it could be an array as empty [] or single string [“background”] - Yoav: For example, segmenting between visibility-related or if Dev Tools was open - Nic: If we do say just “tained” boolean, users will always immediately want to know “why”. Maybe they do want it, maybe not, but without more details they might not know. - Yoav: ResourceTiming: Dev Tools was open and Network Throttling was enabled - … Maybe we don’t want to enumerate all the tainting reasons right now - Nic: Next steps? - … Broad support for PageVisibility Observer. Go forward with that. - … Maybe we continue the discussion for the tainted attribute on the issue - Nicolas: See the value but can add complexity On Tue, May 5, 2020 at 1:57 PM Nic Jansma <nic@nicj.net> wrote: > Hi everyone! > > Join us <https://meet.google.com/agz-fbji-spp> this week to talk about > Event Timing, Page Visibility and Resource Timing. > > *NOTE*: this week's time has moved 2 hours earlier than normal: May 7th @ > 8am PT / 11am ET > > On the agenda > <https://docs.google.com/document/d/10dz_7QM5XCNsGeI63R864lF9gFqlqQD37B4q8Q46LMM/edit?pli=1#heading=h.osvewfb7hvdz>, > we have: > > > > * - Event Timing updates * > > > * - Page Visibility - https://github.com/w3c/page-visibility/issues/29 > <https://github.com/w3c/page-visibility/issues/29> * > > > * - Resource Timing - https://github.com/w3c/resource-timing/issues/226 > <https://github.com/w3c/resource-timing/issues/226> - > https://github.com/w3c/resource-timing/issues/223 > <https://github.com/w3c/resource-timing/issues/223> - > https://github.com/w3c/resource-timing/issues/222 > <https://github.com/w3c/resource-timing/issues/222> - > https://github.com/w3c/resource-timing/issues/221 > <https://github.com/w3c/resource-timing/issues/221> - > https://github.com/w3c/resource-timing/issues/220 > <https://github.com/w3c/resource-timing/issues/220> - > https://github.com/w3c/resource-timing/issues/215 > <https://github.com/w3c/resource-timing/issues/215> - > https://github.com/w3c/resource-timing/issues/200 > <https://github.com/w3c/resource-timing/issues/200> - > https://github.com/w3c/resource-timing/issues/71 > <https://github.com/w3c/resource-timing/issues/71> * > > > > If you have any additional items you'd like to discuss, please add to the > agenda > <https://docs.google.com/document/d/10dz_7QM5XCNsGeI63R864lF9gFqlqQD37B4q8Q46LMM/edit?pli=1#heading=h.osvewfb7hvdz> > . > > The meeting will be recorded and published online afterwards. > > See you soon! > > - Nic Jansma > @nicj > >
Received on Wednesday, 13 May 2020 18:19:02 UTC