Over the last few months Google has continued to focus on performance as a key message to developers. From their “Let’s make the web faster” initiative on Google Code, to their public DNS service, to the constant focus on performance by their Chief Performance guru, Steve Souders, it’s clear that Google wants people to have a faster experience on the web.

This makes sense: the faster the web, the more people will use it and be more likely to search and click on ads. In fact, in an interview with Web Pro News in November last year, Matt Cutts (head of Google’s webspam team) casually mentioned that in 2010 Google may give search ranking preference to sites that load faster. Om Malik went on to discuss whether this was a good idea or not.

More recently, Google opened up a new “Labs” feature in their Google Webmaster Tools that actually shows you the performance of your site as measured by the Googlebot. This move is further evidence that Google is indeed going to shift to making performance part of it’s ranking routine if it hasn’t already. See a screenshot of what you can expect to see:

In addition to the above chart, there is also some basic analysis and recommendations on how to improve performance, similar to what Page Speed and YSlow recommend. While it is a good start and provides the clearest view of how Google perceives your site’s performance, the data is still rather basic.

As such, when measuring and optimizing page load times we’d still recommend you work with a more in-depth tool such as Page Speed and YSlow. And, of course, for website monitoring and website load testing, we’d have to recommend BrowserMob

Tweet This Post 

Firebug · Google · Google Public DNS · Page Speed · Performance · YSlow

Like many in the industry, we were surprised and intrigued by the announcement yesterday that Google would be entering the DNS business. The basic logic was clear: Google has a vested interest in the internet being fast, and so they want to offer a free public utility to help it be faster.

Of course, some were doubtful. OpenDNS, probably the company that has the most to lose by this decision, responded quickly. Some questioned its security, while others pointed out that Google gains a lot more than you might think by serving DNS: it would now know everywhere you were going, regardless of whether you went through Google Search or whether the site had Google Analytics installed.

While we’re not going to get in to the broader debate of whether this move is Good or Evil, we were curious if their service really offered significant performance benefits. So we extracted the DNS code from our BrowserMob website monitoring service (which itself is based on the fantastic xbill Java DNS library), and built a quick-n-dirty tool to measure exactly that.

The results

Here’s how it works: our tool queries the Alexa worldwide top 1000 sites. It does it against Google Public DNS, OpenDNS, and (optionally) the DNS servers of your choosing. Since we’re located in Portland, OR and have a Qwest internet connection, we used Qwest’s DNS servers in our test. The results surprised us:

Starting test...
 
Test 1: Google
85109 ms for 1000 records
Test 2: Google
67586 ms for 1000 records
Test 3: Google
67318 ms for 1000 records
Test 1: OpenDNS
92521 ms for 1000 records
Test 2: OpenDNS
45793 ms for 1000 records
Test 3: OpenDNS
47899 ms for 1000 records
Test 1: Your DNS
62541 ms for 1000 records
Test 2: Your DNS
25561 ms for 1000 records
Test 3: Your DNS
25879 ms for 1000 records

Taking the lowest time and dividing by 1000 tells us the average DNS lookup times from our location in Portland, OR:

• Google – 67.3 ms
• OpenDNS – 45.8 ms
• Qwest DNS – 25.6 ms

What this told us was that despite all the hoopla about performance, our trusty old DNS server we’ve always been using is still the fastest. And when you think about it, it shouldn’t be a surprise: there are fewer hops from the computer to the DNS server because it’s the same ISP.

We were very surprised, however, to see how much faster OpenDNS was compared to Google. While both are slower than your local ISP’s, OpenDNS promises a bunch of features which might help make up for the performance difference. While Google isn’t promising any features right now, they are, as always, pledging to not be evil. Considering that some ISPs have in the past redirect DNS lookups to serve their commercial interests, Google’s pledge is worth noting.

Running your own test

These results were from a Qwest DSL connection in Portland, OR. We’re curious what your results are, so we’ve made the test available for everyone. It requires Java and can be run like so:

java -jar browsermob-dns-perf.jar

If you wish to test your ISP’s DNS, just add to the command line one or more IPs:

java -jar browsermob-dns-perf.jar 123.456.789.012

We hope that you will comment on this blog with the results you get. We’re very curious to see what the worldwide performance results are.

A note about the test

DNS is somewhat hard to test for performance, since there are many moving pieces. The results can depend on whether the server has a cached entry, how far you are from the DNS server, how far the DNS server is from the other servers, etc. This is why we run the test three times for each service an why we think the right approach here is to take the best score.

However, we do understand one could easily argue that the first result is much more critical. We sort of agree, but the problem is that because these are public services you can’t tell how “fresh” the cache is on the servers you are testing against.

In fact, we should note that Google’s FAQ argues that cache misses are big performance issue and the main benefit they bring to the table. Unfortunately, this is extremely difficult, if not impossible, for us to independently test. As such, we decided that the most consistent and useful result would be the faster time for each service, even if that means it was faster due to 100% cache hits.

Tweet This Post 

DNS · Google Public DNS · OpenDNS