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
get-cpu-profile.js. Here's what it does:
- It navigates your open tab to
- Starts profiling
- run's the page's
- 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.
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"
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.