Pressure to perform: A closer look at web performance metrics

Editor’s note: Keynote Systems’ Startup Shootout Index provides some insight into the three-screen challenge — desktop, smartphone, and tablet — now facing anyone with a web presence. We’ll be bringing you a fresh set of data from Keynote every month. Check out previous Startup Shootout results.

New technology allows us to take an even closer look at the impact of Web performance on the desktop user experience. Rather than simply measuring the time it takes for the entire page to load, new standards allow us to capture details about how long it takes for the visitor to see something change in the browser and how long before a visitor can begin to interact with a page. These are important points in the user experience, which mean that not all load times are equal. Let us explain.

For years, Web sites have used monitoring services that provide an external perspective of performance by measuring complete page load times. However, this doesn’t represent how well a user’s Web browser is actually assembling that content or how soon the user can begin to interact with the page. We also know there are many ways to assemble and display content on a site – some methods are better than others.

New industry standards supported by modern browsers like IE9, Chrome, and Firefox can reveal performance more holistically—based on users’ true experience during the page load. The browser itself now saves timestamps from various events in the process of loading a new page, including timestamps for the starting and ending of phases to help measure:

• The first point at which the user sees something other than a blank screen or the previous screen (“Time to First Paint”)

• When a page can be clicked, swiped and scrolled (“Time to Interactive Page”)

• The total time a page takes to load all assets on the page (“Total User Experience Time”)

As an example, imagine you visit two sites, each with a page load time of five seconds. If site A starts delivering content in half a second and site B doesn’t start giving you any content at all until four seconds, your perception of site A will be much more positive even though both sites have the same overall five second user experience time.

Rovio, where art thou?

On the Keynote Startup Shootout Index, digital entertainment media company Rovio has a woefully slow desktop response time of 7.75 seconds. Given its stature amongst the mobile device user community, it comes in with an also unimpressive 5.71 seconds on the iPhone and 6.59 seconds on the iPad.  Users have high expectations today; sites like Rovio should be aiming for two seconds end-to-end page load times for the desktop and no slower than six seconds end-to-end page load times on 3G mobile networks. Rovio’s desktop site could definitely be faster than it is. We were surprised at some missed opportunities and failures to follow best practices.

Time to Paint

In addition to slow end-to-end page load times, Rovio is also showing a very slow time to first paint. We are seeing over 63 elements loading before the browser is able to render any content on screen. This includes 15 JavaScript files, five CSS files plus four custom font files (few websites use custom fonts, in part because of the effect they have on performance, as the site might need to load fonts before its initial render).

Compression

Interestingly, Rovio is also not using gzip compression on all the elements that are compressible. All modern browsers support gzip compression, which shrinks file sizes for transfer over the network before decompressing them to use in the browser. If the Rovio site were to use gzip on all page assets, many files could be 60-70% smaller, again helping to speed performance. There really is no reason not to do this.

Image Bloat 

We see a number of images loading, such as YouTube video thumbnails that the Rovio site is displaying at a lower resolution in the browser.  The images are being downloaded at 480×360 pixels, but then displayed at 160×120 pixels. This means that the Rovio site is downloading images 9X larger than it needs, an inefficient use of network bandwidth and client-side processing time.

HTTP Persistent Connection

And lastly, Rovio is failing to take advantage of HTTP persistent connections (also known as HTTP keep-alive or HTTP connection reuse).  Without HTTP Keep Alive turned on at the web server, browsers are making and then tearing down dozens of unnecessary network connections to the server.  HTTP Keep Alive allows the same network connection to be re-used for multiple requests, and is much faster.

Conclusion

The three additional metrics for measuring web performance add a very useful nuance to being able to truthfully gauge how a user will perceive a page loading in the web browser.  It gives developers and site owners an additional dimension to improve and refine. Let’s hope Rovio takes some time to step up performance across these best practice areas.

To view the full range of Keynote Indices, please visit here.

Keynote tests the sites in the index hourly and around the clock from four locations over the three largest U.S. wireless networks, simulating visitors using three different devices. Data is collected from multiple locations and then aggregated to provide an overall monthly average in terms of both performance and availability.