I am sad to read this... A new step before the deprecation of server push. I would love to see comparaison in term of performance between server push and early hint. On a pure theoric point of view early hint starts during the html parsing whereas the server push start with the response header. So server push by design is better. Regarding the complexity to put it in place early hints is easy when you serve different page but for Single Page Application the build process don't generate differentiate serving based on the route since the routing of the application is generally managed in the frontend. So for Single Page Application to managed server push not global to all route it will more complexe to include it in the build process.
Just wanted to share my feeling about this whole topic. Thanks Regards Thomas BIANCONI Head of Data Technologies & Data Privacy Champion Global CDMO Team 41 Rue Martre - 92110 Clichy Mob : +33 (0) 6 15 35 33 57 Ph : +33 (0) 1 47 56 45 95 E-mail : thomas.bianc...@loreal.com<mailto:thomas.bianc...@loreal.com> ________________________________ De : Chris Harrelson <chris...@chromium.org> Envoyé : mercredi 2 mars 2022 18:51 À : Daisuke Enomoto <denom...@chromium.org> Cc : blink-dev <blink-dev@chromium.org>; las...@chromium.org <las...@chromium.org>; pme...@chromium.org <pmee...@chromium.org>; Francesco Montanari <francesco.montan...@outlook.com>; Maxim Makarov <maxpain...@gmail.com>; b...@chromium.org <b...@chromium.org>; dsch...@chromium.org <dschin...@chromium.org>; ians...@chromium.org <iansw...@chromium.org>; rektide <rekt...@gmail.com>; Ben Lesh <b...@benlesh.com>; Andrew Wilder <and...@andrewwilder.com>; Vito De Giosa <vito.degi...@gmail.com> Objet : Re: [blink-dev] Re: Intent to Remove: HTTP/2 and gQUIC server push Notice: External mail The API owners met today and discussed this intent at some length. We are very happy that Early Hints is showing very positive promise in terms of experimental data, and feel the positive experimental data is enough to justify starting the process to remove HTTP/2 push. To that end, we approve starting official deprecation of the feature now, with a (publicly communicated) goal to remove support from Chromium in the next 6-9 months. We recommend publishing a blog post describing what's happening and the recommended migration paths. However, we would like to see an Early Hints intent-to-ship before approving actual removal of HTTP/2 Push; please do not consider this an email an approval to actually remove it until we send LGTMs for such. Our understanding is that Early Hints is well on the way to a finished spec and readiness to ship, and the remaining pieces of the specification are to nail down integration with other related APIs such as Fetch. We think this sounds feasible to complete and reach a shipped-in-stable-channel status within the proposed deprecation period, which would allow sites to potentially have a seamless transition. We recognize that this is a long time period, and especially long given the time since the start of the request to deprecate. The reason is that we'd really like to avoid the "old thing is deprecated, new thing is not yet available" situation if possible. Thank you everyone for your patience and efforts. Regards, Chris On Wed, Mar 2, 2022 at 1:47 AM Daisuke Enomoto <denom...@chromium.org<mailto:denom...@chromium.org>> wrote: Hello, We conducted an experiment for Early Hints (chromestatus<https://urldefense.com/v3/__https://chromestatus.com/feature/5207422375297024__;!!IY5JXqZAIQ!tuPS5CAhthikdjYO2ritj17L4LiN-pYSY7buCcpWke1SVokLk44YNKR45xzrzNtkXfmC$>) with partners in Q3 - Q4, 2021. The experiment data suggests that the performance impact is highly positive. Based on these insights, we are confident that Early Hints will be a viable alternative to H/2 Push for performance use cases. In addition, by design Early Hints will not run into the overpushing concerns that bogged down H/2 Push. We are working with some of our partners to share a bit more details. Next steps (for Early Hints) We are actively working on finalizing the shipping plan / timeline. In particular, Early Hints requires updating multiple specs. Once our plan becomes clearer, the details will be shared on a new Intent to Ship thread. Non performance use cases For other perceived use cases beyond performance improvements, we recommend sharing more details over at WICG Discourse<https://urldefense.com/v3/__https://discourse.wicg.io/__;!!IY5JXqZAIQ!tuPS5CAhthikdjYO2ritj17L4LiN-pYSY7buCcpWke1SVokLk44YNKR45xzrzG_bdCve$> with a focus on the problem you are trying to solve rather than how H/2 Push could be used. In addition, if you currently rely on H/2 Push in ways that Early Hints can’t address, please share details<https://urldefense.com/v3/__https://discourse.wicg.io/__;!!IY5JXqZAIQ!tuPS5CAhthikdjYO2ritj17L4LiN-pYSY7buCcpWke1SVokLk44YNKR45xzrzG_bdCve$> about how critical this is to your product/service, on top of your use case. Thanks Daisuke On Sun, Feb 20, 2022 at 6:40 PM Morgaine <rekt...@gmail.com<mailto:rekt...@gmail.com>> wrote: I'm not sure if you are being deliberately cruel & malicious, or just accidentally cruel. Web developers have been begging for Fetch to please for the love of everything holy please report HTTP PUSH responses for 3/4 of a decade now, so we might implement Webpush Protocol or other similar reactive techniques via using Push. There have been a couple explorations of this, but after a series of proposals, nothing has materialized, nothing has developed. Rather than ever making PUSH useful, rather than acknowledge that PUSH could implement a reactive, Webpush Protocl like system, you seem intent on using negligence to destroy the baby before it has a chance. This has been requested & begged for, there's been a couple spins, but you seem ready to destroy possibility in this deprecation, before even having made the most minimum bid to make the technology useful. Please, heed https://github.com/whatwg/fetch/issues/51<https://urldefense.com/v3/__https://github.com/whatwg/fetch/issues/51__;!!IY5JXqZAIQ!tuPS5CAhthikdjYO2ritj17L4LiN-pYSY7buCcpWke1SVokLk44YNKR45xzrzGDYL5uJ$> & try to do some little bit of good in the world, before you go running off macabely destroying possibility. Chrome had a number of attempts where some good responsible smart actually-know-something developers saw that PUSH could be useful, and proposed trying to make Fetch spec be useful, proposed making PUSH useful. That the current crop of developers doesn't understand & see this possibility, either denies or is ignorant to the sad long history of begging, pretty please, to let us observe & react to PUSH requests, is a tragedy. We are headed for using HTTP3-over-WebTransport, because ya'll are sending in the wrecking ball, rather than following up & doing the bear minimum, most essential, most basic spec-authoring work on Fetch, that was begged for, pleaded for, for 3/4 of a decade now. This is such a sad sad route, and it's going to be such a gross boondogle working around the apathy browser developers gave for PUSH, their unlove, their incapability to provide even some simple basic capabilities to use PUSH. https://github.com/whatwg/fetch/issues/51<https://urldefense.com/v3/__https://github.com/whatwg/fetch/issues/51__;!!IY5JXqZAIQ!tuPS5CAhthikdjYO2ritj17L4LiN-pYSY7buCcpWke1SVokLk44YNKR45xzrzGDYL5uJ$> needed some love. It still does. Turn the ship around. Do the minimum viable feature, before you decide to axe it. You might even be able to not put the PUSH into cache, if that makes you happy, so long as you provide an alternative means to receive the PUSH responses to a Fetch. Doing nothing, permitting nothing: that's such a misdeed. Please, again, don't do this. And don't tell us something that is deeply related, that is at the heart of this disaster, that has gone unaddressed & unimprove for so long, is unrelated. On Wednesday, June 30, 2021 at 9:42:26 AM UTC-4 las...@chromium.org<mailto:las...@chromium.org> wrote: No, the Push API (https://developer.mozilla.org/en-US/docs/Web/API/Push_API<https://urldefense.com/v3/__https://developer.mozilla.org/en-US/docs/Web/API/Push_API__;!!IY5JXqZAIQ!tuPS5CAhthikdjYO2ritj17L4LiN-pYSY7buCcpWke1SVokLk44YNKR45xzrzHd5HvEU$>) is entirely unrelated other than the name. -Brad On Wed, Jun 30, 2021, 9:00 AM Vito De Giosa <vito.d...@gmail.com> wrote: Does it mean that also that the webpush protocol, Push Api won't work anymore? On Monday, 28 June 2021 at 17:15:54 UTC+2 pme...@chromium.org wrote: It feels like there are a lot of different things going on here and it might be useful to unpack it a bit. Web Vitals thresholds - they aren't a hard line where you pass or you don't. The last updates from the team explained that each metric is looked at independently and there is a progressive boost in the "needs improvement" zone based on how close a given URL is to the "good" threshold. That doesn't really help if you're being held to the "number of URLs that need improvement" in the search console but there is not much practical difference between a 2.6 and a 2.5 LCP (not like the cliff that it initially sounded like it would be). Layout Shifts from late-loading fonts - Using PUSH to try to fix this race condition feels like the wrong tool for the job. Even with font-display: block it is possible that a text element won't be sized correctly until the font loads, causing something after it in the DOM to be moved. Preload can help get the font loaded sooner so it will be there at layout time more often but it will still be racy. PUSH is also still racy but makes it even more likely that the font will be there early but at the cost of delaying literally everything else (including the HTML in a lot of cases). It feels like we need a better primitive to tell the browser to block layout until the text sizes are known (if that is something a site wants to do) so that things can still load asynchronously but the rendering can be controlled. It's a lot like CSS blocking layout/render - otherwise unstyled content is flashed for FOUC. font-display: block prevents the render of text in the wrong font but nothing lets you block incorrect layout (that I know of). Fixing that properly rather than wedging fonts ahead of everything else is a better fix. Push sounds like a great solution, particularly when it can be done intelligently to not push resources already in cache and if it can exactly only fill the wait time while a CDN edge goes back to an origin for the HTML but getting those conditions right in practice is extremely rare. In virtually every case I have seen, the pushed resources end up delaying the HTML itself, the CSS and other render-blocking resources. Delaying the HTML is particularly bad because it delays the browser's discovery of all of the other resources on the page. Preload works with the normal document parsing and resource discovery, letting preloaded resources intermix with other important resources and giving the dev, browsers and origins more control over prioritization. On Friday, June 25, 2021 at 7:32:05 PM UTC-4 Brad Lassey wrote: On Fri, Jun 25, 2021, 6:58 PM Andrew Wilder <and...@andrewwilder.com> wrote: Interesting, thanks Brad. I'd imagine that the performance benefit is actually greater for sites that don't use a CDN at all, since one RT is likely to take much longer Due to initial window sizes, one RT worth of data is measured in bytes, not time and does not vary based on round trip times. ... so if you're only looking at CDNs, that might explain part of the difference? We looked at all sites that were using Push, but in addition cut the data by CDN to look for correlations. With the extremely tight requirements of Core Web Vitals, one round-trip's time potentially could make a significant difference in some cases. I was recently working on a site where I just couldn't get the Largest Contentful Paint metric to pass the 75th percentile of 2.5s in CRuX. I was stuck, soooo close, at 2.6s. (And it was testing great in Lab Data...just not in the field data, frustratingly) I'd suggest you look at how big your initial resources are and what's left over after the initial window. Again, the reference to a round trip is to the amount of data, not time. A roundtrip can take well over 100ms, so that alone could be enough to shave off 0.1s under the right conditions, or maybe more, to get the site to pass CWV. But I also stopped short of actually bothering to implement and test this when I saw this thread (I wasn't even sure if Chrome was still working for Server Push or not -- though I see that was answered a few messages back.) I don't think I would have argued this point before core web vitals, since one round-trip does seem nearly negligible -- but because now we have absolute metrics we need to hit, which are pretty tough in some cases, I think keeping this one additional tool in the toolbelt may be worthwhile... Thanks again, Andrew On Fri, Jun 25, 2021 at 3:28 PM Brad Lassey <las...@chromium.org> wrote: On Fri, Jun 25, 2021, 4:53 PM Andrew Wilder <and...@andrewwilder.com> wrote: Brad, thanks for the clarification. We're definitely utilizing preload -- that's pretty much "table stakes" for passing Core Web Vitals at this point. We're also utilizing many other tools, including Critical Path CSS and delaying JavaScript until after user interaction. Those are far more complicated to implement properly than Server Push (especially with Cloudflare's excellent implementation, as Francesco pointed out). The new Page Experience requirements from Google have changed the game when it comes to site speed. Previously, speed was known to be a ranking factor, but the details were secret, and it was more of a "relative" factor compared to the competition. "Just be faster than your competition" was sufficient before. But with Core Web Vitals, the requirements are now absolute criteria, and it's pass/fail regardless of other sites in your vertical. There's no gray area here -- and for many sites, passing all three CWV criteria, while keeping the features that site owners need, is quite challenging. Furthermore, you mentioned "this depreciation represents a low risk of web breakage." But keeping Server Push is not detrimental - it has zero risk of web breakage. So why remove support for it? So it seems we have one department of Google (Search) pushing for a faster web, and another Department (Chrome) considering taking away a tool that, with proper implementation, should actually help achieve that goal. Having said that, the truly important question that we're kind of dancing around is: Is Server Push actually beneficial? If the answer to that is "yes," then I think it's better for Chrome to keep supporting it -- and, instead of killing it, to make efforts to increase adoption. But if you're able to demonstrate that, when properly implemented, it has no actual speed/CWV benefits compared to using <preload> links in the <head>, I'll be grateful because it means I don't have to spend time finding that out on my own. :) Our data shows that it is not providing a speed benefit in practice and in fact is an overall slight performance regression for Chrome users. As far as differentiating "proper" use versus naive use, I cut the data by which CDN hosted each domain and didn't see any one CDN with a net performance benefit, which I interpret as not indicating that there is necessarily a proper vs improper way to use the feature. This intuitively makes sense as the theoretical potential benefit over preload is vanishingly small (1 RT worth of data minus your initial resource) and depending on the situation very possibly nil, versus the relatively high penalty of pushing the wrong thing. Thanks again, Andrew On Fri, Jun 25, 2021 at 1:25 PM Francesco Montanari <francesco...@outlook.com> wrote: It's not necessarily complex to implement for the developer. For example, Cloudflare gives it by default, you just need to add the HTTP preload header ( https://www.cloudflare.com/it-it/website-optimization/http2/serverpush/<https://urldefense.com/v3/__https://www.cloudflare.com/it-it/website-optimization/http2/serverpush/__;!!IY5JXqZAIQ!tuPS5CAhthikdjYO2ritj17L4LiN-pYSY7buCcpWke1SVokLk44YNKR45xzrzN4sNSwd$> ) and they have a smart implementation of it, they push assets only at the first visit, they don't push them again when they know the browser should have it already in its cache. They also were the first to offer SSL for free to everyone in 2014, and today nobody would pay for a SSL cert. So good things take time to spread... It's just a matter of time, when the WordPress themes start adding the preload HTTP header for their resources (it's a one-liner in PHP), all the wordpress sites which are on cloudflare will automatically have HTTP push with zero configuration, and the usage stats will rise as well. On Friday, 25 June 2021 at 22:58:41 UTC+3 las...@chromium.org wrote: Hi Andrew, I just want to clarify one point, we are proposing to depreciate and remove HTTP Push because it has not proven to provide performance benefits over other, less complex and technically burdensome techniques such as preload (which I would encourage you to look at if you haven't already). The discussion of the amount of usage of Push is largely making the case that this depreciation represents a low risk of web breakage. Thanks, Brad On Fri, Jun 25, 2021, 1:08 PM Andrew Wilder <and...@andrewwilder.com> wrote: Sorry, I meant to say that Origin Summary CLS is just over 0.10, and/or LCP is 2.6s or 2.7s. Just wanted to clear that up so you don't think I don't know what I'm talking about! 😉 On Friday, June 25, 2021 at 10:02:13 AM UTC-7 Andrew Wilder wrote: I run an agency that supports and maintains over 500 WordPress sites -- and we do a lot of site speed optimization work. Most of them are food blogs, and because of their complexity, it's very difficult to get them to pass the three Core Web Vitals requirements (especially LCP and CLS). I've been experimenting with Server Push as a way to get assets loaded faster -- especially web fonts, which are often a source of shifts, as they switch from the default fallback font to the web font. Often we run into situations where the Origin Summary CLS is 2.6 or 2.7 seconds. Being able to get fonts loaded earlier may help prevent shifts as they load; or to shave off even 0.1 second for the LCP element (especially if it's an image) may be enough to get the site to pass CWV completely. On some sites we exhausted other ways to speed things up to pass CWV, and it was starting to look like Server Push might be able to get us across the finish line. But I paused on getting further into development on this, because I found this thread! Unfortunately, you're now creating a self-fulfilling prophecy of killing off Server Push. By announcing that you're considering removing it -- primarily because not enough people use it -- you're discouraging further people to start using it! Oh, the irony. Considering Google's push on site speed and Core Web Vitals, it seems quite contradictory for you to disable Server Push. Instead, it would be far better to invest more resources into helping people utilize it -- and making it more effective to help improve speed and user experience. On Friday, June 25, 2021 at 8:45:09 AM UTC-7 Maxim Makarov wrote: Please don't remove HTTP/2 Server Push support On Monday, June 21, 2021 at 5:32:25 PM UTC+3 b...@chromium.org wrote: Hi Francesco, Responding to the first part of your email only: no, HTTP/2 push is currently not disabled by default or removed from Chrome. However, there is a 1% holdback experiment running on Stable channel to allow monitoring of *hypothetical* performance benefits. If push does not work for you, your browser session might have been randomly assigned to the experiment. In that case, restarting Chrome will fix it (with 99% probability). Cheers, Bence On Sat, Jun 19, 2021 at 3:58 PM Francesco Montanari <francesco...@outlook.com> wrote: Is it already removed? I've implemented it but it doesn't seem to work in Chrome. Anyway, please don't kill it. Now that Google Search is deploying the "web vitals" update, which makes the loading speed a key factor for ranking, more and more developers are working to improve the sites speed, and pushing key assets would be very helpful. On Monday, 7 June 2021 at 23:25:02 UTC+3 rektide wrote: On Wed, Dec 30, 2020 at 2:11 PM Brad Lassey <las...@chromium.org> wrote: On Wed, Dec 23, 2020 at 10:25 PM Morgaine <rek...@gmail.com> wrote: As I stated in the very first reply to this thread, it is a horrific tragedy that the situation is like this. It's been HALF A DECADE OF IGNORING DEVELOPERS on https://github.com/whatwg/fetch/issues/65<https://urldefense.com/v3/__https://github.com/whatwg/fetch/issues/65__;!!IY5JXqZAIQ!tuPS5CAhthikdjYO2ritj17L4LiN-pYSY7buCcpWke1SVokLk44YNKR45xzrzEiQWO2T$> and https://github.com/whatwg/fetch/issues/607<https://urldefense.com/v3/__https://github.com/whatwg/fetch/issues/607__;!!IY5JXqZAIQ!tuPS5CAhthikdjYO2ritj17L4LiN-pYSY7buCcpWke1SVokLk44YNKR45xzrzFbdSMTO$> , who have begged for fetch to support push, have BEGGED, & gotten no where. To say that the fetch spec does not mention push is to spit in our faces. This is farce & tragedy. Perhaps it's only ignorance you speak from, but I can not be more hurt to hear you say this. I have repeated time & time again in countless threads the desires for fetch to PLEASE FOR THE LOVE OF GOD support fetch. It's insulting that there has been zero progress. I am sorry that my words had this effect on you. I believe the use cases that you've articulated are being addressed with WebTransport (https://github.com/w3c/webtransport/<https://urldefense.com/v3/__https://github.com/w3c/webtransport/__;!!IY5JXqZAIQ!tuPS5CAhthikdjYO2ritj17L4LiN-pYSY7buCcpWke1SVokLk44YNKR45xzrzAN4tjvn$>). If you don't believe so, can you file issues there to make sure they are properly considered? It seems farcical to me that we are going to need to run HTTP3 over WebTransport to get a usable implementation of Push. The browser should be good at HTTP. We should have these capabilities. Deciding to make everyone invent and bring their own userland WebTransport stack to be able to tell that an HTTP resource was pushed is a huge waste of bandwidth to send that userland stack, & a colossal mass of complexity to do the tunneling, & generates a far far more complex networking situation than if the browser would implement the one optional part of HTTP. Where-as before an a service might have run on HTTP3, pushed a resource, & seen it arrive, the service must host an WebTransport tunnel that carries HTTP3 inside of it. Now we have to worry about X-Forwarded-For like concerns. WebPush Protocol already takes advantage of these capabilities, for example, to create a simple to implement, elegant notification service, used by all browsers: but without the Fetch standards I linked, it is unusable for such obvious cause. Without Push, we grow complex systems like grpc-web, which are partial, incomplete, radically complex alternatives to what the browser ought just be able to do, what only the most minor, long requested additions to Push would have allowed. And now here we are, building Early Hints to try to reclaim only the most minor, smallest of advantages Push gave us. Focused only on this one tiny bit of the puzzle. And told that we must DIY alternatives if we want them, using WebTransport, and told that this web browser will not support the one optional component of the HTTP standard. Words have not had an effect on me. This decision continues to have a profound & disturbing effect on me, and it should be reversed. Hopefully before we need to start implementing HTTP3 over WebTransport, but I rather suspect not. -- 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<mailto:blink-dev+unsubscr...@chromium.org>. To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/06cb378d-e243-4200-9af5-5eb2868388bcn%40chromium.org<https://urldefense.com/v3/__https://groups.google.com/a/chromium.org/d/msgid/blink-dev/06cb378d-e243-4200-9af5-5eb2868388bcn*40chromium.org?utm_medium=email&utm_source=footer__;JQ!!IY5JXqZAIQ!tuPS5CAhthikdjYO2ritj17L4LiN-pYSY7buCcpWke1SVokLk44YNKR45xzrzLVyveu0$>. -- 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<mailto:blink-dev+unsubscr...@chromium.org>. To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAA5e699N7CPOqRMT%2BpZ60evzZSUvn6jH00pVc%2BXObtK9GSk0Fw%40mail.gmail.com<https://urldefense.com/v3/__https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAA5e699N7CPOqRMT*2BpZ60evzZSUvn6jH00pVc*2BXObtK9GSk0Fw*40mail.gmail.com?utm_medium=email&utm_source=footer__;JSUl!!IY5JXqZAIQ!tuPS5CAhthikdjYO2ritj17L4LiN-pYSY7buCcpWke1SVokLk44YNKR45xzrzAh3D4lp$>. -- You received this message because you are subscribed to a topic in the Google Groups "blink-dev" group. To unsubscribe from this topic, visit https://groups.google.com/a/chromium.org/d/topic/blink-dev/K3rYLvmQUBY/unsubscribe<https://urldefense.com/v3/__https://groups.google.com/a/chromium.org/d/topic/blink-dev/K3rYLvmQUBY/unsubscribe__;!!IY5JXqZAIQ!tuPS5CAhthikdjYO2ritj17L4LiN-pYSY7buCcpWke1SVokLk44YNKR45xzrzMGsZ9qr$>. To unsubscribe from this group and all its topics, send an email to blink-dev+unsubscr...@chromium.org<mailto:blink-dev+unsubscr...@chromium.org>. To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAOMQ%2Bw-rNUrRaBKE5YKZ8DFRvoO3L2e6ojgzKJyLp5MS4BQXqw%40mail.gmail.com<https://urldefense.com/v3/__https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAOMQ*2Bw-rNUrRaBKE5YKZ8DFRvoO3L2e6ojgzKJyLp5MS4BQXqw*40mail.gmail.com?utm_medium=email&utm_source=footer__;JSU!!IY5JXqZAIQ!tuPS5CAhthikdjYO2ritj17L4LiN-pYSY7buCcpWke1SVokLk44YNKR45xzrzCZd8FK4$>. This message and any attachments are confidential and intended solely for the addressees. If you receive this message in error, please delete it and immediately notify the sender. If the reader of this message is not the intended recipient, you are hereby notified that any unauthorized use, copying or dissemination is prohibited. E-mails are susceptible to alteration. Neither LOREAL nor any of its subsidiaries or affiliates shall be liable for the message if altered, changed or falsified. C1 - Internal use -- 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/PA4PR05MB90898054ACE52E707A43508D81109%40PA4PR05MB9089.eurprd05.prod.outlook.com.
