TechCrunch: The slowest tech blog, or one of the fastest? Turns out, it’s both.

When I started writing this post, my intent was to do a bit of performance benchmarking for leading tech blogs. But what started off as a standard benchmarking exercise turned into a great opportunity to talk about another approach to understanding your performance numbers in a meaningful way, and why it’s important to look at your site from as many angles as possible.

Shortly after TechCrunch announced its acquisition by AOL yesterday, some folks in the performance community were quick to suggest that one of AOL’s first jobs should be to improve the site’s performance. People cited that the main page that takes more than 20 seconds to load, making TechCrunch a desperate candidate for performance tuning.

But TechCrunch isn’t the only tech blog out there that readers complain about. So I decided to run some page tests to see how they measure up.

Time to interact (aka “load time”)

When you do a test via Webpagetest, this is called “load time”. Up till recently I’ve been using this term, too, but lately I’ve started calling this “time to interact”. It refers to the amount of time before the document is complete and fully interactive. Whatever you call it, this is the number most people pay attention to.

Website Time to interact (first view)*
TechCrunch 30.168
GigaOM 19.556
LA Times: Technology Blog 19.448
Mashable 17.868
New York Times: Bits Blog 15.297
Technology Review 14.973
Average 19.551 seconds

This is one of the worst industry benchmarks I’ve ever encountered. In fact, it’s suspiciously bad. There’s no way sites this slow could have such dedicated readerships.

I wanted to take another view, so I used Webpagetest’s video function to create a set of side-by-side videos to show how these sites load in real time (I’ve slowed it down so you can appreciate it in all its incremental glory):

This video reveals a couple of perspectives that you would miss if you just focused on load time…

Time to fully load: Interesting but not necessarily important

This is the amount of time it takes for every page element to load.

Website Time to interact Time to fully load
TechCrunch 30.168 29.5
GigaOM 19.556 21.9
LA Times: Technology Blog 19.448 26.8
Mashable 17.868 39.6
New York Times: Bits Blog 15.297 29.1
Technology Review 14.973 17.2
Averages 19.551 27.35

These numbers aren’t a huge surprise, given that the number of calls to the server for these sites ranges between 129 (Technology Review) and 323 (TechCrunch).

Before I started this entire exercise, I made a blindfolded guess about the performance culprits for most of these sites: ads and other bits of third-party gak. But as I’ve discussed elsewhere, a decently optimized page can sort and prioritize third-party content so that visitors are served meaningful content first. So let’s add those numbers to our table…

Time to start drawing: Very important

I define “time to start drawing” as the amount of time it takes for meaningful content to appear on the screen. Let’s take a look:

Website Time to interact Time to fully load Time to start drawing
TechCrunch 30.168 29.5 5.8
GigaOM 19.556 21.9 6.4
LA Times: Technology Blog 19.448 26.8 6.1
Mashable 17.868 39.6 6.5
New York Times: Bits Blog 15.297 29.1 7.2
Technology Review 14.973 17.2 5.1
Averages 19.551 27.35 6.18

Now, I’m not saying that an average time of 6.18 seconds is good. There’s clearly room for improvement here. But it’s not outright terrible, and it’s lower than the Fortune 500 benchmark of around 7 seconds.

And check it out: at 5.8 seconds, TechCrunch is actually the second-fastest site surveyed, not the worst, as the initial page test results indicated.

This exercise serves as a reminder of three things:

  1. The danger of focusing on just one piece of performance data
  2. The value of benchmarking your site against your competitors (though I’m still a staunch proponent of the audacious goal)
  3. And most important: always making sure you look at your site from your visitors’ perspective

Edited 9/30/10 to add: I just realized that I accidentally published the wrong numbers in the “time to interact” columns. I had originally tested the sites on both IE7 and IE8, but decided in the end to focus on the results for IE7. However, I mistakenly entered the IE8 numbers in the “time to interact” column. Duly corrected now, with my apologies for any confusion. Note that the updated numbers still corroborate the thesis behind this post.

*All tests conducted on Webpagetest — IE7 on DSL via the server in Dulles, VA.

Related posts:

18 thoughts on “TechCrunch: The slowest tech blog, or one of the fastest? Turns out, it’s both.

  1. Great Analysis. But something is missing here is the why it’s slow. You need to mention that techcrunch has over 300 objects on their pages. web sites should also worry about what content goes in. The fact that the site took 30 seconds just shows how no one is responsible for making sure you do not put something that will make the user experience horrible.

  2. Nice analysis Joshua.

    I’d like to add this, in line with #3 of your ‘reminder of three things’: always analyze what’s actually happening in the browser between Time to Start Drawing and Time to Interact. The 2 main questions are:

    a) Does something useful appear shortly after Time to Start Drawing? A subtle gray background image does not qualify as useful, the title and first paragraph of a blog post does.

    b) Can the user interact with the page (scroll, click) or is the UI basically frozen until Time to Interact (because of JavaScript execution)? Watching a page load without being able to *do* something is frustrating, especially if the load time is high.

  3. You forgot Engadget – AOL’s existing Tech blog (since the hope was that AOL would make Tech Crunch faster it seems particularly appropriate).

    300 requests, 1.8MB, 20 second load time with 10 seconds before useful content is visible.

    It’s an interesting starting point – expect to see that get better but it’s also a reflection of how most of the long-format blog pages are presented (and don’t get me started about the evil that is Facebook’s like buttons if you need to put them on each article). You have to be a lot more creative about how you present content to the users when you’re throwing that many pictures and widgets at them. It’s very doable but it doesn’t happen on it’s own – it takes quite a bit of work to get there (at least when you’re doing it by hand).

  4. What I can’t understand is why you use the repeat view document complete time as the time for “Time to start drawing” rather than start render time.

    There are a whole load of things that happen on a page that are not necessary for a user to initially appreciate the content often such as many images, avatars etc.

    Start render time for Techcrunch is pretty fast

  5. Pingback: Cloudflare – Potentially Mindblowing e-Commerce CDN Solution | My Blog

  6. TechCrunch is slow? My first 35 seconds of Twitter experience were…dull?

    bit.ly/drv8vu (screenshot)

    It’s great to use cloud services, but its even better to obtain services that have decent response times. Not like tens of seconds.

  7. Pingback: Clutch Time – A New Web Performance Metric? Application Performance, Scalability and Architecture – The dynaTrace Blog

  8. Pingback: Three kinds of page test visuals, and the best ways to use them — Web Performance Today

  9. Pingback: Why test with Internet Explorer 7? — Web Performance Today

  10. Pingback: MarketingNode.com | Blog | Cloudflare – Potentially Mindblowing e-Commerce CDN Solution

  11. Pingback: Setting up your own page test systems? Beware of your CPU and memory limitations. — Web Performance Today

  12. Pingback: 9 cool performance links (plus one) — Web Performance Today

  13. Pingback: Gawker readers are leaving in droves. Is slow performance partly to blame? — Web Performance Today

  14. It’s an interesting starting point – expect to see that get better but it’s also a reflection of how most of the long-format blog pages are presented (and don’t get me started about the evil

  15. Pingback: Do you really need that widget? — Web Performance Today

  16. Pingback: Fourth-party calls: What you don’t know can hurt your site… and your visitors — Web Performance Today

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>