Re: WebPerfWG call today!! 10am PT/1pm ET/7pm CET

Minutes are now published at
https://w3c.github.io/web-performance/meetings/2025/2025-08-28/index.html

Copying here for convenience:
Participants

Patrick Meenan, Noam Helfman, Adrian de la Rosa, Barry Pollard, Michael
Wilson, Bas Schouten, Jacob Groß, Robin Marx, Nic Jansma, Yoav Weiss,
Gouhei Deng, Michal Mocny,  Andy Luhrs, Philip Tellis, Joone Hur, Carine
Bournez, Michelle Vu, Victor Huang,
Admin

   - Feedback form on WG participation -
   https://docs.google.com/forms/d/e/1FAIpQLSeEZOM3txDvSN9mMR_7dMNfmhKw0imMnmgX3OlJCnloqxuwjQ/viewform?usp=header
   <https://www.google.com/url?q=https://docs.google.com/forms/d/e/1FAIpQLSeEZOM3txDvSN9mMR_7dMNfmhKw0imMnmgX3OlJCnloqxuwjQ/viewform?usp%3Dheader&sa=D&source=editors&ust=1757078122638406&usg=AOvVaw3DlgG_Sk1_yiSxz-XvJlac>



   - How are we doing as chairs, can we make participation easier/better,
   etc


   - TPAC is approaching!! Add topics to the agenda:
   https://bit.ly/webperf-tpac25
   <https://www.google.com/url?q=https://bit.ly/webperf-tpac25&sa=D&source=editors&ust=1757078122638903&usg=AOvVaw3NRXxMTfPB0af9WN2oImHw>


MinutesExpose Performance interface to AudioWorklet
<https://www.google.com/url?q=https://github.com/w3c/hr-time/pull/169&sa=D&source=editors&ust=1757078122639287&usg=AOvVaw2v6-hSwMAiWxKiVa6UuqGf>
 - PR:hr-time#169
<https://www.google.com/url?q=https://github.com/w3c/hr-time/pull/169&sa=D&source=editors&ust=1757078122639429&usg=AOvVaw2d-2ZUBRvwLyAweYXMySMU>

*Michael*: Working on the Web Audio API which has an audio worklet.

… Seen requests for performance.now() inside the audio worklet.

… Want to discuss to see if it can be done safely and efficiently

… The Audio WG thinks it should happen, but looking for feedback

*Nic*: Beyond performance.now() are there other performance APIs that could
be useful in Audio worklets?

*Michael*: Seems like developers are trying to get performance information
and get timing inside the worklet

… Trying to get timing for signal processing code and how it runs

*Nic*: How would developers would surface this timings? Through the main
page?

*Michael*: I’m pretty sure they want to use it inside the worklet itself

*Bas*: I assume that all the stuff that goes through the worklet is cross
origin safe, right?

*Michael*: I should double check. Need to be in a secure context and there
are cross origin restrictions

*Bas*: If you can have your signal processing code process bytes from
another origin, that would be bad

… I assume that’s already the case, as there are other ways to exfiltrate

*Yoav*: Said developers want to use this in worklet itself

… I that they want to measure code to adapt it to machine or to some other
thing, or to measure code to report measurements to server to make sure
code is optimized

… For the second one, it may make sense to expose this info to main window
rather than they have to postMessage to report it, or to beacon directly
from the worklet

*Michael*: Possible they’d want to use this timing information, if
processing is taking too long, switch to other version.  Or higher quality
version.

… It’s not just one request for this

… From a cross-origin isolation perspective, performance.now() has
different granularities when inside COI environment vs. not, what would
AudioWorklet be?  Attached to document that may not be COI?

*Michael*: SharedArray buffer can only be used in COI context.  Some audio
apps can do it, others cannot.

*Yoav*: For documents, depends on COI bit, but I don’t know if that exists
in AudioWorklets or not.

… Something we’ll need to figure out in order to properly specify this.

*NoamH*: I’m not aware of a way to communicate back to main thread.  Can
you postMessage() back to main thread or not?

*Yoav*: If current communication is not allowed, how can we make sure this
isn’t a backchannel?

*NoamH*: If there’s a threat or vuln, that depends on timing attack, how
could it be used?

*Yoav*: I don’t know why there isn’t a comm mechanism, I just wouldn’t want
the first comm mechanism worklets could use

