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

Workers: consider grouping importScripts calls #1220

Closed
jrburke opened this issue Oct 22, 2014 · 2 comments
Closed

Workers: consider grouping importScripts calls #1220

jrburke opened this issue Oct 22, 2014 · 2 comments
Milestone

Comments

@jrburke
Copy link
Member

jrburke commented Oct 22, 2014

It may allow parallel fetching, need to test more. Also, generic mechanism for grouping these calls on a tracing/resolution "turn" may help server side bundling APIs. It may complicate the resolution semantics, the equivalent of completeLoad in current 2.x implementation.

Only so much bundling could be done though: for multiple module tracing, the dependencies of a module are not known until they are fetched, so there will still be multiple importScripts calls used. Doing optimized builds will still achieve the best results.

@jrburke jrburke added this to the 3.0 milestone Oct 22, 2014
@skaegi
Copy link

skaegi commented Jun 18, 2015

We tried this (multiple urls with importScripts) in an Orion proof-of-concept fork of requirejs and it made not a hint of difference (at least in Chrome).

On the otherhand what did make a "huge" difference was doing an XHR to get the js blob and then calling importScripts on the Blob URL. This gave us parallel downloads and was many times faster.

Do you have any interest in this?

@jrburke
Copy link
Member Author

jrburke commented Jul 10, 2015

I am surprised the XHR fetch helped much. I suppose it just seeds the browser cache with the contents of the blob URL. I would not want to do this for a default implementation, but it seems worth writing up how to override requirejs.load to do that sort of change. Feel free to add a page to the wiki about that approach.

Going to close this issue based on your feedback though, since it does not help.

@jrburke jrburke closed this as completed Jul 10, 2015
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants