Frontend’s Lost Decade and the Performance Inequality Gap

I'm Alex Russell, I am a product manager which is all weird to say. I do an engineering job, I did an engineering job before I joined the Edge team for 12 years on the Chrome team at Google, and before that I spent a decade on TC39, building JavaScript frameworks and libraries, and when I joined the browser side of the world, I went to try to make sure that the trailing edge could move up to meet us at the front of where the web was being developed. We want experiences to be made out of the best stuff because a lot of the stuff in the ecosystem is hard to move, right? It's hard to get people to change their devices, it's hard to get people to change their operating systems, and in many cases, the easiest thing you can possibly do is get people to update their software.

That's why I joined the Chrome team, to build something called ChromeFrame where we shoved Chrome as a plug-in into IE. Don't ask! All that is to say that all of that work since I sort of switched jerseys to work on browsers has been an attempt, you know, working on TC39, helping to lead teams that designed and promises, and service workers, and classes, and project Fugu, and all that kind of stuff. All of that has been about trying to bring us closer to what native developers expect a platform to do, not because there is some sort of envy but because what winning looks like for a platform is for users to spend more of their time using applications that are built in that platform.

We are all connected here under this roof as an ecosystem, even if we don't know each other individually. It is the success of our peers and the products that are to the left and the right of us that make us more successful or less able to deliver. To do a good job of that, we have to apply the principles of engineering, right? We have to understand what the constraints are we're going to build to, and then we have to build solutions to the problems that people come to us with, and use what we know to build to those constraints. Which is to say that anything that you might see in a survey, a popularity contest effectively, is immaterial to the question of whether or not you're doing a good job as an engineer, because the fitness function for engineering isn't whether or not your tool is popular.

The fitness function for engineering is whether or not the result works well for end-users, the people that you're actually building and designing for. Okay. So, let's take that as the north star. That's what we want to do. We want to do engineering. How do we do it? Well, we have to understand our limiting factors. What are the things that we, you know, are building underneath? What is the environment that we are building in to solve the problems? Because that should determine, you know, for instance, what materials we use, what properties they should have, how much of it we can afford, right? There's going to be a budget. All of those things are important in other kinds of engineering and just as important in our engineering.

What are our limiting factors and are we actually building to them? Let's find out. So we have a couple of constraints. The first is, of course, the amount of CPU graphics performance and storage performance that we have got on any specific device. That is a shared resource on the web. We're heavily sandboxed. I always say that web developers don't send edicts down the wire. They send hopes. It's influence-oriented programming. You send something from the data center and you're very lucky if it comes out the other side in any of the ways that you expected it to because of different browser runtimes, extensions, browsers mediating your content in ways that you don't expect, and the huge diversity of devices that the web targets.

We're not targeting a single narrow ecosystem of a specific set of users. We're targeting all users on the web. So the set of all users that you would like to address, the properties of their devices turn into a big problem for us, as do the networks that they connect over. That is a huge diversity. That is not sort of a narrow target. Of course, the browsers that users use define the software ecosystem that we can program to. We can only target the APIs that we believe are available. So these are the three things that I think we should be keeping in mind when we sit down to try to solve a problem for a user. This is, you will note that there is nothing in here about frameworks, right?

This is about the hardware and the networks that the platform is operating on. These are the actual constraints. Nothing about what you prefer to write or how you would like to spell your angle brackets has anything to do with these properties.

So what does failure look like? Unfortunately, we've got some very punchy and front and center examples of that failure mode. These are the pass rates for Coro vitals, Google's Chrome user experience report-derived set of histograms which you will know as interaction to the next paint, large contentful paint, and cumulative layout shift.

So only 38% of mobile sites are passing Coro vitals. This isn't a passing grade in any course I ever took. I would be surprised if it was for you. That is to say, even on secondary pages where large amounts of the, hopefully the first top-level content are cached, because you use the opportunity of going to the top page to get to the second page, only half are passing on mobile.

And mobile is where users are. I put together some of the data from the web almanac last year to try to understand why is it that popular tools or what is it that popular tools are doing in terms of helping us out? Are we getting what we expected from our investments in the tooling that you will see heavily marketed and showing up at the top of the surveys you heard about this morning? And the answer is that many of the tools that are most heavily funded, most heavily used and most heavily marketed, specifically, left their users in the lurch the most.

