- From: Yoav Weiss <yoavweiss@google.com>
- Date: Fri, 12 Aug 2022 13:34:35 +0200
- To: public-web-perf <public-web-perf@w3.org>
- Cc: "Jansma, Nic" <njansma@akamai.com>, Carine Bournez <carine@w3.org>
- Message-ID: <CAL5BFfWWeK5uV5d3W16T2MOcafLJ_m-sNKsLMQfoHxUsAN_C=Q@mail.gmail.com>
The minutes from last week's meeting are now published
<https://w3c.github.io/web-performance/meetings/2022/2022-08-04/index.html>.
Copying them here for convenience:
WebPerfWG call - August 4th 2022
Participants
Yoav Weiss, Alex N. Jose, Lucas Pardue, Annie Sullivan, Refael Lebre,
Michal Mocny, Nic Jansma, Dan Shappir, Pat Meenan, Amiya Gupta, Alex
Christensen, Andrew Galloni, Aoyuan Zuo, Ian Clelland, Abin Paul, Philip
Walton, Giacomo Zecchini, Marcel Duran, Rafael Lebre, TK(?), Mike Henninger
Admin
- Next meeting - September 1st
- 1pm EST / 10am PST
- Skipping August 18, 2022 due to holiday and slowdown in topics
- WIP TPAC Agenda items
<https://www.google.com/url?q=https://docs.google.com/document/d/1RbszCu4NG-fcRRoL1TsP6SvjohIuz-uxv5NZm_6iA4U/edit&sa=D&source=editors&ust=1660306450312406&usg=AOvVaw2L8Ks6trAd22Va0qWshZcl>
- Please add issues, proposals, use-cases that are/are not covered well
- CfC for Beacon
- Any objections, please voice on mailing list
MinutesSet response body info's content type to type after sniffingSummary
- Strong preference to avoid exposing sniffing results
- No real use case for sniffing, server generated mime type seems good
enough
- Preference to coalesce server provided values to a known set of valid
mime types, to avoid servers leaking information to the document using
cross-origin resources.
Detailed minutes
- https://github.com/whatwg/html/pull/8139
<https://www.google.com/url?q=https://github.com/whatwg/html/pull/8139&sa=D&source=editors&ust=1660306450313810&usg=AOvVaw1qBapPKHcXz9Lzzft3wUZ4>
- *Abin*: Issue regarding Content-Type that we wanted to expose
- … Either surface the Content-Type from the server
- … or use mime-sniffing and expose that into ResourceTiming
- … Draft feedback to not expose mime-sniffing so as to not hard code
that in
- … Can we just stick to what the server tells us?
- … What’s the use case for exposing the sniffed type?
- *Nic*: From a CDN point of view, it would be sufficient to expose the
server’s responded content type. There may be some cases where knowing the
browser chose to use it differently could be useful (to surface bugs).
- … At the end of the day, those would be rare, so the server’s content
type would be interesting to get
- … If there are spec concerns around exposing sniffing, it’s ok to take
the simple path
- *Yoav*: Exposing the Content-Type is easier from spec perspective
- *Dan*: Exposing Content-Type would be beneficial, seeing more
scenarios where mismatch from type expected from URL vs. Content-Type.
- … E.g. images where the URL can be one thing and other content
delivered
- *Yoav*: And server-provided Content-Type is good enough?
- *Dan*: Yes
- *Amiya*: If it can be an arbitrary field, could servers fingerprinting
or have a unique ID sent down?
- *Yoav*: They can already do that with Server-Timing, providing an
arbitrary string, or as part of the content
- … Don’t see any specific capability that this would provide beyond
what we have
- *Dan*: If anything not using the server-specified Content-Type would
be more susceptible to fingerprinting, if it was a client-derived value vs.
what the server says
- *Yoav*: If there are differences in implementations, theoretically all
browsers should MIME-sniff identically, but it could be used by a
user-agent fingerprinting
- … You could detect browser behaving unlike what it’s advertised to be
- *Lucas*: Using server Content-Type is fine, ensuring reflecting
omission should be possible
- *Yoav*: We need to specify what happens when it’s not there
- *Alex*: Use-case for this is to detect incorrect content types
- *Nic*: We have an image compression services at the CDN level, but
from a RUM perspective, we only see the URL. Knowing what type of content
came in would help a lot
- *Dan*: Wix already implemented such a mechanism, where the URL is
fixed, but the image format delivered depends on the UA
- *Alex*: I can’t say that there are no fingerprinting concerns. May
have to do some sanitized content type. We’ll deal with that as it comes.
- … “Can already do that with Server timing” is not a great argument
from our perspective as we don’t yet ship Server Timing
- … I proposed we’d enable server timing and it was denied
- *Yoav*: Trying to understand the case, do you have some sort of
server-side identifier
- … If you don’t have cookies, you can send it w/ the resource to the
document, and you somehow reflect it back?
- *Alex*: I think so.
- *Dan*: Just to clarify I follow, third-party cookies are prevented,
but the third-party resource sends Server-Timing information?
- *Alex*: Correct.
- *Yoav*: Could be an interesting topic for discussion at TPAC if you’re
interested in discussing this further
- … But for this maybe you could keep Content-Type as a pred-efined list
of options, or coalesce to a set
- *Alex*: Something like that. Not sure if UID could be tacked on to
the end of the Content-Type field.
- *Yoav*: Yeah I think the primary use case is getting the class/type
instead of the full field, so we could start from there.
- … I will add that Server-Timing fingerprinting stuff as a subject at
TPAC if you don’t mind
- *Alex*: In favor of no sniffing
User Timing conventions - Annie
Recording
<https://www.google.com/url?q=https://youtu.be/CROTBMuiuS0&sa=D&source=editors&ust=1660306450317737&usg=AOvVaw0eNyPdIZMhwpaKp_MzQkO7>
Summary
- Removed from spec due to lack of usage
- Seems useful, and we should try to revive it
Detailed minutes
- *Annie*: In UserTiming Level 1, there was a “recommended mark name”
section
- … Sites could mark when fully loaded, fully visible, above the fold
and time to user interaction
- … Events like Page Load didn’t fit all the cases, and we think even
with Core Web Vitals there may be a lot of product-specific cases with
points to track
- … The reason we’ve been looking at it in Chrome, sites would like to
tell us specific points in page load where e.g. a large object is loaded
they want to optimize
- … But could help with RUM, automated testing tools, etc
- *Nic*: Vague memory, but removed due to lack of usage
- … extremely little use, and when the spec moved to L2, it was dropped
- *Annie*: Did an HA study last year and 6000 sites use mark_fully_loaded
- *Nic*: Was always in favor of keeping them in. Not doing anything
special with them due to low usage. But we would incorporate if more people
use them
- *Michal*: One that isn’t on the list mark_time_to_interactive. TTI is
a browser-defined metric, but many sites define their own “interactive” as
hydration complete. A hot topic of competition. Would be interesting to see
- *Dan*: Contrary to that. Instead of using the same name for
potentially different things, we may want a standard implementation and
measurement
- *Annie*: Working on that, but there are still concerts that are only
relevant in some pages
- *Dan*: Standard names without standard semantics seem problematic.
Different implementations would do different things. “Naming things”
without specifying what they are
- *Pat*: Part of that can be avoided by naming these.
“Mark_site_is_useful”.
- … Not used for comparing sites, but in the context of the same site or
in the browser, they can be used to spot regressions and optimize to
improve those metric
- … “user engaged” or “user did something useful from a biz perspective”
would enable us to correlate perf and biz metrics
- *Nic*: Bringing it outside of perf focus could indicate to a RUM
system that something interesting happened. Understand Dan’s concern about
these being undefined. As long as there are no carrots attached to that,
that seems fine.
- … intentionally left vague and not comparable across sites. Useful for
devtools, RUM, etc
- … The original user timing spec design foresaw everyone using those,
but that didn’t happen
- … In favor of reviving those
CORS, CORP, TAO & "public static resource" metadataSummary
- Strong preference to not override semantics of existing ACAO opt-ins,
but create new ones
Detailed minutes
- https://github.com/whatwg/html/issues/8143
<https://www.google.com/url?q=https://github.com/whatwg/html/issues/8143&sa=D&source=editors&ust=1660306450320752&usg=AOvVaw3cYH8NEvH3oWlDXu91im5n>
- *Yoav*: Figuring out a way to somehow bridge the gap between CORS and
TAO
- … Came up in context of Content-Type changes
- … CORP enabled reading of metadata
- … Instead of trying to force metadata reading opt-in to CORP, it would
be better to just have some sort of public resource opt-in that would work
for CORS, and non-CORS fetches
- … Dominic proposed to simply consider ACAO: * if no credentials were
sent nor set (even if the fetch itself was in no-CORS mode) it would be a
public resource and would be OK to expose various details about the source,
TAO opt-in, Content-Type and other bits
- … A bunch of discussion but maybe most notably Ollie on the Mozilla
side is generally in favor of that idea but prefers a more explicit opt-in
that would avoid changing the current semantics.
- … The adoption curve is steeper since ACAO: * is widespread
- … Advantages and disadvantages to both sides, but seem generally
reasonable
- … We’re still waiting on some more opinions, but wanted to let
everyone know this is happening and you can chime into the issue
- … Are there any particular objects here?
- *Alex*: I’m generally opposed to CORS implies ability to read timing
data
- … Because timing data is not visible across-origin by default
- … And if they want to make it available via TAO, I don’t think we
should add a generous interpretation of old technologies to data they did
not have access to.
- *Yoav*: For a resource that is CORS enabled, looking beyond network
data (requestStart), the rest is exposed to any origin that would fetch
what that resource would fetch.
- … e.g. measure when responseStart is observable
- *Alex*: This is the side-channel argument and you’re correct it could
be gleamed
- … But I would be opposed to exposing the information just because CORS
has a * on it
- *Yoav*: What about a new opt-in what would imply ACAO and TAO
- *Alex*: Yes that means the server was updated by somebody that says
“I’m allowing both”
Need a new DOM concept for user-driven events rather than using isTrusted
Summary
- Similarity to the concept of user activation, but it doesn’t take
scrolls into account
- Seems like this is needed for scrolls only.
Detailed minutes
- https://github.com/w3c/largest-contentful-paint/issues/105
<https://www.google.com/url?q=https://github.com/w3c/largest-contentful-paint/issues/105&sa=D&source=editors&ust=1660306450323113&usg=AOvVaw2NoDDSPe4k-UPLhDPRaox1>
- *Yoav*: Issue regarding isTrusted attribute and one of the tests is
that we’re modifying the scroll using element.scrollLeft() and this is
triggering a trusted scroll event, which by spec should stop LCP entries
- … Seems like there’s a bug in Chromium where this doesn’t stop LCP
- … Not what we intended by trusted events stopping LCP entries
- … We want user scrolling to stop LCP but not what user is doing with
script
- … Need a new concept in DOM spec that indicates that type of user
interaction, at least for scroll events
- … Not clear if we also need this for input events
- … Having a discussion with Domenic and Noam regarding this is
something that needs to be defined
- *Michal*: Some APIs are gated on user-interaction already, e.g.
permission prompts, do they have a similar problem?
- *Yoav*: Not sure. User activation spec concepts, not sure if it
relies on trusted events or not
- … I don’t believe scrolling is considered user activation
- … It’s a good point we can try to look into how that’s specified and
piggy-back on it
- *Philip*: Is the use-case to point to something from LCP spec in HTML
spec that is not accurate, or is the use-case to provide a web-exposed
version of this behavior that someone can then measure LCP with by checking
isTrusted
- *Yoav*: Goal is to initially properly specify LCP, as spec is not
doing what we want it to do
- … If you have JS driven scrolling, that is something that is supposed
to stop LCP due to the spec, but not according to the spec’s spirit
- … If there are use-cases beyond that to web-expose, that could be
interesting but beyond what we had in mind here
- *Philip*: Is the problem in Chrome implementation or what’s specified?
- *Yoav*: What’s specified. Chrome does what’s intended of the spec but
not that’s not well specified. Which is why it's helpful having a second
implementor to point out those gaps.
- *Philip*: There was a point in the web-vitals JS library, we would
look at scroll event not as a signal for LCP but to understand when to not
look for more events
- … It was a nice feature of the library to know when to stop listening
- … If we need to better specify an algorithm for LCP that makes sense
- *Yoav*: Dan in the past asked for some way to know the browser is no
longer listening to LCP entries, and that could be a separate event or
entry.
- … Underlying concept based on isTrusted or something else, but higher
level abstraction that says LCP has stopped
- *Dan*: I asked for that primarily so the client could send this
information back to the server
- … If there’s any way to send this information earlier it increases
likelihood of a RUM provider to send this data
- *Michal*: Exactly why we had listened to this scroll event
- *Yoav*: With Unload Beacon you may no longer need that
- *Dan*: Unload Beacon would increase likelihood to send info at the end
of a session, but it’s not 100%
- *Yoav*: And you may want to send LCP when it’s ready or send
complementary data
- *Michal*: I found user activation algorithm, it’s defined in terms of
isTrusted, but it filters on specific event types, and I wonder if those
event types in this context you can’t fire from JavaScript
- *Ian*: User Activation is based on isTrusted but doesn’t cover scroll
events
- … pointer-up may be true on mobile devices but not desktop
- … Don’t consider page activated on scroll
- … Activation also does interesting this with frames, activating a
frame activates its parent
- *Yoav*: Yeah wasn’t planning on tying it to it, but could be
interesting to see what it’s doing
- … Good for input but not scrolling
*Links*:
Abin Paul7:14 PM
https://github.com/whatwg/html/pull/8139
<https://www.google.com/url?q=https://github.com/whatwg/html/pull/8139&sa=D&source=editors&ust=1660306450326532&usg=AOvVaw3mqOHZZFSdQzHMIrJWtt5->
Lucas Pardue7:19 PM
you could constrain the list to registered media types from IANA -
<https://www.google.com/url?q=https://www.iana.org/assignments/media-types/media-types.xhtml&sa=D&source=editors&ust=1660306450327044&usg=AOvVaw0lldB9N53K3-_ZKx4cYWMV>
https://www.iana.org/assignments/media-types/media-types.xhtml
<https://www.google.com/url?q=https://www.iana.org/assignments/media-types/media-types.xhtml&sa=D&source=editors&ust=1660306450327244&usg=AOvVaw32M8pZGw9_9WJ4Jml93fNr>
Nic Jansma7:32 PM
https://github.com/whatwg/html/issues/8143
<https://www.google.com/url?q=https://github.com/whatwg/html/issues/8143&sa=D&source=editors&ust=1660306450327658&usg=AOvVaw3eyawxM5U64P5EuIc9ZckD>
Nic Jansma7:39 PM
https://github.com/w3c/largest-contentful-paint/issues/105
<https://www.google.com/url?q=https://github.com/w3c/largest-contentful-paint/issues/105&sa=D&source=editors&ust=1660306450328063&usg=AOvVaw34PA6mLeLE9GtKsFL-yYVo>
Michal Mocny7:48 PM
Hmm, user activation is defined in terms of isTruster + types:
<https://www.google.com/url?q=https://html.spec.whatwg.org/multipage/interaction.html%23activation-triggering-input-event&sa=D&source=editors&ust=1660306450328559&usg=AOvVaw3AZWaaJzPaHgvz3A209YM6>
https://html.spec.whatwg.org/multipage/interaction.html#activation-triggering-input-event
<https://www.google.com/url?q=https://html.spec.whatwg.org/multipage/interaction.html%23activation-triggering-input-event&sa=D&source=editors&ust=1660306450328801&usg=AOvVaw12_DoRU9NmlOaQneF9qbE1>
On Wed, Aug 3, 2022 at 9:55 PM Yoav Weiss <yoavweiss@google.com> wrote:
> Hey folks,
>
> Let's talk <https://meet.google.com/agz-fbji-spp> webperf tomorrow! On
> the agenda
> <https://docs.google.com/document/d/10dz_7QM5XCNsGeI63R864lF9gFqlqQD37B4q8Q46LMM/edit?pli=1#heading=h.6rk0josqrh6l>
> we have User Timing conventions, LCP and trusted events, and a proposal to
> bridge gaps between CORS and TAO.
>
> See y'all there!!
>
> Cheers :)
> Yoav
>
Received on Friday, 12 August 2022 11:35:17 UTC