Premium apps Part of Signalhouse
Slow Web Resource Budget
Model a resource list under bandwidth, latency, caching and packet-loss assumptions.
Try an example: Try an example
How it works
Compare a resource list or HAR in sequential and shared-link modes with explicit throughput assumptions, cache effects and a baseline waterfall.
- Signalhouse tcpModel supplies aggregate window/loss/bandwidth-limited throughput. A host needs two RTTs of modeled setup and each uncached resource one request RTT.
- Sequential mode transfers one resource at a time. Shared-link mode fairly divides that aggregate throughput among ready resources, with a bounded number in flight; it is not an implementation of HTTP/2, HTTP/3 or browser scheduling.
- HAR import reads sizes and cache indicators. Modeled requests do not fetch resource URLs. CPU, rendering, dependency discovery, DNS/TLS details and real traffic are excluded.
Part of Signalhouse
-
Signalhouse Website & internet infrastructure inspector
Inspect DNS, TLS, mail, CDN and routing of all your domains — and see what changed.
How to use the Slow Web Resource Budget
Estimate how long a page's files take to load on a slow or lossy connection, compare sequential and shared transfers, and see what caching saves.
What it is for
A page that loads instantly on office Wi-Fi can take ten seconds on a train or a rural mobile connection. Before you add another hero image or script, it helps to know what your resource list costs under slow-network assumptions. This tool takes a list of resources with host, transferred bytes and cache state, or a HAR file exported from your browser's developer tools, and models the transfer time from bandwidth, round-trip latency and packet loss. It draws a waterfall and compares a one-at-a-time baseline with a shared-link model where several downloads split the bandwidth.
It is a teaching and budgeting model. It does not fetch your URLs, and it leaves out DNS and TLS details, CPU, rendering, script execution and how browsers discover dependencies. It does not emulate HTTP/2 or HTTP/3 scheduling.
Worked example
The default models two files from one host, a 25,000-byte index.html and a 1,500,000-byte photo.jpg, at 5 Mbit/s and 100 ms latency. The result: 2.84 modeled seconds; the HTML is done after 0.34 s, the photo after 2.84 s.
A fuller page in Shared-link model with 6 concurrent resources, still 5 Mbit/s, 100 ms and 0 % loss:
| Resource | Host | Bytes | Cached |
|---|---|---|---|
| index.html | example.test | 25,000 | No |
| app.js | cdn.example.test | 300,000 | No |
| style.css | cdn.example.test | 60,000 | Yes |
| photo.jpg | example.test | 1,500,000 | No |
Result: "3.22 modeled seconds; sequential baseline 3.62 seconds." Parallel transfers save 0.4 seconds, mostly round trips that now overlap. The cached stylesheet costs nothing, and Transferred bytes shows 1,825,000 because cached bytes are not counted. app.js finishes at 1.3 s instead of 1.12 s in the sequential run because it shares the link with the photo, which dominates the total either way.
Now set Packet loss to 1 %. The same page takes 10.506 seconds, sequential 10.906. In the result JSON the throughput drops from 5 to 1.431 Mbit/s with limitedBy: "loss". A little loss hurts far more than a slightly slower connection.
How to read the result
- Modeled seconds is the total time in the chosen transfer model. Sequential baseline (seconds) is the one-at-a-time comparison; Modeled time difference is the gap.
- Transferred bytes counts uncached bytes only.
- Transfer waterfall lists start, end and duration per resource. Each new host costs two round trips of setup, and each uncached request one more.
- The chart draws the same waterfall; export it as SVG, CSV or JSON.
Tips and common mistakes
- Enter transferred (compressed) bytes, not file sizes on disk. The network panel of your browser shows the transferred size per file.
- Compare several profiles, such as 1.6 Mbit/s with 300 ms against 10 Mbit/s with 50 ms, to see whether bandwidth or latency limits your page.
- Mark files as cached only for repeat visits. A first visit has an empty cache.
- Moving files to a new host adds setup round trips. On high-latency links, fewer hosts help.
- Shared-link mode divides throughput fairly among ready resources; it does not reproduce browser priorities.
FAQ
Why does packet loss slow things down so much?
TCP reduces its sending rate when packets are lost. The model caps throughput by window, loss and bandwidth, and at 1 % loss the loss limit is the tightest.
Can I import a real page load?
Yes. Use Import HAR with a HAR file from your browser's network panel; sizes and cache indicators are read from it.
Does the tool contact my website?
No. It only uses the names, hosts and sizes you provide.
Why is shared-link mode not always faster?
Total bytes stay the same. Parallel transfers mainly hide round trips, so with few, large files the gain is small.
Guide last updated:
For scripts and AI agents
- JSON API:
POST https://signalhouseresourcebudget.usefulweb.app/api/v1/calculate(same calculation as this page) - Interface description: OpenAPI 3.1 · AI guide: llms.txt
- MCP server (Streamable HTTP):
https://signalhouseresourcebudget.usefulweb.app/mcp· tool namesignalhouse_resource_budget
Example request
curl -s -X POST https://signalhouseresourcebudget.usefulweb.app/api/v1/calculate \
-H 'content-type: application/json' \
-d '{}'