Ecosyste.ms: Awesome
An open API service indexing awesome lists of open source software.
https://github.com/paulirish/automated-chrome-profiling
Node.js recipes for automating javascript profiling in Chrome
https://github.com/paulirish/automated-chrome-profiling
Last synced: 8 days ago
JSON representation
Node.js recipes for automating javascript profiling in Chrome
- Host: GitHub
- URL: https://github.com/paulirish/automated-chrome-profiling
- Owner: paulirish
- Archived: true
- Created: 2015-01-22T02:19:02.000Z (almost 10 years ago)
- Default Branch: master
- Last Pushed: 2019-12-09T03:15:03.000Z (almost 5 years ago)
- Last Synced: 2024-05-02T06:07:22.947Z (6 months ago)
- Language: JavaScript
- Homepage: https://github.com/paulirish/automated-chrome-profiling#readme
- Size: 557 KB
- Stars: 865
- Watchers: 39
- Forks: 72
- Open Issues: 9
-
Metadata Files:
- Readme: readme.md
Awesome Lists containing this project
README
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](https://developer.chrome.com/devtools/docs/debugger-protocol) and go directly to [how Chrome's JS sampling profiler interacts with V8](https://code.google.com/p/chromium/codesearch#chromium/src/third_party/WebKit/Source/devtools/protocol.json&q=file:protocol.json%20%22Profiler%22,&sq=package:chromium&type=cs). So much power here, so we'll use [chrome-remote-interface](https://github.com/cyrus-and/chrome-remote-interface) as a nice client in front of the protocol:
**Step 1: Clone this repo and serve it**
```sh
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:**
```sh
# 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**
```sh
node get-cpu-profile.js
```
#### CPU Profiling
Read through [`get-cpu-profile.js`](https://github.com/paulirish/automated-chrome-profiling/blob/master/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](https://github.com/paulirish/devtools-timeline-model) provides an ability to use the Chrome DevTools frontend's trace parsing.
```js
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](https://chromedevtools.github.io/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`](https://github.com/ChromeDevTools/awesome-chrome-devtools#chrome-devtools-protocol) for more.
### Contributors
* paul irish
* [@vladikoff](http://github.com/vladikoff)
* [Andrea Cardaci](https://github.com/cyrus-and)