Optimizing for performance can fall by the wayside when developing in a fast-paced environment such as the Informatics Innovation Unit (IIU). The IIU team strives to rapidly build out web application prototypes. Often, to get a prototype “into the hands” of our clients as quickly as possible, we are forced to adopt a “we’ll get to that later” philosophy. This issue came to the forefront when, out of curiosity, I tested our sites through Google’s PageSpeed Insights and was surprised to learn that, even though our sites ran well in our testing and production environments, our sites had page weights of more than 3mb and scored relatively poorly on their speed tests. This result was well over the average of 1.7mbs, which meant that for slower connections our sites would have a prolonged load time.
Enable Gzip Compression
You will see this in many places but it’s worth reiterating here. Everyone should be enabling compression on their web servers so that they will send out a nice zipped version of the site that all modern browsers are able to unpack. This is probably the most simple step you can take to reduce page weight and it’s also the most effective because it can reduce your websites page size by almost 70%. For an Express.js application, starting with version 3.X, this is easily accomplished by adding the following code block to the very top of your express configuration. Gzip compression is also an available configuration on Windows’ Internet Information Services (IIS) or Apache as well, please see the documentation for either server to find instructions on how to enable it.
Use Content Delivery Networks (CDN) when possible
According to a survey done by www.sitepoint.com, the average site in 2014 made about 95 Hypertext Transfer Protocol (HTTP) requests on initial load. This becomes a problem because most browsers can only process 4-8 requests from a single domain at a time which causes bottlenecks when loading your page. CDNs can help with these issues because you are hosting static content on different domains allowing your browser to load content in parallel.
Minify and concatenate your Cascading Style Sheet (CSS)
During development it’s good practice to keep our styles for different sections of the application in separate files. It helps keep a sense of order while we are still developing the application and makes it easier to maintain the application in the future. However, when we move the application to a production environment, it is irrelevant to the browser if our styles are in one file or in ten. What is important is that if we choose to keep all of our files separate, the client will have more requests to make to the server, which will slow down the loading of our page. Here we can concatenate (combine) our many disparate CCS files into ideally one file so that the server will only have to make one request for all of our custom CSS. If you are writing styles for a very large or complex application it still might be a good idea to keep things a bit separate and maybe break it down into 2-3 relatable files instead of just one.
While we are concatenating our CSS we should have our few CSS files go through a process called minification. This is where a process will remove all of the whitespace and comments that we use to keep things legible during development, but the browser does not need to reduce the file size.
Audit your application
A lot of things change during the development of an application. Modules are installed and uninstalled, scope changes and features are reworked. This opens the door for libraries to be included in an application that is no longer used, but are still required to make requests to the server. In the ongoing effort to optimize our applications, I audited our Morbidity and Mortality Weekly Report (MMWR) Case of the Week prototype and was able to find about 8 different libraries that we were no longer using. You can use a tool like Chrome’s Audit Developer Tool to help you out with this task. So be sure to be vigilant with what you are actually using in your application and you’ll be able to keep it slim.
There are many more steps you can take to reducing the weight of you application but this is pretty good start that doesn’t take too much effort to implement. After applying these steps to our MMWR Case of the Week, I was able to cut the page size from 2.4MB to 690kB while shaving about a second off of our load time.