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.
Saturday, August 31st, 2019
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.