That is to say that the developers in the sites that adopted those tools specifically, the popularity contest winners, found themselves with the worst results when Coro vitals moved from first interaction delay to INP. Which is to say the more honest the metrics got to what the actual end user experience was, the worse the sites looked. These tools were gaming the user experience in the metrics, and when the metrics got more honest and tried to reflect more accurately what the users see all day, it turned out that the people who had invested in these tools found themselves in more trouble than folks who invested in simpler stacks.

This is tough to swallow, and I think it leads to a couple of things. First, you know, it's obvious now that people are spending not as much time as I think it would look like to succeed on the web on their mobile devices. This is a competition. Platforms are a competition and the web is currently losing dramatically. You can see it from space.

This is data from the United States and this is to say that web usage as a fraction of time on device is low and falling. At a base rate, it is stable in terms of absolutes, but time spent on devices is not absolute. If you're a web developer, this should scare the shit out of you. This is what it looks like to have your ecosystem eclipsed by something else. This is what losing looks like. So let's step back. We're not necessarily succeeding. What should we be doing? Well, if you want to build to a good target for users at the margins, which is where every market is made, you always make your market at the margin, you cannot be building to the latest MacBook Pro. The limits of this device are stratospheric compared to what most people have, because what it costs is stratospheric related to their budgets. The same is true for mobile devices. The real target looks something like this.

The real target looks something like this. This is a Surface SE. This is a device that my company sold to schools primarily. It features either the $250 version sold with an N4020 Celeron chip, which is a two-core, two-thread, four gigabyte device with very slow eMHC, all encased in polycarbonate so the cooling sucks. You're always thermally throttled on this device. The top-selling laptop frequently on Amazon is this device, which was launched in 2022 about the same time as the Surface SE.

This is the HP Stream 14. It uses the same chip, the N4020 or the 4120. The 4120 will get you four cores and four threads. It has very little cache, because the space you allocate to cache, which is to say making things go fast, is very expensive compared to other kinds of things that you would put on the same chip. It also features very little memory and a very, very, very slow eMMC. I have both of these devices on my desk at work, because it's important for us to be testing on these real devices, because that's the only way that we can really understand where the market is.

Most computers today are phones. Most of the things that can run a web browser today are phones. There's no legacy browsers on phones. They just, to a first approximation, don't exist. Almost everyone has a browser that was built within the last three years on a phone. You don't have to think about IE on a phone. You have to think about the hardware and software, because this device has eight cores nominally. They are Cortex A73 and A53 cores, which is to say they blow chunks. Mostly, those cores are not spun up. The big lie is that you're going to keep those cores powered up, and that's why your system is going to be fast. That never happens. The battery, in that same polycarbonate case, has to power the dang thing all day.

So we're not keeping cores spun up. You don't get eight cores. You're lucky if your website gets one or two. Maybe four if you're in the loading phase and we're doing things like image decoding. This brings us back to understanding the economics that feed into the questions of what does the actual device landscape look like. Average selling prices for phones worldwide, new, unlocked, have been hovering between $270 and $350 for a decade. That is to say that the median device, the device sold at the average price, because the average and the median are actually very close in these cases, has not accelerated in price the way the device that you probably carry has. If you are a wealthy developer, it is very likely that your phone used to cost about $500 and then about $600, and then you got a $1,000 phone and then you got a $1,200 phone, and that's what you carry now. You pay for what you get in many cases.

For laptops, which is the dominant form factor for PCs, the average selling price is hovering about $650. But it's worse than that because most of these devices are old. Most of the landscape that you're deploying your software into is not comprised of devices that were sold this year or in the last six months. The lifespans of these devices define where the median actually is, or where the 75th percentile or the 90th percentile, which is what we actually care about, 90th, 95th. Those devices have lifespans which mean that the median phone was sold at $350 two years ago. And the median laptop was sold about five years ago for $650. Are you building your testing to that? Because that's what your users are carrying.

So we have good telemetry from Edge. We can see a lot of metrics where the inbox browser on Windows, so something like a third of the fleet that we get telemetry from have spinning hard drives or they have four gigabytes of RAM or less, or they have four cores or fewer. This is our low-end bucket. And this low-end bucket is not draining nearly as fast as you'd like it to. This same test set has only decreased by 7% over the last two years. Okay. So what you need to understand about the world that you're actually putting your software into is that most of the devices are old, much older than the ones you probably carry. They're mostly phones, and they're not running Mac OS or iOS. That's just not reality. So if you would like to do a good job to solve problems for users and society under these constraints, you need to understand how to build for them. Okay. I know that there's a big risk of me getting up here and doing my blog in 20-minute form on stage. But I will say that I started paying attention to this because when we built PWAs, when the team that I was leading built PWAs in 2013, 14, and 15, we started working with lots of partners, lots of folks who wanted to build good competitive mobile experiences. And what we were finding over and over and over again was that they were taking the tools and frameworks that made sense in the old desktop consensus, and they were trying to apply them to mobile.

