Skip to content

Latest commit

 

History

History
160 lines (102 loc) · 5.77 KB

Render_Blocking_Status.md

File metadata and controls

160 lines (102 loc) · 5.77 KB
Raw

Render-blocking Status

Proposal to add a new field renderBlockingStatus to PerformanceResourceTiming which is an enum highlighting the status of stylesheets and scripts.

Use cases

RUM providers could then easily determine the render-blocking resources without having to rely on complex heurestics to determine the same. This would enable analysis for below scenarios and possibly more.

  • Determine resources downloaded before FCP but were not render-blocking? (and hence, could've been delayed)
  • Determine resources that were render-blocking, but weren't discovered early enough? (and hence, could've benefited from being preloaded) (Reference : w3c#262)

API Changes and Example Code

The PerformanceResourceTiming Interface in resource-timing would be updated to

[Exposed=(Window,Worker)]
interface PerformanceResourceTiming : PerformanceEntry {
    ...
    ...
    readonly attribute RenderBlockingStatusType renderBlockingStatus;
    ...
    ...
    [Default] object toJSON();
};

enum RenderBlockingStatusType {
    "blocking",
    "non-blocking"
};

Sample usage:

const entry_list = performance.getEntriesByType("resource");
console.log(entry_list[0].renderBlockingStatus);

Render-blocking Status Values

The following values are proposed for the resource blocking status enum

blocking - A potentially render-blocking resource

non-blocking - Non blocking resource

We primarily reuse the value of the render-blocking boolean associated with fetch request

Potential Spec Changes

Fetch (whatwg/fetch#1449)

Resource Timing Level 2 (w3c/resource-timing#327)

  • 4.3 : Adding new field to interface : renderBlockingStatus
  • A PerformanceResourceTiming has an associated RenderBlockingStatusType render-blocking status.
  • [4.3.1] Add new RenderBlockingStatusType enum which can have 2 defined values. blocking if timing-info's newly added render-blocking field is true and non-blocking if its false
  • Getter steps for renderBlockingStatus returns RenderBlockingStatusType enum

Security/Privacy Considerations

  • The field does not reveal any new cross-origin information. With respect to ResourceTiming, each frame only reports on the resources fetched by itself, and not any child IFRAMEs and hence no new info is made available.

Self-Review Questionnaire: Security and Privacy

  1. What information might this feature expose to Web sites or other parties, and for what purposes is that exposure necessary?

It exposes information relating to if a particular resource blocks rendering or not.

  1. Do features in your specification expose the minimum amount of information necessary to enable their intended uses?

Yes

  1. How do the features in your specification deal with personal information, personally-identifiable information (PII), or information derived from them?

It does not deal with such information.

  1. How do the features in your specification deal with sensitive information?

It does not deal with sensitive information.

  1. Do the features in your specification introduce new state for an origin that persists across browsing sessions?

No.

  1. Do the features in your specification expose information about the underlying platform to origins?

No.

  1. Does this specification allow an origin to send data to the underlying platform?

No.

  1. Do features in this specification enable access to device sensors?

No.

  1. Do features in this specification enable new script execution/loading mechanisms?

No.

  1. Do features in this specification allow an origin to access other devices?

No.

  1. Do features in this specification allow an origin some measure of control over a user agent's native UI?

No.

  1. What temporary identifiers do the features in this specification create or expose to the web?

None.

  1. How does this specification distinguish between behavior in first-party and third-party contexts?

No distinction.

  1. How do the features in this specification work in the context of a browser’s Private Browsing or Incognito mode?

No difference.

  1. Does this specification have both "Security Considerations" and "Privacy Considerations" sections?

No.

  1. Do features in your specification enable origins to downgrade default security protections?

No.

  1. How does your feature handle non-"fully active" documents?

No difference.

  1. What should this questionnaire have asked?

None.

Changelog

  • Update 1 - Spec changes modified to reuse Request's render-blocking boolean.
  • Update 2 - Added section for Privacy/Security considerations
  • Update 3 - Change type to enum as per TAG suggestion
  • Update 4 - Change mentions of render blocking to render-blocking to better allign with HTML spec terminology