Break down page weight by resource type, visualize the composition, and estimate total load time across devices and networks. Enter sizes manually, choose a preset, or analyze a live URL.
Only statically referenced resources are shown. JS-injected resources, lazy-loaded images, and analytics scripts are not discovered. Sizes shown are from Content-Length headers; some servers may not report this.
| Type | URL | Size |
|---|
This tool models three components of page load time, with differentiated processing costs by resource type:
Before any data transfers, the browser must establish secure connections. Each critical connection requires TLS negotiation, which depends on network round-trip time (RTT).
setup_time = connection_setup * critical_connections
The time to download all bytes over the network:
total_KB = html + css + js + images + fonts transfer_time = total_KB / (bandwidth_Kbps / 8)
Unlike a simple "JS heavy" toggle, this tool applies per-type processing multipliers reflecting real-world browser work:
| Resource | Multiplier | Why |
|---|---|---|
| JavaScript | 1.0 | Parse + compile + execute (most expensive) |
| CSS | 0.5 | Parse into CSSOM, style recalculation |
| HTML | 0.3 | DOM parsing, tree construction |
| Images | 0.1 | Decode (decompression only) |
| Fonts | 0.05 | Parse/decode, minimal processing |
weighted_KB = js*1.0 + css*0.5 + html*0.3 + images*0.1 + fonts*0.05 client_time = weighted_KB * BASE_TIME_PER_KB * (moto_g4_score / device_score)
Where BASE_TIME_PER_KB = 1/150 (~6.67ms per KB on a Moto G4 baseline).
total_time = setup_time + transfer_time + client_time
The "Analyze" feature fetches a page through a server-side proxy, parses the HTML for <script>, <link>, <style>, and <img> tags, then HEAD-requests each discovered resource to get its Content-Length. Results are approximate — only statically referenced resources are discovered, and some servers don't report Content-Length.
Not all bytes are created equal. A 200 KB JavaScript bundle costs far more than a 200 KB JPEG image, because the browser must do fundamentally different work with each:
Every byte of JavaScript must be parsed into an AST, compiled to bytecode (or machine code via JIT), and executed. On a low-end phone, a 200 KB JS bundle (compressed, ~600 KB uncompressed) can take 2-3 seconds just for parsing and compilation — before any of your code actually runs. JS also blocks the main thread, delaying interactivity.
CSS must be parsed into the CSSOM and combined with the DOM to build the render tree. Large stylesheets trigger expensive style recalculations, especially with complex selectors. But CSS doesn't execute arbitrary code, so it's roughly half the per-byte cost of JS.
HTML parsing builds the DOM tree. While the parser can be interrupted by synchronous scripts, the actual DOM construction is relatively fast. HTML is typically the smallest resource and the cheapest to process per byte.
Images are decoded (decompressed) but don't require parsing or execution. Modern browsers decode images off the main thread, so they don't block interactivity. The main cost of images is transfer time, not processing time.
Font files are parsed and rasterized, but the per-byte processing cost is negligible. The real cost of fonts is the potential for layout shifts (FOIT/FOUT) and the additional connection required to fetch them.
A page with 200 KiB of JS + 200 KiB of images (400 KiB total) will load significantly slower than a page with 50 KiB of JS + 350 KiB of images (same 400 KiB total) — even though the transfer size is identical. Reducing JavaScript has an outsized impact on performance.