 So that last thing about the Glee Club is completely true. It was called The Ambassadors. It was in Carmel, Indiana. If you've seen the TV show Glee, it's basically that. The joke was that it was 30 suburban brats and a perfectionist, and it was completely correct. So normally, when I get up to give a talk sometime this year, I kind of put this slide on stage. And I'm really surprised not to be giving a Progressive Web App talk today. So Francis Barrowman and I named Progressive Web Apps last year, and it's sort of taken off since then, and we've been working on a bunch of technology behind that. And then starting about 2010, I guess, four or five years ago, I worked with Alex Komarowsky and Dmitry Glaskov, and we started the project that created web components. We added a bunch of new features to JavaScript of language, too, and so I spent a bunch of years working on the platform kind of from a lot of different angles with a lot of the folks who are actually here today. It's kind of great to see everyone out. But since 2012, I've basically been working on other stuff. I haven't really been involved in day-to-day web component development, and so this won't be that talk. I won't be talking about Progressive Web Apps. I won't be talking about web components. I won't be talking about ES6. I won't be talking about any of this stuff, basically that I've been working on for the last couple of years. And yes, you should probably make a Progressive Web App. You should probably use the purple pattern. You should probably adopt the Polymer App Toolbox, but what I want to talk to you about today is why the purple pattern is so critical to mobile. And I know that mobile isn't everything yet. It's about to be everything. Mobile is basically about to be all of computing, and if you go to emerging markets, it is basically all of computing. The next billion users who come online will probably only have phones. They'll have devices like these. They don't need devices anything like these. These are $700 phones. This is an iPhone 6S. This is a Pixel XL. These are $700, $750 phones. Basically, nobody has those. And what people do have, though, are phones like... This is a bad guy carry with me everywhere. We'll talk about this in a second. They'll have phones like these. This is a $100 phone from last year's Android One lineup in India. We'll talk more about that phone in a second. And so because people are running the software that we make on devices like these, what we're finding out is that we're not succeeding on mobile. We basically aren't. And so I've been having to say things like this to the JavaScript community, and it hasn't made me any friends in JavaScript land. And in fact, I'm a little bit surprised that Matt and company invited me to give this talk at all because I have been making the polymers very sad too. Scott, Steve, Monica, Frankie, and the rest of the team will tell you that this is basically the PG version of a bunch of conversations that we had where I would walk up with, say, one of these, over to their desks and be like, why is this slow? And I would do that sort of continuously once every couple of weeks, I guess. And then eventually we had a bunch of really uncomfortable meetings where they would show me an awesome new thing and then I would pull out a phone and I would plug it in and I would say, this is really slow. Why is this so slow? And at some point, I think it was Steve who you heard from yesterday to talk about being lazy. And I would say things like, you need to be more asynchronous. You need to stop doing so much work up front. You need to split these bundles up and he would say, stop telling us what to do. Just stop. Tell me what I need to hit. And so put a finger in the wind and it came up with it. You need to be interactive in about three seconds on a simulated 3G connection and I'm going to call it a $200 device. And this next time that I visit that same application, I need to be able to interact with that application in less than a second. Okay, so they went away. The stages of grief happened. Nobody was very happy about it. And eventually what they came back with was the purple pattern. And we'll talk about why that's so important. And this is pretty desperate stuff coming from me. Like I am not the sort of person who really would be saying that you need to stop loading a lot of JavaScript. I've spent years of my life trying to make it so that you have more power when you have JavaScript inside of the browser. Spent years working instead of TC39. I persistently advocated for extensibility so that the bits of the browser process, the threads that you haven't had access to like the network thread, bits of the UI thread, the compositor, painting, layout, obviously the parser with web components that you would have access to those to plug into those with script yourself. And in past life, I even helped make JavaScript frameworks with Scott and Steve. So to get to this point takes a lot. It takes a lot for me to say you need to stop putting so much script in your apps. You have to have really failed pretty badly to get me to be sending this message. So how do we get here? Well, I'd say that we've pretty persistently failed users on mobile devices. And I think if we put the rail model back in our heads, we can sort of understand what that means. Obviously, we talked about the rail model a bunch over the last couple of days, but we want to respond to user input in less than 100 milliseconds. We want to animate everything in that 16-millisecond budget to hit 60 frames a second, but that means that we probably have to do our work on the main thread in less than 8 milliseconds per frame because we have to wait for the browser to do the rest of its work. We need to make sure that we're chunking up our idle work into relatively small chunks so that we can remain responsive and get input processed so we can respond in under 100 milliseconds. And when we load, when we start to take an action inside our application, we want to get back to that interactive state in about a second. So this is long-term user research. I've been validated in lots of ways. 1,000 milliseconds is a really hard limit to hit. Getting to a second, interactive in a second when you load a document is a really, really, really hard thing to do on a fast network connection, on a desktop. Mobile is so much harder than you think it is. So how fast could we get? Like, if we probably can't get something loaded in a second, what's realistic? Well, I think three seconds on a 3G connection is realistic for something that you can interact with. And this is sort of buttressed by some data that the DoubleClick folks went out and researched and they came back and they said, there's real money on the table. This really caught my eye. 53% of visits are abandoned if a mobile site takes more than three seconds to load. And in the same report, they said the average mobile page takes 19 seconds to load. Collectively, as a community, we are not succeeding on mobile. We are not succeeding on mobile. Okay? Let's just accept that. We can be sad about it, and then we can figure out what to do about it. But we have to accept that we are not succeeding on mobile. And so I think it's worth asking why we're not succeeding on mobile. We're smart, thoughtful, intelligent people who are trying to build good interfaces for users. We don't want to do bad things. We don't want to make slow UI. We want to make something fast and beautiful. We want to really actually deliver great user experiences. No one's trying to fail. So that means that it can't just be that web developers are evil and hate users. I don't think that's true. I don't think anybody hates their users. Maybe if you're doing with support. But, you know, my first hypothesis, though, is that we have failed at mobile because we have allowed ourselves to only run our apps on desktop. So you open up DevTools. You see that inspector mode. You see the responsive design thing. It emulates the viewport of some mobile device. And you do your development there. And you're like, oh, yeah, this works great on a phone. Okay, who has used Chrome Inspect? Hey, I like you. All right. Who's using web page test? Okay, cool. Cool. This is a good crowd. I like this. But I think that most developers aren't doing that because a lot of the traces that I see are people who obviously haven't tried this stuff out. And so I am a one-trick pony. That this bag is in my backpack at all times and it includes all of these phones is so that when I go to a partner meeting, which happens a lot these days, I can sit down, plug in a phone to Chrome Inspect and show it to them on a real device, on a $200 device. Because that $200 device is ground truth. So to give you an example of what I'm talking about, this was the IO website from 2015. This was a super cutting edge progressive web app. It did push notifications. We barely, I think we just launched push notifications for the web in the release that was cut and sent to users the week before IO. I mean, this was bleeding edge stuff. It had a service worker. And on desktop, this thing was punchy. There's this nice intro animation. The whole bit gets loaded. Dom content loaded in 700 milliseconds. Pretty good. Get the onload at about a second and a half at which point that nice animation kicks in. We get smooth frames through most of that animation. And the whole time spent for all of that work to get the application booted and get that sort of nice fade-in animation is about 600 milliseconds in JavaScript. So this is a nice feeling app. I do the exact same thing, which gets me to interactive it four seconds on a Nexus 5x using Chrome Inspect. And it looks completely different. That big chunk of JavaScript there, that balloons to two and a half seconds of straight line script of L. That is just a slug of JavaScript at which point you can't do anything with this thing. It gets onload at five and a half seconds, roughly. The script locks up the UI thread for two full seconds. We spend four seconds in script overall and we aren't interactive until very late, but at the same time, for having done all that work, we still get janky frames, slow janky frames. This is not okay. We have to accept that this is not okay. And I think we're enabled because we are one of the few software ecosystems where we're running the same binary on the desktop as we are on a mobile device. Nobody runs a Win32 app on their phone. You can't take an OS X universal binary and run it on your iPhone. Nobody takes a Java jar with the Swing or AWT or SWT app and runs it on their Android device. That doesn't happen. Everybody else switched their tools when they switched form factor. We didn't do that. So we've been stuck in this world where we think that we have to build everything or can build everything for this desktop world and that it's okay. Traces from mobile devices are really harsh masters and most of the teams that we've worked with over the past year start looking at their thing on mobile and they wind up, like I said, they do the stages of grief. It's really, really, really hard and there's roughly three major areas that make this so much worse than it looks. The CPUs, the storage and the networks. So let's talk about it because I think we don't really... I think most of us sort of have an intellectual understanding of why mobile phones are different to desktop class machines but I don't think we really have thought hard about the real practical implications of that. I say all the time, pretty much in every meeting, that the truth is in the trace. The truth, the ground truth for your users is something that you can go and you can copy, take a snapshot of and send it to someone else on your team and have them look at it. And so if you're not taking traces and you're not inspecting your traces, you're not really going to understand what's going on in the real world but you can get traces from web page tests, you can get them from DevTools. So this is my desk. These are almost all of these devices wind up traveling everywhere with me including that 15-inch MacBook Pro and almost every phone on that desk aside from the Pixel XL on the right is about $300 or less. And that matters because these are the phones that most people have. I don't mean most wealthy people. I don't mean most of your customers potentially. I mean most of your next set of customers probably have phones that are not a $700 iPhone or a $700 Pixel. They probably don't. So what makes these things so different? Well, that 15-inch MacBook Pro has four symmetric multi-processing cores. They've got very deep pipelines. They can go from 2.8 gigahertz. They can actually scale much further than that in that process node. It's got 16 gigs of RAM, but it cost $2,700. The Pixel XL has four cores. Same number of cores. Obviously the MacBook Pro with the i7 has hyperthreading but that's sort of neither here nor there. It's got two of these cores which can go to 2.1 gigahertz and two of them which can clock up to 1.6 gigahertz which sounds a little bit weird, right? It's not sort of the thing you would have bought if you were putting together a gaming rig. You wouldn't pick different speeds, right? It's got 4 gigahertz of RAM so it's pretty good. It costs $750. It's a real computer but it's limited. The Nexus 5X has two more cores than that. Some of them even scale higher than the Pixel XL's cores. It's got less memory but it's only 300 bucks. And that Moto 4G, the $200 device, is the most endowed in terms of number of cores. So why is JavaScript ten times slower on that Moto 4G than it is on my $2,700 MacBook Pro? What the heck is going on? These things, like Core Count doesn't predict anything, right? At this point it's really hard to understand what's going on here. It's not the number of pixels that you push, right? The MacBook Pro has a very high density screen. The Pixel has a very high density screen, too, right? 400 dots per inch on the Moto 4G, right? They're all pushing these things. They've all got GPUs. They've all got flash-based storage. I think it bears repeating that if you think the $500 iPhone that you may be carrying with you is a stand-in for a real device, you're not looking at ground truth because the top of that line and the bottom of that line is between the Pixel XL and the iPhone class performance and the Moto 4G is a different world entirely. Worldwide, phones are getting slower. More people can afford phones now, and when they buy their first phone, they're not buying an iPhone. They're not buying a Pixel. They're buying $100, $150, $200 phone. Maybe, maybe, with financial incentives and with pay-as-you-go plans. And the average network is getting slower. Most people are coming online on 3G connections, and many of those 3G connections feel like 2G connections thanks to carriers. Let's not talk about carriers. It'll all make us even sadder. So this is the, this is some code. This is a benchmark that the WebKit team put together. It's called MotionMark. On my 15-inch MacBook Pro, between Safari and a local build of Chrome, Chrome is in the hunt. We get roughly the same performance. It's a lot faster. Sometimes we're a little bit slower. And it's a graphic story and a benchmark, but the main thread is always busy. This is basically apples to apples on OS X. We can take the same version of Chrome, run it on the Nexus 5X, and as you can see that the desktop version is 25 times faster, right? It's not 25 times cheaper. It's a $300 device. But this is dramatic. This is a huge difference. So I changed just one thing and re-ran this benchmark a couple of times and got a significantly faster result. I think you're going to be really interested to know what this one thing is. Across a bunch of different runs, I got this thing to be 15% faster overall. So what did I do? What did I do differently in the same hardware and the same version of Chrome or in the same benchmark? Is it magic? Did I decide, did I figure? Could be, but probably not. Instead, magic isn't really a thing, right? Magic doesn't exist. Instead it's science. What I did is I put this thing on an ice pack. My colleague Victor sort of figured it this out that this was the issue when he was trying to Victor and his team were trying to figure out why we were getting these wildly varying results out of this benchmark on mobile devices. And so he put the phone in a fridge and then ran it again and got a significantly faster result. What you're seeing here is thermal throttling. So the guts of a modern desktop style computer looks something like this. There's going to be a heat sink, a big chunk of copper or aluminum sitting on top of a chip which has a metal top on it and between those two is going to be a bit of paste. The same thing is true if you open up a MacBook Pro. There's going to be a fan that's evacuating heat out from a heat sink which probably looks like a thing with a lot of fins on it. And sometimes you see these weird pipe things, these copper pipes connected to these aluminum fins but that's what that is, right? We're just trying to take heat away from the chip as fast as we possibly can. Copper moves heat away, aluminum is heat away very aggressively. Fans move that heat out of the area and then we can continue to dissipate power without burning out the circuits in the chip. The result is that a desktop class chip like the one in my MacBook Pro rated for about 45 watts of total power dissipation. It can scale up to about 60 watts of power dissipation. That's a lot of power. This is what 60 watts looks like if you were to hold this in your hand. I think you would get very uncomfortable very quickly. Maybe you're not as dumb as I am, but I've tried this. So you probably aren't going to be dissipating 60 watts in your hand, in your phone, right? That's going to be very uncomfortable. We're talking about heat transfer here, right? Like if the back of your phone felt like a light bulb you probably wouldn't use it for very long. So this is a major reason why mobile devices don't have desktop class performance. For the same process node and the same architecture with the same number of transistors the CPU that turns more power into heat is the CPU that does more math, right? So we probably need to figure out a way to do a lot less math to turn a lot less power into heat if we're going to keep our hands from burning on a day-to-day basis. So this is the inside of an XS5X. This is one that gave up the blue smoke a couple of weeks ago. Let's get it apart. And this was my daily driver phone for about a year. What you can't see here is that that little round circle is where the vibrator goes. That blue, sorry, that square cut out next to it is where the camera assembly goes. That's one of the hottest components in a phone. Below that is the power supply. And on the other side of that power supply on the same PCB on the other side of it is the system on a chip which is the CPU, GPU, baseband, processor, all that stuff. The memory and the radio, all in one assembly. So let's flip it over, take a look at it. There's no thermal paste on top of that CPU there. That's interesting. There's also, you'll note, I had to take that little aluminum assembly off that you saw on the other side, but it's not connected. There's nothing to connect it. That's not actually a heat sink in the normal sense. The CPU module, you don't see it here. It says Samsung on the top, but it is a Qualcomm chip. The CPU module is sitting underneath that Samsung chip because that Samsung chip is the RAM. So think about that for just a second. To get heat out of the CPU back out to the outside world it has to go through one layer of ceramics and then another layer of chip and then another layer of ceramics to air not assisted by anything else to draw it out. No fan. There's no fan anywhere in this, probably in any phone you own. Thank goodness, right? And this thing backs onto plastic. Two layers of plastic. Two layers of plastic. That plastic is a terrible thermal conductor. The thermal conductivity of plastic is about a thousand times lower than aluminum. Right? So in order to prevent us from burning up our hands we actually have to make sure that we don't run this thing to actually draw that much power. It can't do that much math. All of this reminds me of a paper I read a couple of years back. If you have a couple of spare moments I recommend it highly. It wasn't perhaps intended to be a prophecy about mobile devices, but it is. It tells us why so many of the transistors that are now in those eight cores that I'm carrying around on that Moto 4G are dark most of the time. They're not lit up. Why they're not actually doing useful work for me? And the reason is thermals and power. In fact, the reason that everything is slow is this. I can hold 2700 mAh in the Nexus 5X battery or 10 watt hours, roughly. Think about that in terms of powering a light bulb. You get a couple of minutes of light bulb power out of it if you could actually draw that much current at once, which you probably can't. Insert exploding phones joke here. So this is why everything is slow, because this is the primary limiting constraint on a mobile device. This thing has to power the Bluetooth radio, the NFC radio, the cell radio, Wi-Fi radio, chips, and screen, and you want it to last all day on something that can't power a light bulb for more than a couple of minutes. So everybody has an incentive to make sure that you actually aren't clocking those CPUs very high, that they aren't running very fast, that you're not drawing that much power. And it's much more complicated than this. These days what you're seeing is something called Big Little Architecture inside of these phones. What that means is that there's a couple of big cores and they have deeper pipelines, they have more transistors on them, they have more cache. Not as much cache as, say, the iPhone. The iPhone has, I think, something like four megabytes of L3 cache, one megabyte of L2 cache. It's a pretty beefy device. My MacBook Pro, for instance, has a megabyte of L3 cache. I think the part that's in the Moto 4G might have a megabyte of L2 and L3 cache total. So spending power, spending transistors on power, power on transistors is a big deal and you don't want to do very much of it. So these days we're aggressively moving computation out to these little cores. Smaller power, lower frequency cores, which can do a lot less math, but they are much more power efficient because the amount of power you burn is much more linear. If you scale up the frequency in a modern semiconductor, as that frequency scales up, you burn more and more and more power per gigahertz over time. And so schedulers do a bunch of things to try to make sure that this all works out. They try to aggressively move work around. They've got a lot of different strategies for this. Your desktop is going to use symmetric multi-processing. Your phone is going to use something like clustering or if it's very clever, there are several ways of thinking about each of those individual chips powering them up and down and moving work between them. We're finally getting to energy aware scheduling. There's something called touch boost as well. Touch boost is sort of like you put your finger down and then the phone spins all the CPUs up as fast as it can, the big ones, in order to give you the ability to do things like animate stuff very, very quickly. And then as soon as it thinks it can, it spins it all right back down. Now the normal way that you load a web page to do some stuff and then a couple of seconds later you get the body of stuff you have to start processing. You might have scaled the CPUs back down by the time you get that big bundle of stuff back. When you launch an app we spend a lot of time or OS has spent a lot of time trying to make sure that that app launches quickly. So they are primed to give you a lot of juice at the moment that you decide to launch a new activity or launch a new application. The web doesn't work that way. Our schedulers actually work against the web's basic workload but we've built them until today. And benchmarking is really a thing. You'll see benchmarks floating around about like, oh, this mobile processor is almost as fast as a desktop processor. Maybe. But you can't keep it spun up for very long. It's not going to be for very long. You're going to get thermally throttled. That envelope is going to close over you and then you will have to scale it right back down again. Else you're going to be holding a light bulb in your hand. Right? So all of this should make us sad. But it's worse than that because storage isn't actually even that good either. When you look at the read performance on my MacBook Pro, again, I get about 2 gigabytes a second at maximum theoretical transfer across the storage. My Nexus 5X, even though it has a nice flash storage component can only get 400 megabytes a second across that bus. What's going on? Well, in SSDs parallelism is king. We don't have to wait for the platter to spin around again after we move the head to get a read. Our latency is persistently low, which is awesome. But our throughput is based on the amount of chips that we can put in parallel and then distribute reads to because they're all going to have a particular size for each of the packets, if you will, that they're storing. So you can get a lot more read throughput if you can actually have a fast bus and then parallelize a lot. The Nexus 5X motherboard, there isn't a lot of space for extra chips. You can't parallelize. So you have MLC or TLC, which is to say cells on top of cells in three-dimensional chips now are very popular for storage technologies because they allow you to pack more transistors in, they allow you to run them at effectively lower power, but that penalizes you in terms of parallelism, which means that unlike your SSD where you can spread out a lot of chips you don't have that ability, and so everything feels much, much slower, especially when you're trying to read sequentially or large chunks of content. The controllers aren't as good. You don't have as much free memory to throw the controllers. You don't have as much power. The file systems are now optimized to some degree for this stuff, but even when they get full they still feel slow. Basically the way to think about a mobile storage device is that it's probably about the same speed as spinning metal from about 2010. That should make you sad. Okay. Then there's mobile networks. If you haven't I recommend checking out Ilegre Gorick's high-performance browser networking. They will also make you sad. The TLDR is a mobile network that hates you. They hate your guts. They really don't like TCP. They don't like what the way you use them, especially if you're in 3G. They have wild variants underneath your high-level protocol stack, which your high-level protocol stack is not tuned to understand. The Reno congestion control algorithms, the stuff that's built into our current modern TCP assumptions doesn't work well with a physical layer that we're assuming. We see wild variants in packet loss on mobile networks in ways that simulated networks don't really explain. As Ilya said, a 4G user isn't a 4G user most of the time. They're probably going to start from a lower power state. Radio resource control means that you may be spending seconds just getting that first packet across the wire if you come from that low power network state. This is really bad. Okay? I think it's only reasonable to be sad about this. The tools and techniques that we've brought over from the desktop area don't serve us in this environment. To make really great apps, we need to do things fundamentally differently. We need to match the expectations of the OS and of the underlying networks and of the underlying hardware capabilities. We need to load less script. We need to load it better. We need to make sure that we are doing work on demand and that we are able to meet the CPU when it's spun up. So Paul Lewis characterized this in a couple of graphs earlier this summer. Today we wind up with these big JavaScript bundles and then frequently they wind up feeling very slow if you render block with them or you put a loading bar like Gmail does and you feel like you've got a bunch of waste time at the front. When it finally evaluates you get a very fast application. Now I've heard a lot of application authors and framework authors tell me that this is okay because people then have these instant applications but maybe your interaction depth isn't very large and you're probably going to bail on that site. That double-click data is kind of compelling. You're probably going to bail if it takes longer than a couple of seconds to get there. So we're seeing framework authors do something that they think is very clever. They're saying I'm going to server-side render this. I'm going to do universal JavaScript. I'm going to start running this JavaScript on the server, spit and load that giant pile of JavaScript. Well, that sort of sleight of hand only works if you actually get that JavaScript loaded quickly enough but you don't. So instead you get a UI where you tap the glass and then nothing happens because the main thread's locked. Now maybe we can scroll for you because browsers are magical and they do threaded scrolling these days. But if you tap on it and it doesn't work, I submit to you as a web developer your thing is broken. It's broken. It doesn't work. So this doesn't work. What we really want is something that looks like this. We want to be able to load and run things at basically the time that we want to interact with them. We don't want to pay too much up front. We want quick interactivity for all the components that we can see and we don't want to be paying for stuff that we're not currently using. This is why purple is so darned important because it actually does what native app frameworks do. They delay view loading to the view transition moment. So this is the shop app which I'm sure you've seen a dozen times on a desktop class machine interactive 400 milliseconds. We've seen this story before. That's pretty good. 200 milliseconds of JavaScript. So what? It's going to be 10 times slower on a mobile phone. But here we're interactive at 1.75 seconds. On a 3G connection this thing is interactive in less than 3.5 seconds. This thing is amazing. And it's 1.3 seconds of JavaScript overall, except if you look at that right hand side all those little slices are chunked. That means that I was interactive at the end of the first big yellow slug. I was interactive so much faster because of HTML imports and the way they do small chunking. They allow the browser and the platform to schedule work in such a way that you can remain interactive much earlier. So the other thing about the purple pattern is that it adds a service worker. People tend to think that when we added service workers we were trying to solve offline. And we were. But the thing that I'm most excited about them for is getting to reliable performance. The purple pattern and the Polymer app toolbox give you the ability to always respond for a navigation out of the local cache. You never have to wait for that radio resource control to spin up the radio maybe over a couple of seconds to go do DNS and then TCP and then TLS and then HTTP handshaking to finally get you some content. Instead you can pull it out of the local cache and boom the variance goes down and it can also be faster. This is why service workers matter. Low variance, high performance, reliable UI. And you can see this. This is data from this year's IA web app. The light green is that first load experience. You can see it's a long tail. Networks suck. They hate you. That dark green, that spike up there, that's with a service worker. It moves all of that work to the front of the pack. That is reliable performance. That's where we have to be in order to be able to build compelling native competition mobile apps on the web. So how do you fight back? Please implement purple or as much as you can. Monica yesterday had ripple. Get as far as you can. Please. Only load things that you need for the current route. Install a service worker to prefetch things for your subsequent routes. Break up your work to the best of your ability. Push if you can. And then go by a 150 quid phone. Please if you can. If you can afford it. Please go by a medium priced, unlocked Android device. And then use Chrome Inspect to see how it works. Use Lighthouse. Lighthouse will tell you whether or not your thing is a PWA and it's going to have an increasingly good set of performance inspection tools. Webpageses.org is your friend. You can take traces from it. Use Chrome telemetry inside of your continuous integration if you have continuous integration. I hope you have continuous integration. And DevTools network and CPU throttling are really important. Okay. So a lot of people haven't seen how to use Chrome Inspect. So let's go take a quick look. I know I'm over time but just very quickly. This is the UI. I plug in a phone that has been unlocked for USB debugging. And now I get a view of this. If I go to the network tab, I can throttle whatever connection it's on. Regular 3G is a good starting place. And then if I go back to the timeline, I should be able to hit control R or shift open Apple R to do a hard refresh. I'm going to select also capturing the paint stuff. And then it'll start recording. It'll start running this thing. There is some recording overhead. But remember that that emulated mobile network is actually better than a real mobile network because it doesn't have the same variance. And so now I've got a trace. And I can inspect it. I can start to look at where things actually started to show up. You've seen Paul and Sam navigate DevTools. You can go back to the videos and see how best to learn about all of the things that are causing this to be faster slow. But the most important part about this is I can now right click and save this. And then I can send it to my teammates and I can share it with Drive or Dropbox. And we can start to understand our performance over time. Okay. We can then go back into the Chrome Inspector and we can load it back up. Any Chrome DevTools can load a trace that I've saved this way. I saved this one on the desktop. So let's go there. Great. And then slow me from yesterday. Loads it back up. And there we are. On any computer with DevTools I can see how this thing performed on a real device. This is pretty awesome. Okay. So there's also Chrome tracing but for Chrome Inspect but for tracing. Now tracing is the DevTools equivalent but it's a power tool. It is the thing that browser engineers use to diagnose the performance of things. When I use Chrome Inspect question mark tracing it gives that little trace button there. Now I can record. This is a UI that's again a power tool but it'll let you see every process and every thread of every process that the browser is running including all of your tabs and everything else that's happening inside the browser and it instruments it. Now Chrome is a multi-processed browser. The renderer process and the browser process are different. They talk to each other over IPC. This is the way that if you start working with a browser engineer we're going to ask you to do any trace for your application and then we'll dig in using this. It works almost exactly the same way. I've started to refresh the shop app here. I'll stop my trace when I'm finally done loading it. I can explore it. It feels very much like a video game. WASD get you around. You select stuff. It shows you what's happening. It takes a while to open but again the important part is that you can save your traces and you can load them back up and this is everything. This is everything Chrome is doing basically. It'll show you the CPU usage. This is the resources that I'm starting to pull in this case out of the service worker and this is what's happening inside of the renderer process. We can go select an area and see what was taking so long here and this will actually trace through HTML parsing, V8 execution and an ever richer set of V8 instrumentation. Lighthouse is amazing. Please use it. It's a Chrome extension. You can use it at the CLI. Paul showed it yesterday. Please go install it. And thank you so much for making fast websites that are reliably performing.