<!--
Copyright 2020 The Chromium Authors
Use of this source code is governed by a BSD-style license that can be
found in the LICENSE file.
-->
<!--
This file is used to generate a comprehensive list of Startup histograms
along with a detailed description for each histogram.
For best practices on writing histogram descriptions, see
https://chromium.googlesource.com/chromium/src.git/+/HEAD/tools/metrics/histograms/README.md
Please follow the instructions in the OWNERS file in this directory to find a
reviewer. If no OWNERS file exists, please consider signing up at
go/reviewing-metrics (Googlers only), as all subdirectories are expected to
have an OWNERS file. As a last resort you can send the CL to
[email protected].
-->
<histogram-configuration>
<histograms>
<histogram name="Startup.AfterStartupTaskCount" units="units"
expires_after="2025-02-10">
<owner>[email protected]</owner>
<summary>
The number of after-startup tasks that were queued prior to startup
completion and deferred until that time.
</summary>
</histogram>
<histogram name="Startup.AfterStartupTaskDelayedUntilTime" units="ms"
expires_after="2025-02-10">
<owner>[email protected]</owner>
<summary>
Time from the process creation until deferred after-startup tasks began
running. The histogram was expired and extended in M119 again.
</summary>
</histogram>
<histogram name="Startup.Android.BrowserProcessCreationReason"
enum="ProcessCreationReason" expires_after="2025-01-26">
<owner>[email protected]</owner>
<owner>[email protected]</owner>
<summary>
Records the first type of component created after process creation - most
likely the reason the process was created - at the time the component is
created on Android P+.
Differences in distribution between Android versions (particularly with
respect to ContentProviders) likely indicate a change to Android startup
that broke our detection.
</summary>
</histogram>
<histogram
name="Startup.Android.Cold.FirstNavigationCommitOccurredPreForeground"
enum="Boolean" expires_after="2024-09-29">
<owner>[email protected]</owner>
<owner>[email protected]</owner>
<summary>
Records whether the first navigation commit after a cold start occurred
before UmaUtils.hasComeToForegroundWithNative() became true. Recorded only
for startups in which startup metrics were being tracked.
</summary>
</histogram>
<histogram name="Startup.Android.Cold.FirstPaintOccurredPreForeground"
enum="Boolean" expires_after="2025-01-05">
<owner>[email protected]</owner>
<owner>[email protected]</owner>
<summary>
Records whether the first paint of StartupPaintPreview after a cold start
occurred before UmaUtils.hasComeToForegroundWithNative() became true.
Recorded only for startups in which startup metrics were being tracked.
</summary>
</histogram>
<histogram name="Startup.Android.Cold.FirstSafeBrowsingApiResponseTime2.Tabbed"
units="ms" expires_after="2025-01-29">
<owner>[email protected]</owner>
<owner>[email protected]</owner>
<owner>[email protected]</owner>
<summary>
The time it took GmsCore SafeBrowsing API to respond to the first
SafeBrowsing request for the Tabbed Activity during a cold start. Cold start
is determined by whether the process creation reason is Activity.
Similarly to Startup.Android.Cold.TimeToFirstVisibleContent2 omits recording
a sample:
1. when the first Activity is a CCT/WebAPK/TWA,
2. when an error page is committed,
3. for non-http(s) pages,
4. for downloads,
5. when another activity was shown and hidden before the first navigation
committed,
6. when the first navigation was preceded by showing a NTP (New Tab Page).
This v2 metric is recorded at the same time as
Startup.Android.Cold.TimeToFirstNavigationCommit3.Tabbed, utilizing
ColdStartTracker. Only logged if the URL of the first navigation is checked
by SafeBrowsing API.
</summary>
</histogram>
<histogram name="Startup.Android.Cold.FirstSafeBrowsingResponseTime.Tabbed"
units="ms" expires_after="2024-11-17">
<owner>[email protected]</owner>
<owner>[email protected]</owner>
<owner>[email protected]</owner>
<summary>
The time it took GmsCore SafetyNet API to respond to the first hash-prefix
SafeBrowsing database request in the process lifetime. Recorded at the same
time as Startup.Android.Cold.TimeToFirstNavigationCommit.Tabbed. Only logged
if the URL of the first navigation is checked by SafetyNet API.
</summary>
</histogram>
<histogram base="true" name="Startup.Android.Cold.TimeToFirstContentfulPaint"
units="ms" expires_after="2025-01-05">
<owner>[email protected]</owner>
<owner>[email protected]</owner>
<summary>
Android: The time from the activity creation point to the first contentful
paint of the first loaded page. It's not recorded when the first loaded page
is non http(s) page like a chrome error page, a new tab page, a blank page.
It's also not recorded if the application wasn't in the foreground since the
start till the end of event.
</summary>
</histogram>
<histogram name="Startup.Android.Cold.TimeToFirstContentfulPaint3" units="ms"
expires_after="2025-01-26">
<owner>[email protected]</owner>
<owner>[email protected]</owner>
<summary>
The time from activity creation on a cold start to FirstContentfulPaint
happening in this activity. Cold start is determined by whether the process
creation reason is Activity.
Recorded only for tabbed activity and on cold starts. Therefore it cannot be
recorded more than once in the application lifetime.
Similarly to Startup.Android.Cold.TimeToFirstVisibleContent2 omits recording
a sample:
1. when the first Activity is a CCT/WebAPK/TWA,
2. when an error page is committed,
3. for non-http(s) pages,
4. for downloads,
5. when another activity was shown and hidden before the first navigation
committed,
6. when the first navigation was preceded by showing a NTP (New Tab Page).
This v3 metric uses ColdStartTracker and is a rename for
Startup.Android.Experimental.FirstContentfulPaint.Tabbed. It otherwise
preserves the same semantics and aims to replace the original v1 metric as
well.
</summary>
</histogram>
<histogram base="true" name="Startup.Android.Cold.TimeToFirstNavigationCommit"
units="ms" expires_after="2025-01-05">
<owner>[email protected]</owner>
<owner>[email protected]</owner>
<summary>
Android: The time from the activity creation point to the moment the first
navigation is committed, i.e. when renderer gets the first byte of the
document. It's not recorded when the first loaded page is non http(s) page
like a chrome error page, a new tab page, a blank page. It's also not
recorded if the application wasn't in the foreground since the start till
the end of event.
</summary>
</histogram>
<histogram name="Startup.Android.Cold.TimeToFirstNavigationCommit2.Tabbed"
units="ms" expires_after="2025-01-05">
<owner>[email protected]</owner>
<owner>[email protected]</owner>
<summary>
Same as Startup.Android.Cold.TimeToFirstNavigationCommit.Tabbed with two
modifications. Aims to replace the original metric.
The first difference is to record navigation commits happening before
post-native initialization. The second modifications is not to record
samples when FRE is shown.
</summary>
</histogram>
<histogram
name="Startup.Android.Cold.TimeToFirstNavigationCommit3.{ActivityType}"
units="ms" expires_after="2025-01-26">
<owner>[email protected]</owner>
<owner>[email protected]</owner>
<owner>[email protected]</owner>
<summary>
The time from activity creation on a cold start to the FirstNavigationCommit
happening for a particular {ActivityType}. Cold start is determined by
whether the process creation reason is Activity.
Recorded for both Tabbed Activities and WebApks only during cold starts.
Omits recording a sample:
1. when the first Activity is a CCT/TWA,
2. when an error page is committed,
3. for non-http(s) pages,
4. for downloads,
5. when another activity was shown and hidden before the first navigation
committed,
6. when the first navigation was preceded by showing a NTP (New Tab Page).
This metric aims to replace
Startup.Android.Cold.TimeToFirstNavigationCommit2.Tabbed due to a loss of
samples for the v2 metric as well as add a .WebApk variant similar to the v1
metric.
It utilizes ColdStartTracker and records 5x more samples than what the v2
metric currently records. The Experimental metric,
Startup.Android.Experimental.FirstNavigationCommit.Tabbed.ColdStartTracker
is currently being used to diagnose A/B problems running in the field so the
new metric will replace it and the v2 metric once it approximately reaches
the counts of the Experimental one on Chrome Stable.
</summary>
<token key="ActivityType">
<variant name="Tabbed"/>
<variant name="WebApk"/>
</token>
</histogram>
<histogram name="Startup.Android.Cold.TimeToFirstVisibleContent" units="ms"
expires_after="never">
<!-- expires-never: guiding metric (internal: go/chrome-browser-guiding-metrics) -->
<owner>[email protected]</owner>
<owner>[email protected]</owner>
<owner>[email protected]</owner>
<owner>[email protected]</owner>
<summary>
The time from the first Chrome tabbed activity creation to the moment Chrome
first appears ready to the user.
This metric captures when the omnibox is painted and either a navigation has
committed or a Paint Preview is shown. The intent is to reflect Clank's
perceived cold start performance regardless of different launch paths, while
controlling for the factors that we have the most direct influence over and
minimizing external factors. Note that network connectivity is mostly but
not entirely omitted as it does impact the initial response time for a site
which impacts the omnibox UX and loading metric.
This metric captures the value of the first emitted metric out of the
'Startup.Android.Cold.TimeToFirstNavigationCommit.Tabbed' and
'Browser.PaintPreview.TabbedPlayer.TimeToFirstBitmap' metrics and emits the
value.
This metric is only recorded once per application lifetime during cold
startup i.e. when Chrome's native library is not loaded at first activity
creation. Specifically, it is recorded for the first foreground committed
http(s) URL in the primary frame if that first navigation is not: an error,
same-document navigation, or fragment navigation.
This metric is expected be stable from milestone to milestone. Updating
Chrome or the Android system image on the device are expected to result in a
noticeable slowdown on the first cold startup after. The total counts
changes for this histogram are not of significant importance; however, a
non-trivial increase in total counts could signal more background kills, for
example.
This metric is not recorded:
- If another navigation occurs before the first navigation commit and the
Paint Preview show.
- If the navigation is pre-warmed, is a background navigation, or fails to
be committed (e.g. cancelled, network error, or error due to lack of
connectivity).
- If the activity was ever backgrounded between activity creation and this
metric reporting.
- If the app opens to the Chrome Start page.
- For WebApps, PWAs or WebApks.
- For NTP.
Bugs:
- This metric does not get recorded when the first navigation commit happens
before post-native initialization. This behaviour is not intentional, see
crbug.com/1273097. TimeToFirstVisibleContent2 addresses this issue and aims
to become the replacement.
This histogram is of special interest to the chrome-analysis-team@. Do not
change its semantics or retire it without talking to them first.
</summary>
</histogram>
<histogram name="Startup.Android.Cold.TimeToFirstVisibleContent2" units="ms"
expires_after="never">
<!-- expires-never: guiding metric (internal: go/chrome-browser-guiding-metrics) -->
<owner>[email protected]</owner>
<owner>[email protected]</owner>
<owner>[email protected]</owner>
<owner>[email protected]</owner>
<summary>
The time from the first Chrome tabbed activity creation to the moment Chrome
first appears ready to the user.
This metric captures when the omnibox is painted and either a navigation has
committed or a Paint Preview is shown. The intent is to reflect Clank's
perceived cold start performance regardless of different launch paths, while
controlling for the factors that we have the most direct influence over and
minimizing external factors. Note that network connectivity is mostly but
not entirely omitted as it does impact the initial response time for a site
which impacts the omnibox UX and loading metric.
This metric captures the value of the first emitted metric out of the
'Startup.Android.Cold.TimeToFirstNavigationCommit.Tabbed' and
'Browser.PaintPreview.TabbedPlayer.TimeToFirstBitmap' metrics and emits the
value.
This metric is only recorded once per application lifetime during cold
startup i.e. when Chrome's native library is not loaded at first activity
creation. Specifically, it is recorded for the first foreground committed
http(s) URL in the primary frame if that first navigation is not: an error,
same-document navigation, or fragment navigation.
This metric is expected be stable from milestone to milestone. Updating
Chrome or the Android system image on the device are expected to result in a
noticeable slowdown on the first cold startup after. The total counts
changes for this histogram are not of significant importance; however, a
non-trivial increase in total counts could signal more background kills, for
example.
This metric is not recorded:
- If another navigation occurs before the first navigation commit and the
Paint Preview show.
- If the navigation is pre-warmed, is a background navigation, or fails to
be committed (e.g. cancelled, network error, or error due to lack of
connectivity).
- If the activity was ever backgrounded between activity creation and this
metric reporting.
- If the app opens to the Chrome Start page.
- For WebApps, PWAs or WebApks.
- For NTP.
This metrics has the same semantics as
Startup.Android.Cold.TimeToFirstVisibleContent, except with the
crbug.com/1273097 fixed. In other words, this v2 metric also records a
sample when the first navigation commit happens before post-native
initialization.
This histogram is of special interest to the chrome-analysis-team@. Do not
change its semantics or retire it without talking to them first.
</summary>
</histogram>
<histogram name="Startup.Android.Cold.TimeToFirstVisibleContent3" units="ms"
expires_after="2025-01-26">
<owner>[email protected]</owner>
<owner>[email protected]</owner>
<owner>[email protected]</owner>
<owner>[email protected]</owner>
<summary>
The time from the first Chrome tabbed activity creation to the moment Chrome
first appears ready to the user.
This metric captures when the omnibox is painted and either a navigation has
committed or a Paint Preview is shown. The intent is to reflect Clank's
perceived cold start performance regardless of different launch paths, while
controlling for the factors that we have the most direct influence over and
minimizing external factors. Note that network connectivity is mostly but
not entirely omitted as it does impact the initial response time for a site
which impacts the omnibox UX and loading metric.
This metric captures the value of the first emitted metric out of the
'Startup.Android.Cold.TimeToFirstNavigationCommit3.Tabbed' and
'Browser.PaintPreview.TabbedPlayer.TimeToFirstBitmap' metrics and emits the
value, skipping the record when both are missing.
The metric is meant to replace
Startup.Android.Cold.TimeToFirstVisibleContent2 as a guardrail metric and
therefore has the same semantics as the v2 version except with one of the
sub-metrics changed. For the v2 metric,
Startup.Android.Cold.TimeToFirstNavigationCommit2.Tabbed, was one of the
sub-metrics, however, moving the native library initialization to be earlier
resulted in a loss of samples. Therefore, the new sub-metric,
TimeToFirstNavigationCommit3.Tabbed, utilizes ColdStartTracker for its lower
maintenance risks, and preservation of the good properties from v2, all
while providing 5x more samples.
</summary>
</histogram>
<histogram name="Startup.Android.Cold.TimeToForegroundSessionStart" units="ms"
expires_after="2025-01-05">
<owner>[email protected]</owner>
<owner>[email protected]</owner>
<summary>
The time from activity creation till the point when UMA foreground session
starts.
</summary>
</histogram>
<histogram name="Startup.Android.Cold.TimeToVisibleContent" units="ms"
expires_after="2025-01-05">
<owner>[email protected]</owner>
<summary>
Android: The time from the activity creation point to the moment the content
may first appear ready to a user. The intent is to capture readiness of
Chrome regardless of whether Chrome is launched into native UI or a web
page. The recorded value is the minimum of
'Startup.Android.Cold.TimeToFirstContentfulPaint.Tabbed' and
'Browser.PaintPreview.TabbedPlayer.TimeToFirstBitmap' metric values.
Not to be mistaken with the Startup.Android.Cold.TimeToFirstVisibleContent
histogram, as this metric is intended for the use of the Paint Preview
owners and the other is intended to track Clank's perceived cold start
performance.
</summary>
</histogram>
<histogram name="Startup.Android.DurationSinceLastBackgroundTime" units="ms"
expires_after="2025-01-26">
<owner>[email protected]</owner>
<owner>[email protected]</owner>
<summary>
Android: The elapsed time from the last time when Chrome goes to background
till it becomes foreground again. The histogram is recorded when
onResumeWithNative() is called.
</summary>
</histogram>
<histogram name="Startup.Android.Experimental.{name}.Tabbed.ColdStartTracker"
units="ms" expires_after="2024-12-30">
<owner>[email protected]</owner>
<owner>[email protected]</owner>
<owner>[email protected]</owner>
<summary>
The time from activity creation on a cold start to the {name} happening in
this activity. Cold start is determined by whether the process creation
reason is Activity.
Recorded only for tabbed activity and on cold starts. Therefore it cannot be
recorded more than once in the application lifetime.
Similarly to Startup.Android.Cold.TimeToFirstVisibleContent2 omits recording
a sample:
1. when the first Activity is a CCT/WebAPK/TWA,
2. when an error page is committed,
3. for non-http(s) pages,
4. for downloads,
5. when another activity was shown and hidden before the first navigation
committed,
6. when the first navigation was preceded by showing a NTP (New Tab Page).
For cold start detection based on process creation reason it is recommended
to limit analysis of data on the UMA dashboard to Android P+ because on
prior versions the cold start detection is time-based and therefore less
robust.
TODO(pasko): Rename the .ColdStartTracker suffix when graduating these
histograms out of experimental. The preference is to avoid Java class names
in metric names.
</summary>
<token key="name">
<variant name="FirstContentfulPaint"
summary="first contentful paint (FCP)"/>
<variant name="FirstNavigationCommit" summary="first navigation commit"/>
</token>
</histogram>
<histogram base="true" name="Startup.Android.FeedContentFirstLoadedTime"
units="ms" expires_after="2024-09-15">
<owner>[email protected]</owner>
<owner>[email protected]</owner>
<summary>
Records the time duration from a cold start till the Feeds articles are
first loaded on the StartSurface. This histogram is only recorded when
StartSurface is shown at launch due to "return to tab switcher"
feature.
</summary>
</histogram>
<histogram base="true" name="Startup.Android.FeedStreamCreatedTime" units="ms"
expires_after="2024-09-15">
<owner>[email protected]</owner>
<owner>[email protected]</owner>
<summary>
Records the time duration from a cold start till the Feeds stream is created
on the StartSurface. This histogram is only recorded when StartSurface is
shown at launch due to "return to tab switcher" feature.
</summary>
</histogram>
<histogram base="true" name="Startup.Android.FirstDrawCompletedTime" units="ms"
expires_after="2024-09-15">
<owner>[email protected]</owner>
<owner>[email protected]</owner>
<summary>
Records the time duration from a cold start till the first draw completes.
</summary>
</histogram>
<histogram name="Startup.Android.GURLEnsureMainDexInitialized" units="ms"
expires_after="2025-02-16">
<owner>[email protected]</owner>
<owner>[email protected]</owner>
<summary>
Measures the amount of time startup has likely been delayed due to GURL
waiting on the native library to be initialized.
</summary>
</histogram>
<histogram name="Startup.Android.IsLastBackgroundTimeLogged" enum="Boolean"
expires_after="2024-11-17">
<owner>[email protected]</owner>
<owner>[email protected]</owner>
<summary>
Android: Records whether the last time when Chrome went to background or
closed was logged. The histogram is recorded when onResumeWithNative() is
called.
</summary>
</histogram>
<histogram name="Startup.Android.IsLastVisibleTimeLogged" enum="Boolean"
expires_after="2025-01-26">
<owner>[email protected]</owner>
<owner>[email protected]</owner>
<summary>
Android: Records whether the last time when Chrome was showing in foreground
was logged. The histogram is recorded when onResumeWithNative() is called.
</summary>
</histogram>
<histogram name="Startup.Android.LastVisitedTabIsSRPWhenOverviewShownAtLaunch"
enum="Boolean" expires_after="2024-09-15">
<owner>[email protected]</owner>
<owner>[email protected]</owner>
<summary>
Records whether or not the last visited tab is a search result page when
StartSurface is shown at launch. This histogram is only recorded when
StartSurface is shown at launch due to "return to tab switcher"
feature.
</summary>
</histogram>
<histogram name="Startup.Android.MainIntentIsColdStart" enum="Boolean"
expires_after="2025-02-08">
<owner>[email protected]</owner>
<owner>[email protected]</owner>
<summary>
Records whether Chrome started cold or warm when the main Chrome launcher
icon is used to start the app i.e. LaunchCauseType is MAIN_LAUNCHER_ICON or
MAIN_LAUNCHER_ICON_SHORTCUT.
Utilizes ColdStartTracker to determine if a start was cold based on process
creation reason. Therefore, it is recommended to limit analysis of the data
to Android P+ because on prior versions the cold start detection is
time-based and therefore less robust.
</summary>
</histogram>
<histogram name="Startup.Android.PrivacySandbox.AdsNoticeCCTAppIDCheck"
enum="Boolean" expires_after="2025-02-10">
<owner>[email protected]</owner>
<owner>[email protected]</owner>
<summary>
Whether or not the current AppID matches the required AppID from the
PrivacySandboxAdsNoticeCCT feature parameter. Returns true if required AppID
is not specified.
</summary>
</histogram>
<histogram
name="Startup.Android.PrivacySandbox.DialogNotShownDueToTabLaunchedFromExternalApp"
enum="Boolean" expires_after="2024-08-04">
<owner>[email protected]</owner>
<owner>[email protected]</owner>
<summary>
Android: PrivacySandbox dialog not shown because Chrome Tab was launched
from an external app.
</summary>
</histogram>
<histogram name="Startup.Android.PrivacySandbox.ShouldShowAdsNoticeCCT"
enum="Boolean" expires_after="2025-02-02">
<owner>[email protected]</owner>
<owner>[email protected]</owner>
<summary>
Whether or not the user using a CCT meets the requirements to view the
Privacy Sandbox Ads Notice.
</summary>
</histogram>
<histogram base="true" name="Startup.Android.SingleTabTitleAvailableTime"
units="ms" expires_after="2024-09-15">
<owner>[email protected]</owner>
<owner>[email protected]</owner>
<summary>
Records the time duration from a cold start till the title of the single Tab
is shown on the StartSurface. This histogram is only recorded when
StartSurface is shown at launch due to "return to tab switcher"
feature.
</summary>
</histogram>
<histogram name="Startup.Android.StartSurfaceShownAtStartup" enum="Boolean"
expires_after="2024-11-17">
<owner>[email protected]</owner>
<owner>[email protected]</owner>
<summary>
Records whether the Start surface homepage is showing at a cold startup when
the Start surface is enabled. This histogram is recorded in a deferred
startup task after Chrome is launched.
</summary>
</histogram>
<histogram name="Startup.BlockForCrashpadHandlerStartupTime" units="ms"
expires_after="M85">
<owner>[email protected]</owner>
<owner>[email protected]</owner>
<summary>
The amount of time that elapsed during in
crash_report::BlockUntilHandlerStarted().
</summary>
</histogram>
<histogram name="Startup.BringToForegroundReason"
enum="BooleanBringToForegroundReason" expires_after="2025-01-05">
<owner>[email protected]</owner>
<summary>
Records the cause, each time Chrome is brought to the foreground. Currently
only checks if a NotificationUIManager notification was shown in the last 5
seconds (includes Web Notifications, but not media or Cast).
</summary>
</histogram>
<histogram name="Startup.BrowserMainRunnerImplInitializeLongTime" units="ms"
expires_after="2025-02-10">
<owner>[email protected]</owner>
<summary>
The amount of time that elapsed during BrowserMainRunnerImpl::Initialize.
</summary>
</histogram>
<histogram name="Startup.BrowserMessageLoopFirstIdle" units="ms"
expires_after="2025-02-09">
<owner>[email protected]</owner>
<owner>[email protected]</owner>
<summary>
Time from application start to the first time MainMessageLoopRun() reaches
idle. This is a new (Feb'2021) metric intended to capture UI jank caused by
the long queue of tasks post initialization. This is believed to capture
performance issues (startup responsiveness) none of the other Startup.*
metrics capture (crbug.com/1175074). Recording is dropped if blocking UI is
shown before first-idle is reached (as this blocks main loop progress on
unbounded user interaction).
On ChromeOS: Was not being recorded when the device started at the login
screen. Fixed in M129.
</summary>
</histogram>
<histogram name="Startup.BrowserMessageLoopStart.To.NonEmptyPaint2" units="ms"
expires_after="never">
<!-- expires-never: breakdown metric for Startup.FirstWebContents.NonEmptyPaint2
guardrail metrics -->
<owner>[email protected]</owner>
<owner>[email protected]</owner>
<summary>
Time between Startup.BrowserMessageLoopStartTime and
Startup.FirstWebContents.NonEmptyPaint2. Recorded explicitly to allow easy
breakdown of Startup.FirstWebContents.NonEmptyPaint2 when diagnosing issues.
On ChromeOS: This metric was broken before M129. The code considered
displaying the login screen as impeding the initial foreground tab even
though a browser window doesn't even exist at that stage. Since it's common
for the device to boot to the login screen, this metric was being recorded a
small percentage of the time. This metric was fixed in M129 to be recorded
for the active browser window's initial foreground tab from a full ChromeOS
user session restore. However, since the arbitrarily long amount of time
that the user spends at the login screen is incorporated into this
measurement, it is highly recommended to analyze
Startup.FirstWebContents.NonEmptyPaint3 instead.
</summary>
</histogram>
<histogram name="Startup.BrowserMessageLoopStartHardFaultCount" units="faults"
expires_after="never">
<!-- expires-never: calibration metric for StartupTemperature, see
kColdStartHardFaultCountThreshold and WarmStartHardFaultCountThreshold in
startup_metric_utils.cc for details -->
<owner>[email protected]</owner>
<owner>[email protected]</owner>
<summary>
The number of hard faults incurred in the browser process from startup to
start of the main thread's message loop, not including first runs of the
browser.
</summary>
</histogram>
<histogram name="Startup.BrowserMessageLoopStartTime" units="ms"
expires_after="never">
<!-- expires-never: used to diagnose regressions to Startup.FirstWebContents.NonEmptyPaint3 -->
<owner>[email protected]</owner>
<owner>[email protected]</owner>
<summary>
Time from application start to the start of the main thread's message loop.
Not recorded for first run.
April 8, 2020: Changed the reference from process creation to application
start. See Startup.FirstWebContents.NonEmptyPaint3 for a definition of
application start.
On ChromeOS: Was not being recorded when the device started at the login
screen. Fixed in M129.
</summary>
</histogram>
<histogram name="Startup.BrowserMessageLoopStartTime.FirstRun" units="ms"
expires_after="never">
<!-- expires-never: only metric to ensure that first run doesn't regress -->
<owner>[email protected]</owner>
<owner>[email protected]</owner>
<summary>
Time from application start to the start of the main thread's message loop.
Recorded for a first run of the browser.
April 8, 2020: Changed the reference from process creation to application
start. See Startup.FirstWebContents.NonEmptyPaint3 for a definition of
application start.
On ChromeOS: Was not being recorded when the device started at the login
screen. Fixed in M129.
</summary>
</histogram>
<histogram name="Startup.BrowserWindow.FirstPaint" units="ms"
expires_after="2025-02-10">
<owner>[email protected]</owner>
<owner>[email protected]</owner>
<summary>
Time from application start to the time the first Browser window has
finished painting its children.
April 8, 2020: Changed the reference from process creation to application
start. See Startup.FirstWebContents.NonEmptyPaint3 for a definition of
application start.
On ChromeOS: This metric was broken before M129. The code considered
displaying the login screen as impeding the initial foreground tab even
though a browser window doesn't even exist at that stage. Since it's common
for the device to boot to the login screen, this metric was being recorded a
small percentage of the time. This metric was fixed in M129 to be recorded
for the active browser window's initial foreground tab from a full ChromeOS
user session restore. The latency is measured from the time the browser
window restore begins, rather than application start. Browser window restore
begins after login either immediately or after the user clicks a
notification prompting them to do so, depending on their settings. If the
user did not have a Chrome browser window open in the previous session, this
metric is not recorded.
</summary>
</histogram>
<histogram name="Startup.BrowserWindowDisplay" units="ms" expires_after="never">
<!-- expires-never: used to diagnose regressions to Startup.FirstWebContents.NonEmptyPaint3 -->
<owner>[email protected]</owner>
<owner>[email protected]</owner>
<summary>
Time from application start to the time the browser window initially becomes
visible.
April 8, 2020: Changed the reference from process creation to application
start. See Startup.FirstWebContents.NonEmptyPaint3 for a definition of
application start.
</summary>
</histogram>
<histogram name="Startup.ColdStartFromMain" units="ms"
expires_after="2025-03-26">
<owner>[email protected]</owner>
<owner>[email protected]</owner>
<summary>
The duration of all initializations from the call to main to UI ready to
receive input. iOS specific, from M125+
The process can only be created in response to a user action, either tapping
the icon, tapping a link that opens in Chrome, or using the app switcher to
switch to Chrome after it has been background-killed by the OS.
The metric is recorded at the point where the Chrome window starts receiving
input events like touches and keypresses. However, the Chrome splash screen
is showing at this point, so there aren't any UI elements for a user to
interact with.
It does not include code loading and static initializers.
The total counts in this histogram can be compared with the number of emits
to the user action MobileWillEnterForeground. The former reports the number
of cold starts. The latter is only recorded when Chrome comes to the
foreground on non-cold starts.
</summary>
</histogram>
<histogram name="Startup.ConsecutiveDidFinishLaunchingWithoutLaunch"
units="count" expires_after="2024-09-18">
<owner>[email protected]</owner>
<owner>[email protected]</owner>
<summary>
[IOS] The number of time [UIApplicationDelegate
application:didFinishLaynching] was called but no scene was activated.
Recorded when first scene is becomes active.
</summary>
</histogram>
<histogram name="Startup.ConsecutiveLoadsWithoutLaunch" units="count"
expires_after="2025-05-30">
<owner>[email protected]</owner>
<owner>[email protected]</owner>
<summary>
[IOS] The number of time +load was called but no scene was activated.
Recorded when first scene is becomes active.
</summary>
</histogram>
<histogram name="Startup.CreateFirstProfile" units="ms" expires_after="never">
<!-- expires-never: used to diagnose regressions to Startup.FirstWebContents.NonEmptyPaint3 -->
<owner>[email protected]</owner>
<owner>[email protected]</owner>
<summary>
How long it takes to load the original profile synchronously on the UI
thread.
</summary>
</histogram>
<histogram base="true" name="Startup.CreateProcessLauncher2.{Status}"
units="ms" expires_after="2025-02-05">
<owner>[email protected]</owner>
<owner>[email protected]</owner>
<summary>
Records the time it took for the creation attempt of the ProcessLauncher COM
class when {Status}. The `AtStartup` variants record the creation attempt
times for when Windows has just started up, and the non-`AtStartup` variants
record the creation attempt times for all the other cases. Only recorded on
Windows.
</summary>
<token key="Status">
<variant name="TimedWaitFailed"/>
<variant name="TimedWaitFailedAtStartup"/>
<variant name="TimedWaitSucceeded"/>
<variant name="TimedWaitSucceededAtStartup"/>
</token>
</histogram>
<histogram base="true" name="Startup.DoUpgradeTasks.{Status}" units="ms"
expires_after="M99">
<owner>[email protected]</owner>
<owner>[email protected]</owner>
<summary>
Records the time it took to complete upgrade_util::DoUpgradeTasks() when
{Status}.
</summary>
<token key="Status">
<variant name="NoRelaunch"/>
<variant name="RelaunchFailed"/>
<variant name="RelaunchSucceeded"/>
</token>
</histogram>
<histogram name="Startup.FirstWebContents.FinishReason"
enum="StartupProfilingFinishReason" expires_after="never">
<!-- expires-never: used to understand user behavior shifts when Startup.FirstWebContents.NonEmptyPaint3 regresses -->
<owner>[email protected]</owner>
<owner>[email protected]</owner>
<summary>
[Desktop] The reason for which startup profiling was deemed complete. Logged
once per session on startup.
On ChromeOS: This metric was broken before M129. Since the device typically
boots to the login screen (at which point a browser window doesn't exist),
`kAbandonNoInitiallyVisibleContent` was recorded most of the time.
WebContents-related startup metrics were fixed in M129 to be recorded after
login during a full ChromeOS user session restore. `kDone` is expected to be
the predominant recording after the fix.
</summary>
</histogram>
<histogram name="Startup.FirstWebContents.MainNavigationFinished" units="ms"
expires_after="never">
<!-- expires-never: used to diagnose regressions to Startup.FirstWebContents.NonEmptyPaint3 -->
<owner>[email protected]</owner>
<owner>[email protected]</owner>
<summary>
[Desktop] Measure the elapsed time from application start to the moment when
the navigation is committed (first bytes received) in the first web
contents' main frame.
April 8, 2020: Changed the reference from process creation to application
start. See Startup.FirstWebContents.NonEmptyPaint3 for a definition of
application start.
On ChromeOS: This metric was broken before M129. The code considered
displaying the login screen as impeding the initial foreground tab even
though a browser window doesn't even exist at that stage. Since it's common
for the device to boot to the login screen, this metric was being recorded a
small percentage of the time. This metric was fixed in M129 to be recorded
for the active browser window's initial foreground tab from a full ChromeOS
user session restore. The latency is measured from the time the browser
window restore begins, rather than application start. Browser window restore
begins after login either immediately or after the user clicks a
notification prompting them to do so, depending on their settings. If the
user did not have a Chrome browser window open in the previous session, this
metric is not recorded.
</summary>
</histogram>
<histogram name="Startup.FirstWebContents.MainNavigationStart" units="ms"
expires_after="never">
<!-- expires-never: used to diagnose regressions to Startup.FirstWebContents.NonEmptyPaint3 -->
<owner>[email protected]</owner>
<owner>[email protected]</owner>
<summary>
[Desktop] Measure the elapsed time from application start to the beginning
of navigation in the first web contents' main frame.
April 8, 2020: Changed the reference from process creation to application
start. See Startup.FirstWebContents.NonEmptyPaint3 for a definition of
application start.
On ChromeOS: This metric was broken before M129. The code considered
displaying the login screen as impeding the initial foreground tab even
though a browser window doesn't even exist at that stage. Since it's common
for the device to boot to the login screen, this metric was being recorded a
small percentage of the time. This metric was fixed in M129 to be recorded
for the active browser window's initial foreground tab from a full ChromeOS
user session restore. The latency is measured from the time the browser
window restore begins, rather than application start. Browser window restore
begins after login either immediately or after the user clicks a
notification prompting them to do so, depending on their settings. If the
user did not have a Chrome browser window open in the previous session, this
metric is not recorded.
</summary>
</histogram>
<histogram name="Startup.FirstWebContents.NonEmptyPaint3" units="ms"
expires_after="never">
<!-- expires-never: guiding metric (internal: go/chrome-browser-guiding-metrics) -->
<owner>[email protected]</owner>
<owner>[email protected]</owner>
<owner>[email protected]</owner>
<owner>[email protected]</owner>
<improvement direction="LOWER_IS_BETTER"/>
<summary>
[Desktop] Measure the elapsed time from the application start to the first
non empty paint of the first web contents. Only comprised of cases where the
initial foreground tab gets to complete its rendering task unimpeded (an
improvement over Startup.FirstWebContents.NonEmptyPaint).
Application start is a time recorded as early as possible in the startup
process. On Windows, application start is when chrome.exe:main starts,
before chrome.dll is loaded. On other platforms, it is when
ChromeMainDelegate is constructed.
On ChromeOS: This metric was broken before M129. The code considered
displaying the login screen as impeding the initial foreground tab even
though a browser window doesn't even exist at that stage. Since it's common
for the device to boot to the login screen, this metric was being recorded a
small percentage of the time. This metric was fixed in M129 to be recorded
for the active browser window's initial foreground tab from a full ChromeOS
user session restore. The latency is measured from the time the browser
window restore begins, rather than application start. Browser window restore
begins after login either immediately or after the user clicks a
notification prompting them to do so, depending on their settings. If the
user did not have a Chrome browser window open in the previous session, this
metric is not recorded.
Do not modify this metric in any way without contacting
[email protected].
</summary>
</histogram>
<histogram name="Startup.GPU.LoadTime.ApplicationStartToGpuInitialized"
units="ms" expires_after="2025-02-09">
<owner>[email protected]</owner>
<owner>[email protected]</owner>
<summary>
Time from when the application started to when the GPU finishes its
initialization.
Application start is a time recorded as early as possible in GPU process
startup. On Windows, application start is at the start of the GPU process'
chrome.exe:main, before chrome.dll is loaded. On other platforms, it is when
ChromeMainDelegate is constructed.
It should be noted that this does not include rendezvous starts, since in
that case, a new GPU process is not launched.
This metric is recorded every time the GPU process finishes its
initialization, including the case where the process restarts several times
during the same browser session. This does not include the GPU info
collection process, as that process does not use the GpuServiceImpl.
</summary>
</histogram>
<histogram name="Startup.GPU.LoadTime.ChromeMainToGpuInitialized" units="ms"
expires_after="2025-02-09">
<owner>[email protected]</owner>
<owner>[email protected]</owner>
<summary>
Time from when ChromeMain was entered in the GPU process to when the GPU
finishes its initialization.
This metric is recorded every time the GPU process finishes its
initialization, including the case where the GPU process restarts several
times during the same browser session.
</summary>
</histogram>
<histogram name="Startup.GPU.LoadTime.ProcessCreationToGpuInitialized"
units="ms" expires_after="2025-02-09">
<owner>[email protected]</owner>
<owner>[email protected]</owner>
<summary>
Time from when the GPU process was created according to the OS, to when the
GPU finishes its initialization.
Mostly useful on Windows, where much time is spent in pre-main.
This metric is recorded every time the GPU process finishes its
initialization, including the case where the GPU process restarts several
times during the same browser session.
</summary>
</histogram>
<histogram name="Startup.IncognitoForcedStart" enum="IncognitoForcedStart"
expires_after="M134">
<owner>[email protected]</owner>
<owner>[email protected]</owner>
<owner>[email protected]</owner>
<summary>
Records whether Incognito switch was present in commmand line switches and
if Incognito mode was enforced or denied. This is recorded during browser
startup when commandline is processed.
</summary>
</histogram>
<histogram name="Startup.InitializeFontConfigDuration" units="ms"
expires_after="2025-02-10">
<owner>[email protected]</owner>
<owner>[email protected]</owner>
<summary>
The time taken to initialize FontConfig. Recorded once on startup on Linux
and ChromeOS.
</summary>
</histogram>
<histogram name="Startup.IOSColdStartType" enum="IOSColdStartType"
expires_after="2025-04-01">
<owner>[email protected]</owner>
<owner>[email protected]</owner>
<summary>
Records session type for a cold start. It is recorded at cold start.
Histogram only for iOS.
</summary>
</histogram>
<histogram name="Startup.LoadTime.ApplicationStartToChromeMain" units="ms"
expires_after="never">
<!-- expires-never: used to diagnose regressions to Startup.FirstWebContents.NonEmptyPaint3 -->
<owner>[email protected]</owner>
<owner>[email protected]</owner>
<owner>[email protected]</owner>
<summary>
Time from the application start to the C++ ChromeMain() function being
invoked.
On ChromeOS: Was not being recorded when the device started at the login
screen. Fixed in M129.
</summary>
</histogram>
<histogram name="Startup.LoadTime.ProcessCreateToApplicationStart" units="ms"
expires_after="never">
<!-- expires-never: used to diagnose regressions to Startup.FirstWebContents.NonEmptyPaint3 -->
<owner>[email protected]</owner>
<owner>[email protected]</owner>
<owner>[email protected]</owner>
<summary>
Time from the process creation to application start, i.e. time recorded as
early as possible in the startup process.
On ChromeOS: Was not being recorded when the device started at the login
screen. Fixed in M129.
</summary>
</histogram>
<histogram name="Startup.LoadTime.RecordedProcessCreation" enum="Boolean"
expires_after="2024-12-30">
<owner>[email protected]</owner>
<owner>[email protected]</owner>
<summary>
Whether Process::Current().CreationTime() was able to acquire the process
startup time. Recorded once per process startup, as early as possible.
</summary>
</histogram>
<histogram name="Startup.MobileSessionStartAction"
enum="MobileSessionStartAction" expires_after="2025-01-05">
<owner>[email protected]</owner>
<owner>[email protected]</owner>
<summary>
The action requested on the application startup when called from another app
or the OS.
</summary>
</histogram>
<histogram name="Startup.MobileSessionStartFromApps"
enum="MobileSessionCallerApp" expires_after="2025-01-05">
<owner>[email protected]</owner>
<owner>[email protected]</owner>
<summary>The calling application (if any).</summary>
</histogram>
<histogram name="Startup.PreMainMessageLoopRunImplLongTime" units="ms"
expires_after="2025-01-05">
<owner>[email protected]</owner>
<summary>
The amount of time that elapsed during
ChromeBrowserMainParts::PreMainMessageLoopRunImpl.
</summary>
</histogram>
<histogram
name="Startup.Renderer.LoadTime.ApplicationStartToRendererStartRunLoop"
units="ms" expires_after="2025-01-05">
<owner>[email protected]</owner>
<owner>[email protected]</owner>
<summary>
Time from application start to renderer run loop start.
Application start is a time recorded as early as possible in renderer
process startup. Application start is at the start of the renderer process'
chrome.exe:main, before chrome.dll is loaded.
This metric is only recorded on Windows, and is recorded every time a
renderer process starts its run loop, meaning that many instances of this
metric will be recorded throughout one execution of the browser.
</summary>
</histogram>
<histogram name="Startup.Renderer.LoadTime.ChromeMainToRendererStartRunLoop"
units="ms" expires_after="2025-01-05">
<owner>[email protected]</owner>
<owner>[email protected]</owner>
<summary>
Time from when ChromeMain in the renderer process was entered to when the
renderer run loop was started.
This metric is only recorded on Windows, and is recorded every time a
renderer process starts its run loop, meaning that many instances of this
metric will be recorded throughout one execution of the browser.
</summary>
</histogram>
<histogram
name="Startup.Renderer.LoadTime.ProcessCreationToRendererStartRunLoop"
units="ms" expires_after="2025-01-05">
<owner>[email protected]</owner>
<owner>[email protected]</owner>
<summary>
Time from when the renderer process was created (CreateProcess call) to when
the renderer run loop is started.
This metric is only recorded on Windows, and is recorded every time a
renderer process starts its run loop, meaning that many instances of this
metric will be recorded throughout one execution of the browser.
</summary>
</histogram>
<histogram name="Startup.ShowDefaultPromoFromApps"
enum="MobileSessionCallerApp" expires_after="2023-05-23">
<owner>[email protected]</owner>
<owner>[email protected]</owner>
<summary>
The external application requesting showing the default browser settings.
Logged when the command is received from the external application. Histogram
only for iOS.
</summary>
</histogram>
<histogram name="Startup.StartupBrowserCreator.LaunchBrowser" units="ms"
expires_after="2024-11-17">
<owner>[email protected]</owner>
<owner>[email protected]</owner>
<owner>[email protected]</owner>
<summary>
The amount of time that elapsed during
StartupBrowserCreator::LaunchBrowser().
</summary>
</histogram>
<histogram name="Startup.Temperature" enum="StartupTemperature"
expires_after="2025-01-26">
<!-- expires-after: Diagnosis metric for changes in StartupTemperature suffix.
Shouldn't truly expire but kColdStartHardFaultCountThreshold should be
surveyed yearly. -->
<owner>[email protected]</owner>
<owner>[email protected]</owner>
<summary>
Indicates whether or not the given startup was warm, cold or unable to be
determined. This is based off observing the number of hard faults that occur
during startup prior to Startup.BrowserMessageLoopStartTime. The threshold
for cold startup was updated Jan 2020, a bump in the metric is expected.
</summary>
</histogram>
<histogram name="Startup.TimeFromMainToDidFinishLaunchingCall" units="ms"
expires_after="2025-03-26">
<owner>[email protected]</owner>
<owner>[email protected]</owner>
<summary>
[IOS] The duration between the call to main and the call to
[UIApplicationDelegate didFinishLaunching:]. Recorded when first scene is
becomes active.
</summary>
</histogram>
<histogram name="Startup.TimeFromMainToSceneConnection" units="ms"
expires_after="2025-03-26">
<owner>[email protected]</owner>
<owner>[email protected]</owner>
<summary>
[IOS] The duration between the call to main and the call to the first scene
connection. Recorded when first scene is becomes active.
</summary>
</histogram>
<histogram name="Startup.{Process}.LoadTime.PreReadFile" units="ms"
expires_after="2025-01-05">
<owner>[email protected]</owner>
<owner>[email protected]</owner>
<owner>[email protected]</owner>
<summary>
Time that it took to call base::PreReadFile() during main DLL
initialization. Only recorded on Windows. Recorded once on {Process} process
startup, as early as possible, but only if base::PreReadFile() was called.
</summary>
<token key="Process">
<variant name="Browser"/>
<variant name="GPU"/>
<variant name="Renderer"/>
</token>
</histogram>
</histograms>
</histogram-configuration>
Codebase Browser
chromium