 Awesome. Thanks, guys. So I figured I'll share some tips and tricks about DevTools. In no particular order, this is just kind of a random picking of things that I enjoy. I keep learning new things about DevTools literally almost every day because they keep changing it literally every day. So I'll share the slides later. I hope everybody will find something interesting that will be useful to you guys for performance. A lot of the things I'm going to share about actually about performance. But before we even get into the specific demos, the first thing you should do is you should download Chrome Canary. So a lot of the features that I'm demoing today, I'll show you, are in Canary. That's where all of the cool experiments are. If you guys are developing apps, I would actually encourage you to test the stuff in Canary or at least kind of have your development workflow in there. So if you don't have it installed, that's tip number one. Tip number two is how many people here use DevTools on a day-to-day basis? Awesome. Okay, so that's like literally almost everybody. If you have people that or you want to teach somebody about DevTools, I just want to kind of pick up a little bit more tips, maybe you missed a few things, maybe you're not sure what the timeline is. We actually just recently released this course on CodeSchool, which goes through all the kind of major high points of how to use DevTools. So if you're trying to help somebody get started, this is a great resource, and likewise, just check it out yourself because you may be able to pick up a few tips. So that's, the link is there, it's a free course, definitely check it out, awesome stuff. So I've actually done a couple of these. I've done a couple of videos, if you guys want to learn more about these tips, you can check them out online later, they're all up on YouTube. And today I'm just going to do kind of, there's going to be some overlap, but I want to share some new and interesting things. So first and foremost, how many people here have customized their DevTools? Are you aware of their customization? Give you hands, all right, this is like the first thing they should find out. There's a little gear in the bottom right corner of DevTools, click on that thing. You'll discover a whole world of interesting things. So for example, I do a lot of network debugging, and this checkbox right here just saves me sanity because I'm never quite sure if I reloaded the page, that I hard refresh the page, that I pull in cache resource is my bug because I didn't hard refresh and I'm using old code, but I think I'm using new code. It's just a mess. In any case, check that box every time you refresh your page, it'll pull down the fresh resources. And don't worry, it won't screw up your actual browsing, because when DevTools are closed, you're still using your cache. So it's not going to affect anything else. Another one is you can now un-collect this button for Show Toolbar Icons, so if you remember the big icons for like Timeline and all the rest, it just becomes a little bit more compact, which is handy, kind of gives you more space to work with. A few other things, we'll actually talk about the GPU and rendering stuff, but you can find a lot of new things going in here. And you'll find a lot more things going over the course in the next year. So in any case, look through this stuff. There's lots of good things that you likely haven't noticed before. The second tip is, and this is new, this is new in Chrome Canary. If you go to, we added the experiments tab. So previously, we were looking at general. If you go to experiments, previously you had to go to about flags and you had to enable different things or start the browser. Now this is much, much easier. You go to experiments, and you have a lot of really awesome stuff in here. So for example, we have support for SAS, CodeMirror are the things. This is one of my favorites. So you can now toggle between all different panels in DevTools using command one, command two, or command number, whatever that panel is. So I continually toggle between Timeline and NetworkView, this is just my workflow, saves me a ton of time. Snippets, I'll show you in a second, really awesome stuff. So in any case, this is a growing list. There's lots of stuff in here. We're not promising that this stuff will stick around. It's basically us trying to figure out what makes sense, what sticks. You guys give us the feedback, this is missing, this doesn't work. Play with this. It's pretty awesome. So network timeline, kind of powering through this. So network timeline is where I spend personally a lot of my time. I tend to focus on kind of web performance and specifically first page load. So trying to help accelerate sites for how to get a good time to glass, as we call it, that first paint. So I find that a lot of people kind of, we've all seen this and it all looks familiar, but we actually kind of miss a lot of the information that's hidden in here. So for example, the stuff that's in gray, right, so size and content. And I'll be the first one to admit that this is perhaps not the best UI. Maybe we can do better. And maybe you guys can give us tips for how we can communicate this data better. But what's the difference between size and content, right? You can look at this line right here. The size is 10 kilobytes, but content is 41 kilobytes. Well, it tells you that there's Gzip compression. So this asset was compressed, so it's 10 kilobytes on the wire. But once we uncompressed it, it's 41 kilobytes when we're actually interpreting it. So this already tells you, you can just eyeball this thing and see if any of your resources are not being compressed, right? Which is kind of like the first thing you can do to improve performance at your website. So that's one. The second one is time and latency. So this is actually quite interesting. So time tells you the total time that it took to download the resource. And latency is just a wait time where you dispatch the request and you're waiting for the first byte to arrive, right? So if your request is queued for a long time, you can actually spot this here. So you can see that, for example, this request for general.css took in total 329 milliseconds to complete to download the whole thing. Except that, we spent 325 milliseconds waiting on the network. And then in four milliseconds, we did the whole transfer and got the data, right? So you're spending all of your time here waiting on the network. And likewise, you can actually restore it and do interesting things with the timeline. So I have an example here. I'm just, I have the CNN page here, right? Waterfall, we're all familiar with it. This is kind of a trick. It's not intuitive, but you can actually click on the timeline and you can restore it. So actually, you can see things like, well, I wonder which resource took the longest time to download, right? And you can restore it. And you can see that this hplib-min took nearly four seconds to download, right? So you kind of, you can quickly pin down which resources are slow. Or alternatively, you can say, well, I wonder which resources ended up waiting for the longest. So I sent the request, but I'm just waiting for the server to respond. So it's the same thing here. You can see that we've just been waiting to hear back from the server for three seconds for a lot of these PNGs. So this is actually likely, there's a lot of PNGs in here and they're all very small. It's likely because we've exhausted our connections and we're just queued. We're just waiting, right? So just looking at this actually tells you a lot of very interesting and useful information. Similarly, actually, you can pay attention or you should pay attention to the color coding. And this is one of those things where you really need to get familiar with DevTools and then once you know what these mean, you can actually diagnose a lot of performance problems very quickly. So for example, the solid line here tells me that I made a request for an HTML file and it took about, let's see, 1.5 seconds to download. And because it's a solid line, it was literally downloading for 1.5 seconds, right? Like I got the first byte and then I'm either waiting for more data or I'm receiving data. Whereas the one on the bottom tells you a different story. So this is the latency part that we just saw, right? So I sent a request and the request was waiting for a long time. And then at the very end, the solid bar actually tells you the true download time of that resource, right? So just looking at this, you can actually figure out what's going on. So first of all, we downloaded the HTML document. We're still downloading the HTML document, but the browser sends the request for the CSS file because we're parsing HTML in parallel or we're not waiting to parse the HTML to dispatch there are other resources. But then we're blocked on something on the server, right? So this helps you diagnose server problems as well. And if nothing else, there's actually a link here to kind of a quick gist that shows you that you can actually accelerate your pages quite a bit if you flush your content early. And what I mean by flush is, let's say you have a server that is generating the response, the HTML response of the body. You don't have to wait to generate the whole thing and then ship it over the wire. If you have just a header, ship was just a header because the browser will parse the header and start downloading the CSS and JavaScript and all the rest and then feed us the rest. So kind of a fun example that I'd like to share is Google search. It's kind of like an awesome hack that we have where we get the first packet, so you send us a query, right? You hit Enter. We get the first packet. We don't even look at what's in the packet. We just send you the HTML for the header of the search page immediately because we can. And the browser starts parsing that and starts fetching the CSS and all the resources if you don't have it in your cache. And only after we've sent that header, we actually look at the packet and we're like, okay, so what did you ask us for? And let's go back, query index and aggregate the search results. So this can do wonders in terms of your actual page load performance. It's not the most trivial thing to do, obviously, right? You need cooperation from your application server, but it's an important thing. So, how many people here are familiar with Har? Two hands, maybe like four, okay, awesome. So, this is like the power tool that you should be using for debugging network performance problems or anything to do with the waterfall. So, Har stands for HTTP Archive Format. And it's literally the data behind this waterfall. So if I go back to CNN, and I right-click in here, and you can actually say copy all as Har, and I paste it in. I get this 22,000 line file, which is all of the metadata for every single request that I made, all of the cookies, everything else, it's all in here. So what does this tell you? It tells you that you can export this entire timeline and save it as a file. So you can also, oops, let's go back. So you can also save it as a JSON file and you can attach it to a bug, right? I often get people emailing me saying like, hey, this page is slow, this page is broken. And they'll attach me a screenshot of the timeline like, well, I'd really like to know what the request headers are on this thing or what the response was and all the rest. By saving this file and attaching it to a bug or doing something else, you can actually recreate all of that data. And I'll show you a couple of examples. So you can save this file directly out of the network panel. Alternatively, there's a couple of different ways you can get it as well. So for example, there's this nice module called Chrome Har Capture, which allows you to capture the same thing from a command line, right? So you can actually export this file from command line and then feed it into some other tool. And I'll show you a couple of examples. Then if you have, for example, Ruby installed, you can gem install har and then just run this command har trace file and it'll actually open the viewer. So you can export any har file and then import it and visualize it. So here is an example. No, that's not the one I want. This should look familiar, right? This kind of, it's a little bit dated now, but it looks similar. If I click on this load sample har, this is a network timeline. And this is actually a web app, right? So DevTools itself is a web app. It consumes JSON data. It consumes this hard data and it visualizes it. So similarly in here, you can just drag and drop the har file that you exported and visualize all the data. You can click and interact with all the stuff. It's all the same functionality. It makes it beautiful to work with network level data. And we actually have an entire one hour episode on just all the many different things that you can do with har files. You can export them. You can make it part of your build process. So every time you check in code, the build spits out a har file, which you can then throw into an open source project like har storage. Har storage will then plot your response times and other things. So you get all of this trending just for free if you integrated with your CI builds and all the rest. You can also just convert a raw pcap file or TCP dump file into har. So there's lots of crazy stuff you can do here. So I definitely encourage you guys to play with it. Once you know what it is, I think you'll find yourself using it quite frequently. And I just showed you this tool. So this is a great work by Eric Duran. He actually, I think he built this with Angular. And it's just basically, he took the skin of Chrome DevTools, added a little bit of logic. You just drag and drop your har file into this web app, and it visualizes the whole thing. And there's other implementations of this as well. So really awesome stuff. All right, so moving on. From the network to, I guess, rendering and time to glass. One question that I often wonder about is when was the first time that we painted something to the screen? So not just when did we finish loading something? Because the page can take 10 seconds to load for all the assets and all the rest. But we could be painting something or the first content on the screen sometime earlier. So frequently, I would do something like this. Chrome actually has this, if you open your console and type in crowed load times, it will give you this fancy object with a bunch of different Chrome-specific variables. And one of those things is actually first paint time. So oftentimes, I'll be, I want to answer this question. I want to know the answer to this question. I'll go into the console and start typing crowed load times, first paint time, minus start load time. And it tells me that the first time we managed to paint something to the screen is about 180 milliseconds in. And to be honest, this is annoying because I have to retype this all the time. So we added a new feature in DevTools called snippets. So let me show you this. Actually, no, I need to hear. So if I go into sources, snippets is something that you just, this is independent of any given page. You can just store snippets of whatever you use in Chrome and then you can see that I have this first paint. I mean, it's a trivial example, but it's something that I run all the time. You can think of more complicated examples. You have it here. You press Command Enter, and it runs the code on the page in that context, which I find is beautiful and invaluable. So let's cross this guy. So that's snippets and first paint time. So really, really handy. This is in Canary now, so give it a try. I think you can do lots of cool stuff with it. Similarly, then I get my answer. And then I start wondering, what's slowing down the first paint? Can I make some modifications to my CSS, my structure of my markup, et cetera? You end up editing the sources panel. And then, of course, you have this question like, OK, I think I've made all the changes. What did I change again? Like, you've changed five things. We actually have, if you right click on any given file and sources, and you click on local modifications, it will give you a full diff of the changes that you've made within these files, which is quite nice. So if you weren't using this before, and I can tell you that I wasn't aware of this until fairly recently when I discovered this, wow. That was nice to know. All right, moving on, 60 frames per second. That's just for games, right? That's the question and answer, I guess, that I get most often. But it turns out that 60 FPS matters even for web pages. Increasingly so, because we're putting more and more JavaScript logic, more and more CSS styles, and everything else on the page, such that these things add up. And oftentimes, you can't hit 60 FPS with those effects. And you need to worry about it. Just recently, we were talking to Facebook, and they told us that on one of their apps on the timeline, they ran an experiment where they had, the timeline runs at 60 FPS, as you would expect. They intentionally slowed it down to 30 frames per second, and they saw their engagement drop significantly, just users interacting less with the timeline. They would not scroll as deep and all the rest. So these things matter. And if you do the math, right, 60 frames per second, we have one second divided by 60, that gives you about 16 milliseconds per frame. That's the total budget that we have to render for each frame, except that you can't use the entire 16 seconds, because the browser also needs to do its own work. Your JavaScript code may not be the only code that needs to run either. So really, and then, of course, 60 milliseconds on my laptop here is not the same 16 milliseconds on my phone. So you really need to allocate the budget and track it. So one way that we allow you to get a good glimpse into this is the timeline view, and specifically the frames view. In here, you can go in and hit record, and then just start interacting with your page. And what these lines tell you here is the time it took to render each frame. So these frames here are taking very little time, 1.82 seconds, so these vertical lines here tell you how much each frame took. So we're well under our budget, but then every once in a while, we have a frame that's taking much, much longer. And I'll show you some examples of this. But these frames is what we call jank. What that means is the frame took more than 16 milliseconds, which means we skipped the frame. We're not just painting anything to the screen. If you're running your code for 150 milliseconds or 160 milliseconds, we've just skipped 10 frames. And that's what translates to kind of that annoying experience as you scroll and all the rest. I certainly had this experience on the web where I come to certain sites and you start scrolling down the page and it just kind of feels like clunky, or it's like, ah, ah. And it's like, oh yeah, crap, I gotta turn off Photoshop and a few other things and I'm running out of memory. Turns out then you open a timeline and you start recording and you're like, nope, nope, it's all JavaScript. So better fix that. So here's an example. That's a more visual example here. So I have this little animation here, it just runs and I have this hard beat timer. And every time I click this button, I'm just executing some JavaScript code. And nothing really happens because I keep it under, it's just like three milliseconds or something. Actually, let me record this as well. So not so bad. Then I do skip three, which actually takes about 50 milliseconds. And you can see kind of these frames right here. And then if I start skipping 10 frames, I mean, this is the experience that you get on the web. It's really choppy. So let's stop and then we can look here. Actually, let's zoom in on one of these. And you can see that this frame right here took 180 milliseconds to execute. So this is us skipping 10 frames. So you can actually investigate this stuff and discover which specific, like this was a timer that fired. You can see the stack trace and what caused it and drill into your code and hopefully fix the problem. Here's perhaps a more interesting example. So we have a number of new tools that we've added that will help you track down and figure out, is it the CPU that's affecting me? Is it the heavy visual effects or something else? So let's go to this guy right here. So this is kind of a silly example. I'm just, it's a long page and as I scroll, the Chrome Logos moves, right? Nothing too exciting. We can enable the show FPS meter. And in the top right corner here, you can see that 60 frames per second. If I scroll, it kind of bumps around, but it's roughly 60 frames per second. Then I'll add some on scroll effects and all of a sudden you can see that the frame rate drops to 11 seconds. Let me add some CSS styles and all of a sudden I'm down to nine or 10. So this is useful, but we can do much better. So first of all, the question is, what's the problem here? Are we repainting too much every single time? Is it the CSS or JavaScript? So first, let's actually show paint, we'll click on the show paint rectangles. And now as I'm scrolling, you can see that the entire screen turns red and the red region actually tells you the area of the screen that is being repainted every single time. So ideally you should see a small section of your site when you trigger some activity to light up. Here it tells you that every single time I'm scrolling, I have to repaint the entire screen, which means a large upload to the GPU, lots of memory bandwidth, basically that's a bottleneck. Here's a new module that is actually really cool. So enable continuous page repainting. So what this does, it actually changes this box right here, I'll just toggle it back and forth. And it specifically makes the browser repaint the entire screen for every single frame. And of course now you're asking, like, why the hell would I want to do that? The benefit of that is now you have direct feedback for toggling effects and certain aspects of your page on and off to see which ones are causing the problem. So for example, right now with all these things disabled, it's telling me that an average frame, that full frame takes about three milliseconds or so to render, right? Let me add some on scroll, and now I'm scrolling. As you can see, the weight or the time it took to paint the page didn't change, right? Which is what you expect because we're just executing JavaScript. So the painting time didn't change but my actual frame rate has decreased. So this tells you that we're executing JavaScript and we're not blocked on the GPU. But watch this, now I'm gonna add some drop shadows and other things. All of a sudden, the cost per frame is approximately 20 milliseconds, right? So this is just me adding drop shadows and a few other effects. So toggle is back and forth and you can see the difference. Three milliseconds, drop shadow, 20 milliseconds. So you can use this to go into your DOM. You can actually click on any element and hit H, key H, and it'll hide it. And then you can scroll and you can do any, you can interact with the page and you can quickly kind of figure out which aspects of the page are causing the slow down. So a very, very handy tool. And that's what we just saw. So that's the continuous page repainting. So in elements tab, select any given element, hit H, it'll just hide it, it'll make it invisible and then you'll be able to figure out if that's a problem. Similar to the hard file, you can actually export the timeline data as well, which can be very, very handy, right? Oftentimes I'm looking at some problem. And I don't have time to kind of finish debugging it right there and then I can export it and I can also import it back into this tool and then interact with it later. So same thing if you're, if somebody's sending me a message saying, hey, could you take a look at this page? It's kind of slow. If you're not attaching a timeline, I don't know how to help you. If you're not attaching a hard file, I don't know how to help you. So these are just things that we use a lot on the Chrome team and I think you guys will find useful as well. Another really awesome tip that I learned about recently is annotations within the timeline. So within your code, sometimes it can be fairly hard to figure out like what is this callback referring to? What is this timer? You can actually timestamp these things and it'll add a new line into your timeline so she could figure out and say, I'm triggering this animation or I'm doing X, Y, or Z and you can then quickly pin it down on the timeline here as well as it adds an event in the timeline. So much, much richer data set to work with which is really handy. Memory leaks, no such thing happens, right? Not on our code. Turns out it does and unfortunately it happens all too frequently and we have a couple of useful, so first of all we have a full out ability to do snapshots and all the rest but you can take multiple snapshots and then you get a lot of objects in there because it's all of your code plus the browser code and all the rest but one thing that I think a lot of people miss is that you can actually compare it to different snapshots. So this is actually a demo page that we have. Let me just reload it to make sure that hopefully the Wi-Fi gods are with us. They are. Maybe. So this page, so we just reloaded the page. Our memory is clean. I'm going to go ahead and take a snapshot, right? So snapshot one. I'm going to run some random action here. I'm finished. I'm going to take another snapshot and now we want to compare the two snapshots so you can go, instead of looking at the summary mode of each one of these, you can actually go to compare and we're comparing to snapshot one, right? So we're basically getting a diff of two different states of the VM and you can see that at the top here we have the Spidem object and if you actually look at the snippet that I ran here it's creating 11,000 objects and it deletes 10,000 so it forgets to delete 1,000 of them and you can actually see it here, right? So we created 11,000, deleted 10,000 and the delta is we have 1,000 objects just sitting around in a browser here. So that could potentially be a memory leak, right? So this is a very handy way to figure out like run, capture a snapshot, run whatever logic your page does, take another snapshot and compare the diff and you should not see any unexpected code in there, right? If you've been allocating objects, this should be gone or if you've allocated some then they should be there for a reason. And we actually have a really good kind of 30-minute deep dive into how this works. Definitely recommend checking it out. So same thing for Timeline. So similar to what I showed you with Framesu we actually have the same thing where you can hit record and just start interacting with your page and it'll record the total memory allocation within the browser but we'll also give you counters for things like how many DOM nodes are there or event listeners or other things and you can kind of plot it here or you can even force a GC if you want, right? So you have lots of controls to figure out if you're leaking memory and if so hopefully help you find what the reason is. One tip that I do have is when you're doing this kind of debugging do use an Incognito window which is to say don't run it with all of your usual extensions and other stuff because it can add a lot of overhead and garbage noise into your data that makes it hard to figure out what's actually going on and that's actually a good tip for a lot of profiling and debugging in general. All right, one thing that very few people know is we actually have two different types of JavaScript profilers in Chrome. There's a structural and a sampling profiler built in and how many people here know the difference? Yes, no hands, awesome. So I did not know either and John, we did an episode with John McCutcheon where we sat down for an hour and actually talked through like what is the difference between a structural and a sampling profile? So the short difference or the short story you should go and watch this video or highly recommend it but the difference is when you run the profiler in DevTools, that's a sampling profiler which means that every 100 milliseconds or so we'll stop the world, we'll capture the state and then we'll let you run and then we'll stop the world, capture the state and let you run but there's breaks in there, right? Like you could be missing other things whereas a structural profiler actually captures the entire timeline and you provide the specific annotations in there. You have to use Chrome tracing to get at this data but it gives you another level of control, right? So you should always start with a sampling profiler just to get a feel for what's going right, what's going wrong and then you can drill in into a specific library or a specific chunk of code to see what's going on. And if you're not familiar with Chrome tracing in that episode with John we actually go into fairly good detail as to how to use it because the first time you open Chrome tracing I'll be completely frank, it was just overwhelming because it's a tool that we built for ourselves to use on the Chrome team. You'll see like hundreds of events in there, lots of threads and you're gonna go like what the hell is this? Once you figure out how to use it it's actually very, very handy. So here's an example. You can actually get visibility into low level operations of what the browser is doing. So for example, we won't just say JavaScript has been executing here you'll actually see that v8 call the specific function will give you a trace. If we're doing rendering or GPU uploads we'll show you that data. So you can get an unprecedented level of visibility into what the code is doing, how many times we've called each function and oftentimes you can actually click on any one of these parameters here and we'll give you the actual name of the C++ method that's being run. You can just copy that, throw it into your favorite search engine and in all likelihood you'll be looking at the source code of WebKit or Blink or whatnot as to what that's doing. And that sounds a little crazy but sometimes you have to do that to figure out what's happening. Especially I know that a lot of people that are building games often find themselves kind of going down into this route to figure out how can optimize my code. And similar to the timeline annotations that I showed you earlier you can also annotate your Chrome tracing traces by injecting these labels. So you can see that if you just run a function, right we would have just told you like okay, well v8 has been running a function for whatever 40 milliseconds but inside of it you can actually break it out and say like while I was running this chunk of code and that chunk of code and all the rest. So you can really figure out where the time is going which can be really handy. All right, moving to customizing. This is a crowd favorite, this is my favorite. I've spent way too much time customizing all of my text editors that I care to admit. So it was great joy to discover that you can do the same in DevTools. So DevTools is, it's a web app, right. So if you just open your whatever platform you use, if you just navigate to here you'll see that this is the default profile. If you have other profiles you'll live under corresponding profile. You can go to user style streets and can just provide your own CSS. So you can restyle DevTools in any way you like to match all of your color schemes and all the rest. In fact, there's an entire site, sorry you guys can't see the link. DevThemes.com which has a nice compilation of the many different themes you can just drag and drop into your DevTools to get different look and feel. So it's kind of silly but it's awesome. Another thing you can do is you can actually extend DevTools. So we provide a couple of different ways to do that. So the first one is audits. So audits, I tend to think of audits as a great way to automate things that you may be doing all the time. So for example, prior to a release I need to make sure that all of my links don't 404 or something silly like that. Or you want to have an audit for things like there shouldn't be more than 50 links on the page. Like these are real world requirements for some people. Audit allows you to codify that and just basically package it into a run button where you go to a page, you click on audits, you select whatever you wanna run, you click run and it gives you a report. And for example, this kind of a silly example here, this is all the code you need to create a new audit that looks at the font size on the page and reports whether any given text on the page is lower than certain font size. All right, so maybe not the most useful plugin, but it's terse and provides kind of good visibility into what you can do with this functionality. Similarly, you can also add custom panels. So you can add whole new chunks of functionality and I'll show you some awesome examples in a little bit where for example here, it's also very simple. It's for example, we're adding a font picker. So I want to click on a font, a web font and I want to know what the name of it is. So of course you could drill into CSS and all the rest, but here is just a very simple extension that we're providing where you get this panel here as well that says the name of the font and all the rest. So here's one example, topical of course, jQuery. So you can download this plugin, I think it's called jQuery debug and you can then click on any element and it'll tell you the jQuery data and the jQuery events that are attached to it. So yes, you can look at these events in your regular kind of like long list of all the events attached to a DOM element, but why not make it nicer? And this is applicable to just about anything. If you have a custom framework, custom code, you can actually just build these new modules into DevTools and teach DevTools how to interpret these things. So this can be a great life saver and a time saver I should say. This is an awesome one. So this is a great example of a panel. How many people here use Rails on the backend? Okay, so maybe 10, 20%. So this is a really cool plugin which allows you to not leave DevTools and get all of your performance data about database access, how much time each view took and all the rest. And of course it's not specific to Rails. You can apply this to Node, anything that can spit out data in a similar format. This just happens to be for Rails. So here you can see that we can toggle between views and database access and you can actually see that not only would you get the, oh the HTML page took 100 milliseconds to render, right? You can also go into the Rails panel and see the exact SQL queries that executed and how much time it took and all the rest. So very, very powerful and you can do lots of cool stuff with it. This is probably my favorite one. So as I mentioned, DevTools is a web app. It's a web app that consumes JSON data that happens to come over a web socket. So the enterprising crew at Square, square.com decided that they really like DevTools, they love working with DevTools and they're building iOS apps. It wouldn't be nice if they could use DevTools to debug their iOS apps. So what they did was they built a custom module for iOS that emits data as Chrome DevTools expect and then just feed it directly live into DevTools. So in this example, what they've done is they're actually feeding core data. So if you guys are familiar with iOS and they're basically looking at core data directly within Chrome DevTools. Similarly, they've done the same thing for all the network activity. So for every network request that comes out of iOS, they create a waterfall, right? So they're just feeding, this is a completely different data source. It has nothing to do with Chrome, feeding it into DevTools. So I think there's other opportunities to leverage DevTools and reuse the functionality which is really cool. One of my favorites, speaking of adding new panels and extensions is of course PHP Insights. I worked with the creatively titled Make the Web Fast Team at Google. And this is an extension that we developed. There is the web version and then there's the one that's packaged within Chrome itself. So you install this thing, you hit the run button and it analyzes the page and think of it as like a performance linter for your page. It'll look at the structure of your DOM, your images and other things. It'll tell you things like, hey, you haven't minified your file and your images are not compressed and you can do this to fix your page and accelerate it. So one example that I can give you is for example, running this on the CNN site tells me that they're not compressing their images in the best way. You know, if they applied a little bit more work, they could save 33% or 210 kilobytes of data if they optimize their images. But not only will we tell you that, we'll also give you the optimized content and I think a lot of people miss this. You can actually click on that link or just right click, click save as, overwrite your original asset and you're done. Like the optimization is done. So lots and lots of goodies in there and actually the team is currently working on adding a lot of new mobile oriented functionality in here. So you'll see it updated soon and that's gonna be pretty exciting. And of course, speaking of mobile, I didn't talk about anything specific on mobile and that's because after lots and lots of thoughts and trying to figure out how to surface all this data for mobile phones, we realized that we really don't need to because we just wanna give you all the same functionality, right? Like there should be no difference between developing an app for desktop or mobile. You should have all the same fidelity experience. So how many people here have used remote debugging on Chrome? All right, so quite a few. How many of you remember the ADB commands that you need to run to do the poor forwarding? Oh my God, right? Like every single time I need to run that thing, I'm searching for the damn string. So I'm happy to say that we fixed this in Chrome Canary. So this is really cool. So I'll show you an example. I have my phone here. Well actually let me switch to Chrome Canary. So we have this new page, Chrome slash slash inspect. And this is the page that just, it shows you all of the currently open tabs, right? So I have that. I have USB debugging enabled on this thing and if demos work, let's see. Plugging in my phone. Oh, look at that. Nexus 4. So a new entry popped up. This is a page that's currently open on Chrome on this phone. There is no more ADB TCP port forwards, whatever that command is. You can just click on inspect. As you can see, I was trying to top up my three CoU case SIM card, at which I failed, because they give you a 500 error when you actually try to pay them. That's awesome. So here we are. We're looking at, let's see, the elements tab. This is the actual page, right? So we're interacting with this page on the phone. So that's just, that just lives in Chrome inspect and that makes our life a lot easier, right? So all it takes is just plugging in via USB and I hear that it's gonna get even easier in the future. So that's really awesome. When you have all of the same things that I've described, access to timeline, you can look at the FPS counts, you can force rendering on each frame, all of the same features, which is really nice. Similarly, until very recently, you couldn't actually get the Chrome tracing data, which is that lower level access that I showed you previously. Thankfully, so John built this really nice repo that you can just check out from GitHub and all it takes is you basically run one executable. It attaches to your phone, you interact with the page, and then you stop the actual trace and it pulls down the trace, the full JSON file to your machine and you can import it into Chrome tracing on your desktop machine. So this makes life a lot easier for capturing low level data. And I think it's very important to highlight this. If you're building for the mobile web, and of course the question today is not if, because everybody is building for the mobile web, when you're building for the mobile web, you should test your site on the actual phone. So certainly develop it on your desktop, but then make sure that you at least take a run or two with your phone because, first of all, the CPUs in these things are different. The GPU performance is completely different. You may find yourself bottlenecked on things that you didn't expect. And then the other great thing that allows you to do is it allows you to use the real 3G and 4G network. So when you're testing on these things, disable your Wi-Fi and see how the page loads on real 3G and 4G connections because those connections are very different. If you think of mobile connections as the same as your Wi-Fi, you're gonna fail reliably in terms of delivering a great experience. There are additional latencies and other things that you need to take into account. But otherwise, the actual debug workflow is all the same, which I think is awesome. And then of course, at the end of this whole spiel, I'll tell you that I shamelessly stole all of these great tips from the breakpoint. So about weekly or so, Paul Irish and Addy actually have a great show. They bring in other people to talk about all the awesome things that are being developed within context of DevTools and answer questions and all the rest. So if you haven't followed this, I recommend that you do. There's some links for some of the shows that I found very useful. They're anywhere from 20 minutes to an hour long, depending on how much content there is. And of course, another show that I run is the Make to a Fast series, which is more web performance oriented. So if you guys are interested in that, of course, check it out. And that's it. There's the link to the slides. If you guys have feedback, suggestions, complaints about DevTools, let us know. Send all the complaints to Paul Irish. Yeah, any questions? First of all, thanks to the DevTools Peaks. Very, very informing. I think most of us know bits of this, but we're profiling a big project we're having, and we're having very big issues with remote debugging iOS. Do you have any feedback on how we could improve the Chrome on iOS, considering the remote inspection you just showed in Canary, for example? So anything in particular when you say problems with that? Remote debugging doesn't work at all in the newest iOS, for example. Okay, yeah, so there's some limitations there due to the platform. I think we're gonna address that in the newer releases. So both Chrome on Android and iOS used an older kind of frozen version of Chrome that's being addressed now. So we're migrating to the latest, like it's Chrome 25 and 26. So I think we'll have a much better story there. Thank you very much. Are there any plans to add a code coverage tool for JavaScript? So are there any plans to add code coverage? In what context for? Code coverage on the test lines. So we're very much agnostic, so we don't provide any sort of kind of testing functionality, right? No test runners and all the rest. That seems like something that you could definitely build a custom panel for, because there's no definitive way for what your test framework is or should be. There's many different flavors. I don't think we're really in a position to dictate what that should be. That seems like a custom extension that could be built, but I'm not aware of any specific plans. Great, thanks guys.