Steve Souders is the current king of Web performance gurus. His mantra, which is sound and can be borne out by empirical evidence, is that 80% of performance issues occur between the Web server and the Web browser. He offers a fantastically detailed methodology for approaching these issues. But fixing the 80% of performance issues that occur on the front-end of a Web site doesn’t fix the 80% of the problems that occur in the company that created the Web site. Huh? Well, as Inigo Montoya would say, let me explain.
The front-end of a Web site is the final product of a process, (hopefully) shaped by a vision, developed by a company delivering a service or product. It’s the process, that 80% of Web site development that is not Web site development, that let a Web site with high response times and poor user experience get out the door in the first place.
Shouldn’t the main concern of any organization be to understand why the process for creating, managing, and measuring Web sites is such that after expending substantial effort and treasure to create a Web site, it has to be fixed because of performance issues detected only after the process is complete?
Souders’ 80% will fix the immediate problem, and the Web site will end up being measurably faster in a short period of time. The caveat to the technical fix is that unless you can step back and determine how a Web site that needed to be fixed was released in the first place, there is a strong likelihood that the old habits will appear again.
Yahoo! and Google are organizations that are fanatically focused on performance. So, in some respects, it’s understandable how someone (like Steve Souders) who comes out of a performance culture can see all issues as technical issues. I started out in a technical environment, and when I locked myself in that silo, every Web performance issue had a technical solution.
I’ve talked about culture and web performance before, but the message bears repeating. A web performance problem can be fixed with a technical solution. But patching the hole in the dike doesn’t stop you from eventually having to look at why the dike got a hole in the first place.
Solving performance Web problems starts with not tolerating them in the first place. Focusing on solving the technical 80% of Web performance leaves the other 80% of the problem, the culture and processes that originally created the performance issues, untouched.
2009-09-17 — 08:56
Got any feedback on Aptimize? When I was at Velocity there was a lot of buzz about it but would like to hear from someone using it.
2009-09-17 — 12:16
Having looked at the Aptimize Web site (I unfortunately was not able to attend Velocity this year), it seems to do many of the things in a single package that Steve Souders recommends sites do to improve measured performance.However, as the above post notes, Aptimize is simply another in a long line of tools designed to fix the technical problem of poor Web performance. If Web performance is being examined after a site has been released, the question of how the site got out the door in the first place becomes even more important.
2009-12-16 — 17:06
I agree with what you are saying, in that bad design is a cause of poor performance, but in my opinion the two you pit against each other are as important as each other. The key thing about performance optimization is that it's a practice of highly detailed painstaking analysis and refinement. What your actually complaining about is the lack of the same in the UX design process. Only if both are given the same level of detailed craftsmanship and forethought will you create a website that meets the standards you are talking about.The best analogy to use here is cars, if you put spoilers and bonnet vents on articulated lorry, it doesn't make much of a difference to performance, however, if you put them on a Nascar in the right places, it can make the all important difference…