How much speed is gained with RequireJS/AMD in JS?

问题:

How much faster is requireJS actually, on a large website?

Has anyone done any tests on the speed of large websites that use asynchronous loading vs not?

For instance, using Backbone with a lot of views (> 100), is it better to simply have a views object that gets loaded with all the views at once and is then always available, or should they all be loaded asynchronously as needed?

Also, are there any differences for these considerations for mobile vs desktop? I've heard that you want to limit the number of requests on mobile instead of the size.

回答1:

I don't believe that the intent of require.js is to load all of your scripts asynchronously in production. In development async loading of each script is convenient because you can make changes to your project and reload without a "compile" step. However in production you should be combining all of your source files into one or more larger modules using the r.js optimizer. If your large webapp can defer loading of a subset of your modules until a later time (e.g. after a particular user action) these modules can optimized separately and loaded asynchronously in production.

Regarding the speed of loading a single large JS file vs multiple smaller files, generally:

“Reduce HTTP requests” has become a general maxim for speeding up frontend performance, and that is a concern that’s even more relevant in today’s world of mobile browsers (often running on networks that are an order of magnitude slower than broadband connections). [reference]

But there are other considerations such as:

• Mobile Caches: iPhones limit the size of files they cache so big files may need to be downloaded each time, making many small files better.
• CDN Usage: If you use a common 3rd party library like jQuery it's probably best not to include it in a big single JS file and instead load it from a CDN since a user of your site may already have it in their cache from another website (reference). For more info, see update below
• Lazy Evaluation: AMD modules can be lazily parsed and evaluated allowing download on app load while deferring the cost of parse+eval until the module is needed. See this article and the series of other older articles that it references.
• Target Browser: Browsers limit the number of concurrent downloads per hostname. For example, IE 7 will only download two files from a given host concurrently. Others limit to 4, and others to 6. [reference]

Finally, here's a good article by Steve Souders that summarizes a bunch of script loading techniques.

Update: Re CDN usage: Steve Souders posted a detailed analysis of using a CDN for 3rd party libraries (e.g. jQuery) that identifies the many considerations, pros and cons.

回答2:

This question is a bit old now, but I thought I might add my thoughts.

I completely agree with rharper in using r.js to combine all your code for production, but there is also a case for splitting functionality.

For single page apps I think having everything together makes sense. For large scale more traditional page based websites which have in page interactions this can be quite cumbersome and result in loading a lot of unnecessary code for a lot of users.

The approach I have used a few times is

• define core modules (needed on all pages for them to operate properly), this gets combined into a single file.
• create a module loader that understands DOM dependencies and paths to modules
• on doc.ready loop through the module loader and async load modules needed for enhanced functionality as needed by specific pages.

The advantage here is you keep the initial page weight down, and as additional scripts are loaded async after page load the perceived performance should be faster. That said, all functionality loaded this way should be done approached as progressive enhancement (i.e. ajax on forms) so that in the event of slow loading or errors the basic functionality is still available.