Web Fonts

9 Dec 2015

One of the things I enjoy doing with this site is tweaking the design. I’ve previously written about the goals I’m aiming towards when I do this. Along with the publication of this post, I’m made another change in order to get closer to the ideal described there; I’ve introduced web fonts.

In that previous post, I was less than complimentary about web fonts:

No web fonts for body text. This not only adds another resource to the page load, but unlike an image or style sheet it renders the text itself invisible until it arrives. Until someone works out a way around this, I’m steering clear of web fonts for sites with casual visitors.

This is all still factually correct, but I’ve reconsidered how it relates to my goal of a fast, lightweight site that works well for drive-by readers. Firstly, I realized that the that the biggest non-content resource on all pages was the logo, which is just text. If I could replace this with real text in a font of my choice, I could eliminate the image entirely while still retaining visual control.

The second aspect, the invisible text while loading, remains, but isn’t the problem I thought it was. Even in my original objection I left myself an out — the body text is still in reliable old Georgia, and so will not be affected. A brief delay in the rendering of headings and so on seems acceptable, as long as it really is brief. On a lot of sites that use web fonts, it isn’t — it’s often noticeable, and occasionally a real impediment to getting to the content. Why do I think I can do better?

The main problem isn’t web fonts themselves (which are a just a resource like any other), but rather the way they’re often implemented. Services like Adobe TypeKit and Google Fonts offer a wide range of high-quality fonts, hosted on their own servers. This makes for painless integration — just add a single stylesheet and you’re done — and allows them to manage licensing and pricing, but comes at a cost. Third party resources like this not only put you at the mercy of someone else’s operations and priorities, but can also torpedo performance by requiring a separate HTTP connection and DNS lookup. For reasons of both performance and pigheadedness, I ruled such services out.

The alternative is to host the font yourself, just like a stylesheet or image. There’s no technical trick to this, but it requires a font licensed in such a way that allows redistribution. Unless you’re willing to pay far more than I can justify, this rules out most well known fonts from major foundries (who, not unreasonably, want to charge for their work). However, in parallel to the software world, there are fonts with more open licenses which would suit my purposes. After a bit of searching on FontSquirrel, I came across the rather nice Cooper Hewitt, a font that the Cooper Hewitt Smithsonian Design Museum commissioned for their own branding and then released under an open license. The light weight fit with the look I was aiming for, and the integration was straightforward. I also took the opportunity to replace some image links with text, meaning that there are now no non-content images on the site.

So, what’s the end result? Looking at the previous post, which is short but not unusually so:

  • Before: six resources, totaling 65.3KB.
  • After: four resources, totaling 34.0KB, a little over half the size.

So, not only do web fonts make the site prettier and more accessible, they substantially reduce both the size and number of resources. This translates into genuine performance gains for anyone visiting the site. When I started looking at web fonts, my aim was to improve the appearance without increasing load times, so such a marked improvement is a very nice bonus.

Update

Having inlined the font stylesheet into the main one, the page is now down to three resources — the HTML, a single stylesheet, and the font itself. The total size remains about the same.

Hashes In Space

18 Sep 2015

IPFS - InterPlanetary File System - is an open source project to create a “permanent web”, one that avoids the broken links and single points of failure arising from HTTP. Kyle at NeoCities explains this in far more detail, but the core idea is to replace URLs with hashes, resulting in content-addressed links.

We use such hashes extensively at Cydar to wrangle the data flowing through our distributed system, so I know first hand that they’re a straightforward and effective way to tackle this. Content hashes solve the two hard problems in computer science: names are unambiguous and can be generated locally, and the corresponding content is effectively immutable, meaning cache invalidation isn’t required. Throw in the fact that integrity checking is built in, and you have a compelling approach to handling distributed data.

IPFS is by no means perfect. In particular, while I like the content addressable part, I’m less convinced about the blockchain-based naming mechanism. Nevertheless, there’s definitely enough there to make it worth keeping an eye on.

Toys

29 Aug 2015

The history of computing is full of toys that nobody would seriously try to get real work done with. The PDP was a toy. The Apple II was a toy, and so was the Mac. Unix was a toy Multics, C a toy version of Algol (thrice removed), and the Web a toy in comparison to Xanadu.

With renewed rumours of an iPad Pro, people1 are again suggesting that the iPad (and tablets in general) isn’t suitable for real work. If history is anything to go by, this is a pretty good indicator that it’s an avenue worth pursuing.

  1. Such as Marco on ATP episode 132. [back]

MonolithFirst

7 Jun 2015

Martin Fowler (of Refactoring fame) writes in praise of monoliths, at least at first.

Margaret

18 May 2015

Announcing the arrival of Margaret, born Saturday at 4:30pm, weighing 10lb 3oz (4.62kg). Mother and baby doing great, and Rosalind can’t get enough of her little sister.

This site is maintained by me, Rob Hague. The opinions here are my own, and not those of my employer or anyone else. You can mail me at rob@rho.org.uk, and I'm robhague on Twitter. The site has a full-text RSS feed if you're so inclined.

Body text is set in Georgia or the nearest equivalent. Headings and other non-body text is set in Cooper Hewitt Light. The latter is © 2014 Cooper Hewitt Smithsonian Design Museum, and used under the SIL Open Font License.

All content © Rob Hague 2002-2015, except where otherwise noted.