Visualize critical rendering path with a waterfall chart. Simulate resource loading order for CSS, JS, fonts, and images.
Enter the resources your page loads - type, size, and whether each script uses defer or async - and the tool draws a waterfall chart on a simulated time axis, with bars showing when each request starts and ends. The chart applies browser-loading semantics: CSS blocks first paint, a classic script blocks HTML parsing until it executes, while images and fonts do not block. Milestones for first paint, DOMContentLoaded, and load are marked on the same axis. The surprise most users hit: the result is computed from the sizes and bandwidth you enter, not measured from the real site - so read it as a what-if model, not a profiler.
A concrete input and expected output from the current implementation.
Input
Resource rows entered in the form: - styles.css - CSS - 50 KB - no attributes (render-blocking) - app.js - Script - 300 KB - classic, no defer/async - hero.jpg - Image - 200 KB - in body, after app.js Settings: bandwidth 1 MB/s, latency 0 ms
Expected output
Waterfall bars: - styles.css: 0-50 ms, render-blocking; first paint at 50 ms - app.js: download 0-300 ms; parser blocked until it executes at 300 ms - hero.jpg: 300-500 ms Milestones: first paint 50 ms, DOMContentLoaded 300 ms, load 500 ms
The script is 300 KB at 1 MB/s, so its download takes 300 ms; because it has no defer or async, the parser cannot move past it, so the image in the body is only discovered at 300 ms and takes 200 ms itself, closing the load event at 500 ms. The CSS finishes at 50 ms, which is where the first paint marker lands.
Each resource becomes a horizontal bar. Its start time is when the simulated parser reaches it in the document, and its length is the entered size divided by the simulated bandwidth you set, plus latency when you set one. Downloads run in parallel, but the parser cannot move past a blocking script, so every bar after that script starts later. That delay is the blocking the chart is designed to expose.
A script without defer or async stops the parser from the moment it is reached until its download and execution finish. Defer downloads in parallel and executes after parsing; async executes as soon as its download lands, pausing parsing briefly. Fonts are fetched only when text that uses them is being laid out, and the font's display setting (swap, block, fallback, optional) decides whether fallback text is shown first. Re-running with changed attributes is the core workflow.
Both let the download proceed without stopping the parser, so resources below the script start earlier in the chart. Defer scripts execute in document order after parsing, before DOMContentLoaded; async scripts execute the moment their download lands, in arrival order, so they can run mid-parse and can jump ahead of other scripts. If execution order matters, async is the wrong choice - defer preserves it.
No. The tool never requests your site; it computes a timeline from the resources and settings you enter, so absolute timings are estimates. It is reliable for what-if comparison - does deferring this script move the load event? - but for measured numbers use a browser trace such as Chrome DevTools or WebPageTest.
The example and behavioral notes were checked against the browser implementation. Standards and primary references below define the relevant format, formula, or platform behavior.
Shorten URLs with local redirect tracking via localStorage. See click counts and generate a QR code for each link.
Build UTM-tagged URLs for campaign tracking with source, medium, campaign, term, and content parameters.
Enter 2+ headlines and see simulated previews in Google results, email subject lines, and social posts side-by-side.
Count characters for Twitter/X, LinkedIn, Facebook, and Instagram with platform-specific limits and warnings.
Calculate click-through rates from impressions and clicks with industry benchmarks and trend analysis.
Check email subject line length against best practices for desktop and mobile with preview text optimization.