April 2010 Archives

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.
countdownlatch-demo-screenshot.pngWhile working on some nifty multi-threaded Java recently, a colleague pointed me to a few really useful Java classes: CountDownLatch and CyclicBarrier.  My code was quite typical, a parent worker thread spawns a bunch of children to do real work, and needs to wait for the children to finish before continuing.  The catch though, is that the child worker threads may or may not finish successfully, and in all likelihood will finish at different times.  Even so, the parent thread must wait until all of its children have finished because the parent can only make forward progress once the children are complete.  I whipped up a little demo (screen shot left) that spawns five worker threads which update a JProgressBar at a random interval.  The demo finishes once each progress bar hits 100%.
Subversion is fun.  Especially when it tries to commit intermediate build files and other junk you want to keep out of your SVN repository.  In my environment, Ant is configured to place intermediate build files into my build/ directory.  The final product is then packaged up and placed into my dist/ directory.  So, I need SVN to ignore everything inside of my build/ directory since the contents of this folder are going to change on every build.

Meet svn propedit svn:ignore ...

#/> svn propedit svn:ignore build
#/> svn -m "ignoring build" commit build

When you run svn propedit, your local text editor will open (usually vi) which will allow you to specify a series of file names to ignore under build/.  If you want to ignore all files and folders, just enter a single * wildcard character, save, and commit:

*

Or, maybe you want to ignore just .class files:

*.class

Of course, if you want to use another editor like emacs to set your ignore properties, you can do so by exporting SVN_EDITOR before running svn propedit:

#/> export SVN_EDITOR=emacs

Enjoy!

Twitter (@markkolich)

Translate

About this Archive

This page is an archive of entries from April 2010 listed from newest to oldest.

March 2010 is the previous archive.

May 2010 is the next archive.

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