Thanks for working on this!! :) On Wed, Jun 29, 2022 at 4:53 PM Abin Paul <abin.pa...@gmail.com> wrote:
> Contact emails > > > *abin.pa...@gmail.com <abin.pa...@gmail.com>*Explainer > > > *https://github.com/abinpaul1/resource-timing/blob/render-blocking-status-explainer/Explainer/Render_Blocking_Status.md > <https://github.com/abinpaul1/resource-timing/blob/render-blocking-status-explainer/Explainer/Render_Blocking_Status.md>* > Specification > > > *Resource Timing PR : https://github.com/w3c/resource-timing/pull/327 > <https://github.com/w3c/resource-timing/pull/327>Fetch PR : > https://github.com/whatwg/fetch/pull/1449 > <https://github.com/whatwg/fetch/pull/1449>*Summary > > > > *Adds a field to PerfomanceResourceTiming to indicate the render blocking > status of a resource. Currently from a developer perspective, the only way > to determine which resources were actually render blocking is to rely on > complex heuristics. The new field would instead provide a direct signal > regarding the same.*Blink component > > > *Blink>PerformanceAPIs>ResourceTiming > <https://bugs.chromium.org/p/chromium/issues/list?q=component:Blink%3EPerformanceAPIs%3EResourceTiming>* > Motivation > > > > > *Currently in order to determine which resources were actually render > blocking and which ones were not, developers have to rely on heuristics.By > providing a web exposed field, developers can get a direct signal from the > browser regarding the render blocking nature of each resource.*Initial > public proposal > > > *https://github.com/w3c/resource-timing/pull/327 > <https://github.com/w3c/resource-timing/pull/327>*TAG review > > TAG review status > > > *Pending*Risks > > Interoperability and Compatibility > > > > > > > *Gecko: No signalWebKit: No signalWeb developers: Reception towards a > similar feature introduced in Chromium was very positive. The article and > tweet linked below is a good > indicator.https://blog.webpagetest.org/posts/new-render-blocking-indicator-in-chrome-and-webpagetest/ > <https://blog.webpagetest.org/posts/new-render-blocking-indicator-in-chrome-and-webpagetest/> > https://twitter.com/tkadlec/status/1417543014705246214 > <https://twitter.com/tkadlec/status/1417543014705246214>Other signals:*WebView > application risks > > > > *Does this intent deprecate or change behaviour of existing APIs, such > that it has potentially high risk for Android WebView-based applications?* > Debuggability > > Is this feature fully tested by web-platform-tests > <https://chromium.googlesource.com/chromium/src/+/main/docs/testing/web_platform_tests.md> > ? > > > *Yes*Flag name > > > *RenderBlockingStatus*Requires code in //chrome? > > > *False*Tracking bug > > > *https://bugs.chromium.org/p/chromium/issues/detail?id=1337256 > <https://bugs.chromium.org/p/chromium/issues/detail?id=1337256>*Estimated > milestones > > > > *No milestones specified*Link to entry on the Chrome Platform Status > > https://chromestatus.com/feature/5166965277589504 > > This intent message was generated by Chrome Platform Status > <https://chromestatus.com/>. > > -- > 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/CAM2ZH3dimwFkdjtC_1O5imD9HNJ6QvNPPuPJ5Me9ushAT9CKiA%40mail.gmail.com > <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAM2ZH3dimwFkdjtC_1O5imD9HNJ6QvNPPuPJ5Me9ushAT9CKiA%40mail.gmail.com?utm_medium=email&utm_source=footer> > . > -- 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/CAL5BFfWEKeoB5SScDY1gPU49GZBgtBNFHq-wwisFZQMfVT%3D3HA%40mail.gmail.com.
