All right. Hi, everyone and welcome to this session, Getting to Know Web Inspector. It's the first of two sessions today about Web Inspector. The second session is right after this one and this session serves as an introduction to Web Inspector. So, if you haven't used this tool before or only occasionally, this is a good talk to really get started and get your hands on the tool. So, my name is Antoine [phonetic]. I'm an engineer in the Safari and WebKit Team and more specifically, I work on Web Inspector which hopefully makes me an-- a relevant speaker for this session.

I really, really love working on Web Inspector. And the reason I love it so much is that I've been involved with Web Technologies my entire professional career. And some may not remember that time, but there was a time before Web Inspector or tools of that [inaudible], of that kind, didn't exist. And that time was a lot more painful than it is today. And so, let me tell you how things used to work before Web Inspector.

You'd be working on your web content, your web app, your website, whatever it is that you're using and that's being powered by web content. And you encounter an issue and you try to fix it and take your best guess as to what the issues might be in your HTML or your CSS or your JavaScript, and so you'd be in your Text Editor, scratch your head a little bit and then eventually you think, "Okay, I think I got it. If I change this thing, type this in, everything will look much better." And then what you would have to do is you would have to switch context, go back to the browser, hit Command-R to refresh the page after the changes you've made in the Text Editor.

And that's just not an ideal scenario because wouldn't it be great if you could stay in the same tool at all times? And going back to about a couple of years ago, that workflow was also appropriate if you were developing an iOS app and you're using UIWebView to show-- to power some of the user interface of your application. And you'd be using web content and you'd be in Xcode, changing that web content.

And this time, instead of just switching to a browser and refreshing, you'd have to actually rebuild your app to send it back down to the device again, and that would start kind of a lengthy process. Xcode will package the content, compile any code that's required, send it down to the device, and it's kind of lengthy. And so all the time, whether it's coming from your Text Editor or from Xcode waiting for your app to be downloaded to the device, you don't really know if the changes you've made are actually the correct changes.

And then once the content finally loads, you have to start a little treasure hunt to get to the point of your app or web content where you think the issue arose. And so you keep going, you cross your fingers, you finally get there, and unfortunately, the bug is still very much there. So, every time that happens, there's just a little bit more added frustration and it's just not a good experience.

And so that whole scenario is the reason why we're making Web Inspector. Web Inspector is the Safari developer tool to help you diagnose, inspect, analyze, and fix any issue you may find in your web content. And what's really cool about Web Inspector is that it's a tool that runs on your Mac and you can target Safari on Mac, but it applies just as well to Safari on iOS and your native app running on iOS using UIWebView. And even though in this talk, we'll be using iOS mostly as a target, always remember that any feature you see will apply just as well to your native app on iOS or Safari on a Mac.

And so, the way we can remotely inspect pages on iOS devices is that you can just run Safari on your Mac, get your iPad or any kind of iOS device running Safari, tether it up to your Mac and then that's all you really need. You're ready to go and you can remotely inspect your iOS content. And you may have any number of devices, or in fact, you may be inspecting simulator so that you're just working on your workstation. And this applies not just to iOS Safari but also your native app that you built yourself, send it down to the device using UIWebView.

Okay, once you've set up, this is what you'll see. This is Web Inspector. And I think just like any developer tool, because these tools are developed for power users and developer will spend a lot of time using those tools to make their life better, this might seem just a little bit daunting.

We try to provide a lot of great functionality, and at first glance, maybe it's a little bit tough to get into. And so in this session, we're going to drill into this user interface and I'm going to walk you through it, give you a little guidance to show you how to use it the best way possible.

So, we'll start this session with an overview of the user interface and then we'll take a really hands-on approach so that you can learn about some of the core features of Web Inspector applied to three core tasks. The first one is something I like to call Inspection Tweaking where we'll be experimenting with CSS in our DOM structure to change the layout and presentation of our page. And then we'll start analyzing the network performance of our page trying to make the load time of our page the best as it can be or rather analyze it to figure out what's going on.

And finally, we'll get into code debugging, trying to work out some errors and some JavaScript that we wrote. So, I'd like to begin with an overview of the user interface. And to get started, I'd like to jump straight to a demo so we can just see it in action. Okay, so Web Inspector is not on by default in Safari. It's a developer tool and we want developer-specific functionalities of Safari to only be available when they're needed.

So, let me show you how to turn it on. I'm going to switch to Safari and I'm going to bring up the preferences, and let me zoom in just a little bit so it's up more obvious. We're going to switch to the Advanced tab and right at the bottom, right here, there's a special menu item called Show Develop Menu and Menu Bar. And as I zoom out and turn it on and off, you'll notice in the Menu bar that a new menu item is going to show up called Develop. Okay, so we want to keep it on, and at the moment, that's all we need to do in Safari.

