2022-06-02
this post is a WIP - last updated 1st July 2023
First of all, I am not a web dev. Let's make that clear from the beginning. But I do like building things that are fast. This is the story of how I built this website and what I did to get that 100 Lighthouse score.
Obligatory Disclaimer: If you want to know how to make a fast website, I would take everything written here with a very large pinch of salt. Why? Because I'm no seasoned website developer, I've just learnt from tips and tricks from others in the field who know what they are doing. And you should do the same!
This is not my first website. I remember writing blog posts when I was 10 or 11 on the now-defunct josiahmendes.co.uk site. That website was built using Apple's iWeb application (another discontinued application), and a lot of help from my Dad. But in the 10 years since, web technologies have evolved and there is now a plethora of technologies that can be used to create a website.
However, in my own experience, a website that generates lots of <script> tags to provide some
cool animation or visual effect tends to increase load time.
So although fancy, using the most hyped or visually pleasing website is not my aim here.
Maybe it's time for a detour to answer the question - why do I want to make this website fast? This website is my portfolio, a showcase of what I have done, a well-crafted representation of my approach to work and a peek into my life. So a this website is a reflection of the things I value - efficiency, speed and simplicity.
So this website is built using Jekyll without a theme,
just some hand-written html and Liquid templates.
Zola, a static site generator written in Rust.
I moved away from Jekyll because the Ruby dependencies were a pain to manage,
Zola's single binary is much easier to work with, and I can submit patches in Rust if I need to!
When I first wrote HTML, the default Times New Roman font put me off almost instantly. At this point, most people (including myself) Google and search StackOverflow for ways to embed some nice font from Google Fonts or a similar platform.
But this approach involves JS, loading remote resources and are all effectively bottlenecks that users go through when viewing a website. So the solution? Using the fonts already present on the user's device. This is something that I stumbled across through Adam Morse's blog on Webfonts.
System fonts are fast, with some careful selection look good, and are adaptable to many devices. They're also probably better from an accesibility standpoint as well!
For convetional images, such as pictures in a blog post or the header photo on my homepage,
I'm using Google's web-optimised image format - webp.
Admittedly, this is one of the tricks to get a 100 Lighthouse score. Why? Because Google created Webp and
Lighthouse, so one of the ways to earn performance brownie points is to use Webp instead of other
common formats such as JPEG and PNG.
But from my observations, webp does generate a smaller file without large scale loss of image fidelity.
That cover image on my about page was originally 1.1 megabytes, but the webp version is just 279 kilobytes.
That's still larger than the rest of the site (HTML + CSS + conent),
but that's still an impressive reduction in size that makes the website load faster.
For other images like the ones on the projects page or some of the individual sketches in blog posts, they are displayed in SVG format. Most of these are handrawn using the Vectornator app on iPad and the SVG is then inlined. As these are "simple" images, using a vector format means that they are low in size without losing quality, and they also scale well to different device sizes.
And as Tom Macwright says in his blogpost about site optimisation
Inline SVGs are so cool: they're images with zero external dependencies, resizable, crisp just all-around lovely. SVG support is pretty darn good cross-brower too.