The Network panel gives us a view into the resources that are requested and downloaded over the network in real-time. Viewing network traffic isn’t the most glamorous activity – especially if you’re new to web development. However, performance becomes an important issue, as your site’s traffic increases. Identifying and fixing requests that take a long time to complete is an important step in optimizing a site.
An HTTP proxy, such as Charles Proxy, can give you a decent amount of information regarding your website’s network. That being said, the Network panel offers a surprising amount of detailed information; considering how it’s only a few clicks away, it’s certainly an excellent candidate for debugging network issues. The following is a screenshot of the Network panel when loading the Linkedin mobile site on a fresh page load:
This button opens the Network panel. Be sure to open the tab before loading a page so that it captures the network requests (e.g. open a new browser tab, open up developer tools, open up the network tab and then finally load the URL to monitor)
This row contains one resource with interesting information that I cover in the following points. The first column is the name and path of the resource. The resource name will show on the first line while the path to the resource shows on the second.
The HTTP method used for the request.
The HTTP status code returned by the server. 200 is a common response for a successful response; although anything within the range of 200-299 is considered OK. Notice how one of the above requests is in red. This is related to the HTTP response code, a 401 Unauthorized response, because I’m not logged in to the LinkedIn mobile site.
The content-type of a request. For example, in an HTTP POST (using the metrics resource as an example), the content-type in the request and response headers is: application/json; whereas, the main HTML page’s response headers contain a content-type of text/html. A small note on the application cache: when serving a manifest file, be sure to serve it with a content type of text/cache-manifest. When debugging, the “Type” column in the Network panel is the place to ensure it’s being served correctly!
The initiator is an interesting column; it allows us to see why a resource is downloaded. For example, you may see the __utm.gif file often in your debugging sessions; it is used by Google Analytics. The initiator shows as ga.js:52, a value in file_name:line_number format. With this column, you can discover why, when, and how resources are downloaded. If Parser is shown for the initiator, chances are good that the browser initiated the request upon seeing something like a <link /> or <script /> element in the document.
Timing contains information on how long a request actually took to download.
This displays the size of the resource, an invaluable piece of information. When building a site, be sure to regularly “sort by size” in the Network panel and ensure that your resource sizes are correct. It is sometimes considered a good practice to base 64 encode images and embed them in CSS files. This can reduce the number of HTTP requests, but it also increases your CSS file’s size. Large resources should be delayed as much as possible to provide a snappy experience for the user.
This displays the amount of time it took to retrieve the resource. Resources served from a different domain may take longer to download than other resources served from another origin.
The Load event which fires when the DOM is ready and resources have finished loading.
Timeline view of network requests. You can hover over them for more information.
Total size transferred, number of requests, and time taken.
Icons to interact with the Network panel, such as clearing the panel of all requests and changing icon size.
Useful network requests filters, e.g. you can control + click XHR and Images to only show network requests for an image resource or a request made with an XHR object.
Headings for the network requests; you can click a heading to sort the requests by the data in the column.
It is necessary for web developers to understand and know how to use browser developer tools, and in this tutorial, I will introduce you to the Chrome Developer Tools. You’ll learn some of the basics, starting with marking up and styling a web page.
Browser development tools allow you to drill down into a web page and inspect just about everything in the page. For example you can:
view an element’s corresponding HTML code (for example a header of some sort)
get an overview of the CSS used in a page and how CSS applies to an element
modify CSS in real time and visually see your changes in the browser
view the HTTP requests made by the browser
identify performance bottlenecks and retrieve a variety of performance metrics
poke around with offline resources to find out what data the page in question is storing locally
Before taking a look at the contents of the Elements panel, let’s take some time to understand the little controls near the top and bottom. Please refer to the numbered list below the following image that explains the different UI elements in the tool window.
Close Developer Tools.
Buttons to select different tool panels (Elements is currently selected).
A custom tool installed by a third-party extention (PageSpeed).
Change the layout of the developer tools.
Show the console (will be covered in a different tutorial).
Select an element in the tool by clicking on it in the page.