AirPods Pro Page Performance Permalink: AirPods Pro Page Performance
Yesterday I posted the below tweet and it received a lot of attention. It brought some good comments and positive exchange, which made me think about it more.
The new AirPods Pro page is a strong contender for this year’s web perf fail award:— Holger Bartel (@foobartel) October 29, 2019
- 1578 requests
- 65.4 MB transferred
- 67.1 MB resources
- Finish: 2.3 min
- DOMContentLoaded: 1.98 s
- Load: 2.65 shttps://t.co/b2VjF0Yqus
When I first opened the page and checked it out, I had the “Wow, that’s a lot of data and requests”-moment. Hence the tweet.
After some of the comments and further exchange, I have to say it really depends on how you look at it. The point of sending 1578 requests with 65Mb down the wire being a lot of data still stands, but there’s much more to it. (The site loads different amounts of data for different viewports, some more data on that below.)
The Issue of Limited Bandwidth
Let’s assume you’re in a situation where you only have limited access to data. There are many of these situations, whether on a plane, in airports, hotels or prepaid SIM cards in other countries. I’ve been in a few situations where I was running low on data, had to manage it meticulously, so it would last me until the time arriving in the airport or the rest of the day.
In one of these moments, you might remember you wanted to check out those new AirPods. You open the page and boom💥: ”We’re sorry, you’ve used up all your data!“—that otherwise could have lasted you the rest of the day… With this in mind, it‘s a web perf fail.
There’s been a few replies mentioning (image) optimisation. Many developers know how to optimise. Apple for sure knows, too ;)
(I did have a brief look into the source and I found some keys appended to image lists like
totalSize: 13501. There are also at least 3 different image sizes being served for different viewports.)
Most of the time, performance issues appear when companies don’t have the knowledge or aren’t set up to optimise their images and sites. Web content editors aren’t web performance experts.
Over the last few years hardly any of my clients has ever gotten excited about web performance or been impressed by speed alone. It’s super nice to have and people notice. The benefits though, always are the business opportunity. When you open this page, the first image you see is a Wow. The product looks great. It’s super detailed and sharp. You probably want to buy it. Now.
Optimising Business Opportunities
By now you probably bought the product. This is the moment when the investment and trade off compromise between design and web page performance has paid off. The design sells and that’s its purpose. The fact that is succeeds says that the design matters more than the size of the page.
It would be interesting to see what decisions went into the design process of this page. There must be quite some stakeholders and you cannot whip this thing out in a week. I assume there’s been many decisions made along the way and I’d be surprised if page weight and performance wasn’t one of the topics.
Kenneth replied to this tweet with:
Come on. Look at the experience and tell me you expected it to be 1kb?— Kenneth Auchenberg (@auchenberg) October 29, 2019
This is an interactive application, not a text document.
I agree with Kenneth 100%. Something doesn’t add up. If every experience was like this example, everyone’s expectation on page weight could be different. Yet most of the discussions about web performance are about different kinds of experiences which should be optimised to their required size. The required size for Apple’s AirPod experience is what it is. You can probably shave off a few megs here and there if you want to, but that doesn’t really matter much. I’d argue it’s less about how much in general, but how much is required to deliver your experience. For every site that gave me a wow-experience, I’d probably be much more forgiving. If you serve me ”colored boxes”, 5Mb of CSS and JS might not be required…
Not to forget, there’s a huge difference between an interactive application or presentation (I like how Kenneth called it) and a productivity app. What works for one, might not work for another.
Dare to Push and Dare to Challenge
I still believe that a page load of 65 Mb delivered to a desktop is a challenge. Someone made a call and was good with it. Fair enough if you think that‘s what it takes. Unfortunately from a user‘s point of view, there is no way to detect the data coming at you, up front. Should it be up to others to decide for us? Should there be a “warning”? Should it be a setting?
I also said ”you gotta have some guts to push this out“. I generally consider having guts a good thing. For sure there have been long discussions at Apple for this page to come to life and I’m glad to see the result. Besides the fact that it’s inspiring, it shows what can be done. It dares to explore. The exploration could end well or even fail, but if you don’t try, you will never know.
That said, I think it’s a fantastic page, well crafted and the longer you look at it, the more details you will spot. The shadows on the pods are fascinating.
The longer I work on the web, the more I think that we’re still, or always will be in an exploration phase. Maybe that‘s the reason work is still fun ;) The web is an ongoing evolution and likely will stay like that for the foreseeable future. Nothing lasts forever (at least pages like these won’t). We might as well push the boundaries and try to find out what is possible, leave the land of design-sameness and dare to challenge again, without loosing sight of the potential impact things might have.