The other day I was thinking about the many parallels between the early days of the web and the early days of performance:
|Web dev circa 1996||Web performance circa 2011|
|Developers leading the charge||Developers leading the charge|
|Designers starting to get interested||Designers starting to get interested|
|Websites barely on execs’ radar||Performance barely on execs’ radar|
|Formal user experience testing just on horizon||Formal user experience testing just on horizon|
We’re at a really interesting juncture. We’re about to enter a time of heavy transition, and while it’s a necessary transition, it’s not going to be easy for everyone. (Warning: There will be crabbiness.)
The early days: The rise of the developer
In the beginning (back when text was left-justified, all gifs were animated, and you could have a website in any colour you wanted, so long as the colour you wanted was grey), the developer was king. He or she was master of the web domain, keeper of the code. And that worked fine until…
Designers arrived on the scene
Whether they were print designers looking to make a career move or self-taught folks with a good eye, designers saw an opportunity and took an interest in the web. Not coincidentally, this happened at around the time that HTML got fancier. At the same time, business owners started taking an interest in this nutty internet fad.
And then the turf wars began
Sometimes the developer was also the designer, but more and more, these roles were split. These two factions tussled regularly over the right way to build sites. Business owners threw in their two cents as well. There were a lot of heated debates where the phrases “Our users want…” and “Our users need…” got bandied about pretty loosely. Interestingly, “user needs” generally coincided with the desire of the person who was making the argument.
Usability testing came along to set us all straight
While usability engineering had been an active practice in software development for years, it was new to the web. When it made the crossover, some devs and designers were all for it, while others were all against it (and some were really REALLY against it). The upshot, however, was that we all realized that usability was something that could be measured:
“Do I get more clicks when I put that menu here or over there?” “What happens to my conversion rate if I change the wording on the main call-to-action button?” “Which banner graphic gets the most click-throughs?”
Today: Performance seems to be following a similar evolution
Up till recently, developers have been almost solely driving performance. And “performance” has been defined as a pure speed play, hence our industry’s unofficial mantras: “Faster is better” and “Every second counts.”
But as I’ve written about recently, performance is a complex and nuanced challenge that demands an equally nuanced solution. Cranking out pages that seem to be faster according to simple tests is not the ultimate solution. Here’s why:
- 96% of your page traffic is part of a unique user flow through your site.
- Therefore, optimizing isolated pages, out of the context of their place in a user’s flow through your site, does not automatically improve performance.
- Sometimes the drive for speed has an impact on how a page looks and feels, which gets designers and marketers involved. Déjà vu.
- Similarly, loading objects in the wrong order could result in your visitors ignoring the most important content on the page.
- Applying generic optimization treatments across your site will get you 80% of the performance you want — but the last 20% is the performance you really need to differentiate yourself from your competitors and satisfy your visitors.
Everyone in our industry needs to be more than just a page speed advocate. We need to be user experience advocates.
I know I risk sounding like a broken record here, but saying “We sped up pages by 150%” isn’t enough any more. Those faster pages could be killing conversion in some unanticipated way. Just like usability engineers use usability tests to test sites in the real world, we need to run A/B and multivariate tests on real users. We need to test the impact of various optimization treatments on different pages and flows, and we need to focus on measuring metrics that matter: revenue, conversion, cart size, and page views.
And just like usability engineers trust real-world data over gut instinct when deciding if a website works or not, we need to rely on these metrics to make our decisions for us, not just our gut feeling that faster pages = better.