When you choose a web browser, you’re also choosing a browser engine and a rendering engine – sometimes these two terms are used separately and sometimes to mean the same thing. Technically, the rendering engine renders pages and the browser engine handles comms between the rendering engine and the browser user interface.
We’re not covering it in detail here, but don’t get confused by Chromium. It’s like a step between Blink and the full Google Chrome (or the new Microsoft Edge): A bare bones, open source browser, which others can build on top of.
If you’re looking for a new web browser or a Chrome alternative, you might want to check out our article on that.
What are browser engines?
Now you know the names of the three major browser engines, so what exactly are they? Their job is to take the HTML, CSS and other code of a webpage – the text you can see in the page source or open in a text editor, setting out layouts, page content, and styling – and convert it into what you actually see on screen.
In some ways the engine is like a translator, turning the raw code that you can’t understand into a beautifully laid out page of text and graphics that you can. The browser engine makes choices about how to interpret what a web developer has typed – how particular lines of code affect what’s on-screen.
In fact, you can consider the browser engine to be the most important part of the browser, much like a car engine is the most important part of your car. Everything else – menus, extensions, smart searching, autofill – is pretty redundant if you can’t actually see the sites you’re visiting properly.
So far so good… so why do we need different ones? Well, different programmers have different ideas about how best to do the job of a browser engine – displaying colours, optimising code, refreshing pages, and so on.
Case in point: Google launched Blink as a separate engine back in 2013 to improve on what it saw as failings in WebKit’s handling of multiple processes.
Say you want to introduce a new and improved way for web developers to show videos embedded inside text on a webpage. For that to happen, you need support from a browser engine, if you don’t get it, and a lot of other engineers agree with you, you might consider creating your own browser engine, which is basically how we’ve got where we are today (although the chances of a new engine ever getting off the ground in the future are slim, as Microsoft has proved).
Browser engines are the main reason that webpages sometimes look, load, and work differently in different browsers – it’s more likely the variations between Quantum, WebKit, and Blink than the variations between Firefox, Safari, and Chrome that are behind these differences.
As the web evolves though, the variations are becoming less about the surface visuals (which are pretty much the same across the board) and more about the underlying technologies.
What makes browser engines different?
Every part of a page’s rendering and the way user interactions are handled is carried out by the browser engine, and while each of the engines do a lot of processing in the same way, there are some differences too. Take the way the security of web apps is handled, this is something that each browser engine can approach differently.
For example, the last major upgrade for a web engine was the switch from Gecko to Quantum on Firefox browsers, which focuses on a lot of these new considerations for the modern web: How web apps get refreshed, how the browser handles memory and CPU core time, and how it responds to system crashes. Gecko is still used, but you’ll mostly find Quantum on Firefox browsers.
Should an engine support older web standards and potentially lose milliseconds checking them (this is why Microsoft built Edge 1.0 in the first place)? Should it render text first and then load in images? How should multiple processes in multiple tabs be handled?
It’s more these high-level questions, and less the intricacies of web fonts and embedded audio (for example), that differentiate the main browser engines today.
As well as existing web standards, browser engines also need to support new standards as the internet gets ever more complex. This is another area where Blink arguably has an advantage – with Google building so many cutting-edge web apps, it’s in a better position to push for the standards they use.
There are other issues too, which really only matter to developers: How quickly code can be added and approved, the procedures for fixing bugs, how closely the browser engine is tied to the actual browser… end-users won’t notice these (unless they’re counting the frequency of update patches), but they’re also important to mention.
Which is the best?
Everything considered, should you stick with your current browser engine or should you switch to another? Well, as we’ve said, on a surface level there’s not a huge difference between them at the moment – Chrome (Blink), Firefox (Quantum), and Safari (WebKit) all render most websites in very similar ways at very similar speeds.
That’s because they all now largely accept the same basic web standards (something which wasn’t always the case – rest in peace Internet Explorer). There’s no headline feature we can point out that would necessarily make you suddenly leave WebKit and switch to Quantum, or vice versa.
On one level, Blink is the best browser engine out there (Microsoft switched to it, after all). It’s speedy at rendering pages and apps, updates are pushed out rapidly, it’s relatively robust, and bugs tend to be patched quickly.
From Microsoft’s perspective, it’s also the easiest to build a new browser on top of and it works best when embedded in desktop apps. At the same time, it continues to hog memory in some situations and has grown more bloated over the years.
With its Quantum upgrade for Gecko, Firefox continues to impress and is making serious speed improvements.
What differences there are in these browser engines tend not to have a huge impact on end-users, so you can carry on using the browser you prefer.
Where Blink’s dominance might have a negative effect on all of us is the way that browser technologies are used in the future and which fall by the wayside ” at the moment, Google engineers are calling the shots for the way the web works for the majority of people (not entirely, but enough for it to be a concern).
In other words, the danger is you’ll see a lot more “works best with Chrome” messages.
With Microsoft engineers now contributing to Chromium too – after the Edge switch – that should be mitigated somewhat, and there is an argument that it’s in Google’s best interests to preserve the open web and ensure its ongoing development is a collaborative effort. Just be aware that your choice of getting on the web isn’t just about the browser”it’s also about the engine running underneath.
This article has been updated since its original publication.