Matt Andrews
Software engineer making apps – that aren’t apps – and more at the FT. 会说汉语.
Removing noise from Timeline reports in Chrome DevTools

Timeline in Chrome’s Dev Tools is really cool. It can help you get all sorts of data from dozens of metrics on the performance health of your web application.

The problem is making Chrome Timeline recordings to me is a bit like the Manual Burn scene in Apollo 13. The minute you hit the red button and move your cursor back to the website all hell breaks loose.

It becomes a race against time to kill the recording before it has filled up with so much information, triggered by so many different events that you lose all hope of hunting down those janks, layout thrashes and performance burps.

No matter how hard I try my timeline recording never look consistent, with a (relatively) clear root cause like this:

– Chrome Office Hours: Performance

Unlike other profiling tools in Chrome that can be controlled directly from JavaScript I always find my Timeline reports have really poor signal-to-noise ratios. They tend to be a chaotic mixture of colours and where there is good information, it can feel like I’m just being told that I’m doing everything wrong:

Note how in the first few frames the frame rate budget is being burst by scripting, rendering and painting.

Where do you even start?

I want a timeline that looks like this:

Only the events in the timeline are those I have triggered (which you can see beneath because I triggered them in JavaScript). There is nothing after, and nothing before – which means there is no need to waste time digging through looking for the event you’re interested in.

Tip: don’t use your mouse when using Timeline profiling. Give elements IDs and trigger the events on them that you want to profile via the console.

The result of doing this gives you a timeline that contains only the data that is relevant to the action you are profiling, leading to easy investigate, reproducible test cases:

This is an improvement but it doesn’t work in all cases – some times you might want to profile, say, a hover state. I’d really like more granular control over what can start Timeline recording. Something like Event Listener Breakpoints (Sources panel of Dev Tools) to choose the sort of events that kick off Timeline recording (to be honest even just a way to stop mouse moves from doing it would be a good start)…

Bonus tips – Keyboard Shortcuts

Cmd/Ctrl + E starts and stops Timeline (and other profilers) recordings but the Dev Tools window must be focused so if you need to use the mouse during profiling (and want to avoid collecting too many extraneous mouse move events) you are probably going to want to switch back and forth with the keyboard.

Unfortunately there’s no keyboard shortcut that I know of to directly switch between Dev Tools on the Timeline and the browser*. If you have Dev Tools undocked you can only use the native OS’s window switching shortcuts (Alt + Tab on Windows, Cmd + ~ on Mac).

* In Chrome 30 if you switch on “Enable Cmd + 1-9 shortcut to switch panels” – the last option in the General tab of Dev Tools settings (click the cog) you can open the timeline with the easy to remember Cmd + Shift + J [release] Cmd + 5.

If you have Dev Tools undocked you can use Cmd + Alt + J to show and hide Dev Tools (and switch what is the focused at the same time), but when Dev Tools closes any Timeline recording in progress will be killed :(.

Pet Peeves

Another really helpful feature Timeline has is when you hover over Layout events, it will show you the affected region by adding a semi transparent blue rectangle over the affected area on your web page.

If you accidentally hover over anything in the timeline report whilst it’s still recording it’ll still add blue highlighting to the elements affected – and that blue highlighting itself pollutes Timeline’s output:

All the Composite layers events (the green ones) recorded after the ~8 second mark were caused by interacting with Timeline output.

When I’m profiling I’d rather Chrome didn’t do any highlighting at all, but I feel it really, really shouldn’t fill up the report produced Timeline with irrelevant noise that I then have to filter out…

Bug reports

Update: you can now start and stop timeline profiles from JavaScript

Full Frontal Conference 2013 Notes

09:50 — 10:30: ES6 Uncensored (slides) Angus Croll – @angustweets

A whistlestop tour of ES6 (the upcoming version of javascript due next year). The highlight for me was finally an explanation of yield that I actually understood. Is it me or does ES6 look a lot like Scala?

10:30 – 11:10: JavaScript in the real world (slides) Andrew Nesbitt – @teabass

Mind still buzzing with yielding generators we segued into Andrew Nesbitt’s delightful Terminator-reference and Rabbit-photo packed presentation on the cutting edge of JavaScript powered robots.

11:40 – 12:20: Mobile isn’t a thing, it is everything (slides) Joe McCann – @joemccann

Lots of charts of absurd growth and examples of mobile changing everything, from the most frivolous to the most life-saving and inspirational ways.

12:20 – 13:00: Pushing the limits of mobile performance (slides) Andrew Grieve – @GrieveAndrew

A peak into the history of Gmail web app for the original iPhones. Amazing to see how much faster smart phones have become since 2007. My main take away: JavaScript performance isn’t the issue it used to be on mobile devices – rendering is (probably) a much bigger concern.

break for fish ‘n’ chips

14:30 – 15:10: Our web development workflow is completely broken (slides) Kenneth Auchenberg – @auchenberg

I imagine like many I had unquestioningly accepted the fact that when I use Chrome I must use Chrome dev tools; for Safari and iOS I must use Safari’s and so on.
We’ve all been doing it wrong.

15:10 – 15:50: Stunning visuals with maths and… No javascript? (slides) Ana Tudor – @thebabydino

Really, really cool demonstrations of what can be done with just CSS (and maths).

16:20 – 17:00: Building with web components using x-tags (slides) Angelina Fabbro – @angelinamagnum

The cutting edge of Web Components from the Mozilla camp.

17:00 – 17:40: Time (slides) Jeremy Keith – @adactio

And Full Frontal 2013 ended on Time – an exploration of the permanence of digital information, the longevity of formats and a brief history of time.

What an excellent day at the seaside.

Does the HTML5 History API automatically add pages to the AppCache?

I met with a colleague from a previous company this evening who had gotten back in touch after stumbling across one of the tutorials I had written about the HTML5 History API and AppCache. This, I thought, was quite cool. What was less cool was that my post didn’t actually answer his question, which was:

Do pages visited via the HTML5 History API get automatically added to the Application Cache?

The answer: No, they don’t.

Basically, the AppCache can only store the URLs that are either:

  1. Listed in the AppCache manifest for the page that was originally loaded from the network.
  2. Or, are themselves the page that is loaded from the network. (See this wonderfully titled Stack Overflow post: “My HTML5 Application Cache is caching everything”)

Note to self – what happens if you programmatically change the manifest attribute on the html tag? (Or set it if it was blank before?). The answer: absolutely nothing.