On Wed, Sep 15, 2021 at 9:40 PM Patrick Meenan <pmee...@chromium.org> wrote:
> > > 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. > That makes perfect sense. It's also not a replacement for asking for explicit signals. That's not a blocker for the OT, but would be a blocker for shipping later on. > > >> >>> 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? > Before the move to 4 weeks per milestone, a typical was run for 2-3 milestones, which is equivalent to 3-4.5 nowadays. Let's settle on 5 milestones? :) Extending the trial if needed shouldn't take more than sending an intent to extend, ideally with learnings so far. > 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/CAL5BFfWqK7%3DkSdLfN2DT8jqU66rbSH2M2KS79bBPb56RxmaJCA%40mail.gmail.com.
