Participants:

Giles Dubuc, Todd Reifsteck, Ilya Grigorik, Yoav Weiss, Philippe Le Hegaret, Steven Bougon, Vivek Sekhar, Ryosuke Niwa, Benjamin De Kosnick, Thomas Kelly, Nate Schloss, Nic Jansma

Administrative

• [Philippe]: Ralph tried to talk to Tim, a week ago, and Tim came with a proposal. Ralph will come to TPAC at the f2f Tuesday after the break, to talk about High Resolution 2 (HR2). Context: privacy folks had some feedback on this spec, which we closed, but they formally objected to move HR-2 to next steps. So, at this point, we don’t have a decision, but it’s moving :-)

Design

• Signed Exchange, Bundles , Portals, what it means for WebPerf.
• [yoav] wanted to talk about it at F2F. Anyway, Chrome wants to ship some APIs regarding this, though there is no consensus from other UA. here, we will talk about how it relates to perf.

• Signed exchange: goal is to decouple the “where it comes from” from “where it’s serves”. One issue is that it does not provide confidentiality (b.com knows that something from a.com was served). The browser treats it like an internal redirect.
• Use case:

• Privacy preserving prefetch: SXG allows services to prefetch without the origin to know about it
• Offline PWA installs: enables various offline caches (but problem with sign discovery).

• Regarding Perf and SXG: additional steps: the browser needs to download and verify the certificate chain (extra hop). Do we want to expose that the content came from SXG ? Can we expose the distributor ?

• [todd] The issue is against NavTiming. I assume it also applies to Resource Timing
• [yoav] We mainly talk about SXGs in the context of navigation responses, because of how they are used today, but theoretically can also apply to stand-alone resources. (e.g. for some CDN use cases)
• [Ilya] Nothing stops you from using SXG on a subresource, it’s just not a use-case we’ve seen tried.
• [todd] Feels it should be fixed in resource Timing not in navigation timing.
• [yoav] Probably a L3 issue, where we are planning to merge both specs, so it won’t matter much. But you’re right.
• [Ilya] Issue 107 . The non-controversial bit is exposing that something was served from an SXG. Exposing a validation timestamp would give us that.
• The bit we still need to figure out is how much we can expose about a specific distributor.
• [Ilya] content was distributed by X distributors. How do we know the perf of each distributor? We’re still working out details and what would be the privacy and security implications of that. But as a first step, we should define validation start (though clearly L3 work).
• [benjamin] Re 107: is it paused till WebPackaging folks figure out next step?
• [Ilya] More or less, but we should break down the issues (some controversial and some not)
• [benjamin] Do we just need to provide validation timing?
• [Ilya] we would add a step for validation which will let you know that you loading from the SXG, and how long the validation step took.
• [benjamin] Exposing certification validation time in SXG seems essential.
• [benjamin] Chrome devtools have this concept of internal redirect. Would love to see internal redirect defined as a new type of redirects.
• [Ilya] true, we call it “Internal redirect” though not currently spec’d
• [benjamin] Need to be spec’d. Bring it on at TPAC ?
• [Ilya] First use case for “Internal redirect” in Chromium is HSTS
• [benjamin] yeah, let’s talk about “Internal redirect” to make it a standard.
• [Ilya] Also, we’ve seen cases where internal redirects take a lot of time, so need to be measured
• [benjamin] yeah, same here for cert validation
• [ryosuke] We are implementing HSTS in the CFNetwork library, but SXG will not be implemented there. So if they are both using the same mechanism, that may cause implementation challenges.
• [benjamin] The terms transport origin and certificate origins seem to be new terminology, where are they defined ?
• [yoav] Defined in the WebPackaging WICG repo. Discussions on creating an IETF WG for that
• [benjamin] Seems of great importance to properly define these new concepts
• [benjamin] One more question - why do we want to hide resource fetches from the origin?
• [yoav] Resource prefetch. Prefetching resource before user has shown interest (eg: site a.com have links to b.com, c.com. Site a.com wants to prefetch these links. Prefetching might leak some intent that the user hasn’t expressed yet). For example, google search result might want to prefetch sites without the sites knowing it.
• [benjamin] The user didn’t ask for those prefetches, so that’s not a user problem we’re solving.
• [yoav] Performance is the user’s problem. Cross-origin prefetch solves a real performance problem, and doing it privately requires something like SXG as a primitive.
• [benjamin] can a user turn off prefetching?
• [Ilya] really good (product) question. Let’s defer that to the SXG people (who will be in TPAC)
• [todd] It’s possible from fetch to do CO requests. It’s not a new privacy leak
• [yoav] not new. SXG makes cross-origin requests less privacy invasive