No other ecosystem tried this. And it has been an absolute disaster, a total debacle. It has not worked. Because most phones then and now are acceleratingly cheap Androids. Okay. Now you may be saying to me, Alex, but we get... Moore's Law's death is greatly exaggerated. And to a technical extent, that's true, in the sense that we get more transistors every 18 months or so. And the trend continues, especially in places like the data center where we're getting full utilization out of these cores.

But that's not the story that matters, because most phones, most computers are running off of batteries, and power is now the limiting factor for those devices. Having more transistors, if they're not able to be lit up, doesn't matter for performance. No matter what your threading model is. They just don't matter. And Denard scaling ended more than a dozen years ago.

What this means effectively is that while we get more transistors, we don't get to light up more transistors, and they don't go faster. The gigahertz stopped. What you see at the top there is that your total number of gigahertz for die shrinks didn't go up. Which means that the same program that used to reliably get faster every year because Denard scaling meant that our same single threaded program would go faster on the next generation of hardware, that's over. Doesn't happen. And our entire JavaScript ecosystem was effectively built under the premise that this was going to continue to happen.

It happened all the way through the 2010s. It's done. It's over. So what we've got now are more dark cores. They're not lit up. They're powered down. They're in the lowest power state most of the time because that's what batteries require of us. They're slower, right?

I keep trying to construct this chart, and the research is actually quite difficult to get a hold of in aggregate. But it's my strong expectation that peak CPU performance probably was hit in 2017. We've probably been on a downward trend at the median ever since because phones have exploded while the PC and desktop market has effectively been a fixed function.

There is good news, which is to say that browsers got the message. We adapted pretty heavily. We moved to mobile. We threaded everything. When you hand us a workload that is designed to work the way the web works rather than the way maybe JavaScript works, we thread the snot out of things today, right? Your image decoding is off-thread. Your scrolling is off-thread. Your parsing is off-thread. Actually, a lot of the compilation in the background for your JavaScript now is off-thread.

Actually, a lot of the compilation in the background for your JavaScript now is off-thread. This matters because we're getting a lot more cores, but we're in most of the market not getting faster devices. You'll see that I'm focused here on single-core scores because this is what defines the performance of your JavaScript, right? This is where your code as a web developer is running on the main thread.

That Galaxy 825 in the third slot down on the right, that is the $350 device. The $300 device today. You'll note that it is... What is that? About a third as fast as an iPhone. Okay. So, if you carry an iPhone, what's in your pocket is not real life. And part of this is because when you pay a lot for a phone, what you're getting is a lot of cash today, right? Like 40 megabytes of cash. It's ridiculous.

What Apple has done with Silicon is ridiculous. That is because they sell to a wealthy cohort of folks, which is to say not most people. Our limiting factor is the fact that we live in an extremely chatty, interpreted, or JITed environment in which data locality is hard to reason about. Every time we fail a branch predict, every time you're deopted in V8, woe is you because you're probably stalled out. This means that every time you bet on JavaScript to deliver your experience, you're making a bad bet.

And that means that your JavaScript will run very fast on devices with a lot of cash. You don't have to spend a lot of time stalled out waiting for main memory. On most phones, ain't no cash. Every time we fail a branch predict, every time you're deopted in V8, woe is you because you're probably stalled out. This means that every time you bet on JavaScript to deliver your experience, you're making a bad bet.

Okay. Well, I've got bad news. And good news. The good news is that networks are improving. And the bad news is that they're starting from a very bad baseline. Again, the predominant story of the last 15 years of computing is not whatever was marketed to you as someone who's relatively wealthy. It is that folks got their first smartphones in large portions of the world. Billions of people got computers for the first time. And those phones were androids, cheap androids, $100, $150, maybe $200, new unlocked.

