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.

There are three major JavaScript performance test suites, each of which were released by different browser vendors. Webkit released SunSpider, Mozilla released Dromaeo, and Google released the V8 benchmark. As is often the case with benchmark tests, they may not necessarily accurately determine what performs best in the actual situations that they try to simulate. These JavaScript benchmark tests may have their flaws, some of which are still being addressed. Despite the flaws that JavaScript benchmarks may have, they can give an indication of how some JavaScript engines can be better than others. In the Computerworld article previously mentioned here, the SunSpider test suite was used to test the performance of the JavaScript engines of different browsers.

After I wrote about Google Chrome in the last entry here, I wanted to more precisely determine how much better it is at JavaScript performance than other browsers are. I considered running a few benchmark tests on a few different browsers. However, that has already been done many times by others. One can view results of such tests in the Computerworld article to which I previously posted a link, and here. However, those tests were run before Firefox 3.5 was released, and JavaScript performance in Firefox 3.0 is not as good as it is in Firefox 3.5. In fact, according to what is on this page on Firefox performance, SunSpider tests indicate that JavaScript performance in Firefox 3.5 is twice as good as JavaScript performance in Firefox 3.0. I also wanted to run these tests myself. I ran the SunSpider benchmark tests using Firefox and Chrome, and found that the benchmark tests ran much faster in Chrome than they did in Firefox.

The SunSpider test suite is a comprehensive one that simulates situations that users will encounter when they browse the web, such as generation of tag clouds from JSON input. In running these tests, I ensured that I was using the latest versions of these web browsers. I also ensured that no other browser tabs were open when I ran these tests. I also created a new Firefox profile and used it to run the SunSpider tests on Firefox. I wanted to ensure that these test results would be as accurate as possible.

I found it interesting to see the mean times it took for the tests in the SunSpider suite to be completed. It was also interesting to see what the 95% confidence intervals were, which as some of those reading this may know, are used to determine with 95% certainty that true mean values are within those intervals. I viewed the source code on the SunSpider website to see how those values were calculated using a Student’s t-distribution, and was reminded of concepts that I learned about in a university statistics course. After running the tests three times with Google Chrome, the average time it took for the tests to be completed was 822.2 ms. I then ran the tests three times with Firefox, and the average time it took for the tests on Firefox to be completed was 1756.8 ms. Firefox took more than twice as long as Chrome to complete the suite of tests. One can verify this after viewing the results of the first, second, and third tests I ran with Chrome, and the results of the first, second, and third tests I ran with Firefox. One can also copy and paste URLs from one set of test results into a text box on a page that contains the other browser’s results to compare results.

As you may have seen if you have viewed the results of other JavaScript benchmark tests that have been posted on the web, they tend to list only the mean times it took to complete them. Confidence intervals are not mentioned in the Computerworld article that I previously mentioned. When one wants to see precisely how much faster one browser’s JavaScript engine is than another’s, one may want to take confidence intervals into account. However, in the tests that I ran, overall confidence intervals did not differ by a large percentage. The mean values and confidence intervals were similar for the three tests that were run on each browser. This gives a strong indication that Chrome’s JavaScript performance is significantly better than that of Firefox.

Google Chrome may outperform other browsers in JavaScript performance. However, Internet Explorer’s JavaScript performance is as good as Google Chrome’s when Google Chrome Frame is used with it. According to this other Computerworld article, when Internet Explorer is used with Chrome’s JavaScript engine, its JavaScript performance is, understandably, much better. Once again, Computerworld used the SunSpider test suite to determine these JavaScript performance differences. Google Chrome’s JavaScript engine’s performance may be better than the performance of other JavaScript engines. It also appears that it will continue to be better than other JavaScript engines. In this post on the Google Chrome blog it was said that JavaScript performance in its latest beta has increased by 30% since the last stable release of Google Chrome.

After I read about what makes Google Chrome faster than other browsers, I have found that a few points tend to be mentioned consistently. It is often said that its use of the Webkit open source web browser layout engine and the open source JavaScript engine known as V8 set it apart. What it is about Webkit and V8 that make Google Chrome faster and more efficient is mentioned in a number of different places. And these explanations appear in a number of different forms, such as this video in which Lars Bak, the head programmer of the V8 project, explains the concepts behind V8.

Some might consider the explanation in that video useful. Others, who do not have as much knowledge of the topics that Bak explains, would prefer explanations that they would be more likely to understand. I personally wanted a thorough and complete explanation of what makes Google Chrome as fast and efficient as it is. What I had not realized was that I needed to look no further than the page on Google that lists its features for the link to the information that I wanted to find. This information may have been there for a long time, although it seems to continue to be the best introductory guide to the technology that makes Google Chrome different.

It seemed to be appropriate that the best guide to Google Chrome’s features came from those employed at Google. The differences in its user interface, security handling, and performance are covered in it. In this post, I will only focus on Google Chrome’s speed and efficiency. I may cover the user interface and security design decisions in a different post about Google Chrome. If I do, I may once again refer to this comic.

There is a section on Webkit and V8 in that comic in which important concepts about V8 are explained well. Webkit, which is also used by Safari, is said to manage memory well. It is said that Google Chrome is designed for the world wide web of today rather than the one that existed when browsers were first written. That is the reason it was said to be important that its JavaScript engine be efficient, considering how often JavaScript is used in web applications. The concept of hidden classes is covered well, and it is covered in enough detail for its intended audience to understand the basics of it. Those who would like a more detailed explanation of this concept may see it explained in further detail here. Also, it is mentioned that JavaScript is compiled into machine code when V8 is used. As those familiar with advantages of compiled code over code that is interpreted as JavaScript typically is, this can lead to a significant performance increase. Also, as hidden classes are created, the machine code can refer to these hidden classes, which leads to better performance. In addition, V8’s method of garbage collection is very efficient, and it is explained how memory is managed much more efficiently than it is in other JavaScript engines.

The explanations in this comic seem to be aimed at an audience that has some knowledge of the concepts explained in it. I thought that those who want to know more about this technology would find it understandable and entertaining. Some might also understand jokes in it, such as the “speed limit” depicted on this panel as being 10¹⁰⁰, also known as a googol. Some might like this comic, some might not. For those who prefer to view a video that covers some of the same material, but in less depth, there is this video.

Some may find my recent praise for comics interesting. Some might also find it interesting that I am praising Google Chrome after writing much here about Firefox. I still use Firefox quite often, mostly because of its extensions. However, when I want to use a browser that is simple, fast, and efficient, I use Google Chrome.