{"id":5931,"date":"2018-02-23T16:15:42","date_gmt":"2018-02-23T20:15:42","guid":{"rendered":"https:\/\/www.webperformance.com\/load-testing-tools\/blog\/?p=5931"},"modified":"2018-09-13T11:25:06","modified_gmt":"2018-09-13T15:25:06","slug":"what-is-the-fastest-web-browser-in-2018","status":"publish","type":"post","link":"https:\/\/www.webperformance.com\/load-testing-tools\/blog\/2018\/02\/what-is-the-fastest-web-browser-in-2018\/","title":{"rendered":"What is the Fastest Web Browser in 2018?"},"content":{"rendered":"

The browser wars have come a long way since the 90s, as each jockeyed for the most market share using performance as the main draw. Browsers were first viewed as an opportunity to lock customers into a particular platform, attempting to create walled gardens where customers would be unable to view content not optimized for that particular browser. \u00a0They simply took the desktop OS strategy and applied it to browsers. \u00a0But thanks to consumer demands for websites that work everywhere, browsers have finally embraced standards and interoperability, creating an environment where almost all browsers work on the vast majority of websites.<\/p>\n

\n \n
\n

Web Performance Consulting<\/h2>\n
\n
\n Our experts find out how many users your website<\/strong> can handle!
\n <\/span>
\n  
\n Learn More<\/a>\n <\/div>\n<\/p><\/div>\n<\/p><\/div>\n

Even though interoperability has been conquered, browsers still want to compete on performance, so picking the fastest one is a reasonable question. \u00a0But what does browser performance mean in a world in which many people now have 1 Gb\/s network connections in their home, and a 4G LTE phone connection can go up to 173Mb\/s?<\/p>\n

Theoretical Minimum Page Load Times<\/h2>\n

Web page load times are tricky to measure, as modern browsers can pull resources on dozens of threads from hundreds of website simultaneously. \u00a0You can get wildly different experiences on the same website simply because of the seeming randomness of instantaneous bandwidth and front and back-end resource utilization. Performance is essentially a look at how time is spent, so what is<\/em> the browser doing while you’re waiting for a web page to load? \u00a0Its making socket connections, transferring data to and from the servers, rendering your GUI, and running javascript, among other things. \u00a0Below is a visualization showing three different categories where browsers spend their time during a page load: network data transfer, layout and rendering, and javascript:<\/p>\n

\"\"<\/a><\/p>\n

Assuming that all browsers are infinitely powerful and take zero seconds to render and execute javascript, how fast could web pages load? \u00a0Let’s look at modern news sites, to pick a random example. Most are around 6 megabytes in size. \u00a0The chart below shows their theoretical maximum load times based solely on some average “high speed” home internet connection speeds.<\/p>\n

\"\"<\/a><\/p>\n

Given the popularity of high speed internet these days, its safe to say that in a perfect world most people would be experiencing sub-two-second page load times. \u00a0With the rollout of 500Mb\/s and faster internet connections web page load times of sub half-second are possible. \u00a0While network speed used to be an insurmountable problem in web performance, its fairly easy for content providers to work around network limitations. \u00a0That isn’t to say there aren’t websites with network-related performance problems, as we still see content providers with enormous web pages wondering why the site is slow when viewed on a phone, only that its a fairly easy problem to avoid.<\/p>\n

The bottom line is, for most applications networks are no longer the bottleneck.<\/p>\n

What About HTTP 2.0?<\/h2>\n

Now that the network has practically been eliminated as a problem, the next hurdle is the limitations of the HTTP protocol, which defines the communication between the browser and web servers. \u00a0HTTP 1.0 was quickly followed by 1.1, but it took many years for 2.0 to be defined and adopted in all major browsers. \u00a0Unfortunately the comparison isn’t straightforward, since all 2.0 traffic is secured via SSL, which causes higher back-end loads to compress the data, and higher overhead on the browser side to decompress the data. On the plus side, theoretically HTTP 2 should lessen server overhead at heavy load by being able to transfer more data over fewer socket connections.<\/p>\n

While most browsers support HTTP 2, many websites do not, so its overall effect on web performance at large is still limited. \u00a0There are many HTTP 2 checkers<\/a> out there if you’re curious about your favorite websites. Here’s just a random sample of the sites I often visit.<\/p>\n

\"\"<\/a><\/p>\n

What effect can you expect to see with HTTP 2 on your website? \u00a0Dareboost.com<\/a> has a nifty comparison feature, that will connect to a page with both HTTP 1.1 and 2 and compare the performance. \u00a0Most other sites have some content in HTTP 2, but usually only the CDN hosted images and other static content. \u00a0Checking average performance metrics for the popular site http:\/\/reddit.com, which has 57% of its resources being served by HTTP 2, \u00a0HTTP 2 is consistently slower than HTTP 1.1.<\/p>\n

reddit.com HTTP 1.1 vs 2<\/h4>\n

\"\"<\/a><\/p>\n

YouTube, on the other hand, is completely HTTP 2 compliant. \u00a0While the full load of the page shows no improvement with HTTP 2, loading just the visual part of the page was around 25% faster. \u00a0 Whether or not a particular website shows an improvement with HTTP 2 depends on its design. \u00a0Although HTTP 2.0 shows some promise in reducing server load, and thus making it easier to support more concurrent users per web server, it has not resulted in a dramatic increase in end user browser performance.\"\"<\/a><\/p>\n

Measuring Browser Performance<\/h2>\n

There are lots of different benchmarks for browser performance<\/a>, and each one measures a specific narrow aspect of performance. \u00a0The problem with using benchmarks is they are designed to be able to measure something so specific, for example, javascript sorts, that they are not directly translatable to end user experience. \u00a0The traditional measurement of the browser user experience is page load time, but what does that actually mean? When web pages were mostly static, when data transfer stopped all of the content was loaded, and there was a fair correlation between network traffic and page load times. \u00a0After all, the images couldn’t be rendered in the page until they were loaded. \u00a0Now websites have switched from being static content displays, to javascript heavy web based applications. \u00a0To make the most of the available bandwidth, data transfer is nearly continuous, as data needed for the future is downloaded in the background, so data transfer is no longer a reliable measure of when a page has stopped loading.<\/p>\n

The solution has been to switch from measuring web page load times based on network traffic to measuring page rendering. \u00a0That metric is focused on what the user sees, which is a more accurate measurement of perceived performance. \u00a0But even that isn’t enough, because\u00a0with the advent of long scrolling<\/a> website design, much of the content isn’t even visible to the user. \u00a0The question then changes from how long does it take the page to load, but how long does it take for visible<\/em> content to render?<\/p>\n

To illustrate the change, the following graph shows how much of the content \u00a0at http:\/\/www.washingtonpost.com is rendered when downloaded over a 5Mb\/s connection, curtesy of WEBPAGETEST<\/a>. Although the theoretical minimum load time is around 9 seconds, the content above the fold rendered at around 2 seconds on both Chrome and Firefox. \u00a0Note that the 5Mb\/s is considered to be a slow network in today’s terms, but even so the mainstream news sites I checked all managed to throw up content in two seconds or less. \u00a0You can see from the chart how the majority of the content is rendered right away. \u00a0The recorded video of the rendering reveals that the content that took the most time was the advertisements being pulled from one of dozens of different servers, which is of little importance to users. \u00a0The first chart is the visual progress of viewing the page on Chrome, followed by Firefox.<\/p>\n

Washington Post (Chrome)
\n\"\"<\/a><\/h4>\n

Washington Post (Firefox)<\/h4>\n

\"\"<\/a><\/h4>\n

As you can see from the charts, the vast majority of the content becomes visible almost immediately. \u00a0This news site (and most other high traffic sites) optimized their content so the most visible content loads as quickly as possible. \u00a0The practical performance difference between the two browsers are negligible. \u00a0Chrome loads all of the content much faster than FireFox, but FireFox loaded the initial content slightly faster at the expense of taking much longer to load all of the visible content.<\/p>\n

Browser Speed and Site Scalability<\/h2>\n

Here at Web Performance customers will often want to run scalability and load tests with different types of browsers simultaneously to see if there are differences between browsers under load. I can save you the trouble of paying us for that info: \u00a0there isn’t a difference. The small differences in browser speed are not affected by load, but rather are constant depending on the website.\u00a0It all comes down to the theoretical single user web page load times vs. load times when the site is under load. There is a fixed load time for a given web page when the website isn’t under load. \u00a0This the baseline performance for an individual page, and assumes ideal network and back end conditions. \u00a0The same difference in web page load times between browsers when there is a single user on the site is the same as when there are 1,000 users on the site. \u00a0Say, for example, that browser A loads the homepage in 2.0 seconds, and browser B loads the homepage in 3 seconds. \u00a0This difference in average web page load time will remain fairly constant as load is applied and the average web page load times increase.<\/p>\n

\"\"<\/a><\/p>\n

 <\/p>\n

The Future: WebAssembly<\/h2>\n

Back in the mid-90s the future of the browser seemed to be Java Applets, small applications that were pre-compiled, and then executed in a runtime attached to the browser. \u00a0For a variety of reasons, poor bandwidth, proprietary technology, etc, Applets never caught on, but the concept is still a good one compared to what we have now. \u00a0As Javascript prevailed as the predominant way of making a web interface interactive, the size and complexity of the Javascript needed to implement even a moderately complex website means that a major portion of CPU power is taken up by Javascript execution.<\/p>\n

Going back to the three places where browsers spend their time, we’ve greatly reduced the network by having access to fast networks and managing page size, but there are still two other categories. \u00a0Pre-compiling the interactive part of the site would reduce the runtime overhead, which is exactly the purpose of a new open standards project called WebAssembly<\/a>.<\/p>\n

\"\"<\/a><\/p>\n

It has the potential to delivery near native application execution speeds while loading faster than javascript, since binary can be decoded faster than javascript can be parsed. \u00a0As of Fall 2017 every major browser had built-in support for WebAssembly, so you can try the many sample WebAssembly applications<\/a> right now.<\/p>\n

The Fastest Web Browser in 2018<\/h2>\n

If you were expecting an exhaustive side-by-side comparison of browser performance, then you may be disappointed to learn that which browser is fastest is largely irrelevant given the architecture of modern web-based applications. \u00a0Browser load times are quickly approaching theoretical minimums for network transfer and rendering, while new approaches reduce processing time for interactive content.<\/p>\n

In the past we’ve setup test sites and done comprehensive comparisons between browsers, but the results wouldn’t have mattered. \u00a0There is no one browser that is fastest for everyone; the only relevant measurement is what browser is fastest on the specific website you wish to measure under your specific network and platform conditions. \u00a0Given that performance differences are likely to be on the order of a tenth or a second, the feature set and every day usability of the browser is more important than raw speed.<\/p>\n

If you want to find out what browser is fastest on your favorite websites, use services like http:\/\/dareboost.com<\/a> (commercial) or http:\/\/webpagetest.org<\/a> (free) and see how each potential browser fairs under your specific conditions. \u00a0Let us know what you find!<\/p>\n

Save<\/span>Save<\/span><\/p>\n

Save<\/span>Save<\/span><\/p>\n

Save<\/span>Save<\/span><\/p>\n

Save<\/span>Save<\/span><\/p>\n

Save<\/span>Save<\/span>Save<\/span>Save<\/span><\/p>\n

Save<\/span>Save<\/span><\/p>\n

Save<\/span>Save<\/span><\/p>\n

Save<\/span>Save<\/span><\/p>\n

Save<\/span>Save<\/span><\/p>\n

Save<\/span>Save<\/span><\/p>\n

Save<\/span>Save<\/span><\/p>\n

Save<\/span>Save<\/span><\/p>\n","protected":false},"excerpt":{"rendered":"

Even though interoperability has been conquered, browsers still want to compete on performance, so picking the fastest one is a reasonable question. \u00a0But what does browser performance mean in a world in which many people now have 1 Gb\/s network connections in their home, and a 4G LTE phone connection can go up to 173Mb\/s?<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[6,8,287,197],"tags":[293,291,295,297],"class_list":["post-5931","post","type-post","status-publish","format-standard","hentry","category-browsers","category-load-testing","category-performance-testing","category-real-browser","tag-browser-performance","tag-browsers","tag-page-load-times","tag-page-speed"],"_links":{"self":[{"href":"https:\/\/www.webperformance.com\/load-testing-tools\/blog\/wp-json\/wp\/v2\/posts\/5931","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.webperformance.com\/load-testing-tools\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.webperformance.com\/load-testing-tools\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.webperformance.com\/load-testing-tools\/blog\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/www.webperformance.com\/load-testing-tools\/blog\/wp-json\/wp\/v2\/comments?post=5931"}],"version-history":[{"count":41,"href":"https:\/\/www.webperformance.com\/load-testing-tools\/blog\/wp-json\/wp\/v2\/posts\/5931\/revisions"}],"predecessor-version":[{"id":6196,"href":"https:\/\/www.webperformance.com\/load-testing-tools\/blog\/wp-json\/wp\/v2\/posts\/5931\/revisions\/6196"}],"wp:attachment":[{"href":"https:\/\/www.webperformance.com\/load-testing-tools\/blog\/wp-json\/wp\/v2\/media?parent=5931"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.webperformance.com\/load-testing-tools\/blog\/wp-json\/wp\/v2\/categories?post=5931"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.webperformance.com\/load-testing-tools\/blog\/wp-json\/wp\/v2\/tags?post=5931"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}