Ever since it became feasible to use more than a limited range of web safe fonts, web designers have been merrily unleashing their creativity, using weird and wonderful typefaces without having to resort to imagery.
And ever since then, the people who care about web performance have been trying to curb some of that enthusiasm. This is because a custom font is an extra resource that the browser has to download for the page to be displayed (different browsers do different things in terms of what they’ll display while waiting for a font to load).
We’ve given a broad outline of how to minimise the impact of custom fonts on performance in a previous post. This time, we’re going to focus on one technique: using the unicode-range CSS descriptor for subsetting.
One of the things that makes web performance interesting is that one size doesn’t always fit all. What works for one website won’t necessarily be right for another.
And while there are some performance optimisation techniques that you can implement with little fear of getting it wrong, there are others that should be approached with caution. If you’re not careful, they could have the opposite of the intended effect.
Back in January, we reported on the web performance hackathon we held late last year. It was a chance for our developers (and others) to unleash their creativity outside their normal working environment. By the end of it, we had not just a number of great concepts, but also some full, working solutions, including a way to get Performance Analyser working with continuous integration solutions such as Jenkins and Team City.
It was so successful that we decided to run another hackathon this summer. It was held on 22–23 July and this time, the theme was data insights.