Next, I'm going to switch to the iOS Simulator. Again, I'll be using Simulator on stage but this will work just as well with an actual iOS device or several iOS devices connected to your workstation. Okay, so in this case, what I need to do is go into Settings, then Safari, scroll down to the bottom to the Advanced Menu and turn on the Web Inspector item right here. What that means now is that this device, or rather the Simulator can be a target for Web Inspector running in Safari on the Mac. Okay, let's go back to the home screen.

And now, what I should be able to do is open Safari, navigate to one of my favorite websites on the internet, switch to Safari on the Mac and remotely inspect this web page. So, how do I go about doing this? So, I'm going to go back to my Develop Menu right here and when I bring it up, you'll notice the third item which is named iPhone Simulator.

And for any iOS device that's connected to your Mac and has the Web Inspector preference turned on, these devices will appear in this menu and you'll be able to drill into this menu to find specific WebViews that you can inspect on this device. So, in our case, we only have iPhone Simulator and it has a single application running, Safari, and I can just hover over the name of the web page and it will show me, as you can see in the back, it will highlight the WebView in question. So, it might not seem like a big deal when you're targeting Safari because the web page is always going to occupy the-- almost the entire screen.

But imagine you're working on an iOS app when you have several UIWebViews laid out on the page, it might be hard to distinguish which of this WebViews is the one you want to inspect, so this will make it really easier to pinpoint what you want to inspect specifically. Okay, so let me zoom out. I've picked this page and this is Web Inspector.

Okay, so let's zoom in a little bit on our Web Inspector and try to work out exactly what we can do here. The first thing you'll notice is that by default, Web Inspector will select the HTML of the page you're inspecting and show it's DOM tree right in the center.

So, how do-- how can we go about finding more about this page? Well, there are three main sections of Web Inspector. The first one is Resources and we've already got it selected, and then we have Timelines, we'll get back to that one later, and debugger, again, we'll get back to that later. Let's focus on Resources. And the three icons actually control the display of the sidebar to the left, which we call a Navigation Sidebar.

This button also acts as a toggle, so when you don't need the sidebar anymore, you can just click on it, removes it, click back on, and will turn it back on so that you can always control what's exactly is on display and customize your workspace. Okay, so depending on what I choose in this Navigation Sidebar, the content of the main view here is going to change. So for example, if I pick an image, the content here changes.

If I pick a piece of JavaScript, the content changes and so on. This is because there's a master-detail relationship between those two things. The sidebar is the master and the content is the detail, which is saying, "We want more detail about this resource," and it appears right away in the center.

So, one thing that's really interesting about the content here is that it's divided in three main areas. So obviously in the center, you got your source code or your DOM tree or your image. But at the top, we always have what we call the Navigation Bar, and what this lets us do is browse through the various resources that we've gone through. So, if I click Back, I'll be back on my-- the image I was previously on, and back again, I'll be on the HTML.

And going back forward, I can go back to my JavaScript. So wherever you are in the user interface and you want to quickly go back to where you were, you can just use the Navigation Bar, which of course has a short-- keyboard shortcuts available for it as well.

In the case of a DOM tree, you also what we like to call the Breadcrumb Bar, and what it shows you is-- let me pick a deeper element. What it shows you is the hierarchy all the way up to the HTML element for the currently selected element. So, I can go easily to the header or parent div of the body and this would be the HTML element. Okay, now let's focus at what we can see at the bottom.

Here, we have what we call the Quick Console and it's a piece of user interface where you can just type code wherever you are, whenever. And it's got two appearances. The default appearance is just a single prompt. But if I type things in it, I immediately get an additional console log showing right up so that I can see what I've just evaluated so I can type something else, and you can see that. And you can toggle this Quick Console on and off by just using the Escape key. So, it's really easy to get more information about your console or just collapse it so that you just focus on the prompt.

Okay, so that was the Content Browser. Now, what about those three-- those four icons to the right? Well, the first thing I'd like to show you is that how these things would change depending on what kind of resource I'm inspecting. So, if I go back to inspecting an image, you'll notice that I have a single button here called Resource. But if I go back to my HTML page, I have more items.

The reason we have more items is these control the display of what we call the Detail Sidebar. It's a sidebar that displays to the right. In this case, I'm going to select Styles, and this will show the Style Sidebar. Again, there's a master-detail relationship which is going deeper down.

The master is the Resources Sidebar, we'll pick a resource which, in this case, is an HTML file. This is the detail of the resource and we can have even more details about this HTML5, HTML file by using one of the Detail Sidebar icons to the right, so I can drill into styles information, note information, resource information, and this is really only contextual to whatever is in the center which is itself selected from the right. So, there's this right to left drilling of details. Okay, again, these act as toggles and it's really easy to customize your workspace.

The last thing I'd like to show you is this in the middle which we like to call the Activity Viewer. Let me reload the page so that the Activity Viewer fills up with more interesting information. And I can reload the page just by running Command-R, I don't even have to switch to my iOS Simulator or in fact to iOS device, you can just do it remotely from Web Inspector.

