When watching a replay in Session Replay, Network Details enable you to identify the potential causes of friction in the user experience (such as slow or failing requests).
The Network Details waterfall chart is a chronological representation of the network traffic associated with the loading of a web page, including all HTTP requests sent by the browser, as well as all additional requests made during the page view.
Top use cases
Learn more about some of the most common use cases and suggestions on performing each:
Discover the root cause of user friction or frustration
When watching a replay, you may observe user frustration (such as rage clicks, users waiting for a long time, or interfaces that are not behaving as expected).
You can use the Network Details feature to discover the root cause of this frustration and find out which related requests may have an impact at that moment.
How to perform the use case
Simply pause the Session Replay Player at the moment you observe the frustration, or click on a specific friction event (e.g. a rage click) in the Event Stream.
Next, open Network Details and check the requests that are occurring around the same time (the vertical bar is synchronised at the same time between Network Details and the Session Replay Player).
Network Details can also help you find out if an error occurred before our Tag is loaded. When this happens, the error is not captured by the Tag. With Network Details, you can observe all resource events before the Tag is loaded.
See how errors and slow requests impact the user experience
By looking at Network Details, you can identify potential impacts on your users' experience. A JS or API error can have consequences: other requests that would normally follow may disappear, or new requests may be sent (to collect the error, for example).
By using Network Details, your technical team can better assess the impact of an error.
How to perform the use case
If an error occurs in the carousel loading script, examining Network Details may show that the carousel images are not being loaded.
If a 500 error occurs in the third-party product recommendation API, examining Network Details may show that no subsequent calls to the first-party product information API to retrieve prices for the recommended products have been sent.
After opening Network Details, you can check those that fail or are very long. You can then watch the related moment in the Session Replay Player to see how it has affected the user experience, and decide to investigate further with your technical team.
Understand which resources negatively affect page load
Improving your page load time (such as the Largest Contentful Paint metric (LCP)) can be tedious if you don't know what to improve.
With the Network Details feature, you can easily see which resources are increasing the load time of your page.
How to perform the use case
You can create a segment of users who never have an LCP value below 2.5 seconds. Next, use this segment in Session Replay to see examples of such sessions.
When watching the pageviews, open Network Details and check the resources loaded at the beginning of the pageview. You will quickly see the resources causing the long load time.
Overview of the Network Details waterfall
Accessing the Network Details waterfall
When watching a replay, click the Open Network Details button at the bottom of the player.
To resize the waterfall view, drag the blue bar up/down (highlighted in red below).
Timings
Click 'Timings' to show/hide the performance metrics for the page. Tick or un-tick any of these metrics to choose whether they display in the waterfall report as vertical lines, so you can analyze them with the related network traffic.
Note, Core Web Vitals timings are not currently available.
Customize columns
Click 'Customize columns' to sort which columns you want to appear. You can choose to display: URL, Domain, Status, Type, Size, Protocol, Scheme, Time, and Initiator Type.
Note, the Status (200, 301, 404, etc.) column is only available for Chrome browsers and when it’s not blocked by security policies.
Filters
You can filter the ‘URL’ column by entering keywords in the ‘URL filter’ field, or filter the ‘Type’ column by selecting the content you want to display (e.g. ‘All’, ‘Document’, ‘Stylesheet’ etc).
Note, ‘Websocket’ is the only filter that is not available in the Network Details waterfall in Session Replay.
Waterfall
Use the waterfall to view a sequential list of all HTTP requests.
The information displayed by default includes:
- URL: The URL (the name of the resource). Hover over the name to see the full URL.
- Status: The HTTP Status (200, 301, 404, etc.)
- Type: The content type
- Size: The response size
- A progress bar on a time axis: This is synchronized with the replay timeline, with a breakdown of the different steps between establishing the connection and receiving the response.
Hover over a request under the ‘Timings’ column to see the timing breakdown and total timing.
Requests starting before and after the replay begins
Session Replay starts recording a session once the Tracking Tag has been loaded. Network Details requests are collected from the start of the pageview. Therefore, some data requests may have taken place before the start of the replay.
In the Network Details waterfall, you can see the area corresponding to the replay on a hatched background in the timeline, and thus understand which requests occurred before and after the replay.
FAQs
Why can’t I see the transfer size for my requests?
There are a couple of reasons for this:
- The request may come from a cross-origin domain. If this is the case, we can’t collect the size.
- The request may already be in the cache, so the user has not loaded the resource.
Why can’t I see the request timing breakdown?
When a request comes from a cross-origin domain, the timing details are not accessible. In addition, certain information such as the transfer size cannot be collected.
Note that the total duration takes into account the potential blocking time of the request.
Does the Network Details in Session Replay feature work with Single Page Applications (SPA)?
With Network Details in Session Replay, you can see the resources that were loaded during the page views on your SPA pages.
Since SPA pages don't load like “regular” web pages, you can’t see certain requests (such as document requests).
In addition, standard timings are not available on artificial page views, as they are related to natural page loading timings.
What is the Blocking Time of my request that I can see in the timing breakdown?
When downloading resources, browsers only have a limited number of connections open for each origin. Thus, resources waiting to be downloaded are blocked until a connection is available. This is the Blocking Time.
Note that the Request Total Time includes the Blocking Time.
Why doesn’t the Network Details in Session Replay timeline match the Session replay timeline?
You may notice that the black vertical bar on the Network Details in Session Replay timeline does not start at the beginning of the Session Replay timeline but before it. For instance, if your replay is at 5 seconds, you may notice that the vertical bar is at 7 seconds on the Network Details timeline.
This is because Session Replay starts recording as soon as the Tag is loaded on the page.
However, we can collect Network Details that occurred before the Tag was loaded.
This is why the beginning of the Network Details timeline starts with requests that occurred before the beginning of the replay.
Why don’t some requests appear in the Network Details timeline?
Some requests may not appear in the Network Details for several reasons:
- The Tag may start late and fill the buffer containing the requests that occurred before (so some requests will be missing)
- API limitation for redirects
- Some resources can’t be collected because they come from an iFrame.
- Only network-level requests can be captured, so a request blocked by a Content Security Policy (CSP) will not be visible.
- TBC redirections
Can I access headers or payload?
Access to header or payload content is usually impossible due to security limitations imposed by browsers, websites, or APIs.
I can see an API error in the Event Stream but it is not marked as an error in the Network Details timeline. Why?
This can happen for two reasons:
- The web browser used in the replay is not Google Chrome.
- There is a CORS restriction (Access-Control-Allow-Origin) that prevents the collection of the available information.