Prioritize Metrics
Overview
Metrics are the measurements we collect from the billions of daily datapoints we gather through our synthetic tests, and which we use to evaluate provider performance for Provider Intelligence.
A select few of these metrics (latency, loss, jitter, and (when applications are selected) Time to First Byte (TTFB)) are chosen to calculate the overall score of a provider because these metrics best represent provider reliability and user experience. We allow you to prioritize these “evaluation” metrics to weight your analysis towards the performance dimensions that matter most for your business.
We also collect 19 other metrics that do not affect the overall score of a provider, but which you can view to better inform and refine your provider analysis.
Metrics Used for Prioritization
A provider’s overall score calculation includes the weighted scores of four core metrics, which we call the evaluation metrics:
Latency
Time for a packet to travel from source to destination and back (round-trip time, RTT). Measured in milliseconds (ms) where < 20 ms is considered excellent and > 100 ms is considered poor.
Latency directly affects how responsive applications feel. High latency makes web pages load slowly, video calls appear jerky, and database queries take longer to complete.
Loss
Percentage of packets that fail to reach their destination (packet loss). Measured as a percentage, where < 0.1% is considered excellent and > 3% is considered poor.
Packet loss forces retransmissions, which slows down TCP connections and causes artifacts in voice and video calls. Even small amounts of loss can significantly impact user experience.
Jitter
Variability in latency over time (variance in RTT). Measured in milliseconds (ms) where < 5 ms is considered excellent and > 50 ms is considered poor.
High jitter causes inconsistent user experience and is particularly problematic for voice and video conferencing, where timing consistency is critical. Applications might sound choppy or video might stutter.
Time to First Byte (TTFB)
Only visible when applications are selected as destinations. While not solely a “network wire” metric, it is still useful because it highlights cross-network deviation for real applications you care about, even when that deviation is partly or fully driven by app, origin, or CDN behavior rather than the access network.
Time from sending the HTTP request to the first byte of the response (ms). Measured in milliseconds (ms) where < 100 ms is considered excellent and > 500 ms is considered poor.
Strong TTFB usually feels “snappier” for web/app interactions at the measured URL. Includes DNS resolution, connection establishment, SSL/TLS handshake, request transmission, and server processing until the first byte arrives. (Verify vs product docs.)
By default, the evaluation metrics are prioritized (weighted) in the order listed here. This reflects common networking best practices, but you can reorder based on your specific needs.
Performance Metric Thresholds Summary
Latency
< 20 ms
20-50 ms
50-100 ms
> 100 ms
Loss
< 0.1%
0.1-0.5%
0.5-1%
> 1%
Jitter
< 5 ms
5-15 ms
15-30 ms
> 30 ms
TTFB
< 100 ms
100-200 ms
200-500 ms
> 500 ms
Key Considerations
Reordering can change scores: Reordering your metric priorities can change which providers score highest.
All metrics are still visible: Even low-priority evaluation metrics are shown in your results; they just have less influence on the overall score.
Understanding the Weights
Provider Intelligence uses a linear weighting system that changes depending on how many metrics you prioritize:
4 Metrics, including TTFB
1st (highest)
40%
2nd
30%
3rd
20%
4th
10%
3 Metrics, excluding TTFB
1st (highest)
50%
2nd
33.3%
3rd
16.7%
See Overall Scoring to understand the overall score calculation and how metric prioritization influences the overall score.
Example Weight Prioritizations
Call center: Prioritize Jitter → Loss → Latency → TTFB (voice quality is critical).
Trading floor: Prioritize Latency → Loss → Jitter → TTFB (speed is everything).
Branch office: Prioritize Latency → TTFB → Loss → Jitter (reliability and general productivity).
SaaS provider: Prioritize TTFB → Latency → Loss → Jitter (user experience for your application).
How to Configure Metric Priorities
In the Rank Evaluation Metrics section, click and drag metrics to reorder them.
The metric at the top receives the highest weight in scoring; the metric at the bottom receives the lowest weight.
Additional Metrics
Provider Intelligence collects and can display many more metrics than the ones used for score evaluation so you get a broader picture of performance measures that might matter to you and your users.
Outages
The number of provider network outages detected by Internet Insights during your selected time period, where connectivity from the provider was unavailable. Measured by count of distinct outage events.
Even brief outages can disrupt critical business operations, cause transaction failures, and impact user experience.
Outages are displayed in the table by default.
Outage Data Collection
Outages are detected at 5-minute intervals.
Each continuous outage period counts as one outage, regardless of duration.
Data comes from Internet Insights' network outage detection system.
Outage counts don't change with percentile selection (they're event counts, not performance measurements).
Total Unique AS Paths
The number of distinct Autonomous System (AS) paths observed from selected user locations to specific applications and/or cloud regions over your chosen time period. Each unique AS path reflects a different route that traffic can take between the source and destination.
Helps users evaluate provider network path diversity (higher numbers) and predictability (lower numbers), which can impact reliability and performance.
Total unique AS paths are displayed in the table by default, but are not available in the Time Series tool.
Application Metrics
When you select one or more applications as destinations, Provider Intelligence provides metrics in addition to TTFB that break down application performance into component parts.
Application metrics are not visible by default. To view these metrics in your results table, see Configuring Visible Columns.
View the raw measurements for each metric when you select a single-destination view.
All application performance metrics are selectable in the Time Series view.
HTTP Server Metrics
These metrics dissect the application request/response cycle to help you understand where time is being spent. All metric timings are measured in milliseconds (ms) at your selected percentile. Lower values are better.
DNS Time
Time to resolve the domain name to an IP address. Slow DNS resolution delays the start of every connection. Can indicate DNS server issues or inefficient DNS configurations.
Connect Time
Time to establish a TCP connection with the server. Reflects network latency and server responsiveness. High connect times can indicate network congestion or server overload.
SSL Time
Time to complete the SSL/TLS handshake for encrypted connections. SSL negotiation is cryptographically intensive. High SSL times can indicate server CPU constraints or use of older, slower SSL protocols.
Send Time
Time to transmit the HTTP request to the server. Usually minimal, but high send times can indicate bandwidth constraints or network issues.
Wait Time
Time spent waiting for the server to process the request and begin responding. Directly reflects server performance and application responsiveness. High wait times usually indicate server-side issues, not network issues.
Receive Time
Time to receive the full response from the server. Depends on response size and available bandwidth. Large files or limited bandwidth result in longer receive times.
Redirect Time
Time spent on HTTP redirects before reaching the final destination. Each redirect adds latency. Multiple redirects can significantly slow down application load times.
Total Time
Total time from request initiation to response completion, including all above components. Represents the complete end-to-end application response time from a user's perspective.
Page Load Metrics
These metrics measure complete web page loading performance.
Page Load Time
Time from starting to load the page until it's fully rendered and interactive, measured in milliseconds (ms). Lower values are better. Directly impacts user experience. Slow page loads frustrate users and can impact business outcomes (conversions, productivity, etc.).
DOM Load Time
Time until the Document Object Model (HTML structure) is fully loaded and parsed, measured in milliseconds (ms). Lower values are better. Indicates when the page structure is ready, even if images and other resources are still loading. Faster DOM load means users see content sooner.
Throughput
The effective data transfer rate for the page load, measured in Kilobits per second (Kbps). Higher values are better (for example, > 5000 Kbps (5 Mbps) is considered excellent, whereas < 500 Kbps is considered poor). Indicates the effective bandwidth available for loading content. Low throughput suggests bandwidth constraints or network congestion.
Response Codes
Response codes indicate the HTTP status returned by the server:
1xx (Informational): Request received, continuing process.
2xx (Success): Request successfully received, understood, and accepted.
3xx (Redirection): Further action needed to complete the request.
4xx (Client Error): Request contains bad syntax or cannot be fulfilled.
5xx (Server Error): Server failed to fulfill an apparently valid request.
Null: No response received or connection failed.
High rates of 4xx or 5xx errors indicate application or server issues. Excessive 3xx redirects can slow performance.
Note: Response codes don't change with percentile selection, nor are they scored—they're categorical data, not performance measurements.
Last updated