And in the center, we have the load time. Here, the page has some difficulty running, actually, sorry, it has-- I'm really sorry about that. Okay, this shows us the load time, the time it took until the load event fired on the page. And as you could see, it kept running until the page was fully loaded, and that's a great metric to keep an eye on as you work on your page. And these are always available, so you always have a quick idea of how many resources you're dealing with, the complete sizes of the page, and the amount of time it took until it loaded.

And those three items to the right are only relevant when there are messages in the console. The first one will be for console logs, the second one for errors, and the third one for warnings. We'll get back to those later. Here we are, we took a full tour of the user interface and I think this makes you a little bit more familiar with the Web Inspector.

So, let's recap what we just saw. This is the user interface of Web Inspector and it split into a series of subsections. So, we have a little coloring going on here so you can see what I'm talking about. And so let's recap what each of those are. First, at the top we have the Tool Bar.

We have the buttons to the left that control the Navigation Sidebars and to the right, the Detail Sidebar. And to the center, we have the Activity Viewer and always on dashboard, it lets you know how your page is doing, how many resources it has, how long it took to load.

And when we toggle the buttons to the left to control the Navigation Sidebar, we can see the sidebar displayed to the left, in this case, the Resource Sidebar. This controls what information is displayed in the center of the Content Browser, which is split in three sections, the Navigation Bar, the content itself, and the Quick Console at the bottom which you can expand and collapse by pressing Escape. And finally to the right, we have the Detail Sidebar toggled by the buttons to the right of the Tool Bar, and this is our user interface.

So, let's start digging into actual tasks and see Web Inspector in action. And I'd like to start by going through inspection and tweaking. And let me go back to demo again so that we can look at what we can do with Web Inspector to modernize a web page to make it feel more at home on iOS 7.

Okay, so I'm going to open Safari, get rid of the page that we were previously on and open a page I created just for this demo. Well, that page may look familiar to you. This looks like a page of iTunes trailers. And I took that page and simplified it just a little bit for a purpose of this demo.

And what I'd like to do is, in this demo, is to make it a little bit better for iPhone. I'd like it to fit the viewport of iPhone so that you don't have to zoom to like, to look at the content. And I'd also like to make it feel a little bit more like it were a web page trying to mimic the aesthetics of iOS 7.

Okay, the first thing I'm going to do obviously is switch to Safari, open Web Inspector for this page and-- okay, let's get started. The mission here is to always remain in Web Inspector, never switch context, and make all the changes in this one session of usage of Web Inspector.

So, the first thing I'd like to do is remove the background of the page. I just don't think this picture here looks right. It's landscape and I want a portrait kind of experience. So, what can I do to make this better? Well, I got the body element selected here and I'm going to open up the Style Sidebar so I can control that CSS properties applied to this element. And so this might be familiar to you if you used Web Inspector before, but the Style Sidebar is just so much better in Web Inspector in Safari 7.

Now, we can just simply click here and edit as if we were in our own Text Editor. In this case, I'm selecting all the background related properties and by hitting Delete, I'm just going to remove them all. So, let me zoom out so you can see what happens when I do that, delete, the background is gone instantly. I didn't have to reload, I didn't have to save anything, I didn't have to go back to my Text Editor and reload the page, this is all happening live.

Okay, next, I think there's an image on this page that would work great as a background image. It's this little poster here and it's got the right aspect ratio. And so what I'd like to do is make it the background, and because eventually we'll want to add a blur filter to that image so that it looks like an iOS 7 kind of background, I will make it-- I will keep it as an image and try to move it to the top of our DOM structure.

Okay, so let me do that, and the easiest way I can find out where that element is in my DOM tree is I can use the Inspect button in the Tool Bar and what this lets me do is tap on any element on the page. And, again, remember this could be in your iOS device. You could be interacting with it in real time. And by just tapping on it, it will reveal the note right in Web Inspector. So, here it is, we have an image and the hierarchy above it. Excellent. So, let's take that image and move it to the top.

So I suppose I could use a Quick Console and write some DOM code to remove it and put it at the top. But this is really not the most intuitive way we could do it. The most intuitive way on OS X would be to just drag it and drop it somewhere else in the DOM tree.

So, let me do that again. Just to show you, I'm going to use Command-Z to undo because we support undo and redo, and redo it so that you see the changes I've made. Excellent, the image is now at the top of the page. It's kind of small. Oh, yeah, well, it's got an explicit size, and I probably want to change that.

I just double-click on the attribute and I can just start editing it right away. So, let me type 100 percent, again changes are instant. Well, the Hide is set as well and we're going to just get rid of it such that it will match the aspect ratio of the image.

Okay, well, there is kind of a problem here because the image is really low resolution. You can really see it's all pixilated. So, if I go back to where the image was hosted, it was inside of an anchor element pointing to another image. Oh, let's see what that image is.

I'm just going to click on the URL and because it's not a resource of the web page itself, it's linked from the web page, this will just download to my desktop and open in preview right away. And I can see this image as much higher resolution and I think I just like to use that.

