Case Study: How Symantec is showing its visitors the wrong content first

In my post on how to read waterfall charts, I touched on the importance of knowing how quickly a page starts to render, because this can have a powerful effect on a visitor’s perception of your site’s overall speed.

This is all true, but here’s where it gets a bit tricky. Yes, it’s important to know when a page starts to render and how long it takes to fully load. But this information isn’t enough. You also need to look at which elements are rendering first and make sure those are the elements you most want your users to see.

Sounds elementary, right? And yet time after time I see sites that make the same mistake: having their most important content load dead last.

Case study: Symantec

Take for example this case study provided by Jakob Nielsen. His team recently conducted an eyetracking study in which they monitored how people viewed a landing page on the Symantec website.

This graphic shows all the places a visitor’s eyes fell when viewing a page that they perceived as loading instantaneously:

Norton: Visitor eye gaze patterns for page that downloads instantly

Notice how the visitor’s gaze spends a significant amount of time on the yellow slideshow widget, the most critical content on the page.

Now compare that gaze pattern to this graphic, which shows all the places a visitor’s eyes fell on the same page when the slideshow widget took 8 seconds to load:

Norton: Visitor eye gaze patterns for page that loads in 8 seconds

Notice how the visitor looked at the empty yellow box a few times while waiting for something to appear, then gave up and spent the rest of their time looking at the rest of the page.

This slideshow widget was the most important piece of content on the entire page, and yet it was the last thing visitors saw. And even after the slideshow fully loaded, the visitor never even glanced at it.

As Jakob observes in his post:

The user who had to endure the download delay spent only 1% of her total viewing time within this space. In contrast, the user who in effect received instantaneous page rendering (because he didn’t look until it was done), spent 20% of his viewing time within the slideshow area.

Let’s look at this problem another way

I wanted to see if Symantec has addressed this usability problem yet, so I ran this page of their site through Webpagetest.* (Jakob’s test took place a while back, on a page that is no longer on the site, so I chose a landing page as similar as possible to the one he used.)

Here’s the waterfall of the results:

The page started to render in just over 4 seconds, and fully loaded in 7.3 seconds — an okay, if not awesome, performance. But let’s look a little bit closer, first in video:

It’s apparent that the featured content widget is still one of the last page elements to load. Now let’s slow it all down and take a frame-by-frame look at the video so that we can see exactly what loads when.

First up, we can see that page elements don’t start to appear until 4.5 seconds:

Webpagetest: Symantec at 4.5 seconds

Next, we see the yellow box that houses the promo widget appears at 5.6 seconds:

And finally, the promo content shows up at 7.1 seconds:

So what to do with this information?

Before reading about Jakob’s eyetracking study, it would be easy to ignore these seemingly tiny lag times. But armed with this information, and knowing that when it comes to web performance and conversion rates, every millisecond counts, it’s clear that this is a performance problem that needs to be fixed. That widget needs to be one of the first, not one of the last, elements to download.

Your tasks

  1. Identify which are the most important pages on your site.
  2. On those pages, prioritize the most important pieces of content.
  3. Analyze those pages using a third-party tool that lets you see the order in which the page elements load, and how long it takes for each of them to load.
  4. Using either a manual or automated solution, tweak your content so that it loads according to its priority.
  5. Repeat as pages change, as new pages are added, and as new browser versions are released.

*Test conducted on 07/28/10 at 11:05:19 from Dulles, VA. Simulated results on IE7 via DSL. See full test results here.

Related posts: