Pingdom Incorrectly Reports Page Load Time

| No TrackBacks
I recently discovered that Pingdom, in many instances, does not correctly report page-load time.  As it turns out, when you ask Pingdom to tell you how fast your site loads it will incorrectly download all images and other resources referenced in your CSS, regardless of whether they are actually used on your site or not.  Of course this isn't ideal, because Pingdom will claim the page you're testing takes longer to load than it really does!  By comparison, smart web-browsers do not blindly download every image referenced in the CSS, on every page.  Instead, they download the resources as needed.

For folks who really care about site optimization and performance, this is a big deal.  Especially if you're hired to help a client optimize the page-load time of their web-site, but services like Pingdom lie and report junk.

Here's an example; imagine this is your homepage:

<html>
<head>
<title>My Homepage</title>
<style type="text/css">
#header {
background: black url(/header.png) no-repeat top left;
}
#homepage {
background: white url(/homepage.png) no-repeat top left;
}
#aboutus {
background: white url(/about-us.png) no-repeat top left;
}
#contact {
background: white url(/contact.png) no-repeat top left;
}
#footer {
background: black url(/footer.png) no-repeat top left;
}
</style>
</head>
<body>
<div id="header">header</div>
<div id="homepage">content</div>
<div id="footer">footer</div>
</body>
</html>

Ok, so you've got a header and a footer that will appear on every page.  In addition, you've got a few other CSS selectors for the homepage, for your "about us" page, and for your "contact us" page.  In a real web-browser, when you visit this page the browser will load the following images as referenced in your CSS:

  • header.png
  • homepage.png
  • footer.png
However, when you test this same page using Pingdom, Pingdom will claim your site is loading the following resources:

  • header.png
  • homepage.png
  • about-us.png
  • contact.png
  • footer.png
Wait a second, that's not accurate at all!  On this hypothetical homepage, I'm definitely not using #aboutus or #contact anywhere, so why should the resources associated with these selectors be factored into my page load time?  In reality, they shouldn't be because that's not how real web-browsers work.

To further validate my findings, I used the Rackspace Cloud and allocated a new machine with a running web-server.  I loaded this hypothetical homepage HTML onto it, and asked Pingdom to tell me how fast it loads:

pingdom-lies-snap1.jpg

Wrong!  I'm not using aboutus.png or contactus.png anywhere on the homepage, so why should Pingdom factor the load time of those images into my test results?  In contrast, using Firefox and HttpFox, I verified that real web-browsers only load the resources they need to properly render the page:

pingdom-lies-browser-is-better.jpg

Here you can see the correct resources are loaded in Firefox: header.png, homepage.png, and footer.png.

Bottom line, you really shouldn't use Pingdom and other external performance analysis tools as "bibles" for improving your page-load time.  Clearly they're only tools to help you identify obvious problems, and are definitely not a complete solution.  For more accurate results, I would suggest using tools like YSlow and Google's Page Speed.

Cheers.

Did You Find this Helpful?

Did you find this post helpful, or at least, interesting?

  

About Mark

A Silicon Valley native, Mark Kolich is a full-time Software Engineer and a consultant for hire. A web technologies expert, his current focus is on building powerful and robust cloud-driven web-applications using Java, PHP, Perl, AJAX, DHTML, CSS, and JavaScript. His favorite programming languages are PHP, Java and JavaScript. He uses Linux, enjoys biking to work, loves building great software, and always writes elegant, readable, and maintainable code.

No TrackBacks

No trackbacks attached to this entry.

Twitter (@markkolich)

Translate

About this Entry

This page contains a single entry by Mark Kolich published on April 24, 2010 1:00 PM.

Understanding Java's CountDownLatch and CyclicBarrier was the previous entry in this blog.

HTTP Digest Access Authentication using MD5 and HttpClient 4 is the next entry in this blog.

Find recent content on the main index or look in the archives to find all content.