On Wed, Sep 15, 2021 at 3:49 AM Yoav Weiss <yoavwe...@chromium.org> wrote:
> Thanks for working on this!! > > On Tue, Sep 14, 2021 at 5:38 PM Patrick Meenan <pmee...@chromium.org> > wrote: > >> >> TAG review >> > > It might be good to spin up a TAG review. > Thanks. I'll start working on that now. > Interoperability and Compatibility > >> >> >> Gecko: No signal >> >> WebKit: No signal >> > > Did you reach out? https://bit.ly/blink-signals > I'll take it back to the W3C web perf working group and see what they have to say. I'm not expecting a lot of browser interest (except maybe Edge) because Chromium is the only engine that uses the 2-step loading phase where hints can move resources back and forth between the render-blocking and "everything else" phases (and we don't all necessarily agree on incremental rendering being a good thing). It has been 2 years though so it's good to gauge interest again as things have changed a lot since the initial pass through. > >> Web developers: Strongly positive >> > > Any links? > This is fairly representative: https://twitter.com/csswizardry/status/1050717710525509633 These days it is usually more in the form of "how can I get my LCP image to load sooner" questions on stack overflow and twitter (happy to link to a few of them). Most devs don't call out Priority Hints specifically, it's usually in the form of a script loading sooner than they expect or an image loading later than they would like with no way to change it. Priority Hints is just the transport by which we allow them to make those adjustments (in addition to letting us unwind the practice of using preload to boost the priority of async scripts). There are also some internal discussions for a team that uses fetch on HTTP/3 where they would like to be able to have lower-priority background requests in flight that don't interfere with the user-facing API calls. > > >> >> Estimated milestones >> OriginTrial desktop last 101 >> OriginTrial desktop first 96 >> OriginTrial android last 101 >> OriginTrial android first 96 >> > > Any particular reason you want to run the OT for 6 milestones? It may be > better to start with 4 and extend as needed.. > Do you have partners lined up to experiment? > Moving to a 4-week release cycle, calendar-wise it's about the same. Optimally we will be able to make the ship decision within a couple of weeks of hitting stable but in case the process takes longer than expected I was erring on the side of a bit of buffer so it doesn't get disabled from under a site as we work to ship. There's also the potential for some delayed feedback cycles as the LCP impacts and side-effects will be measured through RUM tools and search console's 28-day rolling average on CrUX data. Is there a problem with planning for a bit of a buffer and ending sooner rather than planning sooner then scrambling to extend? Thanks, -Pat -- You received this message because you are subscribed to the Google Groups "blink-dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscr...@chromium.org. To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAPq58w517ozPgXMFXXKR_DVVEAR1oqmj0HdpSh%2Bdextxvysp2w%40mail.gmail.com.
