The Big Rig Web App is a dashboard that lets you track your performance over time.
The trace files can be uploaded manually, or via a GitHub Webhook. The results are presented in a dashboard and use RAIL-centric thresholds.
The backend uses Python and Google App Engine (a node version is in the works).
- Install the Google Cloud SDK.
- Install the Google App Engine for Python
- Install Gulp
npm install --global gulp
- Clone the Big Rig repo
git clone https://github.com/GoogleChrome/big-rig.git
. - Change directory to the app directory within your Big Rig clone
cd big-rig/app
- Install the Nodejs dependencies
npm install
- Run
gulp
(orgulp dev
if you plan to change code) in order to build Big Rig. - Open the Google App Engine Launcher application
- Within Google App Engine Launcher add the
big-rig/app/dist/
directory as an existing project - Click Run within Google App Engine Launcher
- Visit
http://localhost
with the port number Google App Engine Launcher gave you, e.g.http://localhost:8080
. - Check the "Sign in as Administrator" checkbox and click login
- Big Rig is now running, to set up a project follow the "Getting Started" guide from within the Big Rig help page. e.g.
http://localhost:8080/help/getting-started/
This project is an experiment / proof-of-concept, and patches, ideas, and thoughts are all very welcome. Do feel free to contribute, but because it's under active development please read the contributing guide first. In particular, please file an issue before writing any code so we can discuss whether the change is appropriate. (I don't want you to waste time on a patch for something that's being refactored anyway!)
In the web app,a user creates a Project, which is a logical grouping of Actions (things on which they wish to track performance details).
An Action is categorized one of three ways:
- Response
- Animation
- Load
You can change an Action's type at any time. The Action type is used to determine how to present the data.
When a trace is ingested it must be matched to an Action, or one must be created. If the developer has used console.time('MenuSlideOut')
and console.timeEnd('MenuSlideOut')
to mark a range in the trace (in this case called 'MenuSlideOut', which we may regard as a Response, and something to be completed in less than 100ms) this will be used to match to an existing Action, and in this way successive traces with 'MenuSlideOut' will be grouped together and tracked over time. (There could be a second Action for the animation itself, which one would want to have run at 60fps.)
If none can be found, a new Action will be created, if possible, and the data will be appended. It is possible for a developer to include several imports for the same Action within a single trace through use of multiple calls to console.time*(label).
For processing, the following trace categories are assumed:
- blink.console
- devtools.timeline
- toplevel
- disabled-by-default-devtools.timeline
- disabled-by-default-devtools.timeline.frame
These categories are the default for Chrome DevTools, WebPagetest, and are configurable for Telemetry (or any other automated trace suite), like ChromeDriver.
- Python (uses Telemetry cloned from Chrome source) and GAE - Status: In progress
- JavaScript (uses Trace Viewer) - Status: Pending
As much data as possible is captured from the trace and stored, and the trace file itself is purged by default (though the user may keep the blobs if desired).
The general processing model is:
- For the trace, filter down to a single (non-Chrome Tracing) named process.
- For the process, locate the following threads:
- Compositor
- CrRendererMain
- CompositorTileWorker*
- For the process, locate the “windows of interest”, based on
console.time*()
- If none is found, assume the entire range is of interest.
- For each thread, locate slices within each “window of interest” that match the following:
- Parse HTML
ParseHTML
- JavaScript
FunctionCall
EvaluateScript
MajorGC
MinorGC
GCEvent
- Styles
UpdateLayoutTree
RecalculateStyles
ParseAuthorStyleSheet
- Update Layer Tree
UpdateLayerTree
- Layout
Layout
- Paint
Paint
- Raster
RasterTask
Rasterize
- Composite Layers
CompositeLayers
- Parse HTML
- For each slice:
- Sum the slices of each type, and store against the Action
- For each thread, locate events within each “window of interest” that match the following:
- DOMContentLoaded
MarkDOMContent
- First Paint
MarkFirstPaint
- Load
MarkLoad
- Frame
DrawFrame
- DOMContentLoaded
The following captures the rules around importing a trace.
- A Project has a secret.
- All Actions have IDs.
- If a trace is submitted, the submitter must provide the secret. If not, the trace will be rejected.
- If a trace is submitted, the submitter may also provide a collection of IDs, which will be used to identify the Action (or Actions) to which to the trace refers.
- If a single label is provided and the Action of that label is for a Load Action, the trace is considered to match entirely to the Action. If the Action is not a Load Action, then only the ranges will be matched.
- If the Action of that label is not a Load Action, then look for time ranges of that label.
- If multiple labels are provided and the trace contains ranges, those ranges will be mapped to existing Actions in the Project with those labels.
- If multiple labels are provided and the trace does not contain ranges, no Actions will be findable, so the import will be a no-op. If, however, only one of the labels provided is for a Load Action, then the trace will be assumed to match to that Action.
- If no labels are provided and no ranges exist, then a match will be assumed if and only if there is one Load Action in the Project. If time ranges do exist, then Actions will be created for those time ranges as necessary during the import.
Please note: this is not an official Google product.