The three tools
Rendering pipeline visualizer
See how five rendering strategies play out on three device profiles.
Long-task budget planner
Estimate INP phases on slower devices from timings you measured.
Rendering optimization planner
Answer three questions and download an ordered plan as a text file.
What each tool is for
The rendering pipeline visualizer is a teaching aid. Pick a rendering strategy and a device profile and it draws a simulated timeline of server response, HTML, JavaScript and hydration, using fixed assumed costs. It is meant to make the trade-offs described in our rendering strategies guide easier to picture, not to predict your app's numbers.
The long-task budget planner takes timings you have measured, such as the length of an event handler in a DevTools trace, and estimates the three phases of Interaction to Next Paint on slower devices. It also tells you how finely to split work to keep each piece under the 50 ms long-task line.
The optimization planner asks a few questions about your framework, rendering mode and symptoms, then writes an ordered plan you can download as a plain text file and paste into a ticket.
Why the tools do not analyze URLs
Many performance tools ask for a URL and return a score. Good free ones already exist, including PageSpeed Insights, which combines lab results from Lighthouse with field data from the Chrome UX Report where available. Building another would add little. More importantly, a single automated run cannot tell you why an app hydrates slowly or which handler delays a tap. Those answers come from traces and attribution, which is what our guides teach and our services provide.
Using the tools without JavaScript
The tools need JavaScript because they calculate in your browser. If JavaScript is off, each tool page still explains the model behind it, so you can follow the reasoning by hand.
How the tools fit together
The three tools follow the order of a real investigation. The visualizer helps you form a picture of where time can go under each rendering strategy. The budget planner turns measurements from your own traces into an estimate of what users on slower devices experience, and tells you how much to split work. The optimization planner turns your situation into an ordered list of next steps. Used together, they make a reasonable first pass before you decide whether outside help is worth it.
Each tool page explains its model in full, including every assumption, so that you can check the arithmetic, adapt it to your own numbers, or disagree with our choices.
Getting the numbers the tools ask for
Only the budget planner needs your own measurements, and they come from one place: a Performance trace in Chrome DevTools. Open DevTools, choose the Performance panel, set CPU throttling to a value close to your users' devices, start recording, perform the interaction, and stop. In the trace, find the interaction on the Interactions track; the main-thread track below it shows the event handler work and the rendering that follows. Note the length of any task that was already running when the interaction began.
If you have real-user monitoring with the attribution build of the web-vitals library, its INP reports give input delay, processing duration and presentation delay directly, which you can enter as a starting point.
Using the tools in a team discussion
The visualizer is useful in architecture conversations, where people need a shared picture before arguing about details: run the same strategy on the laptop and low-end profiles side by side and the cost of hydration on slow devices becomes visible without anyone having to read a trace. The budget planner suits sprint planning, when a team needs to agree how finely to split a slow handler. The optimization planner works as a checklist for a kick-off meeting.
Offline use
Once a tool page has loaded, it keeps working without a connection, because all of its calculations run in the page itself. That makes the tools usable in a meeting room with poor Wi-Fi or on a train.
Feedback on the tools
The models behind the tools are deliberately simple and fully documented on each page. If you think an assumption is wrong or misleading, tell us through the contact page and say which figure and why; we will review it against our sources and update the tool or explain our choice.
Limits shared by all three tools
The tools work from simple models and your inputs, so their output is only as good as both. They cannot account for your code's particular behaviour, real network conditions, caching, browser differences or how real users interact. Treat their results as a way to reason about trade-offs and plan work, then check against traces and field data from your own app.
Accessibility
Each tool uses standard form controls with visible labels, can be used with a keyboard alone, and moves focus to the result when you submit. Results are also given as text and tables, not only as charts. If something does not work for you, please tell us through the contact page.