The issue of the size of code files has always been important, but is even more so today with the development of increasingly complex websites incorporating more and more plugins and frameworks. We are going to see how it is possible to considerably reduce the size of code files thanks to a few good practices.
First of all, it’s probably important to remember the problems associated with the size of code files and why it’s important to pay attention to this data, even in contexts where the weight constraint is not as central as it is for us.
As a reminder, this is how a webpage loads: after sending a request, the server sends a response back to the client. This response is initially HTML code, which is the first resource read by the browser. Once this response has been read, it is displayed by the browser, but the page is only partially loaded since all the other resources (CSS, JS, fonts, images, etc.) have yet to be loaded. The page is not fully loaded until all the resources have been loaded, leaving a time lapse between the first viewing and the moment when the page is fully loaded.
Google has coined a number of terms to identify these different moments in the loading of a page. The moment when the first HTML element is displayed is called First Contentful Paint (FCP). The moment when loading is complete enough to allow the user to use the page is called Time to Interactive (TTI). These values are now closely scrutinised by search engine robots and analytics specialists, making the race for page load speed a central feature of contemporary web development.
Research suggests that 25% of people will abandon a website that takes longer than 4 seconds to load. Amazon found that just 100 milliseconds of extra load time cost them 1% in sales.
Forbes, Why Brands Are Fighting Over Milliseconds, 2016
While on our scale this fight over milliseconds may seem absurd, it is nonetheless interesting from our point of view to manage to rack up a few kilobytes and fit within our 2MB constraint.
All the principles involved in reducing the size of web files can be summed up in the simple idea of removing everything unnecessary and superfluous from our files. So why do we have unnecessary elements in our code files?
The main reason is that web development, by its very nature, creates superfluous elements throughout a work process that is anything but linear. Throughout development, the idea is above all to make the work as painless as possible, by making the code readable, or by keeping leftovers that could be useful at some point.
Code indentation and commenting are excellent practices, but they also make files heavier by adding spaces, tabs and unnecessary characters.
In response to this, a practice that has become widespread among developers is code minification, which consists of using a program to remove all unnecessary elements that make code files heavier. Spaces and comments come to mind, of course, but some programs go much further, offering to rename variables, simplify functions - in short, to simplify files to the extreme.
However, this practice makes the files virtually unreadable to a human being, and the aim is to create what are known as production files, intended to be uploaded online, as opposed to development files used locally by developers. As a general rule, we therefore add the suffix -min to development files. You can use MinifyAll directly in VSCode to perform this kind of minification
Beware, however, that the improvement is often quite negligible on small websites and minification programs cannot work miracles. So it’s important to start by taking stock of your own code, deleting unnecessary or duplicated functions and optimising your code before using a minification program.
Another common practice among developers (but one that I strongly advise against in the context of traditional websites whose content is bound to evolve) is font subsetting, in other words the creation of font files without unused glyphs. Note that not all foundries authorise font subsetting as part of their licence.
Numerous tools, of varying degrees of complexity, exist online, enabling a font to be subset according to certain criteria: according to a type of glyphset, according to a given list of glyphs or even according to a URL. A good tool is glyphhanger (in Python), which lets you create subsets in a variety of ways. The simpler everythingfonts has an interface that makes the procedure much more straightforward, but is less flexible.