*Bas*: Certain if you have an accurate timer available, you could time CPU
work and measure contention on main thread and create a backchannel.

… w/ high resolution timer, you could create a backchannel.  But there’s
also existing ones.

*NoamH*: Is proposal to share .performance from main thread, or isolated to
AudioWorklet?

*Michael*: Just .now(), doesn’t need to be same .performance interface as
main thread.

*Yoav*: I think it would be useful to gather at TPAC as a breakout or joint
session and talk through use-cases, get a better understanding of what
they’re trying to do, so we can do it safely

… Exposing performance.now() is step 1

… Make sure whatever we build wouldn’t be inherently different between
interfaces
Compression Dictionaries Error Reporting
<https://www.google.com/url?q=https://docs.google.com/presentation/d/1UrceUht-GTzVhO-fxWAUYhWdtTGIf1yFYHusEXUPLok/edit&sa=D&source=editors&ust=1757078122645523&usg=AOvVaw1O7OORqJUsVOn5d4ORIlVG>
-
Robin Marx / Pat Meenan

*Robin*: compression dictionaries allow you to compress one file relative
to another

… Implementing it at Akamai and broke my setup several times

… It was unclear why it was breaking and how

… Typically only see devtools error message and no user visible error

…* Some issues I ran into*: add a magic header, not part of the libs

… If you dictionary compress your whole site, the whole site will go down
if you have these error.

… also all JS telemetry won’t run

… NEL helps in such cases, but compression errors aren’t part of it

… Should this be part of NEL? I couldn’t find anything about this in the
specs nor in Chromium code

… It’s possible that some errors (HTTP response invalid) are sent, but
wanted to discuss

… Is this something we need to worry about and how can we fix it?

… Unclear if these problems are worth caring about, as they should only
occur in the initial implementation phase

… Plus if all your RUM beacons go to zero, that’s an indication

… Looking into this, I found it hard to understand how NEL is implemented.
Documentation would help

*Pat*: Haven;t looked at the spec, but MDN claims HTTP_RESPONSE_INVALID
should cover improper encoding. So the browser should spit that out when
there are invalid compression dictionaries

… Planning to add tests to that effect

… Original goals for NEL was to get visibility into intermittent issue.
This feels borderline on that

… It’s not a middle box doing that, it’s the server messing up their
deployment

*Michal*: No experience on compression dictionaries. I assume that if you
get it wrong, it would be suboptimal

*Pat*: It’s like sending a binary as a response to HTML. You’d get a failure

*Michal*: Are there discussions on getting it more resilient?

*Pat*: You can’t guarantee that the requests are idempotent so you don’t
want to automatically retry

… It’s like sending zstd to a browser that doesn’t support it

… It’s a problem if the browser announces it has a dictionary and the fails
to use it (e.g. corruption)

*NoamH*: It’s easy to get it wrong so it’s important to get these errors
after deployment (e.g. if someone messes up the pipeline)

… Devtools is great, but there’s still missing visibility

… So don’t know if the new NEL proposal will include something specific
about the dictionaries, but it would be good.

*Pat*: Not sure NEL reports have a description beyond the event type

… right now improper encoding is INVALID_HTTP_RESPONSE

… We could break it out to specify different types of “invalid” failures

… But there’s no field that would enable the browser to provide more detail

*Robin*: can request other fields with the reports, but not sure how to get
better description with the type

*Barry*: If you send a borked gzip file would it be reported differently?
Why would this be different?

… On better resiliency, can we drop dictionaries when users reload?

*Pat*: INVALID should already be sent, if it’s not it’s a bug

… Chromium implementation already has more detailed code, maybe we should
add encoding specific errors

… Otherwise, don’t know we want to specify force reload. Makes sense to
bypass dictionary cache when the user bypasses their cache

… Needed to make sure regular reload doesn’t bypass cache. We want to align
dictionaries to that

*Barry*: Only if you got this error.

*Pat*: For a local failure, it makes sense. If the origin sent a malformed
response, not sure we want to throw the dictionary from the cache. You’d be
hiding a problem from the origin.

*Barry*: full load is a recovery method

*Pat*: As is brotli vs. identity. You don’t turn off brotli if you get an
encoding error. If the origin screwed up the implementation, not sure
browsers need to work around that

… For H2,H3 we fouhgt against silent recovery mechanisms

*Bas*: Firefox actually never returns INVALID, but returns “error unknown”.
So in Firefox you can actually get that information

