Putting yourself in the user’s shoes

No matter how cool your website experience is, no one wants to wait for excessive loading times.

Therefore, it’s rather disappointing that among the many things that take place after a project is launched (i.e. behavioral tracking, site analytics, usability studies, and regular maintenance), one that is often neglected is performance monitoring.  At AgencyNet, we perform this service as a standard and best practice for projects during and after development.

To illustrate this process, this post is a case study for a sample project and how we optimized the experience based on the performance reports. Keep in mind, that there are many ways to skin a cat and I am certain that we could have taken any number of approaches to improve the operation of the site.  However, the purpose of this particular case study is to illustrate the importance of performance reports rather than provide step by step instructions on what to do or implement.

That said, let’s jump right to it:

Why is performance monitoring important?

Have you ever wondered what type of experience a user is getting when visiting your recently launched project? We, as web developers, tend to have top of the line internet connections which allow us to surf and view content at blazing speeds. However, as stats show, not everyone is as fortunate as we are.  Given the importance of the dreaded “bounce rate” statistic, it is critical to have insight on how quickly users can access your content.

Sure, we could test this out with a separate slower DSL line or download-speed limiter tools, but, for a global and more inclusive report, there is nothing better then taking advantage of a monitoring service to do the reporting for us.

There are many different providers that offer this service such as Gomez, Keynote, and AlertSite. We feel that given their feature set and price, AlertSite’s offering is the best suited for our performance-monitoring needs. Without going too much off topic, AlertSite has some nifty site monitoring tools, which can send alerts when a website is down or even if a certain asset has been changed, thus allowing you and/or your team to react accordingly to such events.

Project Case Study

Our project was global in nature.  We had to build a platform capable of reaching all of the client’s global markets, no small task given that they operate across five continents. The site itself is a primarily Flash portal powered by ASP.net and MS SQL databases.

Although the server environment is hosted within the United States, it takes advantage of a global content delivery network. Even before we began performance monitoring, it was clear that the site would require a CDN in order to reach users across the globe, thus we implemented a CDN service that delivers the site through their nodes located in strategic locations around the globe.

Due to this global complexity, we set up AlertSite to monitor the site from six different locations around the world in key markets. AlertSite measures the site from all these locations with real browsers and computers connected to average speeds and record the findings into their database.

What did the reports reveal?

  1. The site loaded in 8.3 seconds in mature markets. Considering it is a Flash-Video heavy initial homepage load we thought that this was pretty reasonable but knew we could do better.

  2. From emerging markets, however, the loading times were more than double, for sure a red flag that needed to get fixed.

  3. Lastly, and probably the most valuable revelation, the idea of “loading time perception”.  Numbers don’t lie; even at a site loading in 8.3 seconds, users reported it as “slow”.  This is when we realized that the way loaders were set up factored into the perceived loading time of the site.

How did we react?

Now that we were armed with information we could sit down and analyze the site at a microscopic level and come up with solutions to our three major findings.

  1. We took note of each object that was loaded on the site and saw that many requests were being made to web services that served data back to the site. This is not necessarily a bad thing, however if you take the following facts into consideration you will quickly realize how we could enhance and cut loading times on those data objects:  Although each web service call was being cached, the request still needed to be fulfilled by the origin server. In other words, it was not taking advantage of the content delivery network. The Flash file would be served from the nearest node to the user, however the data still came from the origin server in the eastern part of the United States.


    AlertSite Load Report

    To amend this, we combed the site and instead of providing information to the site via real-time web services we changed the method to XML files. Additionally, these XML files were compressed, cutting down loading time even more. However, where the real beauty of this solution comes in though, is that because these XML files were physical XML files on the server, they were replicated to all the nodes of the CDN. Suddenly, data was also being provided from the CDN, thus serving it to the user much quicker.

    Of course, we could not blanket the entire site with this method, as we still needed to rely on real-time web services when real-time data is needed such as a login or registration response. These types of data requests can’t be hard-coded into physical XML files.

    We also compressed JS files and optimized our JPGS and other assets a little better.  Little by little things started to add up.  In the end, we shaved a full second off the site load time, the site now loaded in 7.2 seconds rather than 8.3. Although a 1.1 second different may seem small, to a user one second could mean the difference between sticking around the site and leaving it.

  2. To fix the loading times in the emerging markets, we realized we needed a much more drastic solution than just optimizing web service calls and assets. It was clear that our CDN was not reaching and delivering content there at the speed that we had hoped for. We recommended that a local CDN needed to be contracted. We specifically focused on China, knowing that their infrastructure has inherent challenges. Once a local CDN was in place loading times immediately improved from that region of the world.

  3. To tackle the last problem of loading time perception, we changed the sequence in which loaders are shown and types of loaders. We realized that giving users something interesting to look at and providing ways to keep them occupied while they wait, helps with the impression that the site loads faster. Of course, the actual loading time is the same, but the new loader arrangement makes the user feel that it loaded quicker. And ultimately, that’s what’s most important.

In the end

As mentioned earlier in the article, not all of what I explained may be applicable to your project (global audience, CDN, web services, etc), however it is my hope is that this post helps you remember to put yourself in the user’s shoes and helps to spark some ideas on tackling some of those challenges related to site loading times.