Check for browser or network issues
This recommendation is shown when we've detected that page load times are degrading, but Jira's backend is performing normally. This indicates that the slowness is likely caused by factors outside of Jira itself, such as client browser performance, network latency, or CDN issues.
Signals used
Details of how we detect this issue.
Conditions
The following conditions need to occur together:
At least one key experience, such as viewing or editing an issue, shows degraded page load times (RFU).
The RFU breakdown shows that Jira's backend processing accounts for a small fraction of the total page load time, which means most of the time is spent outside the application server.
When the gap between total page load time and backend processing time is large enough, we surface this recommendation.
How we detect it
Signal | Details |
|---|---|
RFU degradation | We look for Ready for User (RFU) degradation - cases where key Jira experiences take significantly longer than their historical baseline. This helps us confirm that users are actually experiencing slower page loads, not just one-off spike. |
RFU breakdown - unaccounted time | We break down total page load time into known backend components (HTTP request processing, JQL execution, field loading, etc.) and calculate how much time is unaccounted for. If backend processing makes up less than 10% of total page load time, the remaining time is likely spent on client-side or network-related operations, such as DNS resolution, TLS handshake, content download, or browser rendering. |
Filters
When this issue occurs multiple times, we group occurrences under different time filters, for example a 24‑hour or 7‑day period. In this case:
For degraded experiences, we show the highest RFU degradation from all occurrences in the selected time filter.
For unaccounted time, we show the highest time from all occurrences in the selected time filter.
This helps you see which pages and time periods are most affected by client or network issues, and whether the problem is localized (for example, certain regions or times of day) or widespread.
Frequency chart
The frequency chart shows how often this issue has occurred over time. This can help you identify patterns such as:
Specific times of day when network congestion causes slower page loads.
Periods that coincide with VPN changes, office network maintenance, or increased remote usage.
Recommended actions
Since Jira's backend is performing normally, the slowness is likely in the network path between users and the application. Here are some actions you can take:
Check client-side network performance
Use browser developer tools (Network tab) to inspect page load waterfalls from affected users. Look at where time is spent: DNS lookup, TCP connection, TLS handshake, time to first byte (TTFB), and content download. Compare results from different locations, networks, and connection types (wired vs. wireless).
Review load balancer and reverse proxy configuration
Check your load balancer and reverse proxy for connection queuing, SSL/TLS handshake delays, or session persistence misconfigurations. Verify that HTTP keep-alive and connection reuse are enabled, and that SSL offloading is performing efficiently.
For related guidance, see Jira Data Center is slow due to high latency connections.
Investigate network infrastructure
Measure round-trip time (RTT) between end users and the Jira front-end using tools like traceroute or mtr. Check for packet loss, bandwidth saturation, or firewall/IDS appliances introducing latency through deep packet inspection. If users connect through a forward proxy, verify proxy health and check whether SSL inspection is adding overhead.
Was this helpful?