And so the network situation in growth markets, in the places where the margin is actually made, is still pretty rough. In a lot of places, it's highly variable. But in growth markets, it's still improving rapidly. But it is improving from a 3G to slow 4G baseline. What I want you to understand at this JavaScript conference, from someone who spent a decade on TC39 working in the language to give you promises and classes and arrow functions and that sort of thing, is that JavaScript has always been and will always be the slowest way to do anything on the web. Making a fast JavaScript program requires that you think about it the way you would make a fast Python program. You dish off to the C++ libraries that are sitting left, right, and center and you spend as little time in your language as possible.

You dish off to the C++ libraries that are sitting left, right, and center and you spend as little time in your language as possible. Your job as a plumber, you're connecting the input from some parser to some other system that is going to be handling it out in C++ land. Which is to say, every time you're running code in the critical path of a user interaction, you fucked up. And this matters because you're going to hear a lot over the next couple of days about tools that are popular.

And a lot of those tools have been sold on the idea that either their popularity means that they're good, or that you don't have to worry about the factors that I just talked about. And that's bullshit. It's bullshit because it isn't focusing on the question of whether or not we're solving a problem effectively for users. Specifically, users at the margins. That's where the business is. The business is always at the margin.

So if you're not building your own mental model, and you're not building your own testing environment to understand how you're going to be able to deliver well for those users, deliver the experiences that you think are the best quality products for your business or for your enterprise, then you're kind of diluting yourself. Okay. This is all stuff you can find in a bajillion blog posts. You don't need me to tell you how to go fast on the web. You send less code. You run less code. You let the system underneath you do most of the work. You spend as little time in your own code as possible. Specifically in JavaScript.

Because JavaScript, again, is the slowest way to do anything on the web. And so if it is the only way to do anything in your stack, you've failed by default to reach users at the margins or you need extreme discipline. One of the two. You have to go try to reach for the marginal user. Otherwise you're letting down your business. That is what it means to do a quality job in our profession. So if we don't care about quality, none of this really matters. But if we care about quality and we expect people to pay us to do a quality job, then it does matter. And we can't wish away these factors. But we can do well.

So this is from a transition that we're going through internally in edge. We're calling it Web UI 2. A bunch of the browser today is built out of web stuff. It's built out of in the case of edge, a lot of React and a lot of all the data systems that you would have imagined. And this is the settings page. On the left is the old system that was based in React. And on the right is a new system that's been totally rebuilt to be built on what the platform can do. I could tell you about the stack, but it doesn't matter. The thing that changed here in this rebuild that made it, you know, a good 40% faster. That's roughly what we're seeing across the board as we rebuild these surfaces and get rid of React and all the abstractions that were built for 2011's web. What we're seeing is that we're improving the user experience because we decided to care about the user experience. The most important thing wasn't the tool. It was the focus. We decided to focus on quality for users at the margins and that has shaped every decision on the other side.

Don't accept anyone's idea of what your tooling and stack should be. Pose a test. Is it good? Are the results good? That's the only thing that matters. Thank you. The first question here is why don't you use a tool like browser stack instead of buying a laptop to test these devices? It's a great question. I can heavily recommend, whatever way you want to say it, webpagetest.org.

Having a repeatable environment which is tuned for low latency, sorry, low variance and allows you to tune the parameters that impact latency, having a low variance test bench which you can repeat things on inside of your development loop is incredible. At Microsoft we have built our own internal version, stood up our own instance of this open source product with a bunch of configuration and options that are specific to our flows, our authentication flows, our various testing environments at Microsoft. It emulates that service SE. We've tuned our instance of webpagetest. We call it the performance analyzer service. We've tuned PaaS to emulate that service SE device. And so every developer that we work with, we tell them to please put their things on PaaS. Get your critical user journeys into PaaS. Get that automated. You can do the same thing with webpagetest.org. And if you don't have a test bench like that, you need to get one, right? You can have physical devices. I would say one of the easiest hacks you can do is to hand your product managers cheap laptops and phones. You might say, oh, well, that's a new device. The good news is they're really cheap, so you don't have to worry that much about it. We do that. It tends to change minds because when people can actually experience what their users are experiencing rather than, you know, sort of having a graph in front of them about how it's going, that tends to be pretty effective at changing the narrative.

