Understanding & measuring events with Chrome DevTools timeline

Measuring performance is important and so important that we need a hash tag (#perfmatters) to discuss all the difficult scenarios and topics surrounding the question “How can I make my Website faster?” In order to answer that question we have to understand how to collect and measure that data collected. This is where the Timeline panel of your DevTools can help. Let’s take a look at how to record an events timeline capture and identify our bottlenecks.


Measuring Events

Open up your Chrome DevTools and you’ll find a Timeline panel that lets you record and analyze all the activity in your application as it runs. It’s the best place to start investigating performance issues for your site.

A common task today in the world of performance is to record a single load from the initial network request to the final data transmission. During a recording, a record for each occurring event is added to the records view in a “waterfall” presentation. Records are categorized into four groups:

timeline-event-categories

Using blog.grayghostvisuals.com as an example, I load my site in Chrome using “Shady” mode. Shady is my custom profile which doesn’t track cookies, cache or carry over my extensions and browser bookmarks from my default profile. This way I have a clean environment to test with. Apps, extensions, background processes and unnecessary tabs are just a few things that can impact your profiling and should be avoided where possible. Once loaded I immediately open up DevTools (cmd+option+i). Using the quick key cmd+e (Mac) or ctrl+e (Windows/Linux) we can start the recording followed by cmd+r or ctrl+r to refresh the browser, and finally cmd+e or ctrl+e to stop the recording.

timeline load capture
Site load event capture phase

The first record (Send Request) is Chrome’s HTTP request for the URL, a Receive Response record for the corresponding HTTP response, one or more Receive Data records, a Finish Loading record and a Parse HTML record. Lets break things down one by one…

Send Request
A network request has been sent. This is the request for the URL (typically GET).
Receive Response
The initial HTTP response from a request. The response consists of the protocol version (HTTP-[the_version]) followed by a numeric status code(a 3-digit integer i.e. 200, 404 etc.) and its associated textual phrase (the reason for the status code).
Receive Data
Data for a request was received. There will typically be one or more Receive Data events in your recordings. Generally Receive data is any data, but good to think of it in terms of TCP: a large file is split into many different packets. The timeline creates a new event whenever a new set of packets is delivered.
Finish Loading
A network request completed.
Parse HTML
Chrome executed its HTML parsing algorithm. This can also be considered the tokenizing portion. Parsing a document means translating it to some structure that makes sense – something the code can understand and use. The result of parsing is usually a tree of nodes that represent the structure of the document typically called a parse tree or a syntax tree. You may also notice during this stage assets being requested like stylehseets or any other asset within the <head>

DevTools Recording Tips

  1. Keep recordings as short as possible. This makes analysis much easier.
  2. Avoid unnecessary actions (mouse clicks, network loads, etc.) that are extraneous to the activity you wanna record and analyze. For example, if you wanna record events that occur after you click a “Login” button, don’t scroll the page, then load an image etc.
  3. Disable browser cache. When recording network operations, it’s a good idea to disable the browser’s cache in the DevTools settings panel.
  4. Disable extensions. Chrome extensions can add unrelated noise to Timeline recordings of your application. You can do one of the following:

Preserving & Loading Saved Event Data

You can save a Timeline recording as a JSON file, and open it in the Timeline. In order to save a timeline right+click or ctrl+click (Mac only) inside the Timeline and select “Save Timeline Data”, or press the ctrl+s keyboard shorcut and finally pick a location to save the file and click “Save.”

To load your Timeline data Right-click or ctrl+click inside the Timeline and select “Load Timeline Data”, or press the ctrl+o keyboard shortcut, locate the JSON file and finally click “Open”.


Going Further

Of course we can test other areas besides page load like scrolling, clicking and much more. The important part of the entire process is to understand how and why to create a clean testing environment and analyze collected data. Before you make time for your next performance audit pay close attention to these areas:

  1. PageLoad
    • Was load time slow?
    • Does the user have a blank screen for a long duration?
    • Are requests blocking content from displaying quickly?
  2. Runtime
    • Did it scroll well?
    • Are interactions/animations smooth?
    • Are paint times high?
    • Is frame rate feeling janky?

Another great place for speed testing is a service called WebPageTest (PageSpeed Insights is also another great place to start an audit). Simply type in a URL and prepare yourself for the most luscious amount of data at your finger tips. Services like this help you guage your Speed Index which takes the visual progress of the visible page loading and computes an overall score for how quickly the content painted. A lower number in this area is ideal.

Filmstrip View on WebPageTest w/accompanying Waterfall View
Filmstrip View on WebPageTest w/accompanying Waterfall View

Keep in mind with regards to page load that every request you make will increase your site’s load time. Nearly 40% of people abandon a site that takes longer than 3 seconds to load. Always aim for a speed index of 1000. your users will love you for it.


References

8 thoughts on “Understanding & measuring events with Chrome DevTools timeline”

Comments are closed.