2020-03-12-lightweight-website.html (3237B) - raw

      1 <!-- title: A lightweight website -->
      2 <!-- slug: lightweight-website -->
      3 <!-- categories: Personal domain -->
      4 <!-- date: 2020-03-12T00:00:00Z -->
      5 
      6 <p>
      7   Since the start of this site, having a lightweight website has been one of my priorities. Every
      8   file served has been minimized, you won't see any pictures that aren't vector graphics (except for
      9   the <code>favicon.ico</code> file) and users don't need to download fonts or JavaScript libraries.
     10   On top of that, the amount of JavaScript required is minimum. Indeed, as of right now, the only JS
     11   that runs is a very simple function to toggle the theme and another one to open the navigation
     12   menu on small screens. That results in super lightweight pages, which keeps the loading time to a
     13   minimum and reduces the bandwidth usage of the server.</p>
     14 <!-- /p -->
     15 
     16 <p>
     17   The one thing I've had doubts about is minimizing HTML. Some friends argued that minimizing the
     18   code obscures it, while I argued that it is easy to <em>prettify</em> HTML with one of the many
     19   tools online. However, lately, I have been a bit frustrated with Hugo's minimizing tool as it had
     20   some unexpected behavior with SVG's, so I decided to investigate the pros and cons of file
     21   minimization a bit further.</p>
     22 <!-- /p -->
     23 
     24 <p>
     25   When you access a webpage it is normally compressed (if the server supports it), and this compression
     26   makes the previous minimization of files almost useless. Let me explain: my main blog page's size
     27   is about 18.3KB, but it can be reduced down to 17.2KB with Hugo's minimizing tool<sup
     28   id="fnref1"><a href="#fn1">1</a></sup>. Once compressed with <a href="https://en.wikipedia.org/wiki/Gzip">gzip</a>,
     29   the sizes are 5845 and 5747 bytes respectively, so the bandwidth save is only 100 bytes! Similar
     30   results have been obtained for all the pages of the site that I have tested, so it looks like
     31   minimizing isn't helping that much.</p>
     32 <!-- /p -->
     33 
     34 <p>
     35   On the other hand, I see the point made by the friends who argue that having the code available
     36   when pressing <code>view source</code> can be useful, even if code could potentially be
     37   prettified. Given this, I have decided not to minimize the HTML files. A similar argument could be
     38   made to not minimize CSS and JS (indeed, in the future I might change my mind), but they will stay
     39   minimized for now<sup id="fnref2"><a href="#fn2">2</a></sup>.</p>
     40 <!-- /p -->
     41 
     42 <!-- footnotes -->
     43 <hr />
     44 
     45 <ol>
     46   <li id="fn1">
     47     It is actually 15.5KB, but that includes errors on the SVG's minified, once fixed, it becomes
     48     the 17.2KB mentioned. <a href="#fnref1" title="Jump back to footnote 1 in the text">&#8617;</a></li>
     49   <!-- /li -->
     50   <li id="fn2">
     51     These files can be found more easily on the source code since they are not build up from
     52     templates, and it is uncommon to view the source code of those files, as they are normally
     53     viewed from the browser's inspection tools. On top of that, CSS is "compiled" from SCSS files,
     54     and once again, these files are easily reachable at the public repository of the website.
     55     Finally, the change in size is higher (1.5KB for the CSS file). <a href="#fnref2" title="Jump
     56     back to footnote 2 in the text">&#8617;</a></li>
     57   <!-- /li -->
     58 </ol>