soften language for d/l time saved, + GZip note #6
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
https://github.com/substack/browserify-handbook#window-globals >This approach tends to be very slow since each <script> tag initiates a new round-trip http request. > loads much faster because only a single http request for a single <script> tag needs to execute Honestly, I think this depends on the resources needed for the app & loading order. A few external resources hosted on a CDN or separate server (with unique originating URL) could load concertedly, thanks to most browsers having extra [Max Connections](http://www.browserscope.org/?category=network&v=top). A browserified/concocted chunk may have to wait for open HTTP connection, since "Connections per Hostname" has a smaller cap. True, an extra HTTP lookup is needed, but lookup time [can be reduced](https://developer.mozilla.org/en-US/docs/Controlling_DNS_prefetching), & IP &/or file may be cached already.| I did note the extra GZip reduction. But even at best 10 browserified files may save 10 HTTP *packets*, likely 5, so a few Kilobytes? Since there are so many variables, I softened the language of the impact. I'm willing to see some hard proofs either way.
|
It's more about latency because on lousy conections like 3g each round-trip can be really costly. |
|
Also, loading tons of script tags on a resource limited set-top-box can be a nightmare. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
https://github.com/substack/browserify-handbook#window-globals
Honestly, I think improved speed depends on the resources needed for the app & loading order. A few external resources hosted on a CDN or separate server (with unique originating URL) could load concurrently, thanks to most browsers having spare Max Connections. A browserified/concocted chunk may have to wait for open HTTP connection, since "Connections per Hostname" has a smaller cap. True, an extra HTTP lookup is needed, but lookup time can be reduced, & IP &/or file may be cached already.|
I did note the extra GZip reduction. But even at best 10 browserified files may save 10 HTTP packets, likely 5, so a few Kilobytes?
Since there are so many variables, I softened the language of the impact.
I'm willing to see some hard proofs either way.