Web Optimization is a Journey, not a Destination

No one likes slow websites or websites that malfunction. Today, time is very valuable – and no user wants to be frustrated trying to access a website. We all have better things to do than wait for a webpage to load or keep hitting the reload button on the browser in hopes the problem will disappear.

We talked previously in this blog about how slow performance is the new downtime, and is a “Brand Killer”. We are not alone in recognizing the performance problem; in the last few years there have been a series of companies and individuals recognizing the effect of slow performance and are they making efforts to speed up websites, and the web overall. Today gurus like Steve Souders are evangelizing about the need for faster websites and teaching us how to achieve them; there are meetups around US and the world – bringing together developers and operators in the pursuit of faster websites – and most importantly there are some amazing tools like WebPageTest, Firebug and HTTPWatch that let companies look at their performance and give FREE advice on how to optimize websites. At Catchpoint, we applaud all these efforts by the community and we are contributing to them by sponsoring meetups, contests, and tools. We are planning to offer even more in the future, stay tuned!

However, we are still concerned with two things. First, we come across some people who think making their site faster is a onetime optimization job. Let’s make it faster today, and move on to the next feature! While this strategy might have worked with traditional software, it is not going to work on the web.

Unlike traditional standalone software, a website or web application relies on multiple servers to work properly. If any of the servers has a performance or availability issue, the entire site or application could be impacted. Failures happen to everyone; no one has 100% availability! Bugs happen, bad code is written and makes it to productions systems! So while speed optimization is necessary for every site or application, it is very important to monitor performance correctly 24×7 and have action plans on what to do when something fails. Web Optimization and Web Monitoring go hand in hand, and you cannot skip on one of them.

Secondly and most important of all – have an open mind about what feedback other people provide you regarding your performance. Just because you think you have the fastest website, use the best monitoring system to monitor everything, are on multiple clouds, and have action plans for all possible scenarios – does not mean you got it right! You don’t have to follow what people tell or preach, but you can at least listen (responding with a one line email does not count).

I want to share a personal experience I recently had with a very popular “flash sale” site backed by millions of dollars in VC money. As I was browsing the website viewing their latest offers I noticed that their entire site was “quite slow” from my cable connection at home. Luckily at Catchpoint we had been monitoring the Internet Retailer 500 sites and so I pulled the data collected to see what was going on. I quickly realized that the site had a Wait of over 1 seconds (waiting for the server to process and send the response) pushing the Render Start and Page Complete by more than a second. The data also showed that the problem was introduced recently, and did not exist previously.

As any good netizen, I reached out to the company and informed them of the issue providing details on when it happened and included data from other free tools.

HttpWatch

ByteCheck

A day later I received a reply from one of their execs which knocked me off the chair. It went along the following line: “We recently launched an optimized version of our site and our JavaScript real user monitoring solution (RUM) shows we are doing great! What you sent is not an issue!”. Well it was an issue, and it is still an ongoing issue for them.

Obviously their RUM solution was incapable of telling them how slow the homepage was (no JS RUM solution can until Web Timing API is implemented by major browsers).

I know this, because we have Glimpse, Catchpoint’s RUM solution and we know very well its strengths and weaknesses. But that’s not the point, the point is that someone went the extra mile to look at the problem and send them some valuable feedback on the site being slow, backed up by facts that they could have confirmed in a minute utilizing a free tool like WebPageTest or firebug, or paid tool like HTTPwatch. Yet, they choose to dismiss it because they thought they were the best! This sort of attitude is prone to failure!

Let me close this post by quoting Fred Wilson , Fred is Partner at Union Square Ventures (no relationship with Catchpoint) when he said :

“First and foremost, we believe that speed is more than a feature. Speed is the most important feature. If your application is slow, people won’t use it. I see this more with mainstream users than I do with power users. I think that power users sometimes have a bit of sympathetic eye to the challenges of building really fast web apps, and maybe they’re willing to live with it, but when I look at my wife and kids, they’re my mainstream view of the world. If something is slow, they’re just gone. We think that the application has to be fast, and if it’s not, you can see what happens. There is real empirical evidence that substantiates the fact that speed is more than a feature. It’s a requirement…”

Mehdi – Catchpoint