So again, this is just so easy in Web Inspector. I can just double-click on the attribute and selects automatically the text. I'm going to use Command-C to copy it, double-click on the Image Source and paste. And if you pay attention to the left, the resolution of the image is going to be so much better right away.

There you go. Excellent! So, this is starting to look a little bit better. You know what? I don't think I need this Info panel anymore. It's just too much information. I'd like to really focus just on the trailers. So to find out where this menu-- this info element is, instead of inspecting-- using the Inspect button, I'm going to just rollover to various elements in the tree and instantly, it will point to where these are painted on the page.

And until I find the right element which is this one, I'll just poke around, select it, and delete it. Again, I can undo this by just doing-- pressing Command-Z and redo it. So even destructive changes like that is something you can go back and correct if it was not what you wanted. Okay, things are coming together because another thing I'd like to do is to have the page really match the viewport of iPhone. I should make sure that it has the right viewport setting.

So let me click on the head here, and I'm going to use another great feature of Web Inspector and just like you can free form CSSEdit, you can edit HTML into free form way as well. So I'm going to Control click to bring up the Contextual menu and press Edit as HTML.

And what this will bring up is the small HTML editor right within my page again and I can just start typing name viewport content equals width equals device width, and just to press Tab to make it work and there it goes, it applied directly. Awesome! So you notice there are two things are just wrong now.

First of all, the menu is completely gone. I don't know where it went. We'll get back to that in a second. It's also there's annoying margins around the image. That's just something I need to touch on the body and I can edit the style of the body super simply, I can just type here and it's just ready to go.

So let me just type margin and the CSS Editor auto-completes, it knows all the properties are-- that are available inside of WebKit and in fact, it all knows all the properties that are available to this specific version of WebKit because Web Inspector talks to WebKit directly, it's like your window inside a WebKit. So let me use Autocompletion here and type 0-- let me just zoom out so you can see, as I press 0, again, instantly, changes are made.

I'm-- okay, so let's figure out what happened to the menu. So, if I select-- hover the menu here, you'll notice there's nothing highlighting on the page. The menu is definitely gone. So, I can just simply inspect the CSS to find out when we had-- what may have happened.

And I'll notice here that I have a left property set up on the menu to be something slightly convoluted but let me explain to you, what it does is that it positions the menu to the center and then it will move it 480 pixels to the left. That was great with the previous version of the site that we had. It's no longer accurate for what we're trying to do now. We've set up the viewport to be the device width of the iPhone, which means it's now 320 pixels, so these values probably amount to something that's going to be negative and our menu is just off page.

So to validate this theory, I won't even have to write any code. What I'm just going to do is click on the checkbox next to the rule and that's going to comment it out temporarily. So let me just click on it and here, directly, you can see that without that left property, everything looks like what I expect. So, I'm just going to keep that and I also I want to change the top value to be 0. And let me change the width to be 100 percent, and now my menu is starting to look like what I want.

Okay, it'd be great if it was just a slightly more revealing of the background and I think it's hard to tell what the background looks like at this stage. So here again, I'm going to use a DOM tree, use the arrow keys to navigate until I find the things I want to edit.

Here, I'd like to change the title to just say "Trailers," not view trailers. Again, just double-click, edit, return, you're done. And let me [inaudible] as well. Here, again, super simple. Start typing text-align, press Escape and it automatically knows all the values I can use for this property. So let's go with center.

Okay, much better. Let me just make it a little bit less opaque. And so to do that, I'm going to use another great feature of Web Inspector. And since I'm editing a numeric value here, I can use the Option key and the Arrow keys and I can just start decrementing and incrementing this value. So I'm going to zoom out so you can see it in real time, option down, option up.

Okay, I got-- and again, instantly, instant feedback about the content on the page. And let me change in the similar fashion, the gradient applied to the menu content. Okay, how does it look? It's a lot more revealing. We're getting there. And the last thing I want to do, like I told you, is I want to get rid-- I want to make the background blurred so that it looks like an iOS 7 backdrop. So, I want to hide the menu here so I can focus in the background, and it's really easy to do in Web Inspector.

There's a key shortcut you can use at anytime when you select an element in the tree and just press H and it's going to disappear temporarily, we'll just apply some style to make it not visible. Okay, so let's select the image and I'll add a new rule to that image and automatically, it creates the selector that matches that element.

And let me type webkit-filter: blur. And so, let's play around with that blur a little bit. Let's start with five pixels. And here, again, I'll adjust it with the Option key and the arrows until I get the right amount of blur. I think 10 pixels just looks awesome. Okay, I think we're done. Let's go back to the Menu, press H to turn it back on.

It's almost right but there's something wrong. The images are blurred here as well. And if you've paid attention, you'll notice that the rule that we added for the image was a little bit too generic. So let's change it. Here, instead of having image, we want to have a more specific rule.

So let me just cut this property, add an ID to this element so that we target just the background specifically, add a new rule again, and this time, it will create an even more accurate selector for this element because it knows that it's specific image, it's an image with ID background.

