Wednesday, September 12th, 2018
Tuesday, September 11th, 2018
The top four web performance challenges
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.
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?
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.
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.
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:
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.
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.
Friday, July 20th, 2018
This is a great interview with Rich on all things related to web typography—including, of course, variable fonts.
I’m so lucky that I literally get to work side by side with Rich; I get to geek out with him about font stuff all the time.
Saturday, March 10th, 2018
You’ll need to be comfortable with using the command line, but this is a very useful font subsetting tool from those clever folks at Filament Group.
Friday, January 26th, 2018
The gorgeous website for this year’s Ampersand conference might well be one of the first commercial uses of variable fonts in the wild. Here, Richard documents all the clever things Mark did to ensure good fallbacks for browsers that don’t yet support variable fonts.
Tuesday, January 23rd, 2018
In fact, you can do more than saving the date: you can snap up a super early bird ticket for whopping £85 saving.
Monday, October 2nd, 2017
Here’s the flow that eBay use for the font-loading. They’ve decided that on the very first page view, seeing a system font is an acceptable trade-off. I think that makes sense for their situation.
Interestingly, they set a flag for subsequent visits using
localStorage rather than a cookie. I wonder why that is? For me, the ability to read cookies on the server as well as the client make them quite handy for situations like this.
Tuesday, August 29th, 2017
A good introduction to variable fonts, and an exploration of the possible interface elements we might use to choose our settings: toggles? knobs? sliders? control pads?
Sunday, August 20th, 2017
Everyone’s been talking about
font-display: swap as a way of taking the pain out of loading web fonts, but here Chris looks at
font-display: optional and
font-display: fallback as well.
Monday, November 21st, 2016
Douglas Coupland on web typography.
When I discuss the internet’s feel and its random rodeo of fonts, I think of the freedom, naivety, laziness, greed, cluelessness and skill I see there — it’s a cyberplace as wondrous as the bubbling cradle of pea-soup goo from which life emerged. The internet has a rawness, a Darwinian evolutionary texture. It’s a place where metrics totally unrelated to print typography dictate the look and feel.
Tuesday, November 1st, 2016
Monica takes a look at the options out there for loading web fonts and settles on a smart asynchronous lazy-loading approach.
Monday, September 19th, 2016
This is what Nick Sherman has been banging on about for years, and now the time has come for variable fonts …as long as typographers, browser makers, and standards bodies get behind it.
More details on Ev’s blog.
Monday, September 12th, 2016
A good ol’ polemic in favour of using web fonts. It’s a good read although I strongly disagree with this line of reasoning:
The average internet speed in the United States today is three times as fast as it was in 2011.
But that americentric view is redeemed later on:
The World Wide Web may be a creation of the West, but now, at long last, it needs to get ready for the rest.
I may not agree with all the points in this article, but I think we can all agree that if we’re going to use web fonts, we must use them responsibly …otherwise users are going to treat them as damage and route around them.
Tuesday, September 6th, 2016
font-display property is landing in browsers, and this is a great introduction to using it:
If you don’t know which option to use, then go with
Tuesday, July 19th, 2016
A terrific rundown of all your options when it comes to web font loading.
Tuesday, July 12th, 2016
I’ve always loved the way that Edward Tufte consistently uses Bembo to typeset his books. Here’s a version made for screen and freely licensed.
Sunday, May 8th, 2016
Some smart thoughts on web fonts.
Friday, March 18th, 2016
I love good typography but I have to agree with the sentiment expressed here.
System fonts can be beautiful. Webfonts are not a requirement for great typography.
Wednesday, December 16th, 2015
A single page showing all the weights available from Google fonts at a glance.
Sunday, December 13th, 2015
The transcript of a great talk by Wilto, focusing on responsive images, inlining critical CSS, and webfont loading.
When we present users with a slow website, a loading spinner, laggy webfonts—or tell them outright that they‘re not using a website the right way—we’re breaking the fourth wall. We’ve gone so far as to invent an arbitary line between “webapp” and “website” so we could justify these decisions to ourselves: “well, but, this is a web app. It… it has… JSON. The people that can’t use the thing I built? They don’t get a say.”
We, as an industry, have nearly decided that we’re doing a great job as long as we don’t count the cases where we’re doing a terrible job.