To follow up on the previous entry that I wrote here, I considered writing about DNS prefetching in the Google Chrome web browser. After writing about Chrome’s JavaScript performance, I thought it might be appropriate to mention that web pages may appear more quickly in Chrome when DNS prefetching is enabled in it. It was claimed in this blog post that when domains are first visited in Chrome, 250 ms are saved on average when DNS prefetching is used. I thought that DNS prefetching in Chrome was a topic that I should cover, even though that topic had already been discussed elsewhere when Chrome was first released over a year ago. However, it was recently announced that Google was going beyond work on a browser to make web pages appear in browsers more quickly. In this entry, I will also write about the protocol called SPDY that Google has created to address HTTP’s inefficiencies.
When considering ways to make web pages appear more quickly in browsers, one needs to consider everything that occurs when a user visits a web page. It might seem to be a good idea to retrieve the IP addresses associated with the domains to which users may navigate next in advance. When this is done, then the time it takes for web pages to appear should decrease. One can see how much faster pages appear when DNS prefetching is used in Chrome after entering “about:dns” into the address bar in Chrome. After viewing that page, one will be able to see which hostnames had benefits produced as a result of this prefetching. I found this information quite interesting. So I used the packet sniffer named Wireshark to view network traffic with DNS prefetching off, and then I viewed network traffic with it on. There are many pages with many links on them that one can view with DNS prefetching off and then with it on. I personally experimented with viewing Slashdot with this off, and found it interesting to see how much more DNS traffic there was when I refreshed the page with it on.
In theory, and according to tests run by Google, DNS prefetching leads to more efficient web browsing. However, when viewing DNS traffic using a sniffer such as Wireshark, one can get an idea how this can have the opposite effect on web browsing. When there are many links on a page, the majority of them may not ever be clicked by users who view these pages. In fact, it is said in this blog entry that DNS prefetching can lead to the browser spending much time resolving hostnames. It is also said in that entry that incorrect implementation of DNS caching or prefetching or other related errors can lead to web pages not appearing at all. It is suggested there that DNS prefetching be disabled, although I would like to note that I have never encountered issues such as these in the time that I have used Chrome. It should be mentioned that disabling of DNS prefetching tends to be considered a good idea when Chrome seems to be running slowly. When one searches for information on DNS prefetching on the help forum for Chrome, one will see that disabling of DNS prefetching is a common suggestion there. Although some may have found that browser speed issues are worse when this prefetching is disabled, the goal of reduced perceived latency when DNS prefetching is used might not have been attained by Google.
Of course, ideas that may seem good in theory may not always be good in practice. DNS prefetching can be considered an example of such an idea. One must appreciate the efforts that Google is making to improve the web browsing experience for users. There most certainly is room for improvement in the way that the web works, and Google has recognized this. Some of this room for improvement came as a result of the nature of the web changing, and so Google is trying to keep up with changing times. This is what led them to try to improve on HTTP.
When HTTP was first designed, it was made for a web that consisted of single pages, and one in which fewer files were sent from a server to a client. Now that many files are sent to users when they load web pages, this would not suffice. HTTP 1.1 supports sending several requests before replies arrive, in what is known as pipelining. However, pipelining may not be very advantageous, as HTTP 1.1 requires that replies to requests be returned in order. The server must spend extra time processing incoming packets to determine the order in which packets must be sent. Some might also see how sending several requests at once and requiring the server to process them can lead to denial-of-service attacks. This is all explained well in this blog post.
SPDY addresses issues that HTTP has in a number of ways. In addition to its ability to send several requests over one TCP connection, requests are prioritized. The client prioritizing requests leads to what is more important being sent to the browser first. Also, headers are compressed, which is appropriate as much redundant header data tends to be sent back and forth when HTTP is used. It is interesting to note that all SPDY traffic is encrypted. It was claimed that page load times were reduced by up to 64% when SPDY was tested. However, SPDY may have its drawbacks. As it says in this article on SPDY, the amount of processing done in compression and encryption could lead to servers having to be upgraded. This article describes changes that would need to be made on the server side in greater detail.
Google also recently announced the launch of a public DNS resolver called “Google Public DNS” in another attempt to improve the web browsing experience for users. Google’s attempts at making web browsing more efficient may not work as well in practice as they do in theory. Nevertheless, one has to appreciate their efforts in updating the way in which browsers and protocols work to improve the efficiency of web browsing.
2 Comments