Quick Tips on Troubleshooting Your Web Pages – Element Inspector and Network Resources

When I first started out developing web pages back in the day there barely were any tools for development outside of the IDEs that were offered, which weren’t too much to write home about anyways. While some might say that web pages that were manly cluttered with animated GIFs and content related to Warcraft 1 & 2 and Diablo 1 (tells you a lot about my child hood ;)) is not considered much of a web development project, I still say it is (or was) :D. Either way, you wrote your HTML, CSS (fairly new too) and JavaScript and hoped everything would turn out OK when you opened it in the browser. If something was off you went back to tweak it in your IDE (*cough* notepad *cough*) and refreshed while crossing your fingers that everything would be better this time around. Alerts were also frequently used as a way to see if a JavaScript function was accessed, and if a variable existed or what it had for a value.

It’s not like this today though. Today is much, much different – in a fantastic way. In today’s world we have more tools than we can shake a stick at for web development. Especially in the way of helping us developers in figuring out what exactly is happening to our web pages when they get rendered in our browser. Questions like “How come this looks great in Chrome but slightly quirky in IE?”, “Why is none of my JavaScript executing?” and “Why is this page loading so slowly?” can now be answered within each of the major browsers thanks to the Developer Tools offered for each one.

Some of you might be saying “well duh, I’ve been using this forever” but there is still a large group of the developer population that does not know about these tools. So for the sake of people either new to web development, or for those of you that just haven’t heard of these tools, or only use a small portion of them, I wanted to write this quick blog post series. I’ll be covering some of the main features of these Developer Tools, as well as show how they look in the three major browsers that I like to use; Chrome, Firefox and IE. In the case of Firefox I’m going to be using Firebug, an add-on that has been available for quite some time and was my introduction to browser dev tools. Firefox does have built-in dev tools now, but I still think Firebug offers more features and is the preferred tools to use right now.

Enough of my rambling on here, let’s get to it! Today I’ll be covering the Element Inspection tools, as well as the Resources tools.

Element Inspection

Ever seen a button on a page that looked ridiculously awesome and wondered why it looks so good? Maybe you’re just curious why a certain element is now in the upper right-hand corner (has happened way too many times for me), or maybe you just want to see how the page you’re currently on is laid out.

Well thanks to the element inspector all these mysteries are solved! How often do you get to hear that? Well, the element inspector often (as in, most major browsers have this ability) provides you with a couple of useful things.

First of all, when you inspect an element you usually get to see both where it is currently located on the page (each browser does this a little differently) as well as where it is in the DOM. Additionally, and this is an extremely useful feature, you get to see the CSS that affects the particular element. You can see everything from what styles are supposed to get applied, which ones get overridden, and the final styles applied. You can usually also see which CSS file (and what line number!) is responsible for that particular rule as well. Super awesome in scenarios where you would normally just stare at the screen tearing your hair out wondering why everything looks so wrong.

For this particular demo I just have a very quick sample HTML page, as I just want to cover the basics.

As you can see I also have a separate CSS file called Styles.css, which at this moment only looks like this:

Very simple, but illustrates the points I want to make. Just from looking at the code above you can see a few things:

