/en/calc/page-weight/ works fetches the page automatically
Enter a URL — our server does the rest: it fetches the page, follows its stylesheets, scripts, and images, and returns the actual size by file type, the number of requests and domains, whether compression is enabled, which protocol version was used for the connection, and how long the server took to respond. These numbers are filled into the calculation fields automatically, so you don't need to enter anything manually. The calculator then converts bytes to bits, accounts for the protocol, connection overhead, and cache, and shows the time for 3G, 4G, 5G, and fiber — separately for the first visit, a repeat visit, and markup only. The URL is sent to us and never stored; the calculation itself runs in your browser.
The same page on five types of connection. On the first visit, everything travels over the network; on repeat visits, only the markup and anything not in the cache are loaded. The third column shows how long it takes for anything to appear on screen.
| Connection | First visit | Repeat visit | Markup only |
|---|
The breakdown will appear after the URL is measured. Without it, you can't tell whether to cut images, scripts, or fonts.
| Type | Files | Share | Size |
|---|
That's where the discussion of page size starts: usually, the first three files make up half the page.
A ready-to-use piece of markup with all the numbers and a link to the same calculation. Insert it into an article or report as is: it contains no scripts or frames from another site, so it won't break if something changes on our end.
The server will fetch the page and up to forty linked files: styles, scripts, and images. It will return each file's size and type, domain, whether compression is enabled, which protocol version the connection used, and how long the server took to respond. All calculation fields will be filled in automatically.
The mobile and desktop versions of the same page often differ in size by a factor of two. If you're investigating search metrics, use Googlebot or YandexBot—you'll see exactly what they see.
The buttons below the fields set typical values: 3G, 4G, 5G, one hundred megabits at home, fiber, and gigabit; latency ranges from five milliseconds within a city to two hundred fifty to Asia. You can enter any number manually; the mark then turns off.
After the measurement, the switcher shows the version the connection actually used: the connection itself reports it, rather than the tool guessing from headers. Manual adjustment is needed in one case—HTTP/3. Our server uses TCP, so HTTP/3 will not appear in the measurement; if the site advertises it in the alt-svc header, we mention it separately, and you can change the version yourself. The number of exchanges changes noticeably as a result.
As long as latency is high, cutting page weight is almost useless: requests to the server consume the time. Fewer files, one domain instead of five, and a server closer to users will help.
The report can be copied, the table exported to CSV, and the entire panel saved as an image. The calculation link stores all parameters directly in the address, so you can share it.
Time = size × 8 ÷ (speed × (1 − overhead)) + RTT × (handshakes + request waves)
The model is intentionally rough and answers one question: what is limiting the page—the connection or latency? It does not know the order in which the browser queues files, when rendering begins, or how long scripts keep the page busy afterward. A measurement by address uses the real size, structure, and protocol version, but it runs from our server, not your network: both the response time and protocol version in the report describe the connection to us, not your connection.
The input data is the same as the default field values: you can calculate it mentally and confirm that the tool is telling the truth.
Converting the size: 2,000 KB = 2,000,000 bytes = 16,000,000 bits.
Effective speed: 20 Mbit/s minus 15% = 17,000,000 bits/s. Pure transfer: 16,000,000 ÷ 17,000,000 = 0.94 s.
Exchanges: three handshakes plus two waves—markup first, then everything else at once. Five in total.
Latency: 5 × 60 ms = 0.3 s.
Repeat visit: 60 KB of markup and one-tenth of the rest, 194 KB, travel over the network. There are two handshakes and two waves—0.24 s of latency and 0.12 s of transmission.
First visit: 1.24 s; repeat visit: 0.36 s; markup alone: 0.27 s. On the first visit, the connection accounts for three-quarters of the time, so cutting the size is worthwhile. On a repeat visit, the opposite is true: the megabytes are gone, and four exchanges with the server remain.
The page address and the selected browser signature. Our server then requests this page and its files itself—from our address, not yours. Neither the address nor the response is stored anywhere: not in a database or a file. The server allows three hundred requests per hour from one address, and one measurement costs two requests.
We parse the markup; we don't run scripts. Anything the page loads in the browser—analytics, ads, lazy-loaded images, fonts from CSS—is not included in the analysis. There is also a limit of forty files; otherwise one person's request could turn into a crawl of someone else's site. If exactly forty files are found, the notice says so explicitly—the request count should be increased manually.
Because a bit and a byte differ by a factor of eight. 10 Mbit/s is 1.25 MB/s. Providers sell megabits, while file managers show megabytes, so calculations differ by exactly eight at this point. That's why people keep saying, “The connection is one hundred megabits, but downloads run at ten.” The unit list also includes KB/с and MB/с—if the speed is given in those units, no manual conversion is needed.
Both values are used: 1000 bytes is a decimal kilobyte, while 1024 bytes is a kibibyte, КиБ. Decimal is selected by default so the units match the connection speed, which is always calculated in the decimal system. If your size is given in kibibytes, select КиБ or МиБ in the list next to the field—the difference is about 2.4% for kilobytes and 4.9% for megabytes.
From the connection itself. When fetching the page, our server records which protocol version the exchange with the site used and sets it in the switcher. Previously, this was only an assumption—“there's alt-svc with h3, so it's HTTP/3; https, so it's HTTP/2”—and it was wrong on every site where HTTP/2 was not enabled. There is one exception: this is the version between our server and the site. We use TCP, so HTTP/3 will never appear in the measurement, even if the site advertises it. In that case, the tool adds a separate line below the table: your browser will access the site over HTTP/3, and the switcher is there so you can set it accordingly.
Because latency does not depend on speed. In the example above, over a gigabit connection, transmission takes 16 ms instead of 940 ms, while latency remains the same 300 ms. The connection became fifty times faster, but the page opened only four times faster. That's exactly what the “different connections” table shows: the “first visit” column has a floor below which it cannot go.
No, and it has a different purpose. Tools such as PageSpeed or GTmetrix open the page in a real browser and measure rendering: when a large block appeared and when the page stopped shifting. This tool measures transport—how long data takes to travel over the connection and how long exchanges with the server take. It answers “what should I cut?” rather than “what score do I get?”
It divides the result into three levels: up to one second, from one to three seconds, and more than three. The boundaries are round numbers—this is the tool's scale, not a standard.