… I’m not sure if the spec allows this implementation-dependant magic error
codes, but I see value in it

*NoamH*: Is there a way to detect if there was an error without NEL?

*Robin*: If the HTML fails, the page just doesn’t load, so you get no signal

*Barry*: There seem to be mismatches between the implementations and the
spec

*Yoav*: If we have two different implementations, we need to find a point
in the middle and align the spec to that

*Bas*: Or a better option

*Patrick*: A little concerned about backwards compatibility as well, since
there’s a number of endpoints receiving these already

… Would all http.reponse.invalid get grouped together or get grouped in
http, or is string matching what it’s looking for

*Yoav*: On my end, it’s been a while since I read the NEL spec.  Worthwhile
for us to set aside some time at TPAC to review.

… Encoding failures can be bad, need a way to report and be invaluable

*Barry*: Can we open an issue on the Github repo?

… I’ll volunteer[a]
<https://w3c.github.io/web-performance/meetings/2025/2025-08-28/index.html#cmnt1>

*Bas*: Firefox can trivially change, but that would lose useful info for
people

*Nic*: Started a NEL task force and TPAC would be a good opportunity for us
to move this forward
LCP #134: Intrinsic size calculation includes areas of images that are
cropped out using object-fit:cover
<https://www.google.com/url?q=https://github.com/w3c/largest-contentful-paint/issues/134&sa=D&source=editors&ust=1757078122656120&usg=AOvVaw1SUFTLABbKpN80jymN8PED>

*Michal*: <demo> all the images are the same size, but the blue one is LCP
because of object-fit: cover and it’s larger than the others (but scaled
down)

… Image that’s scaled up gets penalized by the LCP algorithm, so it takes
the minimum between the intrinsic size and the visible area

… But here, the blue image has more pixels but they are not helping the user

… So maybe the intrinsic size doesn’t make sense here

… Any kind of cropping/downscaling does the same, not just object-fit

… so should we update the spec to “crop” the intrinsic size? Or is it
adequate to do what we do here?

… Main issue is inconsistency

*Bas*: /testing in Firefox..

*Michal*: Looked into Chromium’s implementation. The blue square is
considered 50% contentful, but the other ones are 25% contentful, but we
don’t “see” that the blue square is cropped due to aspect ratio

… Another case is related to a scaled image and viewport intersection. The
part of the image that’s intersecting with the viewport could be 100%
contentful, but the rest of the image is scaled TODO

*Barry*: If we do change the behavior, we’d need to raise a change request
to Interop

*Michal*: current test suite was forked

*Barry*: We can still ask for it to be considered, if we all agree

*Bas*: The test case here doesn’t report an LCP at all in firefox.
Investigating..

*NoamH*: Is this specific to images in LCP? What about canvas elements?

*Michal*: Canvas is not considered for LCP

*Yoav*: I think they’re not considered

… Even images just inside of a canvas

*Michal*: I think this is just for images, we have issues defining sizes
for vector content

… Visual size of those things and trust them to be fully contentful

… Need to investigate and see if we care enough to resolve this. Should the
blue always be the LCP?

*Barry*: More complicated it would be if the blue is actually smaller, but
calculates as bigger.

*Michal*: If all the squares were 1x1, the blue would have been the LCP
candidate and that would be the right call

*Philip*: should image entropy be considered?

*Michal*: It’s currently a filter, but not considered for picking a
candidate.

[a]
<https://w3c.github.io/web-performance/meetings/2025/2025-08-28/index.html#cmnt_ref1>
https://github.com/w3c/network-error-logging/issues/191

1 total reaction

Yoav Weiss (@Shopify) reacted with 🥳 at 2025-08-28 18:03 PM

On Thu, Aug 28, 2025 at 10:16 AM Yoav Weiss <yoav.weiss@shopify.com> wrote:

> Hey folks!
>
> Apologies for not sending this earlier, but please join us today to talk
> webperf!
> On the agenda
> <https://docs.google.com/document/d/10dz_7QM5XCNsGeI63R864lF9gFqlqQD37B4q8Q46LMM/edit?tab=t.0#heading=h.mz5aze2ove10> we
> have compression-dictionaries error reporting, HR time in audio worklets
> and if there's time a discussion on LCP and object-fit: cover.
>
> See <https://meet.google.com/agz-fbji-spp> y'all there!
>
> Cheers :)
> Yoav
>
>