The Importance of Frontend Performance

I've never "live-blogged" before, and in fact blogging is normally something that takes me forever as I treat the entries more like whitepapers than anything else. I think that comes from the "enterprise" culture and my age more than anything else. That being said, I'm sitting in a session by Steve Souders, who has been the chief performance Yahoo and is now at Google, and is the guy behind YSlow, etc., and it's quite interesting.

I'm blown away by the stats he has on various large sites, where he shows that 80-90% of the time is spent getting the content to and rendered on the client, with a relatively small amount of time spent on the server. This is interesting because many BEA products are very good at the server side, with all the various -ilities that we are famous and loved for. What we haven't done a ton of work on is the client, instead focusing on implementing the latest J2EE and industry standards. The WebLogic Portal team certainly cares about the client, but I can't say that we've gone nearly as far in that area as we could/should have.

A lot of what is being presented may seem obvious, and he's building on the types of things that YSlow, etc. focus on. The slide he's on as I type this is on JavaScript and how it is loaded, where a huge amount of time is spent just getting the code to the client (assuming an empty cache), and that's before it actually starts doing something. If you've followed my earlier blogs then you know that I've minified, combined, and so on the code on they wlp.bea.com playground, but even after all that there is still room for improvement.

My personal opinion is that I shouldn't have had to do this, it should just "work" when I'm using a WLS/WLP/etc. server. If as a developer I specify N JavaScript files, the server should be smart enough to package them all up, minify them, gzip them,etc. to do the right thing to make the client more efficient. As a client-side developer I shouldn't have to use tricks or otherwise fool around with trying to optimize it. Hey, we do a lot on the server to ensure that it works well, so why not on the client?

I sometimes get the impression that some folks don't think the client is important, and in fact they consider it "fluff" compared to the "hard stuff" on the back end. I firmly believe that plenty has been done on the back end, and in fact any further optimization is going to be minimal and won't necessarily add any measurable value. We've been in various horse races to show that the server is fast, and I'm sure that's important at some level, but if the client experience is slow and annoying, who really cares how fast the server is? There is an old saying that the customer is king, and the real end-game customer are the users of the sites, not the people using our products. If these end users aren't happy, our customers won't be happy.

And hey, if the client really is easy and fluffy, solving these problems ought to be a cinch for a bunch of hard core enterprise developers, right?