So let me paste the new rule and you'll notice as soon as I paste the new rule, the background will blur and the content will remain sharp. Perfect! This is it. This is what I wanted and I could do it all within Web Inspector. I never had to switch back to my Text Editor, never had to reload, this all-- I could just experiment to my heart's content within Web Inspector. Mission accomplished.

Okay, let's recap what we just did, inspection tweaking experimentation. Well, the first thing is as soon as we open Web Inspector, you were presented with the DOM view of the web page. And if you think back to viewer source which has been around forever ever since browser existed, this is kind of the same approach except everything you can do with this source is live. You can edit it right away and all the changes will show up instantly on your web page. It's just so cool.

And what's really great about it is that you never had to leave Web Inspector. You can tweak and you never have to reload or rebuild. Again, think about building an app using Xcode that has web content, you would have to usually rebuild. Here, you don't have to. You just use Web Inspector, connect to your iOS device, and you're good to go.

And it was really easy to find the content that we wanted to inspect by using two different techniques. The first one is we used the Inspect button from the toolbar and just tapped on the item on the page that we wanted to inspect and it revealed immediately in Web Inspector.

And another way you can do it is to do it the other way around. You want to select things in the DOM tree and see what they match on the web page. And so you can just hover DOM nodes in the DOM tree and they'll highlight right away on your page and your device. That's really great.

And finally, anywhere you see code, whether it's CSS or HTML, we're just able to click and start typing. And in the case of CSS, it knew all about the support of-- the support of CSS properties on our page and it let us have autocompletion, syntax highlighting. It's just such a great editing experience right within Web Inspector.

And so, I really think this idea of experimenting with Web Inspector is something that's just so much fun and it's a great way to learn about the capabilities of CSS in the browser that you're inspecting. And just this morning at 9 a.m., you may have seen it. If you've missed it, you can catch it later on video.

It was a great session and we went through a lot of new CSS features made available in Safari 7 and Safari on iOS and iOS 7. The session was named "What's new in Safari and WebKit for web developers," and I urge you to check it out. It got some great CSS content and some great things you could experiment with within Web Inspector.

And if you stay in this room right after this talk, we're going to go in much greater details about inspection tweaking within Web Inspector. We've only really scratched the surface here. There are so much more to see so stay tuned and we'll get-- we'll show you a lot more. So, that was inspection tweaking. Now, let's move to network performance analysis. And here again, I'd like to tell you just a little bit of a story here.

I think we're all here aware that mobile devices are a really important target. It's how a lot of people-- it's, you know, I have my device in my pocket, I hear about something, I want to check it out right away. I don't want to wait until I'm at my desktop. I just want to go and look at it right away.

And so, a great experience in mobile is an experience where things load quick. And a way to get things to load quick on your web page or your web content in your iOS app is to have as little and as few resources as possible. That's a great way to get started. So, obviously, you have to have an HTML page, some CSS and some JavaScript if you want it to look really good, and you also want it to be a little interactive.

And you also want to distinguish yourself from other web pages and, et cetera and have a little themeing so you have some images, maybe one, maybe more than that. And if you manage to keep it down to this small number of resources, you're probably on the right path.

But I don't think this is something that we can deal with in the real world so much. The expectations of devices like iOS device is just so high in terms of quality and experience and the capabilities of those devices are just so astounding and improved every year that we want to do more. So then, you'll probably start using some JavaScript library from the network and maybe some other images that you're loading from a third-party service and then you're-- surely enough, you're starting to have a lot more resources.

And on top of that, those resources may not be under your control. Again, you may be using some JavaScript library loaded from a CDN or images from Flickr. And these are not things that you control, you don't know exactly what size is going to be in advance or the quality of the service is going to serve them.

And this is just kind of a complex situation. And it would be really cool if you could just find out how things get loaded and understand what could be potentially a load issue with your page that would impact the initial user experience for a user. Well, this is when Web Inspector comes in. And using the Timeline's panel, we're going to look at how we can keep track of resources using Web Inspector.

So for this demo, I'm going to go back to the developer.apple.com, WWDC page. So load it up in the simulator, switch to Safari, bring up Web Inspector, and let's switch the Timeline's panel. This is what we're interested in this section. And the first thing you'll notice as it loads is that it's completely empty. Well, the reason it is empty is that for the Timeline's panel to load with useful content, WebKit needs to run some special instrumentation on the page as it loads and runs.

And we don't want you to be running this code at all times. We only want to run this code in WebKit when it makes sense. It might have some performance issues. It's only really useful for instrumentation. So, what we're going to do here is we're going to reload the page with Web Inspector open and the Timeline would populate as soon as we start loading.

The other thing I'd like to point out is that not only can I do Command-R to reload the page, I can even do Command-shift-R and what this will do is that it will reload the page while ignoring the cache. This is very important if we want to diagnose network related issues, we want to test the full load of the page and not just things that haven't been cached yet.

