JavaScript application load strategies

The load policy of a web application is really a cross technology topic in fact a web app that loads fast usually get a better user experience.
The components of an application can be roughly summarized as following:

  • services
  • client libraries (the application toolboxes)
  • user interface (css and images)
  • modules

A module can be defined as following:

  • a module is an independent operable unit that is a part of a complex system
  • a module can operate with other modules
  • a good habit is to keep the modules of a system loosely coupled

A web application module, on the client side, consists of HTML + CSS + JavaScript, the  modules are organized and the load policies used can significantly impact the success of an application.
Before starting to discuss about load strategies it’s very important to understand that the design of a module will impact the load policies too;
a good module should follow these rules:

  • A module should call only its own methods or those on its sandbox
  • A module should access DOM elements that belong to its own box
  • A module should not access non native global objects
  • A module should ask what needed to the sandbox not take it directly from other modules
  • A module should never talk directly to another module

Keeping safe this rules it’s possible to define a load policy to reduce as much as possible the waiting time for the end user and all unnecessary request to the server.
The nature of a web application module brings to the creation of several files, a good habit is avoiding to crate monolithic files. Use instead several files in order to split the CSS, the HTML and the JavaScript and load what’s needed in each page of the web application.
There are several tools available to compress a .css and .js files, online there are available (between others):

A compressed file can be 40% less than a plain one so that the application load time can be dramatically reduced.
When an user agent request a resource from a server for the first time, it caches the response to avoid making the same request in the future. The cache of a browser is so powerful that sometimes can represent a problem especially with dynamic web pages (where content change often) and / or with pages in which new features are frequently added.
There are some developers that force the browser to ignore the cache in order to avoid to show not updated web pages or to avoid to load old scripts.
The cache is the best friend of each web application but can also be a nightmare when an application needs to be frequently updated, extended, etc.
A common issue is how to handle a new version of a script, imagine that the application need to be updated and that some JavaScript files have been totally rewritten. In this scenario a developer has to rename all the files reference in the client and on the server, this practice can bring to several errors.
In order to avoid to load old scripts an interesting approach should be the usage of the mod_rewirte Apache module. With some rules defined into the .htaccess file the web page can contain different files searching for the same file on the server.

The strategies outlined in this post can be summarized as following:

  • Split the code in several files to load what’s needed
  • Compress the files to reduce the weight of the files
  • Use the benefits of the user agent caching mechanics to avoid to load the same files multiple times
  • Use the file names to be sure to load the last updated files
  • Use mod-rewrite to avoid to change the files name on the server

These points can be used as the building blocks to define the good practices to follow to create a web application that loads fast.



One Response to “JavaScript application load strategies”
  1. Rickey Johnsey February 23, 2013

Leave a Reply

Your email address will not be published.