What is the Fastest Web Browser in 2018? - Web Performance

What is the Fastest Web Browser in 2018?

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.  They simply took the desktop OS strategy and applied it to browsers.  But 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.

Web Performance Consulting

Even though interoperability has been conquered, browsers still want to compete on performance, so picking the fastest one is a reasonable question.  But 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?

Theoretical Minimum Page Load Times

Web page load times are tricky to measure, as modern browsers can pull resources on dozens of threads from hundreds of website simultaneously.  You 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 the browser doing while you’re waiting for a web page to load?  Its making socket connections, transferring data to and from the servers, rendering your GUI, and running javascript, among other things.  Below is a visualization showing three different categories where browsers spend their time during a page load: network data transfer, layout and rendering, and javascript:

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

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.  With the rollout of 500Mb/s and faster internet connections web page load times of sub half-second are possible.  While network speed used to be an insurmountable problem in web performance, its fairly easy for content providers to work around network limitations.  That 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.

The bottom line is, for most applications networks are no longer the bottleneck.

What About HTTP 2.0?

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.  HTTP 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.  Unfortunately 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.

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

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

reddit.com HTTP 1.1 vs 2

YouTube, on the other hand, is completely HTTP 2 compliant.  While the full load of the page shows no improvement with HTTP 2, loading just the visual part of the page was around 25% faster.   Whether or not a particular website shows an improvement with HTTP 2 depends on its design.  Although 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.

Measuring Browser Performance

There are lots of different benchmarks for browser performance, and each one measures a specific narrow aspect of performance.  The 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.  The 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.  After all, the images couldn’t be rendered in the page until they were loaded.  Now websites have switched from being static content displays, to javascript heavy web based applications.  To 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.

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

To illustrate the change, the following graph shows how much of the content  at http://www.washingtonpost.com is rendered when downloaded over a 5Mb/s connection, curtesy of WEBPAGETEST. 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.  Note 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.  You can see from the chart how the majority of the content is rendered right away.  The 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.  The first chart is the visual progress of viewing the page on Chrome, followed by Firefox.

Washington Post (Chrome)

Washington Post (Firefox)

As you can see from the charts, the vast majority of the content becomes visible almost immediately.  This news site (and most other high traffic sites) optimized their content so the most visible content loads as quickly as possible.  The practical performance difference between the two browsers are negligible.  Chrome 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.

Browser Speed and Site Scalability

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:  there isn’t a difference. The small differences in browser speed are not affected by load, but rather are constant depending on the website. It 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.  This the baseline performance for an individual page, and assumes ideal network and back end conditions.  The 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.  Say, for example, that browser A loads the homepage in 2.0 seconds, and browser B loads the homepage in 3 seconds.  This difference in average web page load time will remain fairly constant as load is applied and the average web page load times increase.


The Future: WebAssembly

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.  For 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.  As 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.

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.  Pre-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.

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.  As of Fall 2017 every major browser had built-in support for WebAssembly, so you can try the many sample WebAssembly applications right now.

The Fastest Web Browser in 2018

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.  Browser load times are quickly approaching theoretical minimums for network transfer and rendering, while new approaches reduce processing time for interactive content.

In the past we’ve setup test sites and done comprehensive comparisons between browsers, but the results wouldn’t have mattered.  There 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.  Given 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.

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













1 Comment

21 June 2018 Have the browser wars ended? – David williams CIST:1001

[…] The biggest difference was once speed but with newer browsers they are only really held back by your internet connection and occasionally on your hardware especially ram. https://www.webperformance.com/load-testing-tools/blog/2018/02/what-is-the-fastest-web-browser-in-20… […]

Add Your Comment

You must be logged in to post a comment.


Copyright © 2024 Web Performance, Inc.

A Durham web design company


(1) 919-845-7601 9AM-5PM EST

Just complete this form and we will get back to you as soon as possible with a quote. Please note: Technical support questions should be posted to our online support system.

About You
How Many Concurrent Users