Journal tags: webfonts

Danielle and I have been doing some front-end consultancy for a local client recently.

We’ve both been enjoying it a lot—it’s exhausting but rewarding work. So if you’d like us to come in and spend a few days with your company’s dev team, please get in touch.

I’ve certainly enjoyed the opportunity to watch Danielle in action, leading a workshop on refactoring React components in a pattern library. She’s incredibly knowledgable in that area.

I’m clueless when it comes to React, but I really enjoy getting down to the nitty-gritty of browser features—HTML, CSS, and JavaScript APIs. Our skillsets complement one another nicely.

This recent work was what prompted my thoughts around the principles of robustness and least power. We spent a day evaluating a continuum of related front-end concerns: semantics, accessibility, performance, and SEO.

When it came to performance, a lot of the work was around figuring out the most suitable metric to prioritise:

• time to first byte,
• time to first render,
• time to first meaningful paint, or
• time to first meaningful interaction.

And that doesn’t even cover the more easily-measurable numbers like:

• overall file size,
• number of requests, or
• pagespeed insights score.

One outcome was to realise that there’s a tendency (in performance, accessibility, or SEO) to focus on what’s easily measureable, not because it’s necessarily what matters, but precisely because it is easy to measure.

Then we got down to some nuts’n’bolts technology decisions. I took a step back and looked at the state of performance across the web. I thought it would be fun to rank the most troublesome technologies in order of tricksiness. I came up with a top four list.

Here we go, counting down from four to the number one spot…

4. Web fonts

Coming in at number four, it’s web fonts. Sometimes it’s the combined weight of multiple font files that’s the problem, but more often that not, it’s the perceived performance that suffers (mostly because of when the web fonts appear).

Fortunately there’s a straightforward question to ask in this situation: WWZD—What Would Zach Do?

3. Images

At the number three spot, it’s images. There are more of them and they just seem to be getting bigger all the time. And yet, we have more tools at our disposal than ever—better file formats, and excellent browser support for responsive images. Heck, we’re even getting the ability to lazy load images in HTML now.

So, as with web fonts, it feels like the impact of images on performance can be handled, as long as you give them some time and attention.

2. Our JavaScript

Just missing out on making the top spot is the JavaScript that we send down the pipe to our long-suffering users. There’s nothing wrong with the code itself—I’m sure it’s very good. There’s just too damn much of it. And that’s a real performance bottleneck, especially on mobile.

So stop sending so much JavaScript—a solution as simple as Monty Python’s instructions for playing the flute.

1. Other people’s JavaScript

At number one with a bullet, it’s all the crap that someone else tells us to put on our websites. Analytics. Ads. Trackers. Beacons. “It’s just one little script”, they say. And then that one little script calls in another, and another, and another.

It’s so disheartening when you’ve devoted your time and energy into your web font loading strategy, and optimising your images, and unbundling your JavaScript …only to have someone else’s JavaScript just shit all over your nice performance budget.

Here’s the really annoying thing: when I go to performance conferences, or participate in performance discussions, you know who’s nowhere to be found? The people making those third-party scripts.

The narrative around front-end performance is that it’s up to us developers to take responsibility for how our websites perform. But by far the biggest performance impact comes from third-party scripts.

There is a solution to this, but it’s not a technical one. We could refuse to add overweight (and in many cases, unethical) third-party scripts to the sites we build.

I have many, many issues with Google’s AMP project, but I completely acknowledge that it solves a political problem:

No external JavaScript is allowed in an AMP HTML document. This covers third-party libraries, advertising and tracking scripts. This is A-okay with me.

The reasons given for this ban are related to performance and I agree with them completely. Big bloated JavaScript libraries are one of the biggest performance killers on the web.

But how can we take that lesson from AMP and apply it to all our web pages? If we simply refuse to be the one to add those third-party scripts, we get fired, and somebody else comes in who is willing to poison web pages with third-party scripts. There’s nothing to stop companies doing that.

Unless…

Suppose we were to all make a pact that we would stand in solidarity with any of our fellow developers in that sort of situation. A sort of joining-together. A union, if you will.

There is power in a factory, power in the land, power in the hands of the worker, but it all amounts to nothing if together we don’t stand.

There is power in a union.

While doing some browser testing this week, Mark come across a particularly wicked front-end problem. Something was triggering compatibility mode in Internet Explorer 8 and he couldn’t figure out what it was.

