- From: Yoav Weiss <yoavweiss@google.com>
- Date: Tue, 4 Oct 2022 09:27:49 +0200
- To: public-web-perf <public-web-perf@w3.org>
- Message-ID: <CAL5BFfVhomqtiYPrT_ZNwsgkDCUVvhZk8gQK+hKtz9UrP8P2ZQ@mail.gmail.com>
Hey folks!
TPAC was a week full of exciting discussions whether you attended in person
or remotely.
We've now published all the session summaries
<https://w3c.github.io/web-performance/meetings/2022/2022-09-TPAC/#h.pig2hdanvast>,
including all the presentation recordings, slides and detailed minutes.
I'll copy the summaries here for convenience, and they contain links to
everything else.
Thanks to everyone who attended, contributed and/or summarized!! :)
SessionsIntros
Slides
<https://docs.google.com/presentation/u/1/d/1ljAkS9M7InItqYUvHUAI_WkpxuzZXAlKPMNqKvvzAws/edit%23slide%3Did.gf9e768be80_0_135&sa=D&source=editors&ust=1664868009022696&usg=AOvVaw3mFexzIavr5M5EJSlZxF9W>
, minutes
<https://w3c.github.io/web-performance/meetings/2022/2022-09-TPAC/#h.my94hel66iw7>
Summary:
- Review of 2022 highlights, including processing model changes and
features added to ResourceTiming, adopting LCP and EventTiming, and moving
some specs to HTML
- The Working Group continues to discuss WICG incubations, and some of
these have been adopted in the past (future session discusses rechartering
and these incubations more)
- Review of Code of Conduct, Health rules and Agenda for the week
Prefetch processing model
Recording
<https://youtu.be/N4ejv-x-wrk&sa=D&source=editors&ust=1664868009023272&usg=AOvVaw1PEMrvK69oNF0y6W7-UvX->
, slides
<https://docs.google.com/presentation/d/1mX9IZEJt6QEZUGY0jlnZgUfaBVnWuTN_zZQhdbMc8sg/edit%23slide%3Did.g156697f22a0_0_108&sa=D&source=editors&ust=1664868009023433&usg=AOvVaw2VZqSBf_o7RFs7sPdK0fzS>
, minutes
<https://w3c.github.io/web-performance/meetings/2022/2022-09-TPAC/#h.dqd5jhyb4kvq>
Summary:
- Proposal - `<link rel prefetch>` would be only for same-origin
document prefetches, and same-partition subresources. We’d remove the “5
minute rule” and apply regular caching rules. (other than ignoring `Vary:
Accept` at consumption time.
- An “idle priority” preload can replace some of the current uses for
same-document prefetch (even if preload is mandatory, and prefetch is not)
- Dropping the “5 minute rule” would reduce some current usefulness for
same-origin navigation prefetches. We should look into the impact, and
if we go ahead with it, tell developers about it (and have them e.g. use
stale-while-revalidate)
No-Vary Query
Recording
<https://youtu.be/goPzBZXOA6g&sa=D&source=editors&ust=1664868009024145&usg=AOvVaw1GK_aIM3keNjDvz1hyDAwx>
, explainer
<https://github.com/WICG/nav-speculation/blob/no-vary-query/no-vary-query.md&sa=D&source=editors&ust=1664868009024302&usg=AOvVaw1WwMgIpFO8LVLWGAMz2R49>
, minutes
<https://w3c.github.io/web-performance/meetings/2022/2022-09-TPAC/#h.5kheo66ndqdy>
Summary:
- General positive reception.
- Points raised during discussion:
- Be sure this gets surfaced to HTTP WG to maximize the likelihood
this gets used throughout the stack, not just in browsers.
- Some worry about people losing their ability to cache-bust if they
accidentally use No-Vary-Query: *. A number of possible mitigations were
mentioned.
- Unclear how `No-Vary-Query: order` treats differing values, e.g.
?a=1&a=2 vs. ?a=2&a=1. The explainer needs to be clear and maybe add
different variants.
Element Timing and Shadow DOM
Recording
<https://youtu.be/sOaZsMFScE0&sa=D&source=editors&ust=1664868009025134&usg=AOvVaw1Ypv2zCtV3_UyprpYLL2u->
, slides
<https://1drv.ms/p/s!AieUMe5bQRWh8qlurhV_ghxLZDor-A?e%3DElL16f&sa=D&source=editors&ust=1664868009025284&usg=AOvVaw1AN1WErURvxR3f9jDcRQ1Q>
, minutes
<https://w3c.github.io/web-performance/meetings/2022/2022-09-TPAC/#h.3zh1jt8o97dg>
Summary:
- Element Timing API is an important step forward for pages to observe
rendering performance
- Unfortunately Element Timing does not support Shadow DOM; pages using
Web Components cannot use this great API
- Largest Contentful Paint does include Shadow DOM elements in its
calculations, which is seemingly inconsistent behavior; we should work
towards ensuring Element Timing can support Shadow DOM
- Discussion:
- LCP spec relies on Element Timing, so has a similar issue (even if
Chromium implementation diverges)
- We should fix this and there are multiple options to do so
- Continue discussion in a followup call
Exposing more paint timings
Recording
<https://youtu.be/9mB0EwrbnG0&sa=D&source=editors&ust=1664868009026221&usg=AOvVaw0bFZ_ZUTWsnZDgUCXwEySX>
, slides
<https://docs.google.com/presentation/d/1oys9eOGPdBClduwb7bwNgB5UgJnfsMGhNlcZRUpniAQ/edit?usp%3Dsharing&sa=D&source=editors&ust=1664868009026364&usg=AOvVaw1WziKu6MljiPCGHXIDNYu5>
, minutes
<https://w3c.github.io/web-performance/meetings/2022/2022-09-TPAC/#h.koot03hzyxnt>
Summary:
- Multiple specs refer to “paint timings”: Paint Timing, Element Timing,
LCP, Event Timing… summarize the different ways there timings are
currently specced and how they differ
- Showcase an example, using FCP and Image decode (sync, async,
decode()) how there are interop issues across all browser implementations.
- Propose that there is no single best time point that works for all use
cases, instead, we should expose multiple time points with unique names (as
we already do with loadTime + renderTime, and as we already plan to expand
with firstAnimatedFrameTime etc)
- Discussion
- WebKit implementation is being modified and observed differences
may change
- Firefox aren’t interested in exposing “commit to GPU” timestamps,
due to privacy concerns
Super early hints
Recording
<https://youtu.be/jgcG48JXzw4&sa=D&source=editors&ust=1664868009027164&usg=AOvVaw1823XHBfDF7Et5HEFvs7WZ>
, slides
<https://docs.google.com/presentation/d/1sBAE3Er3tpDhMNB8e0Jrsg51v0_ghJd3aZQGer1xzb0/edit%23slide%3Did.g1566ab9a0ca_0_0&sa=D&source=editors&ust=1664868009027364&usg=AOvVaw3ACfLpSgsGHwm81x2_clH9>
, minutes
<https://w3c.github.io/web-performance/meetings/2022/2022-09-TPAC/#h.muicicfljq4s>
Summary:
- Proposal to allow early connection hints, perhaps through SVCB DNS
header, to allow frequently used domains (e.g. asset domains, or image
CDNs) that are used on most pages, to be initiated at as soon as connection
is opened, rather than wait for first response to HTML response (either
through 103 Early Hint preconnects, or within HTML response).
- Proposal was positively received (Cloudinary expressed interest).
- *Next steps*: discuss with SVCB spec owners if that is a good place
for this. Email thread started.
CDNs and resource timing info
Explainer
<https://gist.github.com/mnot/d11fd2f4563f58f0828e5f2505a6fca8&sa=D&source=editors&ust=1664868009028013&usg=AOvVaw1nTyMEA1mAa3y6SpVPjGdG>
, minutes
<https://w3c.github.io/web-performance/meetings/2022/2022-09-TPAC/#h.cec8s4h3pq5h>
Summary:
- Proposal to add cache and proxy information to resource timing, to
allow better measurements of CDN (and similar) performance (compared to
synthetic measures used today). E.g., cache hit latency, miss latency, hit
ratio. Next step: develop a proto-spec.
Unload beacon
Slides
<https://docs.google.com/presentation/d/1gPlt_yCN0TSKVlv0P0ZxH5psM64B3EJrJjThRzBQdhY/edit%23slide%3Did.p&sa=D&source=editors&ust=1664868009028588&usg=AOvVaw2c0VgrIIc9UTj_rmTZuXy2>
, minutes
<https://w3c.github.io/web-performance/meetings/2022/2022-09-TPAC/#h.y2cg4zth0n5j>
Summary:
- Proposal to provide a web API that reliably sends queued requests on
page discard.
- Clarifying API behaviors: a single PendingBeacon object represents a
request, backgroundTimeout vs timeout.
- Discussions around API’s capabilities: e.g., can it be abused, how
long should a beacon stay alive, etc
Resource timing and iframes
Slides
<https://docs.google.com/presentation/d/1VyEYZFe0n2Il4mpRAqSbFW5nlqysZNCfznUZSufk74Q/edit?usp%3Dsharing%26resourcekey%3D0-35JIRE7yULq9e1jR5Jywjw&sa=D&source=editors&ust=1664868009029386&usg=AOvVaw0QwnBTdAuseuaxoSh-kUyq>
, minutes
<https://w3c.github.io/web-performance/meetings/2022/2022-09-TPAC/#h.f7pdtp23sxgy>
Summary:
- Presentation on the cross-origin information leaks made possible
because iframe resources are included in resource timing.
- Proposals to remove them or reduce the information obtainable through
that API.
- Discussion brought strong preference towards “option 3”
- “Do something different between same-origin/TAO frames (measure
first navigation and report as completely as it can) and
cross-origin/no-TAO just gets start and time of the load event”
- There’s some hesitance RE it throwing the complexity on API
consumers. Need to better understand that cost
- Aggregated reporting may save us in the future
APA joint meeting - A11y and the Reporting API
Minutes
<https://w3c.github.io/web-performance/meetings/2022/2022-09-TPAC/#h.puc2bk1g1wuy>
Summary:
- The APA would want Reporting API to have reports on automatically
detected a11y issues, user reported a11y issues, slow loading sites
- Such reporting would need to take user privacy into account - there’s
tension between user’s need for accessible/adapted experience and not
revealing themselves as AT users
- There’s potential interest in satisfaction survey reporting
Server Timing and fingerprinting risk
Minutes
<https://w3c.github.io/web-performance/meetings/2022/2022-09-TPAC/#h.rx4xxqoj5us6>
Summary:
- Server Timing enables a passive cross-origin resource to communicate
information to the Window, that can then be read by other cross-origin
scripts run in the top-level document’s context.
- Apple wants the UA to be able to not expose the info across sites
(TLD+1), and potentially across origins.
- Same question for transferSize, encodedBodySize, etc
- Agreement from RUM collectors that same-site Server-Timing and sizes
is better than none.
Aggregated reporting
Recording
<https://youtu.be/62efbp7wwrQ&sa=D&source=editors&ust=1664868009031281&usg=AOvVaw1T487M_eVskOwnZO2AOGh0>
, slides
<https://docs.google.com/presentation/d/1jouxxwqf_l2YvGL-NpUHMEI9Af84QabYMHXvpbCsDjE/edit%23slide%3Did.g15828dc862c_0_6&sa=D&source=editors&ust=1664868009031473&usg=AOvVaw14n5LSPjUPJFHcUknOgai2>
, minutes
<https://w3c.github.io/web-performance/meetings/2022/2022-09-TPAC/#h.svzglivicza2>
Summary:
- Proposal - we could safely expose some cross-origin data if we only do
that in aggregate, by relying on Aggregated Reporting
<https://github.com/csharrison/aggregate-reporting-api&sa=D&source=editors&ust=1664868009031867&usg=AOvVaw3En8BZxneD0tMVQRQhUDEp>
.
- Need to be careful not to expose business data of embedded pages -
that’s different from current threat models, where we protect user data
Responsiveness at Excel
Recording
<https://youtu.be/ePI-PV9hNoY&sa=D&source=editors&ust=1664868009032192&usg=AOvVaw1bILcPe--g6mHkgL8-eCpQ>
, slides
<https://1drv.ms/p/s!Ajo0wos-4RKZj00571S-vcMY-cAB?e%3DOwPRvf&sa=D&source=editors&ust=1664868009032307&usg=AOvVaw3k1zaf_YRvsTzYc-k0YlHQ>
, minutes
<https://w3c.github.io/web-performance/meetings/2022/2022-09-TPAC/#h.vlry6zv712k1>
Summary:
- This talk goes over the journey Microsoft Excel Online went when
trying to find an effective user facing responsiveness metric.
- We explain how we measure responsiveness on the client using Event
Timing API and then the different ways we explored to utilize the
measurement to define a new responsiveness metric which is effective in
detecting regression and has high reliability.
- We show how using the Average Session Responsiveness metric turned out
to be a very effective path and propose an hypothesis why that is.
Joint meeting with PING
Recording
<https://youtu.be/tIYstkdCFwY&sa=D&source=editors&ust=1664868009032933&usg=AOvVaw0a1pfjt1v3c4DJe4F1LAIm>
, slides
<https://docs.google.com/presentation/d/1vzAOpFm1ecYTcOQqxEjUbpiG3aHjJTGjwXxBGGeE1QQ/edit%23slide%3Did.g15240174473_0_15&sa=D&source=editors&ust=1664868009033085&usg=AOvVaw1HHRAvouM4A8nTDLnQoqx0>
, minutes
<https://w3c.github.io/web-performance/meetings/2022/2022-09-TPAC/#h.94i9z44o0zpn>
Summary:
- Discussion on the principles around opt-outs for ancillary data, vs.
ancillary transport mechanisms.
- Some agreements, e.g. turn off reporting when JS is disabled
- Some disagreements, e.g. whether we should provide an opt-out for the
transport mechanisms, that’s equivalent to a “do not monitor me” bit
- We’ll continue the conversation
Early Hints - lessons learned
Recording
<https://youtu.be/pdSd0qs6mls&sa=D&source=editors&ust=1664868009033718&usg=AOvVaw23xaMyF9y-CDIYoRCcg6EY>
, slides
<https://docs.google.com/presentation/d/182x_lQdf8ML5k1bLlne-z1pGb76oiJujFzxqAEcuMsE/edit%23slide%3Did.g153724ec94b_0_303&sa=D&source=editors&ust=1664868009033882&usg=AOvVaw26f1Dl7ISxdqNzlOHWXaqo>
, minutes
<https://w3c.github.io/web-performance/meetings/2022/2022-09-TPAC/#h.au3az36jw07f>
Summary:
- Mileage varies wildly - early Hints & Resource Hints still require
context and developer intention to get it right.
- Most of the gains Shopify saw were from pre-connect and unblocking the
tcp+tls bottleneck
- There are a number of outstanding issues to be resolved: reporting the
initiator, responseStart definition, and sub-resource early hints
Rechartering
Recording
<https://youtu.be/c32vBQBlLKQ&sa=D&source=editors&ust=1664868009034432&usg=AOvVaw0_Tih46wlzTiJuqnjYwGzZ>
, doc
<https://docs.google.com/document/d/1anMV_uOG48TzfLW8xgC50HAfHqDY5udzSo9TrEZlURk/edit?usp%3Dsharing&sa=D&source=editors&ust=1664868009034571&usg=AOvVaw3nupBLy0p8iw692YP7jMVU>
, minutes
<https://w3c.github.io/web-performance/meetings/2022/2022-09-TPAC/#h.ma6vya8ooorq>
Summary:
- Need to re-charter for 2023 (2021 charter expires in February 2023)
- A few specs have been moving out of WebPerfWG and into HTML, this is
good
- We've recently brought in EventTiming and LCP
- Discussed barriers to Layout Instability
- Considering bring in parts of ElementTiming into LCP and parts into
PaintTiming
- No other incubations being adopted
Sustainability and WebPerf
Recording
<https://youtu.be/o8avSFOuT8Y&sa=D&source=editors&ust=1664868009035300&usg=AOvVaw2A5AfyNGpbUMvDkupnjkjw>
, slides
<https://docs.google.com/presentation/d/1Eal_kR6ieSMGtHOUQaNoiEqov7JPxh_pDo0St9LoDKg/edit%23slide%3Did.g1556353e5ef_0_53&sa=D&source=editors&ust=1664868009035484&usg=AOvVaw0WM-2cp5wUstRP4tlM3wCq>
, minutes
<https://w3c.github.io/web-performance/meetings/2022/2022-09-TPAC/#h.u3vuybw1fxr3>
Summary:
- There’s a bunch of overlap between web performance and sustainability
- We don’t currently expose information on server-side energy
consumption, but maybe we should
- Discussion on how that information can be exposed, what more can we do
- Might be worthwhile to add to the charter
Forward referenced data URIs
Recording
<https://youtu.be/wHemhN3SZw4&sa=D&source=editors&ust=1664868009036126&usg=AOvVaw1l41pM6KoYnU1Um1Gv_4zv>
, slides
<https://1drv.ms/p/s!AieUMe5bQRWh8qoIElghI9JDOJXftw?e%3Dp7nI2M&sa=D&source=editors&ust=1664868009036244&usg=AOvVaw0QzL3KSb3FAMqzz7CGrjXS>
, minutes
<https://w3c.github.io/web-performance/meetings/2022/2022-09-TPAC/#h.qmk12q6qfhwc>
Summary:
- For a certain class of web pages that render dynamic and highly
variable content (e.g. search engine result pages), embedding images using
Data URIs is the most efficient way to deliver those images over the
network because the benefits of browser caching are minimal
- Data URI payloads need to be declared where they are used
- Dynamically generating base64 encodings for these images on-the-fly is
expensive and causes a server-side bottleneck if done serially. Instead a
common approach is to append these to the end of HTML sections and hoist
them into the appropriate img tags using JS. This JS should also be inline
since it needs to run quickly.
- What if there was a way to provide a forward pointer to a Data URI
payload that appears later in the page? That would enable generating them
in a non-blocking fashion on the server and eliminate the need for inline
JS to implement this. Also it would cut down on redundant Data URI payloads
such as 1x1 placeholders which currently need to be declared repetitively.
- SVG does potentially support this already so a solution may be to wrap
the embedded images inside an SVG
Performance Beyond the Browser
Minutes
<https://w3c.github.io/web-performance/meetings/2022/2022-09-TPAC/#h.v8jxlvi037me>
Summary:
- Web Performance WG work might be applicable to a slightly more broad
set of environments than just the browser such as edge compute (think
node.js, deno, Cloudflare workers etc).
- Spec tweaks, possibly motivated by new requirements or other
constraints, might help adopt existing designs to the environs where they
find perf measurement valuable.
- The WinterCG, is helping codify the considerations in W3C, so we cross
pollinated in the session.
- The session was closed with brief discussion on a variety of analysis
concerns sitting just outside the envelope of browser perf monitoring -
hars, netlogs, NEL.
Task Attribution
Recording
<https://youtu.be/lP2nEQKIBUo&sa=D&source=editors&ust=1664868009037700&usg=AOvVaw1xfgZU81E3VlCZ6zXXFLNl>
, slides
<https://docs.google.com/presentation/d/1VtDX47o_x1GdXp52PwMcsRcitBHJQ5ZJ1eho5YTgBjU/edit?usp%3Dsharing&sa=D&source=editors&ust=1664868009037871&usg=AOvVaw3tf-MW-QlmNUmaBO_25Qr4>
, minutes
<https://w3c.github.io/web-performance/meetings/2022/2022-09-TPAC/#h.5txowdgcqpl1>
Summary:
- TaskAttribution has a bunch of potential use cases - SPA heuristics,
LT attribution, privacy protections
- For privacy protections, we’d need to think defensively, and protect
against code polluters
- Discussion around traces and if the WG should also cover
cross-implementation lab tooling related efforts
Received on Tuesday, 4 October 2022 07:28:30 UTC