Next question here is, let's see, how relevant is browser incompatibility nowadays? I mean, it's obviously relevant. This is one of the places where the surveys for as much stick as I give them about framework choice are pretty revealing, right? We see consistently in feedback both initially from the MDN developer needs surveys as well as the state of surveys that the fact that Safari is very far on the trailing edge relative to what the web can do today is a big cost that we all pay, right? It turns into a real problem for us. If you'd like to help impact that situation, if you would like Apple to not just take 95%, 90% of the $20 billion a year they make from the web and skim that as pure profit, you can go talk to the OpenWeb Advocacy folks, go join them. They're trying to make it so that real competition for browsers is a reality for users who are wealthy, which would have a big impact on the overall ecosystem and has already delivered big and important changes in the trajectory of a lot of these browsers. The Interop effort was mentioned earlier, and we believe that a big reason that Apple is investing more is that Interop and tools like it are showing what the gap looks like.

There is a saying that if anything can be built in JavaScript, it will eventually be built in JavaScript. What's your take on it while JavaScript is the slowest way? That you can doesn't mean you should, right? Again, what is it to do engineering? It is to identify the problem that the user actually has and then figure out the best way to solve it for them, right? We always understand your content as HTML parsed into DOM, which is then matched with CSS, which is then turned into a layout tree, which is then turned into rasterized instructions, which is then uploaded to the GPU, and then we wait for the instructions. That's the loop. That's what we do all day, every day. If you put JavaScript in the middle there, you're sort of taking the reins and going, I got this. I can do this best. The fact that you can write everything in JavaScript because it's Turing-complete is sort of immaterial to the question of whether or not that's a good choice for a user who's trying to get to 60 FPS on a device that costs $350.

Is there a possibility that progressive web apps will win the web completely and mobile app and web app will finally reunite? The data that I was showing you earlier suggested that's a very long way away, right? For people to want more of the experience, if you think about what we were trying to build when we built PWAs. PWAs are kind of an answer to the question of I've got a bunch of users at the top of my funnel, they're coming to my site, and they're using my site, but then they want deeper engagement experiences with it, right? Some of them want push notifications, it turns out it's true. Some of them want their icon to be on the home screen. They want to be able to get back to it, see their unread messages, that sort of thing. All of that is downstream of the experience being good on the front end. If you think of it as a funnel, if you think of it as a flow, PWAs winning is probably downstream of web experiences being good in the first place. Until we have web experiences that don't suck, like that 50% of users who are having a bad time on most websites, on their phones, until we do better than that, why would we expect PWAs to win? This is a quality question. Our ecosystem is in competition, and that competition is about quality. Totally.

Do you think most businesses should primarily optimize for premium devices as that's where the money is, unless you're building government social services? I can't tell you the number of teams that I've worked with who lived in this privilege bubble, all the way up to their management chain, folks who carry fast devices on fast networks most of the time, who were astonished to find that all of the nonsense, absolute tosh, dreck that had been sold by the JavaScript influencer ecosystem about how people have fast devices now, which is obvious in the data, it's bullshit, they were astonished to find that when they made their websites twice or three times as fast, it made them a lot of money, or increased engagement, or whatever their top level metric was. It isn't one-to-one. You can't say if I make this 1% faster, I'm going to get 1% more business. It doesn't work that way. There's a lot of situated stuff. You have to figure out what the flows are, optimize them, end to end, and every business is different. But as a top level question, the idea that you're going to optimize, by the way, we're not talking about optimizing, we're talking about not optimizing. The idea that not optimizing, and believing that your users will pay the cost for your access is a good business strategy, requires a lot of evidence. And so I think we can all say that this is obviously bullshit, because the people who offer it don't bring any evidence. If they had this big pile of data that made sense of this, that sort of made all of these sort of different data points fit together in a way that made sense, we could say yes. Even people selling product handbags are selling aspirational culture, which is to say that the folks who are buying those primarily aren't the ultra-rich.

Do you have the feeling that the new generation of developers skip learning the platform and jump directly into using a framework? Is that good or bad? I don't want to... It's weird hearing me say this, but I don't really want to yuck anyone's yum. I don't want to tell you that you're doing it wrong if you learned a framework to start. But the difference between being a good engineer and a bad engineer, or doing a good job and a bad job, is understanding the relationship between the inputs and outputs. The best engineers I've worked with are the folks who can see the relationship between what you do up at the highest level system, in your CSS or in your HTML, and how that actually plays out on the CPU. I don't expect most of us to understand all of those phases, but we should all aspire to learn the levels above and below us a little bit, because that's what makes us better able to make the cuts and make the trade-offs that deliver quality rather than volume, right? If what we do doesn't matter, then, yes, do whatever you like. But if you're getting paid for it and someone is going to depend on it, please, spend the time to learn more of the stack around you. Awesome. Thank you so much, Alex. This has been great.