1. Technical Field
A code splitting tool provides various techniques for automatically analyzing and rewriting code of existing applications to reduce initial download sizes in order to improve initial application start times and the responsiveness of user interaction across high-latency networks such as, for example, the Internet or other networks for mobile devices such as cell phones and the like.
2. Related Art
Conventional network-based applications, such as browser-based email programs, interactive mapping services, social networking web sites, etc., typically use a combination of Dynamic HTML, JavaScript, and other Web browser technologies commonly referred to as “AJAX” to push page generation, content manipulation, and other types of execution to the client's browser. A few well known examples of these types applications include Gmail™, Live Maps™, RedFin™, MySpace.com®, NetFlix®, etc.
One advantage of pushing execution to the client is that it tends to reduce overall server load since clients generate their own web pages by locally executing application code transmitted to the client by the server. Another advantage of this type client-based execution is that it tends to improve the latency of user interactions in network-bound applications since local code execution is often faster than communication across the network.
Unfortunately, initial application execution must generally wait until the entire code base has been downloaded from the server to the client. Further, as the sophistication and feature sets of these network-based applications grow, downloading their client-side code is increasingly becoming a bottleneck in both their initial startup time and subsequent application interactions. Given the importance of performance and “instant gratification” demanded by users in the adoption of such applications, maintaining and improving the application responsiveness, despite increased code size is of primary concern. Unfortunately, as applications become more complex and feature rich, the shift of application execution from a back-end server to the client often dramatically increases the amount of code that must be downloaded to the. The result is that perceived responsiveness of the application is degraded.
For example, over a typical 802.11b wireless connection, the simple act of using a web browser for opening an email in a Hotmail® inbox can take approximately 24 seconds on a first visit (with a clean browser cache). Further, even after static resources and code have been cached, this action takes about 11 seconds. Users on dial-up, cell phone, or slow international networks generally see much worse latencies, with large applications becoming virtually unusable. Live Maps™, for example, takes over 3 minutes to download on a second (cached) visit over a 56k modem.
In addition to increased application responsiveness, reducing the amount of code needed for the application to run has the benefit of reducing the overall download size. This is very important in mobile networking and in some international contexts, where the cost of network connectivity is often measured as a cost-per-byte instead of as a flat rate.
One solution to these types of problems, generally referred to as “dynamic code loading,” is to structure the application code such that only the minimal amount of code necessary for initialization is transferred in the critical path of application loading. The rest of the application's code is then dynamically loaded either on-demand or in the background. Many modern browsers support this type of explicit on-demand loading of JavaScript code. However, manually designing a Web application to correctly support dynamic loading of application code is a challenging and error-prone process that must be done at the time that such applications are initially coded. In particular, web developers have to track the dependencies between user actions, application functionality, and code components. Further, this type of manual code design requires scheduling background code downloads at appropriate times to avoid stalling a user's interactions. Finally, developers have to maintain and update the resultant code base as the application code and typical user workloads and behaviors evolve.