The Network view allows you to see and analyze the network requests that make up each individual page load within a single user's session. You can use this view to investigate the causes of slow pages and identify performance bugs.
Network Requests: The Basics
When we talk about "requests" in the context of the Network view, we mean the line-by-line calls for the files that build a web page or send information from the browser to another system. Any given web page in your visitor's session may make requests for:
- HTML (the document that frames out the structure and content of a web page)
- Fonts (typography and icon sets)
- CSS (styles)
- Media (images and videos)
or to send data back-and-forth between databases or APIs (systems that allow your website to share data with third-party tools).
If you've never checked out the Network view in your own browser before, you should try it!
In common web browsers like Google Chrome or Firefox, you can "right-click" and then click "Inspect" or "Inspect Element" to open the developer tools in your browser.
Then, in Developer Tools, navigate to "Network" and re-load the page. When you do, you should see all of the requests that make up the page load into view on a timeline. This is the network view, commonly referred to as a waterfall chart, and it's helpful for understanding how fast a website loads.
Here's a quick look at the Network view in a Google Chrome browser.
Opening the Network view in FullStory is similar to opening the Network view in common web browsers.
The Network View in FullStory
From any session, click Dev Tools > Network to open the Network view for an individual page within a single session.
Navigating the Network View for Sessions with Multiple Pages
In FullStory, a single customer's session may include navigations to multiple pages, but the Network tab and the waterfall chart relate to a single URL—not the whole session.
When the Network view is open, blue page icons will display on the timeline, to indicate events where the customer opened a new page. For sessions with multiple pages, use the blue (-) icon to collapse the waterfall chart for a page and the blue (+) icon to open a waterfall chart for a page.
Pages in the Network view will correspond with "Visited Page" navigation events shown in the Event stream.
- For any page, you can click "Download .HAR" in the page's Event card to get the contents of the Network view waterfall chart in HAR/JSON format. This is helpful for sending along to developers to debug or to pass into other systems for further analysis or reporting.
- For sessions on single page apps, it's common and expected that some navigations between states may not read as new pages in terms of starting a new Network view or waterfall chart. You may see that requests continue to load in long after the Page Load timing milestone has occurred.
Note: If you block or exclude elements from capture, the URLs for the assets that are within those elements will appear as "--blocked--" in the Network view in Dev Tools.
How to Read the Waterfall Chart
The Network view shows each request for the page on a timeline that looks like a waterfall chart. Each rectangular bar represents the time for a request to complete.
Expect Stacked Requests
When bars are stacked (aligned on the left-hand-side) this means that the requests started at the same time. It's common for the browser to have multiple open connections to receive requests in batches, so you may see that you waterfall chart looks like a set of stairs as you scroll down the view.
Investigate Long Requests
When bars are long (from left to right) this means that the request took longer, relatively, than the other requests in view in terms of time to complete, measured in milliseconds. Note: in FullStory's Network tab view, the timeline adjusts as you scroll down, so a long bar that you see early in your list of requests may not be as nefarious as it seems. Refer to the timeline for more context.
Mind the Gaps!
Look for Failures
In FullStory, when a bar for a request shows up red, this indicates an error where the request failed. Refer to the Status column or click this request to gather more information about what went wrong.
It's important to note that failed network requests won’t be captured until the FullStory script has loaded, and even after the script has loaded, we can only identify failed XHRs (not other request types).
How to Read Columns in the Network View
In the Network view, you'll find the following information for each request:
- Status - This relates to the HTTP status codes for each request. Generally, an HTTP status code in the 2xx-3xx range means that the request was successful (i.e. "200 OK" which means that the request was successful, or "307 Temporary Redirect" which means that the request loaded after being redirected because the file wasn't at the expected URL path). An HTTP status code in the 4xx-5xx range means that the request failed (i.e. "404 Page Not Found" where the URL path leads to nothing, or "500 Internal Server Error" where the server encountered an unexpected condition that caused the request to fail). If FullStory can get a specific HTTP status code from the browser, then that code will display under the Status column for that request. If FullStory cannot get a specific HTTP status code, FullStory may display "2xx-3xx" for successful requests or "4xx-5xx" for unsuccessful requests.
- Type - This relates to the MIME Type for each request, which tells the browser what type of file to expect, whether that's some HTML, text, an image, a video, or something else.
- Name - This displays the specific name of the file and its extension. For example, the image hosted at the URL path https://fruitshoppe.firebaseapp.com/images/bluebs.jpg is named "bluebs" and saved in JPG format. If I'm looking at a page where the "bluebs" image loaded, I'll see that image request with the Name "bluebs.jpg" in the Network view.
- Time - This is the time in milliseconds that it look for a specific request to complete. Generally, when looking at the time for a request, lower means faster and faster means better. That said—not all requests are created equal. It may be okay for a request to take a bit longer to load if that request doesn't block the page rendering or interactivity in any way.
Filtering Network Requests by Type or Name
Looking for something in particular? You can use the Type tabs to filter requests...
...or start typing in the Filter text area to narrow your search by text included in the Name.
How to Find More Request Details and Request Phase Timings
Once you've identified an interesting request (whether it looks slow or failing), you can click on the line of the request in the Network view to open the Network Request details panel.
In this panel, you can see even more information about the request, including:
- Method - This relates to the HTTP request method, whether the request is a GET or POST or something else entirely.
- Timing Summary - This is a breakdown of the request by phases.
- Bodies - This section displays the Request and Response bodies, if applicable and allowlisted.
Request Phases in the Timings Summary
- Stalled - Time spent waiting because there were higher priority requests in the queue or no more open connections
- DNS Lookup - Time it took for the browser to resolve the IP address; note: slowness at this phase might represent a hosting problem
- Initial Connection - If applicable, time spent making the initial connection
- SSL - If applicable, this is the time for an Secure Sockets Layer (SSL) "handshake" to take place which is exchange to determine security for a connection
- Send & Wait - The initial round-trip of the request; note: if this is very slow, geographical distance or a problem with a CDN could be at play
- Receiving - After the request has started, the time spent receiving the rest of the data from the remote server; note: this generally relates to the size of the file
With the details from the Network Request view, you'll have everything you need to investigate a slowly loading request or work with an engineer to debug further.