- From: Yoav Weiss <yoavweiss@google.com>
- Date: Fri, 4 Mar 2022 11:29:44 +0100
- To: public-web-perf <public-web-perf@w3.org>
- Message-ID: <CAL5BFfWk-95=p+DDOBghaBMhg3OoqwWe7-LW2uaViNVk2_rAyQ@mail.gmail.com>
Minutes from the meeting are now published
<https://w3c.github.io/web-performance/meetings/2022/2022-03-03/index.html>.
Copying them here for convenience:
WebPerfWG call - 03/03/22
Participants
Michal Mocny, Yoav Weiss, Alex Jose, Pat Meenan, Alon Kochba, Andy Davies,
Nic Jansma, Ian Clelland, Corentin Pescheloche, Steven Bougon, Nicolás Peña
Moreno, Noam Rosenthal, Marcel Duran, Annie Sullivan, Giacomo Zecchini,
Lucas Pardue, Sean Feng, Benjamin de kosnik, Boris Schapira
AdminTPAC 2022
- *Yoav*: W3C is looking into running a hybrid TPAC in Vancouver
mid-September 2022
- … Folks who can and are willing to travel are welcome, at the same
time remote-friendly as well
- … Looking into logistics, equipment and time-zones
- … Time-zones may depend on where the remote folks who are joining are
based
- … W3C wants to know the temperature for in-person/remote participation
- … Not asking for a commitment
- *Ian*: There’s a github issue people can +1 on if they want to visit,
for another WG https://github.com/w3c/webappswg/issues/82
<https://www.google.com/url?q=https://github.com/w3c/webappswg/issues/82&sa=D&source=editors&ust=1646392755167765&usg=AOvVaw3EFQkUga8FSw_q5anN4wre>
- *Yoav*: We can do something similar
- … We’ll make it as remote-friendly as possible
Issue Triage
- *Yoav*: Nic and I have been doing some issue triage meetings
- … To try to reduce amount of issues brought to this meeting that are
just “this is work that someone needs to do”
- … Seems like we may want to go beyond just the chairs, parallel to
this one where we go over issues
- … Make sure we don’t forget any issues for 5+ years without looking at
them
- … That we have full coverage of the issues
- … So we don’t bore this broader group with editorial changes that
aren’t interesting to discuss
- … We’ll send mail to mailing list describing it, wanted to provide
context
- … Anyone is welcome to join, but not expected
- *Carine*: Did you consider also looking at cross-issues between WICG
and this group
- *Yoav*: I think such a meeting would also be suitable to go over WICG
incubations and make sure they’re covered
DiscussionsPrefetch’s processing model
<https://www.google.com/url?q=https://github.com/w3c/resource-hints/issues/86%23issuecomment-1053321735&sa=D&source=editors&ust=1646392755169173&usg=AOvVaw1QccDuR22YoWYf9re6eegb>
-
Noam RosenthalSummary
- Prefetch's behavior RE inflight requests should be specified as well.
- The cross-origin navigation prefetch scenario is complex and
arbitrarily caching there can result in unintended consequences. That's
being defined as part of speculation rules
<https://www.google.com/url?q=https://wicg.github.io/nav-speculation/speculation-rules.html&sa=D&source=editors&ust=1646392755169712&usg=AOvVaw2oMxNyk_XTzuxxPrMyYBW4>
Minutes
- *Noam*: Trying to specify things that were underspecified
- … We’ve gotten to link prefetch
- … Not interoperable at all, in terms of every browser doing something
different, or interpret what prefetch means differently
- … While trying to work with the spirit of what prefetch should be as a
hint
- … The way prefetch was described to developers is something that was
meant for subsequent navigation of the same origin
- … So you’re on the homepage, and there’s a CSS that’ll be used by all
subsequent pages, you want to load that CSS file, for all the pages that
are not the homepage
- … Main thing that is common to all implementations, is that it applies
to documents of the current origin
- … It’s also low-priority
- … vs. preload, which is high-priority, and applies to the current
document
- … I’ve checked the implementation of Gecko, Webkit and Chromium, to
see what is actually done for prefetch
- … It all tries to be what I said, except a little differently
- … How interoperable does it need to be?
- … The closer it is within implementations, the more interoperable and
predictable to know it’s actually going to help them in all browsers,
rather than being harmful/useless in others
- … If I look at implementations, I created this pseudo-JavaScript code
of what implementations do
- … In WebKit, it’s just a fetch. If you have several link tags with
that same URL, they wouldn’t send another request (similar to images)
- … In Gecko, prefetching only starts after the window.onload event.
Once that happens, prefetching starts, and once that’s done the next
starts. They’re serial one after another, and low priority.
- … In Chromium, it’s similar to Webkit in that it just sends a fetch,
though it adds a low-priority flag. It stays in the cache for 5 minutes
without the need for validation. If a resource is non-cacheable, it will
ignore that it’s not cacheable for 5 minutes. Load and error events, get
called for Chromium, but are not specified for Webkit.
-
- … I have a straw-man proposal for how to specify Prefetch with hopes
for how we can change it, create web-platform-tests
- *Yoav*: When you’re talking about “coalesce requests”, you’re saying
they’re fetching into the memory cache? So you don’t see duplicates in
ResourceTiming or Dev Tools?
- *Noam*: Correct
- … Proposal:
- Coalesces requests (like Gecko & WebKit)
- Waits until document onload (like Gecko) - makes it low-priority
- Fires load & error events (like Gecko & Chromium)
- Remains in cache without requiring validation for X minutes (like
Chromium) - what makes it special without just fetching something yourself
- *Marcel*: Do you know if the in-flight pickup is part of this? If
prefetch is ongoing and same request is made by some resource, would it
dispatch a new request or use the one that is dispatched
- *Noam*: I think that’s good to have in the prefetch spec. I didn’t
check with the current implementations.
- *Andy*: Did you look at cross-origin prefetches? One of the problems
is if nothing else is on that connection, it happens quite early?
- *Noam*: In general the whole idea of low-priority is that is something
that is beyond the scope of what should be defined in prefetch. I think
it’s OK for browsers to be a little different there.
- *Yoav*: Regarding waiting until onload, there’s a Chromium bug for a
few years now on prefetches getting in the way of other resources,
especially in the X-O case Andy mentioned, but even in same-origin case if
there are silent periods a prefetch request could get in the way of things
of higher priority
- … At the same time, one of the proposals to resolve that was to delay
until onload or DCL, and there’s some resistance to that it would regress
some use-cases
- *Pat*: It’s complicated, the principle of prefetch is that it’s for
the next navigation, but that barrier makes a lot less sense for SPAs and
apps. Finding a well-defined way for when to delay is difficult.
- … Getting them out of the way of the current content, loading at a low
priority but right away is not best
- *Nic*: onload doesn’t matter much. Content is loaded post onload for
SPAs
- *Yoav*: A competing proposal would be a network idle time of X seconds
- *Pat*: Is there a concern if prefetch fires a load event or is
observable, and it’s in a separate network context, and we link it to
network idle, is that across all frames/document/context, it feels like the
realm of security/privacy may shut us down
- *Yoav*: Network idle from the current document may be a safer
definition
- *Noam*: No active fetches in the current document
- *Yoav*: Barring X-O iframes I guess
- … For X-O prefetches, if you’re prefetching into a cache partition
that is different than this cache partition, it can reveal things you don’t
want to
- *Ian*: Waiting for X seconds for idle may be worse from a mobile
perspective, battery/radio shutdowns
- *Noam*: Regarding network idle, I wonder if current low priority/idle
things allow you to see things you shouldn’t see? If you’re prefetching,
and can see something else is being fetched if your resource fetch is being
delayed
- *Pat*: In Chrome you’re almost running separate browsers in each
context at this point with no information shared between them
- *Noam*: For implementations we need to be careful that something
called “low priority” isn’t leaking information
- *Yoav*: Even without load/error information you can poll the cache
- *Noam*: Or use transferSize
- … Suggest putting thoughts into the Github issue
- … Question is how interoperable do we want to be?
- … And if we decide on something, are implementers going to do it?
- *Yoav*: Sean/Benjamin do you have opinions of keeping resources
in-memory for a certain amount of time (for things that are not
`no-store`), when prefetched?
- *Ben*: Sounds kind of arbitrary to me, is there some heuristic that
picked 5 minutes?
- *Yoav*: 5 minutes was arbitrary, any other arbitrary number would work
too
- … Are you suggesting more complex logic?
- *Pat*: There’s an opportunity for an explicit HTTP header to specify
- … Does there need to be a way other than no-store to opt-out entirely
- *Noam*: Wonder if it could be an attribute in the <link>?
- *Pat*: That’s on the caller, and the lifetime needs to be on the
content owner
- *Yoav*: One side that’s sending out links and prefetching those HTMLs,
and the content owner may not want to be cached for 5 minutes because they
want the ability to revoke the content at any time
- *Noam*: In worst case, you could use no-store
- *Pat*: Could I do something strange to your app if content is
prefetched? Other than no-store.
- *Noam*: New max-age for prefetch?
- *Pat*: If I’m evil.org and I put in a prefetch for good.org’s API
call, the good.org app isn’t making the decision to prefetch the API
call.
- *Noam*: Prefetch is only in the context of your origin.
- *Yoav*: Once we start talking about cross-origin prefetches and we
start talking about navigating into those origins, then the concerns are
reasonable
- *Noam*: Everything here is about documents of the same origin, with
everything else to be TBD/specified later
- *Pat*: As far as I know the big case for prefetch is for search
prefetching HTML links and things like that
- *Noam*: Parallel effort which is nav speculation
- … Navigation prefetch of a cross-origin site
- *Pat*: Are there significant use-cases for same-origin prefetch?
- *Yoav*: Landing on home page, and you’re loading resources for next
page in the funnel
- *Pat*: Cacheable and non-cacheable resources behave a bit differently
- … If you have a well-defined funnel and likely product page, it could
make sense
- *Andy*: Some libraries use prefetch to grab the next page when someone
hovers over a link
- *Noam*: Let’s continue on the github issue
- https://github.com/w3c/resource-hints/issues/86
<https://www.google.com/url?q=https://github.com/w3c/resource-hints/issues/86&sa=D&source=editors&ust=1646392755175192&usg=AOvVaw3VzsAjNvohwc1g9UBznIpc>
JS profiling - lowering the minimum sampling interval
<https://www.google.com/url?q=https://github.com/shhnjk/shhnjk.github.io/blob/main/investigations/js-self-profiling/lowering_interval.md&sa=D&source=editors&ust=1646392755175558&usg=AOvVaw09hgrKkVeRH1Ua1UM6plQH>
-
Corentin Pescheloche
Recording
<https://www.google.com/url?q=https://youtu.be/6B5j5R1JDes&sa=D&source=editors&ust=1646392755175805&usg=AOvVaw3aQ4WfiacHzOL5R26ufnqu>
Summary
- Interest from partners to have lower sampling rates
- Seems safe to do security-wise, but needs verification with sec folks
- Some concerns RE the performance implications. Requires more testing.
Minutes
- *Corentin*: Interest from partners in JS Profiling API
- … Want to leverage past experiences with group on high-resolution timer
- … JS Profiling API is a web-exposed sampling profiler
- … Helps you jump into performance issues of JS code on user-devices
- … Have an interface to specify the interval, max buffer size
- … After you’re done profiling, you can generate a case and send it
back for processing
- … Frames and resources in the stack as an array, samples and stacks
- … Looking for feedback on lowering sampling interval, from 10ms to 1ms
- … Specification leaves option to UA the resolutions they support
- … Risk in introducing timing attacks
- … I believe API shipped with 10ms min resolution because of issue on
high-resolution timer wasn’t resolved at that time
- … Security review done by Microsoft for Blink
- … HR timer is 100us for non COI
- … 1ms sample is 10x, concludes low risk
- … Should we update the spec to advise a reasonable sampling rate for
UAs in relative to HR time resolution?
- *Yoav*: Intuitively I agree with the conclusion that 1ms sampling
can’t introduce more granular timing attacks, have you looked into other
aspects of increasing the sampling rate, beyond security?
- *Corentin*: Mostly concerned arounds security aspect
- *Yoav*: With increasing the sampling rate, do we expect same-overhead,
linear overhead, or super-linear overhead
- *Corentin*: I can do an experiment to do that feedback
- *Nic*: Are there others besides Facebook sharing overhead data?
- *Yoav*: Microsoft are based on the security review, do you think they
can share some insight?
- *Corentin*: I’ll reach out to our contact over there
- … Sounds like what you’d like to see is the scaling impact of the API
as we scale to lower resolutions
- … Back to security concerns, are there any issues supporting the same
resolution as the high-resolution timer?
- *Yoav*: I expect this is a question for the security folks of the
different browsers to answer
- … I can’t think of a reason off the top of my head but I’m not being
paid to be paranoid for a living
- … Might be worthwhile to run by different security teams
- ... Is this something Mozilla has looked into?
- *Sean*: We’ve looked into this, interest in the API, but I’m not
following that progress
- *Yoav*: Is there an open issue on the spec that folks can get back to
you later on?
- *Corentin*: https://github.com/WICG/js-self-profiling/issues/68
<https://www.google.com/url?q=https://github.com/WICG/js-self-profiling/issues/68&sa=D&source=editors&ust=1646392755177975&usg=AOvVaw2eHqfCvuj_oTCa9gEcgV15>
- *NPM*: Little concerned about the performance implications of allowing
the lowest possible sampling we can get. What are the use-cases beyond the
current resolution limit?
- *Corentin*: I don’t have the exact story behind how the 10ms came to
be, but it seems that it was arbitrary and on the safe side.
- *Yoav*: Is the limitation from Microsoft that they’ve hit?
- *Corentin*: Yes, this came from their requests
- *Yoav*: Nicolás would you be happy with some performance numbers if
Corentin can run experiments, or is there something else.
- *NPM*: Yeah we want to make sure it’s not going to cripple the user
that’s going to be the result of this experiment
- … We know there’s some substantial overhead to sampling.
- … Sounds possible that lowering the possible sampling interval it will
result in overhead
- *Corentin*: Would this be something we can ship as an origin trial so
we can get actual data?
- *Yoav*: Yeah, starting with lab experiments to get order-of-magnitude,
then origin trials to get production data
- *NPM*: Not sure we need an origin trial
- *Corentin*: OK, lab should be enough
Interaction counters, take 2 - Michal Mocny
- Previous presentation
<https://www.google.com/url?q=https://docs.google.com/presentation/d/14ngf6XgjNcNFM5Bya1OArpDRXtSy53o16YxdrZs8PCo/edit%23slide%3Did.p&sa=D&source=editors&ust=1646392755179025&usg=AOvVaw1PJQgHrvB0tRuyAHFFuirb>
(previous minutes
<https://www.google.com/url?q=https://docs.google.com/document/u/1/d/e/2PACX-1vQYGB_6_hVxKJX6vm6onSGdHpC4k-NMg9XulXwKHLMQrfQvrp-Oh58xuO5iJEmZ4nFp2cIL_Rf1Vc5I/pub&sa=D&source=editors&ust=1646392755179233&usg=AOvVaw0CwA70ewxaSyJP0YzM2WXO>
)
- *Michal*: Extending eventCounts
- … Prefer Solution 2 a map of performance.interactionCounts
- ... Did not discuss Solution 3
- … What are the key values?
-
- Does anyone have a use-case in mind where someone would want interacts
by type, instead of overall?
-
- *NPM*: If you wanted keyboard latencies, vs. other latencies?
- *Michal*: We have some discussions, I’ll follow up with a Github issue
and we can discuss more on another call if it’s not resolved by then
On Wed, Mar 2, 2022 at 9:47 PM Yoav Weiss <yoavweiss@google.com> wrote:
> Hey folks,
>
> Join us <https://meet.google.com/agz-fbji-spp?authuser=0&hs=122> tomorrow
> to talk about webperf!! Note that this week's meeting would be 2 hours
> before our typical time until now, as we started alternating slots to
> better accommodate folks from EU time zones.
>
> On the agenda
> <https://docs.google.com/document/d/10dz_7QM5XCNsGeI63R864lF9gFqlqQD37B4q8Q46LMM/edit?pli=1#heading=h.7227nyy9fdc1>
> we have:
>
> - A group discussion about a hybrid TPAC
> - Questions regarding prefetch's processing model and what we should
> define there
> - JS profiling and whether we should lower the minimum sampling rate
> - A short conversation about interaction counters
>
> Hope to see y'all there!
> The presentation portions will be recorded and posted online.
>
> Cheers :)
> Yoav
>
>
>
>
>
Received on Friday, 4 March 2022 10:31:27 UTC