One of the most common questions I see in forums, and when talking to people one-on-one is “how do you know?”
How do you know what style rules a specific element has? How do you
know exactly what classes are applied to it? How can you tell that the
script isn’t loading properly? There are JavaScript errors? How do you
know what the return of an AJAX call is? And so on.
My answer is Chrome Developer domains Tools! All big browsers have developer
tools built right in, which can give you a wealth of information about a
website.
In this article we take a look at Chrome’s Developer Tools, but the general idea can be applied to all large browsers.
If you have Chrome open, go to View > Developer > Developer Tools or press Command + Shift + C on your Mac or Control + Shift + C on Windows to bring up the developer tools. Let’s get cracking!
Inspecting Elements
The foundation of any HTML/CSS information is the Elements section and the Element Inspector.
When you fire up the tool this is the initial view (below). You should
see the page’s HTML structure on the left and CSS rules on the right.
By default the inspector will be turned on. This can be switched
on/off using the magnifying glass icon in the top left of the toolbar on
top.
The inspector allows you to hover over an element on the page and
click to select it. The HTML view on the left of the inspector will jump
to that element, the CSS rules will display all the rules for it.
You can also click around within the left-hand side of the inspector
to view specific elements, or use the arrow keys to move around.
One trick I like is that you can copy/edit/delete nodes. Right click
on any element to copy it or edit it. You can delete the currently
selected element vps hosting by just pressing delete.
I use the delete method to figure out what is causing bugs, and also how pages look if a specific element isn’t shown.
Working With CSS
There are three ways you can use Developer Tools to your advantage:
- Get an overview of an element’s styles
- See all rules – what is overriding what and which selectors are used
- Add quick inline styles
Element Style Overview
When viewing an element, take a look at the right hand side of the
tools window. To get an overview of the element styles switch over to
the Computed tab on top.
The image on the left shows an example of what you’ll see. Click on
it to expand it into full view. The top section shows you the box model
visually, and below you can see all the properties. The properties and
their values are the result of the full cascade, which means that they
show the end result of all your rules. By clicking on the black arrows
next to each property you can see all the rules that contributed to it.
This is a handy view if you want to find the final value of a
specific property or you want to get a good idea of the dimensions of an
element. I’ve found, however, that if you need to keep referring to
this view instead of the main Styles view it may indicate that your
style rules are too complex. This is not a hard rule but it is something
I’ve noticed across multiple projects.
View and Add Rules
The default view is the Styles tab, which shows you all the rules
applied to this element. In the case of the second level heading shown
above, you would see that there is a general font-weight associated with
all headings, which is 400. There is also a rule applied to all second
level headings which makes them 3.125em in size Finally the .article-style h2 selector is used to add styles to this specific element making the weight 500 and the font size 34px/40px.
This view is extremely useful because it allows view website you to judge how
complex your rules are and – even better – allows you to modify and add
things on the spot.
You can click on any property or value to modify it and even create new rules within each selector. By using the empty element.style selector on top you can even add inline styles which will overwrite everything else.
I use this view a lot to figure out three things: why my style rules
aren’t working, what selectors I need to use to target an element and
what elements would look like with modified CSS.
Next to the element.style section on the right there are
two icons. The plus icon allows you to add a new style rule altogether,
selector and all. The other icon opens a new section which allows you
to check active, focus, hover and visited states. By checking these you
can view the states and write specific rules for them.
Working With Javascript
The Developer Tools offers extremely powerful features for JavaScript
and it’s a bit similar to an IDE in this respect. The reason JavaScript
is easy to build features for is that it is mostly client-side so
Chrome has access to everything it needs.
The Console
The console is the starting point for most Javascript debugging
needs. It can give you all sorts of info, not just related to
JavaScript.
In the screenshot above we can see some good advice (in blue) and two
issues in red. The message is shown alongside the originating file
which makes it easy to find where the problem is.
If you’re concatenating and minifying your Javascript don’t forget to
generate an source map so you can see where the problems actually are,
instead of just a nondescript line in a huge mass of code.
Alternatively, you can wait with script minification until you push your
product into production.
If you click the arrow to the left of the messages you’ll get some
more information about the issue. By clicking the arrow for the 404
error we see that the issue is actually in global.js but it bubbles through to jquery.js. Clicking on the file will actually take you to that file, awesome!
Script Debugging
Sometimes our scripts don’t work and it’s not really clear why.
Script debugging allows us to figure out problems and solve them easily.
The usual way is to use breakpoints. The concept is fairly simple but
the tools offer us so many features it’s a bit difficult to find your
way.
Breakpoints are essentially intentional stop signs created which will
cease code execution. Using various controls you can then inspect what
is going on at the breakpoint (what variable values are used, etc) and
continue execution when you’re ready.
Your first stop should be the Sources panel where you can open a file using Command + P (Control + P for Windows users). This opens the script on the left side, the tools on the right can be used to control the flow.
You can set breakpoints by clicking the line numbers on the left.
These will show up in the breakpoints section on the right. You can then
run your script cloud hosting again which will stop at the specified points.
You can add conditional breakpoints and use this section for all sorts of other debugging magic. I strongly suggest reading Google Chrome’s documentation on Javascript debugging, it is extremely helpful!
The Network Section
The Network section provides a wealth of data about requests and
loaded assets. It shows things like the status of requests, their type,
size, load times, aws loading timelines and so on. There is a lot you can
learn here. I use it for the following:
- Troubleshooting bad requests
- Finding load time bottlenecks
- Checking AJAX request data
Bad Requests
Each items shows the request method, status and type. It is unusual
to need to correct a method and a type but the status is very important.
You should of course keep an eye out for 404 errors which will be
marked red.
By clicking on the status header you can order the list by status. If
you click it again 404 errors should be near the top since they will be
sorted descending. You should also keep an eye out on redirects and
anything out of the ordinary.
Loading Time Bottlenecks
The whole right side of this view shows horizontal bar charts of
loading times. You may need to view it full-screen to get a proper view.
If you see any bars which are longer than usual take a closer look,
perhaps there is something going on!
You can hover over a bar to get a lot of info like waiting time, DNS
lookup, sending time, etc. Using this information you can weed out slow
services, or even some slow code on your own website.
Checking AJAX Requests
This is my favourite part of the Developer Tools, it makes working
with AJAX so much easier. AJAX requests are shown in the hosting network tab,
you can click the XHR filter on top to show only AJAX requests.
These will be shown on an ongoing basis. If you load a page and do
something via AJAX the request will be added live. You can click on the
request to view the headers, preview, response, cookies and timing. I
spend most of my time in the response and headers section. Let’s look at
an example.
Load up Dustin Curtis’ website – a pretty good read – and take a look at the XHR requests. You should see something like this:
Kudos is something you can give to articles on the Svbtle network.
It’s clear that this request pulls in the Kudos given to the posts
loaded on this page. If you load up the first article you should see
that it indeed does have the number of Kudos shown in the response.
Now, keep your developer window open and hover over the Kudos
facility. Once a Kudos is given you should see a new AJAX request. This
request just returns true, it probably indicates to the javascript that
the Kudos was received successfully.
Now, turn your attention to the Headers section. You can see the Form
Data section in there which shows the data that was sent along with the
request. This information, along with the response gives you all the
data you need to troubleshoot your AJAX calls without resorting to
echoing, alerting, console logging and all that nasty stuff.
Responsiveness Testing
What developer toolset would be complete without responsiveness
testing? Chrome has one of the best interfaces for handling this. Take a
look:
The controls on top make all the magic happen. You can select a
specific popular device like an iPhone 5 or a Google Nexus S, or you can
set custom dimensions. The cool thing is that Chrome also spoofs the
user agent for you so instead of domain names just making the same page thinner, it
makes the website think it is actually being loaded by the specified
decide. Note that you need to refresh to make the spoofing happen.
You can also opt to throttle your network connection automatically.
This helps to test in conditions where networks speeds aren’t great –
you can see how annoying it is to use your site on a 50kb/s GPRS
connection.
The little stepped icon on the left will open a menu that shows your
specified media queries so you can quickly switch between them. I think
this is pretty awesome!
Page Audits
This is a feature I came to very late, simply because it’s hidden in
plain view. It doesn’t show anything and the option to run a site audit
isn’t very visible, especially on large screens. Take a peek at the
bottom and run a site audit with page reload.
It’s like having your own personal assistant! From speed to unused
CSS rules, it analyses a so much and gives you a whole lot to do.
I use this tool whenever I create any new product, be it a whole
website or just a plugin. It lets me know when I’m being sloppy or I’ve
forgotten something.