5 Important Ways to Boost Your Frontend Performance
Performance is one of the most critical aspects of any web project, regardless of the size. A small site, a mobile web app or even a large applications like a full blown e-commerce site. Nobody will continue to use a slow application. Are you a developer looking to achieve a more performant web app with smaller loading time?
Steve Stouders, who wrote the book on High Performance Web Sites estimates that 80% of the average page load times actually occur after the markup is completely downloaded. For your users a 50% speed up in your front-end code is going to mean a lot more to them that a 50% speed up in your backend code. This is important to consider.
Make Fewer HTTP Requests
One of the basic performance rules is to mimize the requests you have to do in your app. Every script, stylesheet and image in your page requires an extra HTTP request. The browser needs to fetch all the resources required to render the page. Each of these requests can be expensive because there is maybe the need to do a DNS lookup, follow redirects, download, parsing etc. You should reduce these requests to a minimum.
Even though most browsers will parallelize your requests, they will only do a fixed amount of requests per domain. If all you assets refer to the same domain, they will be queued up and increase your loading time. If you use a seperate domain for your images, the browser can fetch more assets at once. This one of the reason why a lot of websites have one or more static subdomain for assets. If you combine this with an CDN you can decrease the latency even more because the file will be served from a location that is physically nearer to you enduser.
Every HTTP request your app needs should be a reasonable one and not taken lightly.
Load Only What You Need
Progressive enhancement is a great and you should totally embrace it. However, what you should avoid is that modern browsers have to load resources that are only needed for older browser to support them.
If you 20% of your Javascript/CSS is only for 3% of your users, something is wrong. For these cases, you should use a feature detection library like Modernizr or yepnope, that only loads resources and polyfills if the current browser does not support the one you are relying on.
With this snippets we only load the placeholders polyfill if the browser does not support it. Everyone else saves one request.
CSS and Performance
As outlined by Stoyan Stefanov CSS is one of the performance worst enemies because it blocks the site from rendering. The Browser will block your page from rendering until all CSS Files are downloaded and parsed. Be aware that all CSS Files that are only based on an media query (e.g. <link rel="stylesheet" media="screen and (min-device-width: 1024px)" href="main.css">) will still be downloaded even if they aren’t needed immediately.
Modern WebKit-Based based Browser are starting to prioritize the CSS download, so that the rendering can begin immediately after receiving all the CSS needed for initially rendering the page and defer the rest as late as possible.
Combine and Minify Resources
To further minimize HTTP Requests you should concate files that are belonging together in your build process. While it is for development better to split the code between multiple files, for your live version you should package all related pieces together.
As part of your build step, if you use images in your CSS-Files think about either inline them into the CSS as a data-uri or generate a image sprite. You don’t have to do this by hand, there are enough tools out there which take control of this step (e.g. grunticon, spritesmith, webfont). This step alone already saves you a lot HTTP Requests.
Minifying your text assets by removing any comments and whitespace also saves some bytes while transferring to the user. If you can you also should really activate gzip in your webserver. This will compress all your text assets before delivering to your browser. The savings here a from huge to gigantic. For example a 70kb CSS-File is compressed and minified only around 6 kilobytes. That saves you 93%!
Cache the Hell Out of It
Each release-version of your Application should live in an own folder with an very high cache time like 10yrs, so that your user only have to download the resources that can change between visits to your site.
Only your bootstrapping file, e.g. the index.html, that determines which release you want to serve to your user should have a very low cache time. How low this time should be depends on how often you release new versions of your webapp. Whether this will be five minutes or five days depends on your internal development cycle.
Deploying a new version of your app, becomes then “just updating one file”.