• Bundles Exchange

• Bundled exchange is a concept that used to be with SXG, but now is split. It’s very similar to multi-part resource bundle, but it’s not awful. Various use case:

• Prefetch for sub-resources
• More performant for ES module
• PWA in app store: still from origin, but delivered by the app store

• Resource Timing:

• We will know if it served from a bundle or not
• Bundles are progressively parsed. We are introducing the parsing over-head of bundles as something that will impact individual resource’s start and end times

• [todd] are you talking about client side parsing or server-side + range requests? can range requests work with bundles?
• [yoav] I’m speaking of client side parsing. Range requests can work but once you compress the bundle as a single resource, but then all bets are off for range requests.
• [yoav] The scenario to consider is navigation for foo.html (containing foo.js, etc). Browser receives the bundle. See that it gets foo.html, mark the timestamp, and only then gets foo.js, even though the overall bundle may still continue loading. So we are mixing download and parsing time.
• [todd] but if I ask for a subset of the bundle ?
• [yoav] not sure if a portion of a bundle can be parsed out of context. Jeffrey Yasskin is the person to talk to for details on that.
• [todd] If it downloads the whole bundle, and we get foo.html, and at that point mark that resource’s start time. Doesn’t quite fit the model we have today
• [yoav] Yeah, at least if we want to be getting the granularity we have today.
• [todd] so if we just expose the bundle start and end time, it will hide subresource timing, and potential slowness if the bundles are built in a streaming server. Is that information needed?
• [yoav] Format doesn’t support building on-the-fly, only on-the-fly subsetting. Otherwise, if we don’t expose start and end time, then we have a monolith bundle and we will hide all the internal bundle, so we will never know why a JS did not start the parsing on time. In the extreme, a site delivered over a single bundle will have the same start and end times for all subresources.
• [todd] it’s like inlining JS, you don’t have the information
• [yoav] correct. But not ideal
• [todd] Sure, but how urgent is it?
• [nic] our customers would like to know which resource is large, small, came with the bundle
• [todd] today, we don’t know parse time. It can start any time. With bundle, we will lose information. But trying to see if timing here is really needed.
• [yoav] yes, in-bundle timing is needed as much as resource timing is needed. If a bundle is bloated or mis-ordered the bundle, you’d want to know. Needs more thought.
• [todd] Should we talk about exposing parse time in general?
• Here, we should talk about exposing the parse time of the bundle, for resource discovery (not the JS itself).
• [nic] would there be info about bundle content not used by the page
• [yoav] in today’s model, resources in the bundle but not on the page won’t be exposed
• [todd] Would a resource in a bundle also have an RT entry?
• [yoav] it should be

TPAC

• Agenda is here.
• Monday for designs and Tuesday for issue discussion and progress
• [benjamin] LCP implementation experience session?
• [steven] metrics for SPA?
• [yoav] We should block a couple of hours for that. Also, a related discussion about resetting the history API which may be related.
• [Ilya] Also - CompressStream. Exposing an api to compress the data on the client. Incubated in Japan team in Chrome. We should try to schedule
• [nate] planning to join that effort. Andrew was hoping to talk about that
• [nate] isInputPending: is there a consensus to go from WICG -> WebPerf?
• [yoav] so admin discussion
• [todd] Is there something about isRenderingPending?
• [yoav] I can check with Stefan Zager
• [todd] Also for Frame Timing, let’s schedule it late so Noam can join
• [yoav] Maybe we can do 1½ day for Design, ½ day for issue, if not a lot of issues to discuss.
• [todd] people may want to some in-person work/spec reviews
• [yoav] sure, but that doesn’t require the entire group
• [benjamin] makes sense to prioritize design where we’d be getting a large amount of cross-section collaboration