The Parallel Future Of The Browser

Hi i’m lynn clark and i make code cartoons I also work at Mozilla where I’m in the emerging technologies group so that’s things like the rust programming language and web assembly which is a fast way to run languages other than javascript in the browser we also work on servo which is a new web engine and I’ll be talking.

About all of these things today because they’re all part of the future of the browser so why.

Talk about the future of the browser because browsers are facing a challenge and whether or not browsers meet this challenge could change the web as we know it what is this challenge browsers need to get faster let’s.

Look at the trajectory of the speed of the browser over the past two decades in the early days of the web speed really didn’t matter that much we were just looking at static documents so as soon as that document was rendered to the screen the.

Browser was pretty much done with it it might need to do a little bit more work if you scroll the page up and down but that work wasn’t too complicated then people started pushing the boundaries they started thinking what can we do with this web besides.

Just delivering static documents.

They just started getting interactive they started having animations like do you remember back when everybody went dropped down crazy and you had drop-down menus everywhere people.

Created these fancy sliding up and down and in and out ones with jQuery once those were part of the page the web page wasn’t just being painted once to the screen with every change it needed.

To be repainted and sometimes like when you had this motion it needs to be repainted multiple times for that change to give you that sense of movement so for every one of those changes.

There were multiple repaints of the screen and if you wanted interactions and animations to look smooth those repaints needed to be happening at a certain rate there needed to be 60 of them every second so that meant that you only had 16 milliseconds.

To figure out what exactly the next version of this page should look like browsers made all sorts of changes to come up to speed to accommodate these new applications and get up 60 frames.

Per second what as is the way with the web content authors.

Started pushing the boundaries even further they started not just making their web applications more interactive but bringing whole new classes of applications to the web like PC games and companies started talking about bringing their applications to web applications like Photoshop these new classes of applications are taxing the web even more and making clear that things like JavaScript need to get even faster it’s not.

The content authors that are pushing these boundaries either it’s also hardware vendors for example the new iPad is going from.

60 frames per second up to 120 frames per second that means that the browser has half as much time to do just as much work and new kinds of content are coming to the web and pushing.

This even further for example with VR you have two different displays one for each eye and they.

Both need to be going at at least 90 frames per second to avoid motion sickness on top of that a lot of these are at up to 4k resolution which means you have a whole lot more pixels that you actually have to paint let’s think about what this change means if we’re running a website on.

A 13-inch MacBook Pro we have 16 milliseconds to fill in 4 million pixels with the next iPad you have half as much time you have 8 milliseconds to do.

3 million pixels with a VR experience you have 11 milliseconds to fill in sixteen point five million pixels and this doesn’t even include any heavier JavaScript needs that is a huge leap that browsers need to make in order to keep up what.

Happens if browsers don’t keep up well as more and more people buy these new devices and as more and more content moves towards these heavier.

Applications if browsers don’t keep up people will stop seeing the web as the default place where they should put their content and this could mean that the web as we know it withers.

Which is a pretty scary thought but to be honest I’m actually not too worried about this I’m confident that browsers can make this leap and the reason that I’m confident is that at Mozilla we’ve been prepping for this change for the past ten years we’ve been looking at the direction that computer hardware is going we’ve been figuring.

Out the new way that we need to program to keep up with these changes the answer is parallelism the future of the browser is parallel we’ve only just started taking full advantage of this and Firefox but we’re already seeing big wins from it and every indication is that this new way of doing things can get the browser where it needs to be so in this talk I want to explain exactly what browsers need to change in order to keep up with these changes but before I do that let’s talk about what.

The browser actually does I’m going to start with the rendering engine so this is the thing that.

Takes your HTML and CSS and turns it into pixels on the screen it does this in five.

Steps but to make it simpler I can split up these five steps into.

Two different groups the first group takes the HTML and.

CSS and figures out a plan it figures out what the page should look like and this is kind of.

Like a blueprint it specifies where everything will go on.

The screen and asbestos things like the widths and the color and the element Heights of elements and then the second group.

Takes this plan and then it takes it turns that into pixels the pixels that you see on your screen now let’s look more closely at each step in this process the first step is called parsing what the parser does is it turns.

The HTML into something that the browser can understand because when this HTML comes into your browser is just one big long string of text it’s kind of like a big long paper ribbon that has a lot of characters all in a row but what we need is something different something that the browser can actually use we need a data structure that tells us what the different.

Elements on the page are and how they’re related to each other like parent-child relationships.

I think of this kind of like a family tree we need to turn this long paper ribbon into a family tree of the page so what the parser does.