Things You Should Do In Web Development They Don’t Tell You About — part 2
You can have the best features in the world, but they don’t mean anything if any screen of your app loads even a bit slow. This post tells you how to not frustrate users with your app and uncovers some new technologies.
In the first part of Things You Should Do In Web Development They Don’t Tell You About, I wrote about good development practices. These were the most important things. Now, we can move to less compelling, but also beneficial, examples.
1. Use webpack to bundle your files
I remember the time when almost no one was bundling their files, but now it’s a standard. In most cases, we should send the code in one bundled file (for code splitting see the point 9). Why? It’s faster. Transferring one large file is faster than sending lots of smaller requests (however it might change in the future, see the next point). We can use tools like webpack to do it for us and within a minute make a configuration for our project which can bundle the files, minify code, remove comments, optimize styles and add required prefixes and transpile the code to extend browser support.
Here is a simple example of how it looks:
To help you understand how it works, I recommend you to read this post: How webpack works on examples.
If you want something more advanced, with optimizations pushed to the limits, you can check our SwingDev webpack configuration. It supports .env files, Typescript, different configurations per environments and much more!
2. Use Gzip, obviously
You can save lots of KBs just by making sure gzip encoding is turned on your server. You can check if your server is using gzip with this website Checkgzipcompression.com or you can check it on your own with Google Chrome DevTools.
Navigate to Network tab, select any CSS/JS file and look for Content-Encoding header. If it’s there, you are using gzip 🎉
If you are looking for something even better, you can investigate Brotli. I recommend you to read Understanding Brotlis Potential. It will show you why it’s worth checking out.
3. Use cache whenever possible
Requests: Often, it is unnecessary to re-fetch data from an API if we know that it is unlikely to have changed within a specified period. By not fetching the data, we are being friendly to mobile data users, limiting unnecessary API calls, and minimizing re-renders of applications due to state updates.
Assets: The browser’s caching mechanism is your friend. During development, it might lead to some very frustrating situations, but it really helps to improve your site performance. Every browser caches content like images, JavaScript or CSS. Nowadays we can take it to another level. By using Service Workers, we are able to get offline access to our resources.
Caching files with service worker
Remember to have the respect for this powerful feature. It’s easy to get lost because of caching too much, so keep your hand on the pulse and test everything wisely before pushing it to production.
4. Serve images in proper sizes
Often we use the same images for different parts of our application. Let’s use an online shop as the example. Each product in the shop has its overview picture. We display it on the product details page, product listing page with two layout options: list and grid, and the page with the image in its original size.
We need at least four different image sizes. Why can we not use just one image? Imagine if the original picture is 1 MB and we display ten products per page. The user would download 10 MB of only photos and that’s not what we want. If you can, try to generate different images for the different parts of your site, this will save a lot of KBs for your users. You should also take current screen resolution into account. For example, if somebody opens your site on their mobile phone, there is no need to display the giant header image that you usually use. You probably also want a different picture for your crisp iPad Pro display and different for a budget Android device with low resolution.
You can use <source/> HTML tag which could be used inside HTML5 <picture/> to determine which images the web browser should use depending on screen width or height. Docs
Or use CSS media queries
5. Send only delta on updates
We can minimize payload, unweight our backend and increase the speed of the request by sending only changes that user has made in update requests. It might sound hard to extract changes in the very nested object but who said we have to write it on our own?
For deep deltas, we can use below example:
Remember that PUT and PATCH requests are created for different purposes. The PUTmethod is described as follows in RFC 5789:
Several applications extending the Hypertext Transfer Protocol (HTTP) require a feature to do partial resource modification. The existing HTTP PUT method only allows a complete replacement of a document. This proposal adds a new HTTP method, PATCH, to modify an existing HTTP resource.
So, PUT should only be used if you’re replacing a resource in its entirety, not when you are just updating some parts of it.
6. Show a badge that user lost Internet connection
It’s more common than you think that your users lose their Internet connection. The good practice is to let them know that our app has lost connection to the Internet and it might not be usable until it comes back. Support for queuing user actions and requests while you are offline is a topic for a different article, but I think you won’t have to implement it unless you work for a massive project which has to support such situations. For most applications, it’s enough to show an indicator on the screen that your app is attempting to re-establish the Internet connection.
7. Use HTTP-2
It allows servers to “push” responses proactively into client caches instead of waiting for a new request for each resource. It uses the new ALPN extension which allows for faster-encrypted connections since the application protocol is determined during the initial connection. See also other gains of using HTTP/2.
Another resource I can recommend for you to learn about this protocol benefit is a presentation done by Patrick Hamann on JSConf EU 2018
8. Code splitting
The most descriptive definition I know about code splitting is from React documentation:
Bundling is great, but as your app grows, your bundle will grow too. Especially if you are including large third-party libraries. You need to keep an eye on the code you are including in your bundle so that you don’t accidentally make it so large that your app takes a long time to load.
To avoid winding up with a large bundle, it’s good to get ahead of the problem and start “splitting” your bundle. Code-Splitting is a feature supported by bundlers like Webpack and Browserify (via factor-bundle) which can create multiple bundles that can be dynamically loaded at runtime.
Code-splitting your app can help you “lazy-load” just the things that are currently needed by the user, which can dramatically improve the performance of your app. While you haven’t reduced the overall amount of code in your app, you’ve avoided loading code that the user may never need, and reduced the amount of code needed during the initial load.
Read more about code splitting in React
Analyzing the bundle size code splitting in create react app
As you can see, there are many areas in which we can improve our application performance.
If you want more examples and solutions, you can look at SwingDev’s Frontend Developer Guide. We put in tons of work to make it, but it was definitely worth it, see for yourself.
As always, I’m more than happy to hear your thoughts on this topic, what else could be optimized, and if you were already aware of these things or not. Let me know in the comments!
HAPPY CODING and optimizing! 🦄
Like it? Tap the 👏 button! Thank you!
You can find me on GitHub.
