From f042268e47c667cf6fb252727eeb8e216fc8c6a1 Mon Sep 17 00:00:00 2001
From: tomByrer <tomByrer@gmail.com>
Date: Mon, 19 May 2014 06:28:50 -0600
Subject: [PATCH] soften language for d/l time saved, + GZip note

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.
---
 readme.markdown | 12 +++++++-----
 1 file changed, 7 insertions(+), 5 deletions(-)

diff --git a/readme.markdown b/readme.markdown
index 50e11e5..b965ef9 100644
--- a/readme.markdown
+++ b/readme.markdown
@@ -296,15 +296,17 @@ It can be difficult to refactor or maintain applications built this way.
 On the plus side, all browsers natively support this approach and no server-side
 tooling is required.
 
-This approach tends to be very slow since each `<script>` tag initiates a
-new round-trip http request.
+This approach may be slower since each `<script>` tag initiates a new round-trip
+http request.
 
 ### concatenate
 
 Instead of window globals, all the scripts are concatenated beforehand on the
-server. The code is still order-sensitive and difficult to maintain, but loads
-much faster because only a single http request for a single `<script>` tag needs
-to execute.
+server. The code is still order-sensitive and difficult to maintain. However,
+a concatenated file will help save a few http packets, since only a single http
+request for a single `<script>` tag needs to execute.  Also, a singe GZipped
+file will likely be smaller than the sum of several separate files.  Both of
+these optimizations will help save precious downloading time.
 
 Without source maps, exceptions thrown will have offsets that can't be easily
 mapped back to their original files.