Usually when developing new web application, we don’t pay much attention to application’s loading speed. It loads quickly in the beginning, but as we add new features and complex logic, it takes more and more time to load our page. Once we hit a dead end, clients and project manager start complaining and they ask us to do something about it urgently. Having a page that loads slowly has great effect on business, many researches showed. It affects user experience, position in search engines and ultimately lower conversion rates.
I worked on this problem many times and I see others deal with it, too. Depending on a project, it can take a little action to speed up loading, or it can require multiple actions to be made. Check out some things I collected from working on solution for this problem.
Static caching is saving content’s copy in browser’s memory after initial serving, so that subsequent requests can be served faster — from memory, rather than sending new request to the server to fetch it. In the initial serving, server can setup various cache parameters, like how long will browser keep copy, what kind of files to cache, etc.
Also, if application logic permits, you can cache on your backend, too: if you need some data on initial page load, and it takes time to fetch them from some other service or database, implement caching on backend to serve that data faster.
To ensure faster content delivery to your clients, use CDN: highly optimized services which will serve your clients probably faster than your own origin. They also provide global accessibility by having multiple Points of Presence (PoPs), automatic data analytics, less delays, lower rates of network congestion and protection against DDoS attacks.
Using gzip or brotli compression you will reduce bundle size which in result means faster download of the assets. Configuring this utility shouldn’t be too complicated for most of the technologies today.
If it is possible, limit number of requests used for fetching initial data. Browsers have limitation on maximum number of parallel TCP connections to one origin (usually 6), so some requests can get stalled, which results in slower initial page load.
While waiting for data to arrive, ensure rendering at least initial UI with progress bars or loaders, and update it once the data is there: don’t show blank page because some data is missing.
As we all know, we shouldn’t have unused code, but it happens often. Today, there are plenty of tools for every technology that will help you automate this step: warnings and errors in compile time that will remind or force you to remove unused variables, functions… Unnecessary code will generate bigger bundle files for which it will take longer to download and render.
Add tools and plugins in your building process that will help you create best optimized production build. Experiment with different compilers, bundlers, task runners and minifiers, and go with the one that suits best for your application.
If your app uses a lot of images, there are several things you can do. Quality images are generally big in size, so it takes time to download and show them. You can compress them by specific percentage and still get the quality that the human eye cannot notice the difference. Also, depending on application, you can crop images to fit some predefined dimensions, for example, you don’t need 3200x2400px image for a tiny email profile picture.
If image is not in user’s focus on initial load, you can postpone its’ download to when it gets in user’s focus. This technique is generally called lazy loading, and it is applicable for all content that is not needed for initial serving or showing.
If your application has multiple pages on different URL paths, you can implement lazy loading modules: load module for specific page only when user access it on some URL. That will reduce size of the initial bundle, which again results in faster initial download and render.
As its’ name may suggest, Server Side Rendering is technique where you move creation of complete HTML document from client to server. In CSR (Client Side Rendering) user sends request for our page and receives usually short HTML file with links to JS files. User’s browser then has to download those files, execute its’ code and populate HTML document with DOM. Only after that it will start rendering UI. With SSR this process happens on server, so user receives HTML prepared for rendering.
Although it gives great benefits with loading speed and SEO improvements, SSR is not suitable for every situation and has some drawbacks, so explore it further before using in your application.
Another interesting and promising paradigm which should be taken with caution is Progressive Web Apps (PWA). It has been around several years but it isn’t a standard yet. It uses different kinds of caching (assets and data) so it makes applications load much faster. It also gives smooth user experience with its ability to render your app to the users even when they have network issues or don’t have network at all.
Authors of the technologies, tools and libraries are usually trying to improve their software with every new version. Those improvements often mean performance. Keeping version up to date is also important because of security issues, of course.
Although it usually isn’t an overnight thing to speed up your application, it can help you a lot if you know exactly where the problem is. Is it huge bundle size so it takes time to download it? Is it some stalled HTTP request for initial data? Use debuggers, logs and metrics to pinpoint the problem so you can focus on things that will solve it faster.