One of Google Chrome’s biggest selling-points is its speed, and it happens to be the main one that caused me to jump ship from Firefox a couple of years ago. Since then, however, I’ve found Chrome to go down the same road that Firefox did – fast at first, not after a while. That, along with a couple of other issues, placed me in a spot where I simply didn’t care for any browser. I only continue to use Chrome because it’s familiar, and I rely quite heavily on Sync.
Nonetheless, Alex Hastings of Aptiverse has published a blog post that discusses the reasons why Chrome can be slow – and slower than other browsers. The first aspect tackled has to do with the cache. Unlike most browsers, Chrome doesn’t set a limit on the size of your cache, which leads to a built-up and slow cache over the course of a couple of weeks, or months depending on your surfing habits.
Most browsers start off fast with an empty cache, but begin to slow down ever-so-slightly over time. However, while a browser like Firefox settles-down and remains consistent for the rest of its life, Chrome just gets worse, as the chart above shows.
Next, there are issues with the WebKit engine, which Chrome uses. This might come as a surprise given WebKit’s attention to performance, but as you can see in the next chart, Chrome tends to suffer the most with recursion overhead when visiting some of the Web’s most-popular sites. This recursion is due to look-ups that are constantly going on in the background as a direct result of the “efficiently”-written code. Imagine having a shelf large enough for just one can of food, which can be filled by finding the right can in the background, versus having a much larger shelf that already has a bunch of cans on it.
Further performance analysis is conducted with regards to Chrome’s process isolation, and once again, DOM and post request timings are all over the place, whereas with Firefox, they kept level across-the-board.
Obviously, the goal of this blog post is to show off some of the major problems Chrome exhibits, although it’s not clear if the latter two problems are directly-related to WebKit or not. Another WebKit-based browser used for comparison would have been nice, but regardless, this does show that some work can be done on the Chrome side.