So, Command-shift-R, page starts reloading and the Timeline is populating. Okay, recording is done, and this is what we're presented with. So, we're going to look at this in more details. The first thing I want to show you is that these timelines here at the top are split in three different categories.

There's first, network request in blue, layout and rendering in purple, and JavaScript events in orange. For the purpose of this talk, we're going to focus on network request. In the second session right after this one, we'll go in much greater detail in the layout and rendering section. So if you want to find out more, stay tuned.

So let's get rid of this sidebar for now. We want to focus on the content. Hide this, and you'll notice first that we can see there is some color coding in the list of resources loaded right here. Blue means an HTML page, green means the CSS page, orange means the JavaScript piece of script, and purple means images. So, at a glance, you can tell what's loading without necessarily having to look at the name of the resource. It's really handy.

Okay, so another thing that I'd like to point out is that I'm actually simulating a 3G network on this computer, so that it doesn't looks as fast it would be on a hardware network. And when you're using 3G networks or worse if you're using an EDGE network, latency can be a big problem. And for those who are not aware with this term, latency is the amount of time that elapses between the moment WebKit asks for resource and the moment the server starts coming back to us with the resource and when it starts loading.

And latency might be a lot more important than the actual load time. The 3G network is usually pretty fast downloading content once it's established the connection with the server. So, to illustrate that a little bit better, let me select the first item on the page which is the HTML page, let me select it, let me get rid of the Resource sidebar for a moment.

And you'll notice here that the item on the timeline split in two sections. First is a semitransparent section and a fully opaque section. The transparent section is latency, and it's just so much more than the actual download time of 376 milliseconds out of a total of 412 milliseconds.

That's just a lot of time spent with-- just waiting on assets to actually start downloading. So this is a good indication of how important it is to try to reduce the amount of resources you have on your page. So, if you're using CSS in multiple files or JavaScript in multiple files, maybe you should consider concatenating them into a single asset so that you have fewer assets to deal with and this will improve the load time significantly.

Okay, so let's keep looking at the timeline and find out more. You'll notice that there seems to be a sequence of things happening. We have this first resource loading upfront, and then other resources loading after that. Why do they load only after the HTML? Well, that's pretty obvious. The HTML will link to CSS resources, JavaScript files, and images. And until we've loaded and parsed the HTML page, we don't what other content we need to load.

So there's a sequence here and a dependency established on the HTML to load these first two style sheets, these few JavaScript files, the CSS file, and a couple more images. And this is the core content of the page, it's the content that the page needs to load upfront to make sure it instantly has a great experience to get going.

And so, that's a great approach. You want to have your initial content load right upfront and any secondary content load afterwards. And in fact, this is what this website does. You will notice there is another sequence of images load-- of images loading later on. And these are queued by a style sheet as only loaded afterwards, so that we first get the main part of the web page. So these will be the big WWDC image.

And more or less interesting images will be loaded right after. So we can jump and see for example here we have a little Apple logo but it's not as important as in the great WWDC logo in the middle. Okay, so that was a brief overview of the timeline for networking resources.

And what we saw here is how we can visually see on the page with a great graphical representation how different resources load on a timeline. So we don't have to guess, we don't have to look at a table where it just lists start time, end time, or anything like that, we can just visualize those things, and that's really makes us understand at a glance how things get organized on a page and load.

And the second thing is that we make it really easy to distinguish latency and the download time. Again, latency is not your friend on the mobile network. It's important that you try to avoid having too many resources and you can figure that out really easily using Web Inspector.

And thirdly, we could really identify dependencies and the sequence of how things load on the page. And this is really great because, like I said, you really want to make sure your initial content loads upfront and any second secondary content only loads afterwards so that your initial content loads as fast as possible. And to validate that technique, you can use Web Inspector and its timeline to make sure things load in the sequence you expect.

So again, stay tuned. On the next session, we'll have lot more about the Timelines panel, we'll be looking at layout and rendering. So, if you want to find out more, stay in this room for the next session. And on the topic of performance, even though it's not directly related to network performance and more about layout and rendering, there's a great talk tomorrow morning, we'll be discussing how to optimize power and performance for your web page, 9 a.m. in Russian Hill, be there. I will be. Okay, let's jump to the last section, debugging. And here, again, we're going to go straight into a demo and see how we can use Web Inspector to debug issues with our JavaScript.

So, for this specific demo, I've prepared an update on the initial demo that we we're looking at for Monsters University. So let me jump straight to that page. And what I did here is that is wanted to go further in the iOS 7 experience and provide a new header with white background and I wanted the user to have to tap this back-- to tap this header such that it would reveal the list of trailers with a neat little animation.

Okay, so, again, bring up Web Inspector, jump to Resources sidebar, reveal our HTML page, and what we did here is that we added a little piece of JavaScript whose role is to toggle a specific CSS class on the documents body, the class is called Showing Trailers. And let me just see what that would look like when it's applied. And I can do that very easily.

