When diagnosing performance problems it can be valuable to see what
Chrome is doing "under the hood." One way to get a more detailed view into
what's going on is to use the about:tracing tool.
Capture a trace on Chrome desktop
Sometimes Chromium developers will ask for about:tracing results in a
bug report to help us understand what's going on.
Here's an easy
Submitting an Awesome Performance Bug
- Open a new tab and type "about:tracing" in the
- Press "Record". Choose the "Manually select
settings" preset, leave the default boxes checked and press
- Switch back to the tab with the content you're debugging and do
whatever it is that's slower than it should be (or behaving
incorrectly). A few seconds of the bad activity is usually
- Switch back to the tracing tab and press "Stop", then
- (Optional) If this is for a bug report, upload the output file
as an attachment to bug. If the file is bigger than 10MB, zip it
first (the files compress well, and files bigger than 10MB can be
truncated during upload).
IMPORTANT: Before attaching a trace to a bug keep in mind
that it will contain the URL and Title of all open tabs, URLs of
subresources used by each tab, extension IDs, hardware identifying
details, and other similar information that you may not want to
Capturing chrome desktop startup
Assuming $CHROME is set to
the command you need on your OS to start chrome, the following will record
the first 7 seconds of Chrome's lifetime into /tmp/foo.json
$CHROME --trace-startup --trace-startup-file=/tmp/foo.json
Capture a trace from Chrome on Android (with DevTools)
This also works
with tracing the system Android WebView.
DevTools to the Android device. Follow instructions
desktop chrome. Find the app to be traced, and click on the trace link
beside the title.
on "Record" at top left.
trace categories. Hit Record, then Stop.
Capture a trace from Chrome on Android (on the command line)
- Your device running Chrome on Android
- USB debugging
enabled and the device attached.
- Linux or Mac desktop. Sorry Windows friends!
You can use `profile_chrome.py` from one of two locations:
- Chromium source checkout: ./src/tools/profile_chrome.py
- Standalone adb_trace script from Github. This code is slightly stale and not recommended.
Follow these steps to record a
1. Launch the browser
Run Chrome normally.
Developers, however, may want to launch from the command line:
$ build/android/adb_run_content_shell URL # run content shell
$ clank/bin/adb_run_chrome URL # run clank (Googlers only)
2. Optionally, make a screen recording (optional)
adb shell screenrecord /sdcard/recording.mp4 && adb pull /sdcard/recording.mp4
--browser build --time 5 --view
Note: build here
refers to the version of Chrome you are tracing. Other valid values
beta (see --help for
a full list).
Tracing options for Android
You can also use additional command line flags to capture more data. For
Captures data about
system-level events. Generally useful categories are
sched = Kernel scheduling decisions
freq = CPU core frequency scaling
gfx = SurfaceFlinger events, Vsync
view = Android Framework events
input = Framework input event processing
adb shell atrace --list_categories
Adds arrows showing IPC
message flows, making it easier to
see message traffic.
trace categories, e.g.: --categories=disabled-by-default-cc.debug.scheduler,*
Adding more trace categories
makes it possible to see events that are
normally disabled. This particular example gives information about
why the compositor scheduler decided to run a given action. To see
the full list of categories, use --categories=list.
4. Frame viewer
Captures rich layer data
from the compositor. This is useful for understanding how the DOM
affects the compositor's layer tree structure. When viewing traces like
this, make sure to launch Chrome (on the desktop) with
the --enable-skia-benchmarking command line flag so that
all features are available.
5. Perf profiling
is a sampling profiler which can help you find performance intensive parts
of the source code. The --perf switch
runs perf and automatically combines the data with all other enabled event
You can also view the raw recorded perf data
using the command line which is printed out by
Making a Good Recording
- Keep the recording to a max of 10 seconds
- Try to keep to 1 activity per recording. If you see two slowdowns,
do one recording each. Or leave a second long pause between each.
- Pause and leave the computer completely idle for 2 seconds before
and after demonstrating the slowdown. This helps make the slow part
obvious in the recording.
Step by step:
- Start with only the tab you’re investigating and about:tracing open in
a fresh browser session (see below for other methods of figuring out
which tab is which if you need multiple).
Set up the tab for investigation to right before the point where the
problem will occur (e.g. right before an animation is going to be
triggered, or right before part of the page that scrolls
Start a tracing run in the about:tracing tab
Switch to the tab under investigation
Pause for a couple seconds to record empty space on the timeline (makes
finding it later easier)
Perform the action to trigger the bad performance behavior (e.g. start
the animation or scroll the page). Keeping the recorded activity under
10 seconds is a good idea.
Switch back to the about:tracing tab and stop the
For more repeatable trace recordings you
may want to consider using Telemetry to automate the process. In particular
the --profiler=trace, --profiler=v8 and --profiler=android-systrace flags
will save a trace for each tested page.
Slide deck of Android Tracing
This information is already detailed