Compatibility mode was something introduced in IE8 to try not to “break the web”, as Microsoft kept putting it. Effectively it makes IE8 behave like IE7. Why would you ever want to do that? Well, if you make websites exactly the wrong way and code for a specific browser (like, say, IE7), then better, improved browsers are something to be feared and battled against. For the rest of us, better, improved browsers are something to be welcomed.

Shockingly, Microsoft originally planned to have compatibility mode enabled by default in Internet Explorer 8. It was bad enough that they were going to ship a browser with a built-in thermal exhaust port, they also contemplated bundling a proton torpedo with it too. Needless to say, right-minded people were upset at that possibility. I wrote about my concerns back in 2008.

Microsoft changed their mind about the default behaviour, but they still shipped IE8 with the compatibility mode “feature”, which Mark was very much experiencing as a bug. Something in the CSS was triggering compatibility mode, but frustratingly, there was no easy way of figuring out what was doing it. So he began removing chunks of CSS, reducing until he could focus in on the exact piece of CSS that was triggering IE8’s errant behaviour.

Finally, he found it. He was using an icon font. Now, that in itself isn’t enough to give IE8 its conniptions—an icon font is just a web font like any other. The only difference is that this font was using the private use area of the unicode range. That’s the default setting if you’re creating an icon font using the excellent icomoon service. There’s a good reason for that:

Using Latin letters is not recommended for icon fonts. Using the Private Use Area of Unicode is the best option for icon fonts. By using PUA characters, your icon font will be compatible with screen readers. But if you use Latin characters, the screen reader might read single, meaningless letters, which would be confusing.

Well, it turns out that using assigning glyphs to this private use area was causing IE8 to flip into compatibility mode. Once Mark assigned the glyphs to different characters, IE8 started behaving itself.

Now, we haven’t tested to see if this is triggered by all of the 6400 available slots in the UTF-8 private use range. If someone wants to run that test (presumably using some kind of automation), ’twould be much appreciated.

Meantime, just be careful if you’re using the private use area for your icon fonts—you may just inadvertently wake the slumbering beast of compatibility mode.

There’s been some fantastic collaborative work done recently on the tricky issue of responsive images. Witness the community group and its attendant website, complete with logo.

Meanwhile, there’s been some great research into dealing with high-DPI displays (which the world and its dog have decided to label “retina”). There’s the in-depth analysis by Daan Jobsis which looks at what you can get away with when it comes to compression and quality for “retina” displays: quite a lot, as it turns out.

In fact, you may well be able to double the dimensions of an image while simultaneously bringing down its quality and end up with an image that is smaller in file size than the original, while still looking great on high-DP..—“retina” displays. The guys over at Filament group have labelled this Compressive Images. Nice.

I like that approach. No JavaScript polyfills. No lobbying of standards bodies.

I’m generally fan of solutions that look for ways of avoiding the problem in the first place. Hence my approach to image optimisation for all devices, widescreen or narrow.

Of course this whole issue of responsive (or compressive) images should really only apply to photographic imagery. If you’re dealing with “text as images” …don’t. Use web fonts. If you’re dealing with logos or icons, there are other options, like SVG.

Then there’s the combination of web fonts and iconography. Why not use a small web font containing just the icons you need?

I tried this recently, diligently following Josh’s excellent blog post detailing how to get icon shapes out of Fireworks, into a font editor, and then into an actual font. It works a treat, although I concur with Josh’s suggestion that the technique should really only be implemented using the ::before and ::after pseudo-elements in combination with base-64 encoding the font file. That means it won’t work in every single browser, but that’s the point: these icons should be an enhancement, not a requirement.

Having gone through the tortuous steps required to get my Mac all set up with the software required to follow Josh’s tutorial, I then spotted the note at the end of his article that pointed to Icomoon. That turns out to be a fantastic service. You can pick and choose from the icons provided or you can upload your own vector shapes. Then you can assign the unicode slots you want to use for the icons and you can get the resulting font file base-64 encoded. Very, very cool!

There’s a whole slew of icon-font services like that out there now: Pictos, Web Symbols, and Symbolset with its ingenious use of ligatures to allow for an accessible fallback.

Jenn is currently casting a critical eye over each of these service over on the Nerdary: part one, part two, and part three are all deserving of your time and attention.