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
CPU Profiling
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...
Timeline recording
You can record from the timeline. The saved files is drag/droppable into the Timeline panel.
See get-timeline-trace.js
Finding forced layouts (reflows)
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
Timeline model
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
Why profile JS like this?
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.
Way more is possible
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.
Contributors
- paul irish
- @vladikoff
- Andrea Cardaci