I'll jump to the DOM tree from the source code. I'm going to select the body, edit as HTML, and I'm going to add the CSS class on it so you can see what it will look like when the CSS class is applied. I'm going to hit Tab and you'll notice immediately on the site how it changes the rendering. And so, we have an animation going as soon as we add this class.

Let me undo it, redo it, and you'll notice as we have this animation, the background will blur and the content will slide down. So, this is kind of cool. Let's see if this actually works. So, I'm going to reload the page and the first thing you'll notice is that in the Activity Viewer, we now see that we have an error.

Okay, let's bring up the Quick Console and we could have brought that up by just clicking on the Activity Viewer but here, I've used the Escape command so I don't have to get rid of the source code that I was looking at. And you'll notice right there they will tell me exactly what went wrong, syntax error, unexpected token, closing parenthesis. This in itself is not that useful. I'd have to hunt it down.

But of course, Web Inspector makes that easily-- easy as well. It just tells me what file the error happened and on what line. And I can just click on that and I'm going to zoom out and I will jump straight to the line in question and highlight it. So, it's red, letting me know there's an error.

And what's really cool about any kind of source we show in Web Inspector is that we always have syntax highlighting. So here, if I bring my cursor to this closing parenthesis which just seems to be the problem, clicking on it will highlight it in red. And you'll notice there's another piece of code highlighted in red here and it's the opening brace.

So it looks like this closing parenthesis is expecting to match something else, and sure enough, in my function declaration, I forgot to close using a closing brace. So, let me type that, and right away, it will show in blue, meaning everything is cool. All right, I probably fixed my first error. So, let me just reload the page and it seems like you have a second error. So, let me jump again to the Activity Viewer by just-- by the console-- sorry, by clicking on it.

I'm going to bring up the Quick Console and here, it says-- oh, I forgot to do something, right. There's something really great that I forgot to mention is that when we add our closing brace, we actually need to save that file for-- in order to be able to reload the page as script and it needs to be reevaluated.

So, what I can do here is, for the first time, within Web Inspector, I can just tap Command-S and because I'm editing a local file, I'm prompted to override the existing file, save it, replace it, and this file will now be used as a version that's loaded by the web page. So, this time let me clear the console by pressing Command-K and reload.

This time, I will not get that error, instead I get a different error. This time-- this is the problematic line. Let me bring up the Quick Console again using Esc and it says, "No, it's not an object." Okay, let's jump right again to the error in question, which is further up.

Let me scroll up a little bit, scroll here. And, okay, so header is null apparently. Let me just set a breakpoint so we can figure out what's going on. So, I'm going to bring up the Debugger sidebar, set our breakpoint here, and make sure breakpoints are enabled by clicking on these icons right here which will turn gray to blue, which means my breakpoint is set. So, next time your page is going to load, if there's an error on this line, I will pause automatically in the debugger, so let me reload again.

And this time, I'm pause executing at this specific line, okay. So, indeed, now I have a different detail sidebar which automatically came up called Scope Chain and this will let me take a look at all the variables available in the current scope. In here, I can notice that the header is indeed null so there's no way I can pull a function on it.

Okay, so what can I do to work that out? So, I'm going to bring up the Quick Console again, and what's really awesome is that I'm just going to be evaluating script right where my script is paused and understand what's happening. So, for example, I can type header and indeed it's null.

Okay, well, let's try the document. Surely, we'll have a document object, right? This is kind of-- if you don't have that, there's nothing you can redo. We do have a document object. Well, does it have any children? So, let's look at document.body, that too is null. Let's go back to the code and find out what may be going on.

I think I understand, the problem is the script is in line "the head element" and it executes as soon as it's parsed. But when it's parsed, the rest of the page that has not been parsed yet, so even though I'm trying to get a pointer to my header in the DOM, the DOM is not ready yet, it hasn't been parsed. That should be fairly easy to fix.

Let me resume script by clicking on the Play/Pause button at the top and change the source code. And what I'd like to do is make sure I only evaluate this line of code when the DOM is ready. And there's really helpful DOM event that gets triggered when that happens which is called DOM content loaded and let me just call that function when that happens.

Again, I'm going to save, turn off breakpoints. I don't want to pause anymore because I think I fixed the problem, reload the page, I clear the console again with Command-K to make sure there are no errors as it gets loaded. And this time, no errors triggered. Okay, looks like I'm in business. I'm just going to click on the trailers and the menu is just going to magically appear for sure.

Well, I click and click and nothing is happening. Well, it's not quite right, something is happening. I get errors in my JavaScript console yet again. So, you know what I'm going to do this time is-- I don't even want to know where the error happened, I'm going to turn on the debugger to stop all uncut exceptions.

That means that any time there's an exception happening in JavaScript that hasn't been caught programmatically in the code, the debugger will automatically kick in. So let me turn that on, and without even having to reload the page because I can run this code again live, I'm just going to click on trailers, and as soon as I click it, again, I will break in the code.

