Infrastructure & Network

Speed is not one number; it is a chain. From the moment the user clicks the link to the moment they can interact with the page, several sequential stages run, each with its own clear owner. This dashboard monitors the first half of that chain — everything that happens before the first byte arrives.

The main goal is a root-cause separation: does the slowness originate from the user's network and carrier path, or from your server and code? The answer to this question sets the direction of your next steps.

This dashboard splits into two key parts:

This part gives you the macro state of the first loading phase at a glance. The cards are arranged right to left, in the order the stages actually happen.

• Connection time: this stage sits entirely with the user's carrier and has nothing to do with your code.
• Server response time (TTFB): the heaviest stage in the chain, and the only one that improving your code and database actually shortens.
• Slowest carrier: tells you whether the network slowness is site-wide or confined to one specific carrier.

This part gives you advanced tools for analyzing and automatically monitoring the network chain.

• The network loading chain: the only part of the dashboard showing the full picture of the whole path; it has four stages ordered by when they actually happen (Redirect, DNS, secure connection TCP/SSL, and Server response). Each segment's width shows that stage's share of the total time. Statistical note: unlike the rest of the dashboard, which runs on percentiles, this bar is calculated from means, because only means are additive — building it from percentiles would produce a total that's unreal and meaningless.
• Infrastructure Pulse: automatically detects sudden shifts in the network layer. By comparing the last 24 hours' P95 against the previous 7-day average, results are grouped into two columns, critical regressions and significant speedups. Every row is clickable and links straight to the relevant chart.
• Alert rules: set a defined ceiling for each metric. When a value crosses that threshold, the system flags an anomaly and immediately sends a message to your Telegram. The badge at the top of the page shows the number of active rules.

This dashboard is built on percentiles instead of averages, because the average metric hides exactly the slow users whose condition it's critical to check.

A working example: say your site has a hundred users:

• For 90 of them, the page loads in 200 milliseconds.
• The other 10 wait 3 seconds and leave the page.

The average of this data comes out to roughly half a second — a number that makes the situation look acceptable and completely erases those 10 people.

• P75 (the basis for the cards): shows that three quarters of visits were faster than this value.
• P95: captures the state of the unlucky 5% of users.

Worth noting: events that happen after the first byte arrives are covered on the Render & Interaction dashboard.