automated-chrome-profiling 0,0

Node.js recipe for automating javascript profiling in Chrome

3 years after

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 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

image

image

Way more is possible

This is just the tip of the iceberg when it comes to using the protocol to manipulate and measure the browser. Plenty of other projects around this space as well: Chromium Telemetry, ChromeDriver frontend for WebDriver, trace-viewer, the aforementioned chrome-remote-interface Node API, and a number of other debugging protocol client applications collected here. browser-perf and its viewer perfjankie are definitely worth a look as well.

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.

Contributors

Related Repositories

awesome-wpo

awesome-wpo

:pencil: A curated list of Web Performance Optimization. Everyone can contribute ...

awesome-chrome-devtools

awesome-chrome-devtools

Awesome tooling and resources in the Chrome DevTools ecosystem ...

3rd-party-cpu-abuser

3rd-party-cpu-abuser

From a chrome dev tools JS profiler file, will tell you quickly who on your page ...

frontend-dev-bookmarks

frontend-dev-bookmarks

A huge list of frontend development resources I collected over time. Pull reques ...

frontend-dev-bookmarks

frontend-dev-bookmarks

A huge list of frontend development resources I collected over time. Pull reques ...


Top Contributors

paulirish cyrus-and efx vladikoff GarthDB