• We have a paragraph which should have a black (#000000 in HEX) font
• The font in the paragraph element should be Verdana (no backup)
• The background of the paragraph should be a kind of orange-y color (I’m awful with color names)
• The background of the body element should be #FFFFFF, or in an English term – white :)

Let’s take a peek at how this looks in our browsers various developer tools available to us.

Chrome

There are a couple of ways you can work with the element inspector tool within Chrome. The easiest way to make sure that you are looking at the specific element you want is to right-click on it in your browser and select “Inspect Element” from the context menu that appears.

Once you have done this the Chrome Dev Tools will open up, with your particular element highlighted within the DOM.

Speaking of the DOM, you can actually navigate through the DOM and highlight elements that way too. This can be done by just opening the Chrome Dev Tools (CTRL + SHIFT + I, or F12) and going to the Elements tab. Once here you’ll see the same view as before, only the body element will be highlighted. If you hover over, or click, on any HTML element in here it will get highlighted as well.

As that screenshot shows you, our element is actually highlighted on our page, and we even get some additional information about it. We know that it’s a “p” element, with the ID sampleParagraph (“#” refers to the ID) and that it’s 100px by 54px in size.

You also might have noticed the “Styles” and “Computed Styles” in the second image there. Well, this area allows us to easily wee what styles end up getting applied to the element. This means CSS rules that affect the element, even if they have ended up over-writing other styles. Computed Style shows you the end result, and where each style comes from, as can be seen here:

You might notice that each one of those documents (.css and .html) are actually links and will open the CSS file in the Chrome Dev tools to that specific line in the CSS or HTML file so that you can dive in to the file in charge of the style. This gives you a chance to see where the particular style you defined exists, which becomes very handy when you are scratching your head wondering why that element is not getting styled properly.

Firefox

As I mentioned previously, Firefox has a very similar view brought to you by the add-on Firebug. So let’s go through the same things as I did with Chrome above.

First let’s right-click on my element and go to “Inspect Element with Firebug”. You might notice that there is an “Inspect Element” option as well. This is for the internal developer tools from Firefox that I mentioned in the beginning. Right now I’ll focus on Firebug, but you never know what kind of blog posts the future holds!

Now we see that the element is highlighted in our DOM explorer.

You get the same view that I mentioned above with Chrome as well, where I can highlight the element in the DOM explorer and have it highlighted in the actual web page as well. So far, nothing really too different.

One thing that you see immediately though is the style tab over on the right-hand side. This is where you notice some differences. For example, the first view we see just shows us the rule applied to this particular element. This was available in Chrome as well, but for the sake of comparison let’s go over to the Computed tab:

Not exactly what we saw in Chrome. The nice thing it does is split up all of the styles according to their relevant groups. So Text, Background, Box Model etc., but there is no way to see where exactly these come from. So we have to look through the styles tab to see where everything is coming from, which isn’t a bad thing I just love having those kinds of lines drawn for me.

IE9

IE9 has some pretty spiffy tools for web development, which hasn’t always been its strong suit in previous iterations. The great thing is that you can also test for the various modes that have existed within IE (quirks mode etc.) and go back to IE7 for testing – all in the same browser.

While there isn’t a context menu item to inspect the element we can still very easily get access to an element in order to inspect it. If we open our page in IE9 and press F12 we will see the Developer Tools appear. Once we’ve done this we just need to find the arrow icon under the HTML tab, which starts the element inspection:

Once we’ve clicked on an element we’re granted a very similar view to what we’ve seen before in the other browsers.

We have the same ability to see all of the styles, but one thing that is different is instead of “Computed” styles we now have “Trace Styles”.

This is just the same as in the other browsers, however now we have something that is closer to what we had in Chrome. Unfortunately we cannot get the exact line number, but if we click on a particular file name we can very easily see where in the source file these styles are located. This also allows for very quick tests to see what happens when you remove the styles, which in both other browsers can only be done in the Style tab.

Network

I’m sure you’ve run in to scenarios where you swear that you added an image to a page, or you realize that there’s no CSS being applied to your page and you’re wondering why. Often times these scenarios are derived from the fact that there was an issue downloading the particular resource. Whether it be an image, a CSS file, or maybe even the next page our clients are navigating to, it can always happen. Spelling mistakes, or moved resources – the list goes on.

Well, what if I told you that you can easily see exactly what kind traffic is occurring on a particular web page, and see exactly what files are attempted to, or successfully, downloaded? Hard to believe it? Let me introduce you to the Network tab of these browser dev tools – it’ll rock your world!

For the sake of keeping things simple I’ll be using the same HTML page as with the element inspector.

Chrome

In Chrome it is very easy to find this Network tab. Just open up the Chrome Dev Tools (CTRL+SHIFT+i) and select the “Network tab".

Here we can see quite a bit of information, although since my page is fairly simple there might not be a ton of items to inspect. Nevertheless, we can see that I attempted to download index.html, jquery-1.7.2.min.js and Styles.css, all using the GET method. These all succeeded, and I can even see what initiated this action – pretty nifty! Chrome also gives us the ability to see how long it took to download the file, as well as where in the overall page load the download took place.

If we had more happening on this page it would all go through the Network tab like this. Ajax requests would be found here for example. Of course, if we were unable to download a resource it would gladly tell us and say specifically what kind of error (404, 500 etc.) that caused the issue. This is extremely useful when you see odd behavior on a page. You never know what you might’ve missed to download, or if there are any errors in your way.

If you’d like to you can also click on each resource and see the Headers and Response messages for each of these requests. There is also a Preview (for our HTML file this would display the entire HTML in plain text) and a Timing tab which gives us insight as to how long it took for this entire request to get back to us.

Firefox

Firefox has a very similar view as what we found in Chrome. If I open up Firebug and click on the “Net” tab on my sample page I am greeted by this:

As we can see we get a similar view to what we had in Chrome. While it doesn’t tell us what kind of file this is, it still displays all of the files that downloaded. Additionally we get the status, field which would inform us if anything went wrong. You can also expand each item to get a more detailed view of the response, similarly to what we had in Chrome as well

IE9

IE isn’t far too different either actually and having this as a standard feature is always a good touch. There is an interesting approach that IE9 takes, which is that you can selectively choose when to start and end the capturing of this data. More on this in a second! :)

If we open up the IE9 Dev Tools (F12) and select the “Network” tab this gets displayed:

So, nothing happens by itself here. In Chrome and Firefox we would just refresh the page if we saw nothing under this tab and automatically things would capture. However, this could also leave us with a ton of extra information that we’re not interested in. What if we just want to look at what happens when we click that one button? IE9 lets us define exactly when we start the capture, and when to end it.

If we hit “Start capturing” and refresh the page I should get something similar to the other two browsers.

Bingo! We get to see the method, satus/result as well as what type of request we are dealing with. Additionally all of the timing information is there as well. One neat thing is that we also get to see what particular element was in charge of initiating the request, even if it was a refresh.

For some more detailed information, which would contain all of the more nitty gritty items that we saw in Chrome and FF all we need to do is press “Go to detailed view” and voila – more information than you can shake a stick at!

Oh, We Are Just Getting Started

So that’s a quick overview of the Element Inspector and the Network tab of Chrome 18 , Firefox 12 and IE9. This wasn’t necessarily a deep dive into any one tool or any one browser, but more of a quick overview of what’s available. Hopefully I inspired those of you whom haven’t used these tools before, or maybe I covered something you haven’t been using! Keep in mind that there’s more to come later as I dive in to the more JavaScript heavy items in the next blog post! :D