Performance Monitoring uses
traces
to collect data about monitored processes in your app.
A trace is a report that contains data captured between two points in time
in your app.
For web apps, Performance Monitoring
automatically
collects a trace for each page
of your app called a
page load trace
. Each page load trace collects the
following default metrics:
first paint
? A metric that measures the time between when
the user navigates to a page and when
any
visual change happens
first contentful paint
? A metric that measures
the time between when a user navigates to a page and when meaningful content
displays, like an image or text
domInteractive
? A metric that measures the time between
when the user navigates to a page and when the page is considered interactive
for the user
domContentLoadedEventEnd
? A metric that measures the
time between when the user navigates to a page and when the initial HTML
document is completely loaded and parsed
loadEventEnd
? A metric that measures the time between when
the user navigates to the page and when the current document's
load event
completes
first input delay
? A metric that measures the time between
when the user interacts with a page and when the browser is able to respond to
that input
You can view data from these traces in the
Page load
subtab of the
traces table, which is at the bottom of the
Performance
dashboard (learn more
about
using the console
later on this page).
Definition of a page load trace
This trace measures several metrics about how the pages in your app load,
specifically how long it takes to reach common loading points, like an a
responsive app.
Page load traces help you track your app's
core web vitals
, like first
contentful paint.
Metrics collected for page load traces
These traces are out-of-the-box traces, so you cannot add custom metrics or
custom attributes to them.
First paint
This metric measures the time between when the user navigates to a page and when
any
visual change happens.
This metric is useful since the first paint signals to your users that the page
is
starting
to load.
Starts when the user navigates to a page.
Stops when
any
visual change happens, including a background color change or
a header loading.
First contentful paint
This metric measures the time between when a user navigates to a page and when
meaningful content displays, like an image or text.
This metric is useful for insights into how soon your users see any of your
app's actual content rather than just a new background color or header.
Starts when the user navigates to a page.
Stops immediately after the browser renders the first content from the DOM,
including any text, image (including background images), non-white canvas, or
SVG.
domInteractive
This metric measures the time between when the user navigates to a page and when
the page is considered interactive for the user.
This metric is useful for insights into how soon your users can actually
interact with elements in your app, like buttons and hyperlinks, rather than
just seeing them on the screen. Note that this doesn't mean that the browser
will respond to the interaction (for this metric, refer to
first input delay
trace
).
domContentLoadedEventEnd
This metric measures the time between when the user navigates to a page and when
the initial HTML document is completely loaded and parsed.
Starts when the user navigates to a page.
Stops immediately after the initial HTML document is completely loaded and
parsed (
DOMContentLoaded
), but this does not mean that stylesheets, images,
and subframes are finished loading.
loadEventEnd
This metric measures the time between when the user navigates to the page and
when the current document's
load event
completes.
This metric is useful for insights into how long it takes to load all your
content, including stylesheets and images.
This metric measures the time between when the user interacts with a page and
when the browser is able to respond to that input.
This metric is useful since the browser responding to a user interaction gives
your users their first impressions about the responsiveness of your app.
Starts when the user
first
interacts with an element on the page, like
clicking a button or hyperlink.
Stops immediately after the browser is able to respond to the input, meaning
that the browser isn't busy loading or parsing your content.
Note that to measure the first input delay metric, you need to add the polyfill
library for this metric. For installation instructions, refer to the library's
documentation
.
Track, view, and filter performance data
To view real-time performance data, make sure that your app uses a Performance
Monitoring SDK version that's compatible with real-time data processing.
Learn more about real-time performance data
.
Track key metrics in your dashboard
To learn how your key metrics are trending, add them to your metrics board at the top of the
Performance
dashboard. You can quickly identify regressions by seeing week-over-week
changes or verify that recent changes in your code are improving performance.
To add a metric to your metrics board, follow these steps:
- Go to the
Performance
dashboard
in the Firebase console.
- Click an empty metric card, then select an existing metric to add to your board.
- Click
more_vert
on a populated metric card for more options,
for example to replace or remove a metric.
The metrics board shows collected metric data over time, both in graphical form and as a
numerical percentage change.
Learn more about
using the dashboard
.
View traces and their data
To view your traces, go to the
Performance
dashboard
in the Firebase console, scroll down to the traces table, then click the appropriate subtab.
The table displays some top metrics for each trace, and you can even sort the list by the
percentage change for a specific metric.
Performance Monitoring provides a troubleshooting page in the Firebase console that highlights metric
changes, making it easy to quickly address and minimize the impact of performance issues on your
apps and users. You can use the troubleshooting page when you learn about potential
performance issues, for example, in the following scenarios:
- You select relevant metrics on the dashboard and you notice a big delta.
- In the traces table you sort to display the largest deltas at the top, and you see a
significant percentage change.
- You receive an email alert notifying you of a performance issue.
You can access the troubleshooting page in the following ways:
- On the metric dashboard, click the
View metric details
button.
- On any metric card, select
more_vert
=> View details
. The troubleshooting page displays information about the metric
you selected.
- In the traces table, click a trace name or any metric value in the row associated with that
trace.
- In an email alert, click
Investigate now
.
When you click a trace name in the traces table, you can then drill down into metrics of
interest. Click the
Filter
add
button to filter the data
by attribute, for example:
- Filter by
Page URL
to view data for a specific page of your site
- Filter by
Effective connection type
to learn how a 3g connection impacts your
app
- Filter by
Country
to make sure your database location isn't affecting a specific
region
Learn more about
viewing data for
your traces
.
Next Steps
Learn more about
using attributes
to examine performance data.
Learn more about how to
track performance issues
in the
Firebase console.
Set up alerts
for page loads that are degrading
the performance of your app. For example, you can configure an email alert for
your team if the
first input delay
for a specific page exceeds a
threshold that you set.