So what's going on here? Well, so I can use the Scope Chain to take a look at the various values of my local variables or the Quick Console to just start evaluating code but something new that we added in Web Inspector in Safari 7, which makes even easier, is I can just mouse over different tokens in the code and I'll instantly see where they evaluate to. So the document is available, it has a body this time so what I did in the previous stage worked. I'm evaluating code when the DOM is ready.

And-- oh, this doesn't work anymore, classes is undefined. Well, I guess there's no class' member on documented body. And so since I'm broken into the debugger, I'm going to start experimenting and writing some code to figure out what went wrong. So let me clear the console and type document.body.

I'm going to make use of autocompletion within the console to figure out what it may-- what the property that I was looking for might have been. So, I'm sure it's something related to class but I can't remember the name. So let me just start typing, oops, "Class" and there you go. There are two options, class list and class name. Class list is what I wanted.

Let me validate to make sure it evaluates to something that's not undefined and it looks like it is what I want. Okay, excellent. You know what? I'm going to go back to my code, change classes to class list, resume script execution, save the file, Command-S, and I'm going to clear the console again with Command-K, I don't want to see any [inaudible] errors, reload the page, and finger crossed, I'm going to click on trailers and this time, it just works. Cool. Mission accomplished again, I got where I wanted all with Web Inspector.

Okay, let's recap what we just did. Well, I'll start with something that we didn't do. You'll notice we didn't use any technique that I will call somewhat ghetto. We didn't use Alert to find on what was going on, we didn't even use console log which is kind of the modern version of Alert.

And what the debugger lets us do is go beyond console log and actually debug the code in real time. So we could use breakpoints to pause JavaScript execution and breakpoints are either something you will target directly yourself and say, "I want to break on this line" or it is something you can just have generically happen whenever an error is triggered, so useful.

And using this Scope Chain's detail sidebar, you could always find out about the context of your current code or you can even just roll over your content and use Popovers to show what you understand exactly what values of the various members of your code evaluate to. This is so very useful. And finally, my preferred technique is to start coding. I can bring up the Quick Console, type whatever I want in there, see what it would evaluate to in this current context and figure out what right code would be for the JavaScript that I was trying to fix.

And so, again, we'll go in much greater details about debugging in the next session. We've only scratched the surface. There is so much more you can do with the debugger in Web Inspector and Safari. So stay tuned, stay in this room and we'll find that a lot more.

And this wraps up our session. We've looked an overview of the user interface, the master-detail relationship going left to right between the Navigation sidebar, content browser and Detail sidebar, and the great Activity Viewer within the Tool Bar so that you can always see what errors maybe triggered, your page load time and the resources you're dealing with.

And then we went through three core tasks that I think highlighted different panels within Web Inspector. We started by inspection tweaking where CSS and HTML editing were really front and center. Then we looked at network performance analysis where the Timelines panel made us-- made it really easy to just to identify how things get loaded in sequence and visualized it with a great timeline. And finally, we just debug the JavaScript code in real time within Web Inspector by just using the great debugging tools made available.

And so, if you like what you just saw, there are different ways you can remain and get involved with Web Inspector. And the first thing I'd like to point out is that every day as we make enhancements to WebKit, we build what we call the "Nightly Build". And this is like a special version of Safari that you can download to your net-- to your desktop and have the latest version of WebKit Code from Open Source compiled in and you can just play around with it. And you can go to nightly.webkit.org and you'll get it right away.

And if you find issues when you're using Nightlys or even if you find issues in the currently shipping version of Safari, you can just go the [email protected]/newinspectorbug and type any problem you may have found. You can also use that that raise future request. And we pay very close attention to what goes on in this bug tracker and we try to fix bugs as fast as we can.

And if you need to discuss things a little bit more interactively, you can find us on IRC as well. We hang out at irc.freenode.net, the channel is #WebKit-inspector. And we actually spread all around the world a little bit so depending on what time zone you are, you should still find someone to help you and answer questions.

There's something even better that I'd like to announce today is that we're making Safari's Web Inspector Open Source contributed back to the WebKit Open Source project. And so, what it means is that you can go ever further than raising bugs and discussing future request in IRC. You can just completely get involved with the code and start fixing things yourself. In fact, one of the great features that we show today about how we can save files locally within the Web Inspector is something that was contributed by an external contributor. So the sky is the limit. You can just contribute as much as you want to Web Inspector.

And so, for more information, you can contact John Geleynse, the Technology Evangelist. We are greatly updated documentation for the Safari Web Inspector guide on developer.apple.com/mac. WebKit.org is a lot of information about WebKit in general. And the div forums let you connect with one another and we track those and ask any questions you want and we'll try to answer.

And so, I've already mentioned some related sessions. Here they are recapped. Right here and-- right this morning-- sorry, there was a session about CSS and new features in the WebKit. Right here and right now, we'll have another more advanced session about Web Inspector, and tomorrow at 9 a.m., a great session about power performance for web content. Okay, that's it.