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

Performance impact? #112

Closed
edent opened this issue Sep 27, 2017 · 5 comments

Comments

Projects
None yet
4 participants
@edent
Copy link
Member

commented Sep 27, 2017

Fetching resources with XMLHttpRequest to avoid above behavior incurs a serious performance penalty

Can you quantify the performance penalty? How much faster is using preload?

@yoavweiss

This comment has been minimized.

Copy link
Contributor

commented Sep 30, 2017

As this is highly variable and depends on the page structure, network, user device and UA defined behavior, I don't think quantifying the performance advantage of preload should be part of the spec.

You can see external blog posts (such as @addyosmani's article) or research papers (such as VROOM) for more details on said performance benefits.

@yoavweiss yoavweiss closed this Sep 30, 2017

@edent

This comment has been minimized.

Copy link
Member Author

commented Oct 4, 2017

I strongly suggest that that pointing to those papers would be useful. At the moment, there's no quantifiable reason - or evidence - to suggest that preload will be useful to developers.

@addyosmani

This comment has been minimized.

Copy link

commented Oct 4, 2017

@yoavweiss

This comment has been minimized.

Copy link
Contributor

commented Oct 4, 2017

Paging Dr. @igrigorik for his opinion here - should we link from the spec to external resources which prove the feature's benefits?

@igrigorik

This comment has been minimized.

Copy link
Member

commented Oct 4, 2017

I believe we already provide the necessary context and motivation in the paragraphs above the quoted statement:

However, there are also cases where some resources need to be fetched as early as possible, but their processing and execution logic is subject to application-specific requirements - e.g. dependency management, conditional loading, ordering guarantees, and so on. Currently, it is not possible to deliver this behavior without a performance penalty.

  • Declaring a resource via one of the existing elements (e.g. img, script, link) couples resource fetching and execution. Whereas, an application may want to fetch, but delay execution of the resource until some condition is met.
  • Fetching resources with XMLHttpRequest to avoid above behavior incurs a serious performance penalty by hiding resource declarations from the user agent's DOM and preload parsers. The resource fetches are only dispatched when the relevant JavaScript is executed, which due to abundance of blocking scripts on most pages introduces significant delays and affects application performance.

With respect to "preload use in the wild", I don't believe the spec is the right place to enumerate or maintain such a list — that's what developer documentation (e.g. MDN) resources are for.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.