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.