Part 1 .

So, at the end of the last part, we left the new user alone.
with a single JS file that does not include anything extra. Has it become
is the user happier? Not at all. On the contrary, on average
User ^{1 has} become more miserable than before, and the reason for this is
increased page load time.


')

Nice theory

... you are in a balloon! ...

The resource load time via HTTP is made up of the following main elements:

1. time of sending the request to the server T1 - for the majority of ² requests the value is almost constant;
   server response generation time - for static resources, which we are now considering,
   negligible;
   T2 server response time, which in turn consists of constant for network delay server L and
   response time R, is directly proportional to the size of the resource.
   
   
   In turn, the page load time will consist of the time for loading the HTML code and all
   external resources: images, CSS and JS files. The main problem is that
   CSS and JS-files are loaded sequentially ³ . In this case, communication with the server looks like this:
   

    - requested page
    - received HTML 
    - requested resource A: T1
    - received resource A: L + R (A)
    - requested resource B: T1
    - received resource B: L + R (B)
    - requested resource C: T1
    - received resource C: L + R (C)
   

   
   The total time cost will be 3 (T1 + L) + R (A + B + C)
   
   Combining files, we reduce the number of requests to the server:
   

    - requested page
    - received HTML 
    - requested resource A + B + C: T1
    - received the resource A + B + C: L + R (A + B + C)
   

   
   Obvious savings in 2 (T1 + L).
   For 20 resources, this savings will be 19 (T1 + L). If you take enough of the standard now for
   home / office Internet speeds of 256 kbps and ping ~ 20–30 ms, we get savings
   at 950 ms - one second of page load. Do people who use mobile or
   satellite internet with ping over 300 ms, the difference in page load times will be
   6–7 seconds.
   
   At first glance, the theory says that page loading should become faster. What is she sold
   with practice?
   
   

   Harsh reality

   
   

   We wanted the best, but it turned out as always.

   
   
   Let our site have three pages P1, P2 and P3, alternately requested by the new user.
   P1 uses resources A, B and C, P2 - A, C and D, and P3 - A, C, E and F.
   If the resources are not combined, we get the following:
   
   • P1 - spend time loading A, B and C
   • P2 - spend time loading only D
   • P3 - spend time loading E and F
   
   
   If we merge absolutely everything
   JS-modules of the site, we get:
   
   • P1 - spend time loading (A + B + C + D + E + F)
   • P2 - no external resources required
   • P3 - no external resources required
   
   The result is an increase in the loading time of the very first page,
   which gets the user. With typical values ​​of speed / kick, we start to run through already
   with an additional load of 2-3 kilobytes.
   
   If we combined only the modules necessary for the current page, we get the following:
   
   • P1 - spend time loading (A + B + C)
   • P2 - spend time loading (A + C + D)
   • P3 - spend time loading (A + C + E + F)
   
   Each individual page with an empty cache will load faster, but all of them together -
   slower than the original case.
   
   We get that the blind use of fashionable now combining resources often only worsens
   user life .
   
   

   Decision

   
   

   - Is it possible to swallow a billiard ball?
   - it is possible, but, as a rule, not necessary.
   

   
   
   Of course, there is a way out of this situation ⁴ . In most cases
   to get a real win, just select the “core” - a set of modules used for all
   (or at least on frequently downloaded) pages of the site. For example, in our example, it suffices to highlight
   to the core resources A and B to gain an advantage:
   
   • P1 - spend time loading (A + B) and C
   • P2 - spend time loading D
   • P3 - spend time loading (E + F)
   
   The thoughtful reader will be indignant now and will ask: “What if there is no core? Or the core turns out too
   small? I hasten to assure you that this is easily solved by manual selection of 2-3 independent
   groups with their own cores. If desired, the partitioning problem can be formalized and
   get an exact machine solution - but that is usually not necessary; guided by the simplest rule - what
   the larger the core the better, you can achieve quite a decent result.
   
   As they say on Habré: “What is the message of this article?” We will confine ourselves to miserable three points:
   
   • mindless adherence to fashionable trends will lead to useless work;
   • fashion trends often carry good ideas;
   • if you love your users - combine resources wisely.
   
   
   ¹ with an empty cache, of course.
   ² implies that most requests are GET requests with a reasonable URL length.
   The length of such a request is approximately constant, and is ~ 450–600 bytes.
   ³ at least as long as they are on the same host.
   ⁴ and, which is good to see from the comments, is used .
   ⁵ "We have such devices - but we will not tell you about them." We'll have to believe the word.