Extra, extra! Read all about it! (Once our webfonts have finished downloading)
News sites are probably more concerned with putting the written word on screen quickly than any other type of site. You can’t have your browser dilly-dallying around with webfonts while the visitor is impatiently waiting to read the latest breaking news, now can you? Turns out, some news sites can.
Let’s look at how some of the big boys in the news sector do, font-wise, and see if we can improve things. After checking the very first result in duckduckgo careful research of who the biggests news sites are, I had a list of six sites to investigate:
- Yahoo! News
- Google News
- HuffingtonPost
- CNN
- New York Times
- Fox News
My toolkit consists out of an incognito desktop browser window, Wakamai Fondue, TTX/FontTools and a lazy Sunday afternoon.
I check just the homepage, on an empty cache, no ad blocker, no clicking through to articles, and no scrolling to trigger additional content.
While looking for how to optimise the fonts used, I’m not concerned with subsetting or stripping OpenType features, as I’ll assume the news sites will use the full character set and all the layout features a font offers.
With that out of the way, let’s read some newspapers!
Yahoo! News
Yahoo! News uses system fonts (a boring stack of Helvetica, Arial and sans-serif), an approach fitting for news sites. Content is king, and having content visible on screen a.s.a.p. is of the utmost importance.
Verdict: Fast, functional and boring, Yahoo! News only uses a simple font stack of local fonts.
Google News
Google News loads a surprisingly large amount of fonts: eight fonts, amounting to 158 kilobytes. They’re also used in kind of a weird mix.
First font loaded is Product Sans, which includes contextual alternates and contextual ligatures used to display icons like the Google logo, temperature notations and custom smileys and arrows. But in the end, it’s only used in the header: a nearly 13KB font just to draw the word “News” next to the Google logo in the header.
Google Sans Display Regular comes in three weights. It has OpenType features which could come in handy on a text and data heavy site like a news site: fractions, tabular figures and a bunch of standard ligatures. Also, it has more ligatures to evoke the Google logo and icons. These are icons duplicated across all three files. Oddly enough this font is only used for the navigation, non-news headings and some other odds and ends.
Roboto Regular, Medium and Bold are used for news related content, like titles and meta info, and for the “Sign in” button in the header. Maybe there’s a strict style guide, but why not just use Google Sans Display here too?
Odd font out is a 70KB icon font named Material Icons Extended. It contains 1528 different icons, of which part is mapped to the usual Unicode PUA codepoints (0xE000 to 0xEB4F, and a bull icon at 0x10FFFD) and part is mapped to ligatures for strings like “bottom_navigation” and “battery_charging_full”.
For the buttons to switch between temperature units, the system font is applied. Why aren’t they using one of the webfonts there, I wonder?
Verdict: Everything is obviously served over the heavily optimised Google Fonts network, so not much to gain there. Stripping the duplicate icons could save a handful of kilobytes. Why this page needs three different geometric sans serif typefaces scattered across the page is a bit of a mystery to me.
Huffington Post
The Huffington Post also uses icon fonts. It serves these as a 9.6KB WOFF. With some basic optimizations, and serving the font as a WOFF2 saves 2.5KB. Not bad for 47 seconds of work.
They also serve five weights and widths of Proxima Nova from their own servers, totalling 334 KB in WOFF fonts. Weirdly they serve the bold version as a TrueType font, which is double the size of any of the other four CFF (OpenType) fonts.
Why they don’t serve WOFF2 is another bit of a head scratcher to me.
The fonts come with a full set of OpenType features: all kinds of alternates, stylistic sets, small caps — the lot. It feels like overkill, as at a quick glance most of these don’t seem to be used. The fonts are loaded through JavaScript and injected as base64 encoded strings in CSS files.
Verdict: Suboptimal compression, base64 serving and and overkill of OpenType features leaves a lot to be improved. Some basic optimisations and using WOFF2 instead of WOFF will save 100KB on an empty cache!
CNN
CNN serves its own bespoke font: CNN Sans, a mundane, boring Helvetica clone. It’s packed with OpenType features, and even includes around 90 icons for things like the CNN logo, weather icons, and generic site UI stuff. There are even PUA codepoint for ligatures. The icons are duplicated in all four weights (and even the italics), which sounds unnecessary.
With all these icons embedded in their regular fonts, it’s weird that another font is loaded which contains even more icons. There are a lot of duplicates but they are mapped to other Unicode values, making them incompatible with the embedded ones. Not a huge problem, as it looks like the embedded icons aren’t even used, but it’s dead weight nonetheless.
At a total of 205 kilobytes for the text fonts, and 21 kilobytes for the dedicated icon font, this bundle of WOFF2 accounts for almost a quarter megabyte.
Stripping the unused icons and doing some basic optimisations (but leaving all OpenType features intact) brings the total size of the text fonts down to 133 kilobytes — a savings of a very respectable 72 kilobytes! Optimising the icon font adds another kilobyte of savings.
Verdict: It looks like CNN Sans is carrying around a lot of dead weight, and it’s easy to cut over 73 kilobytes on uncessarary font data.
New York Times
Right of the bat, the New York Times pushes eleven WOFF2 fonts down the wire, at a total of 242 kilobytes.
Five versions of Cheltenham just for headlines and subtitles, one version of Imperial for body copy, and four weights of Franklin for navigation, meta info and a few dedicated link blocks to other articles. Ten fonts for just representing the text on the homepage! The fonts are well optimised and low on OpenType features, so there’s not a lot you could do to bring the total file size down.
It looks like they’re doing their own WOFF/WOFF2 support detection in JavaScript, then loading the relevant fonts base64 encoded in CSS files and storing them in localstorage for future use.
The icons are being taken care of by an icon font served as a WOFF. At 4.8KB it’s already a small font, but could be brought down to 3.3KB when optimised and served as a WOFF2.
Verdict: Apart from the rather large amount of fonts files loaded, the font files are lean and used with a well thought out font loading strategy.
Fox News
Fox News grabs three weights of Roboto off of Google Fonts, being uninteresting both in choice of typeface and opportunities to optimise.
More interesting is that they also use an icon font — a customized version of Font Awesome. It’s and older version, reduced to about 148 icons through the use of IcoMoon. You can tell because of the IcoMoon metadata left in the font file. Stripping this metadata during default optimisation, and turning this into a WOFF2 instead of the WOFF they chose to serve, brings the file size down from 30KB to 10KB.
Verdict: Nothing much interesting going on here, but the icon font could be optimised to save 20KB for each visitor with a clean cache.
Conclusion
We haven’t even dug into using less fonts, subsetting, or stripping OpenType features. Nor have we considered using variable fonts to easily reduce the amount of transferred data (while adding even more typographic freedom to boot). We just did some of the minimal, basic optimisations and already seen quite some room to improve.
I expected major news sites to be really conscious about the fonts they use, and making sure everything is heavily optimised. Turns out a simple Sunday afternoon of hacking could save a lot of data: we could easily save roughly 200KB on these six sites combined. At an estimated 665,000,000 unique visitors per month, assuming 10% visits on an empty cache, that’s 13,300,000,000 kilobytes we could save — a staggering 13 terabytes per month!