Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Render blocking status of resources #262

Closed
yoavweiss opened this issue Apr 1, 2021 · 5 comments
Closed

Render blocking status of resources #262

yoavweiss opened this issue Apr 1, 2021 · 5 comments
Assignees
Projects

Comments

@yoavweiss
Copy link
Contributor

Right now, it's hard to tell which resources were actually render blocking and which ones were not.
Developers can try to heuristically guess that, based on when those resources were downloaded, but that's hard to do in the lab, never mind in the wild.

Lighthouse can now get rid of those heuristics, as Chromium provides a direct signal for render blocking resources (at least for scripts and styles).

It'd be good if RUM had similar capabilities, that would enable similar analysis by RUM providers:

  • Which resources were downloaded before FCP but were not render blocking? (and hence, could've been delayed)
  • Which resources were render blocking, but weren't discovered early enough? (and hence, could've benefited from being preloaded)

And probably more...

@yoavweiss
Copy link
Contributor Author

@ArthurSonzogni
Copy link
Member

ArthurSonzogni commented Jul 5, 2022

Hi @abinpaul1

We were doing the security/privacy review of:
https://github.com/abinpaul1/resource-timing/blob/render-blocking-status-explainer/Explainer/Render_Blocking_Status.md

It would help if you could add a section explaining why this isn't revealing new cross-origin information. You could also fill https://github.com/w3ctag/security-questionnaire

From my reading of the spec, it should be not reveal cross-origin information. The resources will be the ones fetched from <link>,<script>,<style> elements with blocking="render" attribute. The information is already defined in the document.
What about resources nested inside an <iframe> or a <script>?

@abinpaul1
Copy link
Contributor

Hi @ArthurSonzogni,
I've updated the explainer with a section on Privacy/Security considerations along with the questionnaire.

What about resources nested inside an <iframe> or a <script>?

  • With respect to ResourceTiming, each frame only reports on the resources fetched by itself, and not any child IFRAMEs.
  • For resources (scripts) imported by scripts, entries are created for them and their renderBlockingStatus would be non-blocking. Currently based on the spec, script resources not inserted by parser are only render blocking if blocking=render attribute is present.

Does this help with your query?

@ArthurSonzogni
Copy link
Member

Does this help with your query?

It does! Thanks you!

@yoavweiss
Copy link
Contributor Author

@abinpaul1 - I think we can close this as "fixed", right?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
3 participants