Extreme Web Optimizations, without Compromising Style
Over the past 10 months, I’ve worked on and off tweaking my site to get it closer to how I want it to look and perform. The main goal was simple: make a site that looks good, and loads fast. A quick solution would’ve been to keep the css to a minimum, use browser defaults for fonts etc. However that would’ve made my vision of a styled site difficult if not impossible. This pushed me to seek gains elsewhere as much as I could.
In other projects this year, I’ve messed around with combining and editing fonts in FontForge and when it came to look at the fonts for the site, I returned to it once more. Tools like Fontsquirrel’s webfont generator are great for optimising fonts quickly, but I had a feeling I could make the filesizes even smaller.
The reason I originally thought of using FontForge here was because of issues with default fonts on other systems. In my site logo, I have two unicode ‘whiskers’ on either side, however one of the only fonts that even has this character is Symbola. On Firefox Desktop, Symbola is a default font and is automatically used to display characters that aren’t in the supplied font. However, on other browsers I found this wasn’t the case and my characters would show blank boxes. The temporary solution was just throwing Symbola in with the rest, but at a whopping 2.2mb? It wasn’t gonna be permanent. So I went and copied what I did when I made single file Latin+CJK fonts for Rockbox, and transplanted the characters into Lunchtype22 for the title. I did a full writeup on how to do this, which you can find here
When it came to thinning down the character selection of the fonts, FontForge made it pretty easy to pick and choose what stayed and what went. I kept a very minimal range of basic Latin characters, symbols and numbers. In the future I have the option to add some of these back on if they’re needed. Tweaking the export settings saved some extra space as well. All in all, these optimisations helped reduce the combined font’s filesizes from several MBs to just under 38KBs.
SVGs are always some of the smallest resources you can use, but there’s also plenty of room to make optimisations with them. For making simple icons, like my RSS icons, I found dotgrid from hundred rabbits to be a fantastic editor that exports good svgs to work with. You’ll still want to tweak and edit the file to fit your usecase, but overall the easiest to use for icons. For other svg images, I use Inkscape. But I was only able to get usable files if I exported using their Optimised Svg output, with most options turned on. On top of all these, removing xml declarations, version attributes and other stuff not needed or read by browsers helps to trim even just a kilobyte or two off your files, which adds up.
Easily the largest part of any webpage, images became a tricky problem early on. One of the main parts of my site is the Gallery section holding all my photography, and having up to 10 images per page would take forever to load. The first step I took was to match the resolution of the images to their displayed max-width, 720px. I also made a separate folder for section lists images which display at 400px wide, saving loading times for those pages. After doing some searching, I found Rekka Bellums’s guide for optimising images. I took their ImageMagick script and changed it a little to suit my needs, getting rid of colorspace setting and reducing the quality to 80% in order to keep file sizes low. I’ve yet to create a good workflow for optimising gifs, using some web tools in the meantime as I don’t tend to work with gifs much at all.
One of the last optimisations I made was to compress the css. It was really only worth doing after I finalised everything, as it makes reading the raw css file pretty difficult (though I do have to scroll less now which is nice). I reduced all functions to a single line, as well as removing any space that wasn’t strictly necessary. This saved me over a KB. A lot of functions like borders, margins, text-decorations etc. also have shorthand ways of writing them which reduces overall bloat. I wouldn’t recommend the compression step for most use cases, but for simple static sites that wont be used by many, it’s such a simple and quick way to save a few KBs.
In the end, I managed to keep even the largest page under 800KBs. For comparison, the most minimal page is the homepage, coming in at just 48KBs. It was probably all in all more work than it was worth, but I’m glad with the results. Thankfully wont be having any more urges to tweak and optimise the site when I know there’s very little left on the table to save.