Oh, nice! A version of the classic Proxima Nova that’s a variable font that allows you to vary weight, width, and slant.
Monday, March 1st, 2021
Wednesday, May 13th, 2020
Reef is an anti-framework.
It does a lot less than the big guys like React and Vue. It doesn’t have a Virtual DOM. It doesn’t require you to learn a custom templating syntax. It doesn’t provide a bunch of custom methods.
Reef does just one thing: render UI.
Monday, April 27th, 2020
Last week I wrote about the great work that Matthew did and now he’s written up his process:
Thursday, April 23rd, 2020
It’s been fascinating to see how television programmes have adapted to The Situation. It’s like there’s been a weird inversion with the YouTube asthetic. Instead of YouTubers doing their utmost to emulate the look of professional television, now everyone on professional television looks like a YouTuber.
No more lighting or audio technicians. No more studio audiences. Heck, no more studios.
There are some kinds of TV programmes that are showing the strain. A lot of comedy formats just fall flat without the usual production values. But a lot of programmes work just fine. In fact, some of them might be better. Watching Mary Beard present Front Row Late from her house is an absolute delight. It feels more direct and honest without the artiface of a television studio. It kind of makes you wonder whether expensive production costs are really necessary when what you really care about is the content.
All of this is one big belaboured metaphor for websites.
In times of crisis, informational websites sometimes offer a “lite” version. Max has even made an emergency website kit:
The site contains only the bare minimum - no webfonts, no tracking, no unnecessary images. The entire thing should fit in a single HTTP request. It’s basically just a small, ultra-lean blog focused on maximum resilience and accessibility. The Service Worker takes it a step further from there so if you’ve visited the site once, the information is still accessible even if you lose network coverage.
Eric emphasises the importance of performance in his post Get Static:
I’m thinking here of sites for places like health departments (and pretty much all government services), hospitals and clinics, utility services, food delivery and ordering, and I’m sure there are more that haven’t occurred to me. As much as you possibly can, get it down to static HTML and CSS and maybe a tiny bit of enhancing JS, and pare away every byte you can.
Tom Loosemore offers this advice to teams building new coronavirus services:
- Get a 4 year-old Android phone, and use it as your test/demo device.
- https://design-system.service.gov.uk is your friend.
- Full React isn’t your friend if it makes your service slow & inaccessible
Remember: This is for everyone.
Indeed, Gov.uk are usually a paragon of best practices in just about any situation. But they dropped the ball recently, as Matthew attests:
One sign that your website isn’t meeting the needs of all your users is when Matthew Somerville gets sufficiently grumpy about it to do a proper version himself.
It’s true enough that Matthew excels at creating lightweight, accessible versions of services that are too bloated or buggy to use. His accessible Odeon project from back in the day is legendary. And I use his slimline version of the National Rail website all the time: traintimes.org.uk—it’s a terrificly performant progressive web app.
Maybe now, with this rush to make lightweight versions of valuable services, we might stop and reflect on whether we ever really needed all those added extras in the first place.
Hope springs eternal.
Update: Matthew has written about his process in Looking at coronavirus.data.gov.uk.
Friday, February 28th, 2020
How and when did I get to the point where I would consider a page weight of 4 MB on a large page and 500 KB on a small page normal?
This isn’t just a well-earned rant from Manuel. I mean, it *is that, but it’s also packed with practical performance advice.
Monday, February 24th, 2020
Pages are often designed so that they’re hard or impossible to read if some dependency fails to load. On a slow connection, it’s quite common for at least one depedency to fail.
Fire up Reader Mode and read this excellent article informed by data from using a typically slow connection in rural USA today. Two findings are:
- A large fraction of the web is unusable on a bad connection. Even on a good (0% packetloss, no ping spike) dialup connection, some sites won’t load.
- Some sites will use a lot of data!
Saturday, August 31st, 2019
If you treat data as a constraint in your design and development process, you’ll likely be able to brainstorm a large number of different ways to keep data usage to a minimum while still providing an excellent experience. Doing less doesn’t mean it has to feel broken.
Sunday, June 16th, 2019
IntersectionObserver to lazy load images—very handy for webmention avatars.
Saturday, March 9th, 2019
I like Tim’s definition here:
A performance budget is a clearly defined limit on one or more performance metrics that the team agrees not to exceed, and that is used to guide design and development.
And I agree about the four attributes required for a performance budget to succeed. It must be:
The point is not to let the performance budget try to stand on its own, somewhere hidden in company documentation collecting dust. You need to be proactive about making the budget become a part of your everyday work.
Saturday, November 17th, 2018
A fascinating look at standards in the real world. In this case, it’s the kilogram, which is shedding its French Revolutionary roots in favour of the Planck constant.
Our messy human measurements have transcended their messy humanness; they have been melded with an eternal truth.
Mention of The Master Of The Kilogram reminded me of The Keeper Of Time.
Tuesday, October 9th, 2018
Great ideas from Addy on where to start with creating a performance budget that can act as a red line you don’t want to cross.
If it’s worth getting fast, it’s worth staying fast.
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.
Thursday, September 6th, 2018
Take a perfectly useful standardised measurement of length, weight, speed or time, and convert to something far less useful (but much more fun).
Tuesday, October 25th, 2016
Here’s an interesting metric for measuring performance: take the overall page weight of a URL and divide it by the file size of the screenshot of that URL.
Wednesday, December 16th, 2015
A single page showing all the weights available from Google fonts at a glance.
Monday, December 31st, 2012
An excellent tale of performance optimisation …complete with a coda on looking behind the numbers when it comes to analytics data.
Tuesday, May 24th, 2011
The class of device formerly known as mobile.
Tuesday, January 13th, 2009
Font-weight is still broken in all but one browser | Clagnut Â§ Browsers Â· Typography Â· CSSÂ techniques
A superb bit of browser research by Richard. "Thereâ€™s more to the lives of many typefaces than just Bold and Regular, but almost no browsers follow the proper CSS 1 way of specifying Light, Semibold, Black and other weights. There is a workaround,â€¦
Sunday, January 4th, 2009
A super-simple lightweight PHP class by Kellan for calling the Flickr API and receiving back an array of results.