Let's say you want to evaluate the performance of some clientside JavaScript and want to automate it. Let's kick off our measurement in Node.js and collect the performance metrics from Chrome. Oh yeah.

We can use the Chrome debugging protocol and go directly to how Chrome's JS sampling profiler interacts with V8. So much power here, so we'll use chrome-remote-interface as a nice client in front of the protocol:

Step 1: Clone this repo and serve it

git clone https://github.com/paulirish/automated-chrome-profiling
cd automated-chrome-profiling
npm install # get the dependencies
npm start  # serves the folder at http://localhost:8080/ (port hardcoded)

Step 2: Run Chrome with an open debugging port:

# linux
google-chrome --remote-debugging-port=9222 --user-data-dir=$TMPDIR/chrome-profiling --no-default-browser-check

# mac
/Applications/Google\ Chrome.app/Contents/MacOS/Google\ Chrome --remote-debugging-port=9222 --user-data-dir=$TMPDIR/chrome-profiling --no-default-browser-check

Navigate off the start page to example.com or something.

Step 3: Run the CPU profiling demo app

node get-cpu-profile.js

Read through get-cpu-profile.js. Here's what it does:

• It navigates your open tab to http://localhost:8080/perf-test.html
• Starts profiling
• run's the page's startTest();
• Stop profiling and retrieve the profiling result
• Save it to disk. We can then load the data into Chrome DevTools to view

You can do other stuff. For example...

You can record from the timeline. The saved files is drag/droppable into the Timeline panel. See get-timeline-trace.js

A bit more specialized, you can take that timeline recording and probe it with questions like.. "How many times is layout forced"

See test-for-layout-trashing.js

The raw trace data is.. pretty raw. The devtools-timeline-model package provides an ability to use the Chrome DevTools frontend's trace parsing.

const filename = 'demo/mdn-fling.json'

var fs = require('fs')
var traceToTimelineModel = require('./lib/timeline-model.js')

var events = fs.readFileSync(filename, 'utf8')
var model = traceToTimelineModel(events)

model.timelineModel // full event tree
model.irModel // interactions, input, animations
model.frameModel // frames, durations

Well, it started because testing the performance of asynchronous code is difficult. Obviously measuring endTime - startTime doesn't work. However, using a profiler gives you the insight of how many microseconds the CPU spent within each script, function and its children, making analysis much more sane.

This is just the tip of the iceberg when it comes to using the devtools protocol to manipulate and measure the browser. Plenty of other projects around this space as well: see the devtools protocol section on awesome-chrome-devtools for more.

• paul irish
• @vladikoff
• Andrea Cardaci