FullStory captures page speed metrics alongside each captured session. FullStory emphasizes three key, industry-standard metrics that you can reference to understand how fast pages loaded within a customer's session.
Which page speed metrics does FullStory capture?
Within the Events stream for any session playback, FullStory will show four key metrics for each visited page:
- First Contentful Paint (FCP)
- Largest Contentful Paint (LCP)
- DOMContentLoaded (DCL), and
- Page Load, also known as the "onload" event
First Contentful Paint (FCP)
The First Contentful Paint event relates to the moment when the first element from the DOM appears in the users' browser.
Here at FullStory, we believe that this metric relates most closely to a user's experience in terms of perceiving a page to be "loaded" and we use FCP as our own benchmark for page speed.
Specifically, this event fires when the browser has rendered any text, image (including background images), non-white canvas, or SVG, and it marks the moment at which users can start consuming content on a page.
Improve FCP by optimizing your critical rendering path. This means being deliberate about how, when, and what in order the pages content loads. Because FCP is one of the earliest events in the overall page load, server and network timings may have a large impact on the timing of FCP. For example, a high Time to First Byte time will also result in a high FCP.
Read more about this metric in the Lighthouse developer docs.
Largest Contentful Paint (LCP)
Largest Contentful Paint (LCP) focuses on Page Loading Time. In other words, the time it takes for the largest element to load on your page. A good largest contentful paint time is considered to be 2.5 seconds or less.
While the Page Load time measures the time that it takes to load the initial page, the Largest Contentful Paint metric takes into account elements that are added to the page after the initial load. If larger elements are added to the page after the initial load, the Largest Contentful Paint time will be larger than the Page Load time.
Read more about this metric in the Lighthouse developer docs.
Note: FCP & LCP exclude iframed content.
At a high level, DOMContentLoaded gives you a feel for how long it took for the HTML to load so that the page can start rendering content.
More specifically, the DOMContentLoaded fires when the initial HTML document has been loaded and parsed. Often this milestone occurs before stylesheets, images, and subframes finish loading, so the DOMContentLoaded event occurs before a page is done painting.
Read more about this metric in Mozilla's developer docs.
The onload event or "Page Load" fires when the whole page and all of its dependent resources have finished loading.
Page Load often occurs later, after the point in time when the page is rendered and interactive for a user.
While the Page Load metric isn't as closely related to a customer's perceived performance of a page, it can be helpful to keep an eye on your Page Load time to understand how many assets are loading onto your page after First Contentful Paint.
In instances where FullStory isn't able to retrieve performance data and was unable to capture the load event—as can sometimes happen with visitors bounce—FullStory will default the page load time to 1ms.
Note: Page Load metrics only correspond to the page's initial load. For Single Page Applications (SPAs), dynamic route changes will not have their own Load event since they do not result in a full page reload.
Read more about page load in Mozilla's developer docs.
Viewing the Network and the HAR File
Alongside the page speed metrics for each page loaded within a session, you can also view the Network for more details or download the HAR file that corresponds to the page.
The Network view allows you to analyze what happened during a page load. Learn more about using the Network view in FullStory.
The HAR file can be super helpful to save as a log of the page load details for any given page within a session.
The HAR file is a standard format for viewing the assets that contribute to a page load in a "waterfall chart" view. The HAR file downloads in a .json / .har format and it includes detailed request timings, DNS information, asset sizes, and server connection details. Outside of FullStory, you can visualize .har files with Chrome Dev Tools (just drag the file into an empty Network tab in your browser!) or Google's HAR Analyzer tool.
How do I search for sessions with slow pages?
Besides being able to view the page speed metrics within the Events stream during session playback, FullStory also allows you to search for sessions with slow pages in OmniSearch.
There are two ways to search for sessions with slow pages. You can either:
- Start a new search from scratch using OmniSearch, or
- Bootstrap a new search directly from the page speed metrics card in session playback
Search for slow pages using OmniSearch
To start a new search, click the OmniSearch bar and look for the "Page load" criteria under Performance.
Click "Page Load" to start a new search with the Page Load criteria.
Next, use the dropdown menu to select which metric you'd like to search for: First Contentful Paint, Largest Contentful Paint, DOMContentLoaded, or Page Load.
Then, update the criteria to look for sessions when a page was at least a specific number of seconds.
Note: you can also stack together multiple criteria to look for pages that load within a range of speed.
Bootstrap a search for slow page loads from page speed metrics
From any page within any session, you can hover over any of the page speed metrics to open the "Add to Search" and "Create new Search" options.
Clicking either of these options will add the criteria for that specific page speed metric to your existing search or a new search, and it will also bring in the timing related to the page load from the session, too.
This method of starting a search is particularly useful if you see something suspicious during a session and want to quickly understand, "How any other customers saw sessions where pages loaded similarly to this page load?"
FullStory Page Speed Metrics and Chrome's Performance Profiler
If you've used Google Chrome's performance profiler, you may have noticed that the data in performance profiler doesn't match the numbers you see in FullStory. This is because when you choose "start profiling and reload page" in Chrome's performance profiler, the page speed metrics in Chrome are taken from the time you click the button, which includes e.g. unload handlers from the previous page. In contrast, FullStory's page speed metrics, which are based on the browser's performance API (for example), are relative to "navigationStart".
To illustrate, if you start Chrome's performance profiler on a page and the first contentful paint (FCP) is reported as 851.8ms with a navigation start value of 299.31, you would observe that the FCP value in FullStory will be 552.49. The value of 552.49, which comes from the browser's performance API, is exactly the difference between what Chrome's performance profiler reported for FCP and navigation start.