Rendering optimization planner

How the plan is built

The planner follows the order we use at the start of a review, because doing things in the wrong order wastes effort. Fixing a slow handler on a route where hydration mismatches force a re-render, for example, can hide the real problem.

1. Evidence first. If you have no field data, the plan starts by collecting some. If you do, it starts by confirming the problem at the 75th percentile, split by mobile and desktop, which is how Core Web Vitals thresholds are assessed (source 1).
2. A trace on a throttled CPU. Most rendering problems are invisible on a fast developer machine.
3. Symptom-specific steps. Each symptom you tick adds a step aimed at it: Long Animation Frames attribution for slow interactions (source 2), the four-part breakdown for late main content (source 3), reserved space and font metrics for layout shifts (source 4), mismatch checks for hydration warnings, and bundle analysis for large JavaScript.
4. Rendering mode. Client-rendered apps get a step about rendering key routes earlier; server-rendered and static apps get a step about the cost of hydration.
5. Framework notes. A short note for your framework, such as Vue 3.5 lazy hydration strategies (source 5), Nuxt delayed hydration (source 6), Angular's default incremental hydration since version 22 (source 7), or the server-client boundary in React Server Components (source 8).
6. Measure the change. A reminder to ship one change at a time and compare field data across a full 28-day window, which is the period the Chrome UX Report aggregates over (source 9).

What the text file contains

The download is a plain UTF-8 text file named renderloria-plan.txt. It lists the same numbered steps shown on the page, the framework you chose, and a line noting that it is generic guidance rather than a review of your app. It contains nothing else, and it is created in your browser; no copy reaches us.

If you change any answer after creating a plan, the plan and the download link are cleared until you create a new one. That way the file always matches the answers on screen.

An example plan

An invented example: a team on Nuxt with server-rendered pages ticks "Slow responses to taps and clicks" and "Hydration warnings or mismatches". Their plan starts by confirming INP in field data, then asks for a throttled trace, then adds a Long Animation Frames step for the slow interactions and a mismatch step before any speed work, followed by a step about the cost of hydration on server-rendered pages, a Nuxt note about delayed hydration props, and the reminder to measure over a full window. Seven steps, in an order that avoids fixing the wrong thing first.

Re-running the planner later

Answers change as work progresses. Once field data is flowing or a symptom has been fixed, run the planner again with the new answers: the plan will drop steps you no longer need and reorder the rest.

Why the order matters

Measurement comes first in every plan because the most common waste in performance work is fixing a problem users do not have. A slow handler on a settings screen visited once a month matters less than a modest delay on the screen people open every morning. Field data, even rough, tells you which is which. The trace comes second because it turns a metric into a cause. Only then do symptom-specific and framework-specific steps make sense.

Using the plan with your team

The plan is designed to be pasted into a ticket or a team chat as it is. A practical way to use it: create one ticket per step, assign the measurement steps first, and agree in advance what result would make you stop or change direction. For example, if the throttled trace in step two shows that most of the main-thread time comes from a third-party script rather than your own code, the later framework steps become less important, and the priority shifts to that script.

Each step is written to stand alone, so you can drop steps that do not apply. If your team already collects field data with attribution, skip straight to the trace.

When a generic plan is not enough

A plan built from three answers cannot know your code, your traffic or your users' devices. It is a sensible order of work, not a diagnosis. If the plan's first steps turn up something you cannot explain, our rendering analysis and INP debugging services go much further.

Privacy

The planner runs entirely in your browser. It makes no network requests, stores nothing and sets no cookies.