>
    Strata Copilot
    Investigate a Page Load Transaction
    Focus
    Download PDF
    Focus
    1. Home
    2. Autonomous DEM
    3. ADEM Dashboards
    4. View Application Experience for a Specific User
    5. Investigate a Page Load Transaction
    Download PDF
    Autonomous DEM

    Investigate a Page Load Transaction

    Table of Contents

    Investigate a Page Load Transaction

    Drill into a single page transaction to determine whether a performance issue originated on the device, the network, or the SaaS application.
    Where Can I Use This?What Do I Need?
    • Prisma Access (Managed by Strata Cloud Manager)
    • Prisma Access (Managed by Panorama)
    • Prisma Access license
    • ADEM or Strata Cloud Manager Pro license
    • (Browser-Based Real User Monitoring (RUM)) Prisma Browser license
    The Page Load Performance view gives you a detailed breakdown of a single page transaction so that you can identify which phase of the browser's load sequence caused the delay. ADEM captures this data automatically for every hard navigation (full page load) using standard W3C PerformanceNavigationTiming timestamps collected by the ADEM Browser Plugin.
    You can open Page Load Performance from two places:
    • Select any row in the Transaction Performance table on a user's application experience page.
    • Select any page card in the All Pages section of the Real User Monitoring tab.
    The view organizes diagnostic information into three layers so that you can move from a high-level conclusion to the raw technical evidence without leaving the page:

    Root Cause & Remediation

    Review the automated diagnosis before examining the charts to understand the problem and determine the correct next step.
    The Root Cause & Remediation panel appears at the top right of the Page Load Performance view. ADEM analyzes the W3C timing data and generates a natural-language explanation of the primary cause.
    FieldDescription
    Potential Root CauseThe primary factor that ADEM identified as the most likely cause of the performance degradation. Use this field to immediately understand which service delivery segment is responsible.
    Degradation ReasonsThe specific conditions that support the root cause. Use these reasons to confirm the diagnosis before escalating.
    Suggested RemediationRecommended steps to resolve the issue. Use this information to guide your next steps.

    Page Load Time Breakdown

    Use the interactive waterfall chart to see the browser's exact execution sequence and identify which phase accounted for most of the transaction time.
    The Page Load Time Breakdown waterfall chart maps W3C PerformanceNavigationTiming timestamps into a sequential visual timeline. Each row represents a phase or sub-step in the browser's page load sequence. The chart displays the absolute duration and its percentage of the total load time for each step, together with a horizontal bar that shows when the step started and ended relative to the full timeline.
    The chart overlays vertical marker lines for DOM, FCP, and LCP so that you can correlate technical timing events with the user-facing metrics shown in the Web Vital Metrics section.
    Select any bar to view a tooltip with start time, end time, and duration for that step. Select a phase row to expand or collapse its sub-steps.
    The waterfall progresses through the following phases in sequence:

    PREPARE

    Captures device-side delays that occurred before the browser could start the network request. A significant PREPARE phase indicates that the browser was occupied with other activity—such as servicing concurrent requests or allocating cache space—before it could begin connecting to the server.
    StepDescription
    QueuingTime the request spent waiting in the browser's network queue. The browser queues requests when it has reached the maximum number of concurrent connections to the origin, when higher-priority requests are pending, or when disk cache space is being allocated.
    StalledTime the request was stalled after it left the queue but before the browser began sending data. Stalling occurs for similar reasons to queuing and can also indicate overhead introduced by a proxy or browser extension.

    CONNECT

    Captures the time the browser spent establishing the network connection to the server. A large CONNECT phase indicates a network infrastructure issue such as slow DNS resolution, high round-trip latency, or a slow TLS handshake. CONNECT is typically the largest phase on first visits to a domain because the browser must establish a new connection rather than reusing an existing one.
    StepDescription
    DNS LookupTime to resolve the page domain to an IP address. A slow DNS Lookup can indicate an overloaded or geographically distant DNS resolver. If this step is consistently high, work with your network team to investigate the DNS infrastructure.
    TCP ConnectTime to complete the TCP three-way handshake between the browser and the server. High TCP Connect times reflect network round-trip latency between the user and the origin server and are typically caused by geographic distance or network congestion.
    SSL/TLS
    Time to negotiate the encrypted session between the browser and the server. In addition to start time, end time, and duration, the tooltip for this step also shows:
    • TLS Version—The version of TLS used for the session, for example, TLS 1.2 or TLS 1.3. Attach this value to vendor support tickets as technical evidence of the connection configuration.

    RESPONSE

    Captures the full server response time from when the browser sent the complete request to when all response data was received (Time to Last Byte, TTLB). A large RESPONSE phase indicates that the application server is slow to process the request, the response payload is large, or the connection has limited throughput.
    StepDescription
    Waiting
    The time the browser waited for the server to begin returning data after the request was sent (Time to First Byte, TTFB). In addition to start time, end time, and duration, the tooltip for this step also shows HTTP Version—The application-layer protocol used for the connection, for example, HTTP/1.1, HTTP/2, or HTTP/3.
    Content DownloadThe time for the browser to receive the complete response body after the first byte arrived. If Content Download is disproportionately large compared to Waiting, the issue is likely network throughput or payload size rather than server processing.

    RENDER

    Captures the client-side browser work that occurs after the HTML response has been received. A large RENDER phase indicates that the page has significant JavaScript execution, complex CSS, or a large number of sub-resources to load. A large RENDER phase points to the application or the user's device as the bottleneck rather than the network or server.
    StepDescription
    DOM ProcessingThe time for the browser to parse the HTML response and build the Document Object Model, including loading and executing any render-blocking scripts. A long DOM Processing time indicates heavy JavaScript execution or deeply nested HTML on the page.
    Page Load
    The time from when the DOM became interactive until the browser fired the load event, indicating that all dependent resources—images, stylesheets, and scripts—have finished loading. In addition to start time, end time, and duration, the tooltip for this step also shows Objects Loaded—The number of objects that loaded successfully out of the total number of objects the page attempted to load, for example, 56/76 objects loaded. Use this count to assess page weight and complexity when investigating slow rendering without examining individual resources.

    © 2026 Palo Alto Networks, Inc. All rights reserved.