Good point. When we talk about perceived performance, the perception in question is almost always visual. We should think more inclusively than that.
Tuesday, July 7th, 2020
Friday, May 8th, 2020
Progressive disclosure interface patterns categorised and evaluated:
- mouseover popups (just say no!),
- new pages,
- scrolling sideways.
I really like the hypertext history invoked in this article.
The piece finishes with a great note on the MacNamara fallacy:
Everyone thinks metrics let us measure results. But, actually, they don’t. They measure only what they are measuring. Engagement, for example, is not something that can be measured, so we use an analogue for it. Time on page. Or clicks.
We often end up measuring what is quick, cheap, and easy to measure. Therefore, few organizations regularly conduct usability testing or customer-satisfaction surveys, but lots use analytics.
Even today, organizations often use clicks as a measure of engagement. So, all too often, they design user interfaces to generate clicks, so the system can measure them.
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, February 15th, 2020
Friday, February 14th, 2020
This is going to be so useful for client work at Clearleft—instant snapshots of performance metrics across industries and regions!
See Tammy’s blog post for me details.
Friday, January 10th, 2020
Smart advice from Harry on setting performance budgets:
They shouldn’t be aspirational, they should be preventative … my suggestion for setting a budget for any trackable metric is to take the worst data point in the past two weeks and use that as your limit
Wednesday, July 3rd, 2019
Time to Interactive (TTI) is the most impactful metric to your performance score.
Therefore, to receive a high PageSpeed score, you will need a speedy TTI measurement.
At a high level, there are two significant factors that hugely influence TTI:
Thursday, June 6th, 2019
Matt’s publishing a newsletter on the past, present, and future of tracking:
The last 100 years have been a journey to see how to measure ghosts - how to measure the invisible audiences at the end of technological distribution networks. With every decade, these ghosts have come more and more into focus, ending with a the last ten years of social media and digital advertising that has created unimaginable amounts of data about everything we see, read, click and like.
He sees the pendulum swinging the other way now …for those who can afford it:
If there’s one constant in the economics of audience data over the last 100 years, is that we only get free services if we pay for them with our attention. This has been true for commercial radio and television, free newspapers, mobile games and digital content. If we want privacy, we have to pay for it, and not everyone can afford this. Will the right to become a ghost only be for the people with money to buy premium products?
Tuesday, May 7th, 2019
This is a very useful new feature in Calibre, the performance monitoring tool. Now you can get data about just how much third-party scripts are affecting your site’s performance:
The best way of circumventing fear and anxiety around third party script performance is to capture metrics that clearly articulate their performance impact.
Sunday, March 31st, 2019
Font metrics help the computer determine things like the default spacing between lines, how high or low sub and super scripts should go, and how to align two differently sized pieces of text next to each other.
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.
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.
Thursday, September 20th, 2018
A framework for web performance
Here at Clearleft, we’ve recently been doing some front-end consultancy. That prompted me to jot down thoughts on design principles and performance:
We continued with some more performance work this week. Having already covered some of the nitty-gritty performance tactics like font-loading, image optimisation, etc., we wanted to take a step back and formulate an ongoing strategy for performance.
When it comes to web performance, the eternal question is “What should we measure?” The answer to that question will determine where you then concentrate your efforts—whatever it is your measuring, that’s what you’ll be looking to improve.
I started by drawing a distinction between measurements of quantities and measurements of time. Quantities are quite easy to measure. You can measure these quantities using nothing more than browser dev tools:
- overall file size (page weight + assets), and
- number of requests.
I think it’s good to measure these quantities, and I think it’s good to have a performance budget for them. But I also think they’re table stakes. They don’t actually tell you much about the impact that performance is having on the user experience. For that, we need to enumerate moments in time:
- time to first byte,
- time to first render,
- time to first meaningful paint, and
- time to first meaningful interaction.
There’s one more moment in time, which is the time until DOM content is loaded. But I’m not sure that has a direct effect on how performance is perceived, so it feels like it belongs more in the category of quantities than time.
Next, we listed out all the factors that could affect each of the moments in time. For example, the time to first byte depends on the speed of the network that the user is on. It also depends on how speedily your server (or Content Delivery Network) can return a response. Meanwhile, time to first render is affected by the speed of the user’s network, but it’s also affected by how many blocking elements are on the critical path.
By listing all the factors out, we can draw a distinction between the factors that are outside of our control, and the factors that we can do something about. So while we might not be able to do anything about the speed of the user’s network, we might well be able to optimise the speed at which our server returns a response, or we might be able to defer some assets that are currently blocking the critical path.
|1st meaningful paint||
|1st meaningful interaction||
So far, everything in our list of performance-affecting factors is related to the first visit. It’s worth drawing up a second list to document all the factors for subsequent visits. This will look the same as the list for first visits, but with the crucial difference that caching now becomes a factor.
|First visit factors||Repeat visit factors|
|1st meaningful paint||
|1st meaningful interaction||
Alright. Now it’s time to get some numbers for each of the four moments in time. I use Web Page Test for this. Choose a realistic setting, like 3G on an Android from the East coast of the USA. Under advanced settings, be sure to select “First View and Repeat View” so that you can put those numbers in two different columns.
Here are some numbers for adactio.com:
|First visit time||Repeat visit time|
|1st byte||1.476 seconds||1.215 seconds|
|1st render||2.633 seconds||1.930 seconds|
|1st meaningful paint||2.633 seconds||1.930 seconds|
|1st meaningful interaction||2.868 seconds||2.083 seconds|
I’m getting the same numbers for first render as first meaningful paint. That tells me that there’s no point in trying to optimise my font-loading, for example …which makes total sense, because adactio.com isn’t using any web fonts. But on a different site, you might see a big gap between those numbers.
I am seeing a gap between time to first byte and time to first render. That tells me that I might be able to get some blocking requests off the critical path. Sure enough, I’m currently referencing an external stylesheet in the
head of adactio.com—if I were to inline critical styles and defer the loading of that stylesheet, I should be able to narrow that gap.
My point is, you’re going to see very different distributions of numbers depending on the kind of site you’re testing. There’s no one-size-fits-all metric to focus on.
Now that you’ve got numbers for how your site is currently performing, you can create two new columns: one of those is a list of first-visit targets, the other is a list of repeat-visit targets for each moment in time. Try to keep them realistic.
For example, if I could reduce the time to first render on adactio.com by 0.5 seconds, my goals would look like this:
|First visit goal||Repeat visit goal|
|1st byte||1.476 seconds||1.215 seconds|
|1st render||2.133 seconds||1.430 seconds|
|1st meaningful paint||2.133 seconds||1.430 seconds|
|1st meaningful interaction||2.368 seconds||1.583 seconds|
See how the 0.5 seconds saving cascades down into the other numbers?
Alright! Now I’ve got something to aim for. It might also be worth having an extra column to record which of the moments in time are high priority, which are medium priority, and which are low priority.
|1st meaningful paint||Low|
|1st meaningful interaction||Low|
Your goals and priorities may be quite different.
I think this is a fairly useful framework for figuring out where to focus when it comes to web performance. If you’d like to give it a go, I’ve made a web performance chart for you to print out and fill in. Here’s a PDF version if that’s easier for printing. Or you can download the HTML version if you want to edit it.
I have to say, I’m really enjoying the front-end consultancy work we’ve been doing at Clearleft around performance and related technologies, like offline functionality. I’d like to do more of it. If you’d like some help in prioritising performance at your company, please get in touch. Let’s make the web faster together.
Friday, September 14th, 2018
Yes! Yes! Yes!
Our efforts to measure and improve UX are packed with tragically ironic attempts to love our users: we try to find ways to improve our app experiences by bloating them with analytics, split testing, behavioral analysis, and Net Promoter Score popovers. We stack plugins on top of third-party libraries on top of frameworks in the name of making websites “better”—whether it’s something misguided, like adding a carousel to appease some executive’s burning desire to get everything “above the fold,” or something truly intended to help people, like a support chat overlay. Often the net result is a slower page load, a frustrating experience, and/or (usually “and”) a ton of extra code and assets transferred to the browser.
Even tools that are supposed to help measure performance in order to make improvements—like, say, Real User Monitoring—require you to add a script to your web pages …thereby increasing the file size and degrading performance! It’s ironic, in that Alanis Morissette sense of not understanding what irony is.
Stacking tools upon tools may solve our problems, but it’s creating a Jenga tower of problems for our users.
This is a great article about evaluating technology.
Tuesday, July 31st, 2018
Focusing on the median or average is the equivalent of walking around with a pair of blinders on. We’re limiting our perspective and, in the process, missing out on so much crucial detail. By definition, when we make improving the median or average our goal, we are focusing on optimizing for only about half of our sessions.
Tim does the numbers…
By honing in on the 90th—or 95th or similar—we ensure those weaknesses don’t get ignored. Our goal is to optimize the performance of our site for the majority of our users—not just a small subset of them.
Wednesday, March 7th, 2018
Everything old is new again—sometimes the age-old technique of using a 1x1 pixel image to log requests is still the only way to get certain metrics.
While tracking pixels are far from a new idea, there are creative ways in which we can use them to collect data useful to developers. Once the data is gathered, we can begin to make much more informed decisions about how we work.
Wednesday, February 7th, 2018
It’s ironic, isn’t it? Design is more important and respected than ever, which means we have more agency to affect change. But at the same time, our priorities have been subverted, pushed towards corporate benefit over human benefit. It’s hard to reconcile those things.
Thursday, December 21st, 2017
Jared’s spot-on takedown of Net Promoter Scores.
(Andy feels this is like criticising GDP, but GDP measures something that actually happened, whereas NPS, like horoscopes or tea-leaf readings, rely on clairvoyance.)
Monday, September 25th, 2017
A good analysis, but my takeaway was that the article could equally be called Why it’s tricky to measure Client-side Rendering performance. In a nutshell, just looking at metrics can be misleading.
Pre-classified metrics are a good signal for measuring performance. At the end of the day though, they may not properly reflect your site’s performance story. Profile each possibility and give it the eye test.
And it’s always worth bearing this in mind:
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.