2020-03-21-lighter-website.html (3648B) - raw
1 <!-- title: A lighter website --> 2 <!-- slug: lighter-website --> 3 <!-- categories: Personal domain --> 4 <!-- date: 2020-03-21T00:00:00Z --> 5 6 <p> 7 Following up with the <a href="/blog/2020/03/lightweight-website/">last post</a>, I decided to 8 make my website even faster (which probably doesn't make a difference anymore).</p> 9 <!-- /p --> 10 11 <h2>The logo</h2> 12 13 <p> 14 My pages (HTML only) were about 21KB (without compression), but 11KB of those consisted of an SVG 15 that appeared in all of them: the logo. The logo wasn't requested from a different static file 16 because I needed to modify it using CSS (so that colors would change when switching to the dark 17 theme) and, at the time, I thought inlining was the only option to allow that. However, 18 investigating a little I found out there are alternatives to inlining: we can take advantage of 19 the <code>use</code> tag of SVGs to "inline" an SVG from a different URL. By using that, my pages 20 are now around 10KB of size (plus the statics files, which have a total size of 37KB for the pages 21 without MathJax).</p> 22 <!-- /p --> 23 24 <h2>The static files</h2> 25 26 <p> 27 Considering that the <code>favicon.ico</code> is already 15KB, 47KB for a page is very good! 28 Nevertheless, I wanted to reduce it even more<sup id="fnref1"><a href="#fn1">1</a></sup>. I looked 29 into browser caching and liked the idea. I'll explain the basics. When our browser sends a request 30 for a certain resource (URL/file), the server that responds can add information that tells the 31 browser how long it should keep the file for. If the next time you browse that site and need the 32 file again the file hasn't "expired", your browser will not request it, but instead make use of 33 the copy previously downloaded. This reduces the number of requests made and the bandwidth 34 used.</p> 35 <!-- /p --> 36 37 <p> 38 The only problem with browser caching is that if the contents of a certain file change, your users 39 will not see those until their copies expire. We want to maximize the time a file is used for 40 before requesting it again while minimizing the time between update checks (unless our static 41 files never change). To solve that, I used <a href="https://gohugo.io/hugo-pipes">Hugo's 42 Pipes</a>, which allows you to add the SHA256 sum of a static file to its name automatically (and 43 all the places where the file is referenced). Now when downloading the CSS file, your browser is 44 requesting <code>https://oscarbenedito.com/css/style.min.<SHA256>.css</code>, which will 45 (highly probably) change when the contents change. Since the URL will be different, the browser 46 will request the new file.</p> 47 <!-- /p --> 48 49 <h2>The uncompressed SVGs</h2> 50 51 <p> 52 I found out that SVG files where not being compressed by default<sup id="fnref2"><a 53 href="#fn2">2</a></sup>. So I also enabled that!</p> 54 <!-- /p --> 55 56 <h2>Final comment</h2> 57 58 <p> 59 My webpage is ridiculously small and all these optimizations aren't that important. However, it is 60 fun to learn about all of this and it can also be helpful if in the future I have a site with 61 bigger static files (or someone reading this has!).</p> 62 <!-- /p --> 63 64 <!-- footnotes --> 65 <hr /> 66 67 <ol> 68 <li id="fn1"> 69 By now you have probably figured out this is more of a hobby than something useful, as the size 70 reduced is ridiculously small. <a href="#fnref1" title="Jump back to footnote 1 in the 71 text">↩</a></li> 72 <!-- /li --> 73 <li id="fn2"> 74 I don't really know the reason why. It might have something to do with <code>.svgz</code> files. 75 No idea. <a href="#fnref2" title="Jump back to footnote 2 in the text">↩</a></li> 76 <!-- /li --> 77 </ol>