Rendering analysis for web apps

What the analysis covers

Most performance reports stop at a score. A rendering analysis goes one layer down and asks what the browser was doing at each moment of a page load or interaction. For a modern app that means four stretches of time: waiting for the server, parsing and painting HTML, downloading and running JavaScript, and the work a framework does to take control of the page, which for server-rendered apps is hydration.

We trace those stretches on the routes that matter most to your product, for example a landing route, a logged-in dashboard or list view, and one route with heavy interaction such as search, filters or a form. For each route we record what happens on a fast laptop and on a throttled profile closer to the phones many of your visitors carry.

The goal is a short, ranked list of causes with evidence, not a long list of generic tips. If a single hydration pass or one oversized dependency explains most of the delay, the report says so plainly.

Signs a rendering analysis is the right first step

• Field data shows poor or borderline Largest Contentful Paint or Interaction to Next Paint, but nobody on the team agrees on why.
• The app looks ready quickly but ignores the first taps, which often points to hydration or start-up JavaScript.
• Lab scores are acceptable while support tickets or session recordings describe sluggish screens.
• A framework upgrade or a new feature made things slower and the team needs to know which change did it.
• You are planning a rendering change, for example moving routes to server rendering, and want a baseline before you start.

How we run it

1. 01

   Agree the routes and devices

   We pick up to three route families with you and decide which device and network profiles to test. If you have field data, it guides the choice; if not, we use the profiles Lighthouse and the Chrome DevTools Performance panel offer as a starting point.

2. 02

   Gather field data where it exists

   We look at Chrome UX Report data for your origin and any real-user monitoring you already run. Field values are judged at the 75th percentile, split by mobile and desktop, which is how Google's Core Web Vitals thresholds are defined (source 1).

3. 03

   Record and annotate traces

   Each route is traced several times so one noisy run does not mislead us. We annotate long tasks, layout and style work, network waterfalls and, in Chromium, Long Animation Frames, which attribute slow frames to the scripts that caused them (source 2).

4. 04

   Break metrics into parts

   Largest Contentful Paint is divided into its four documented subparts, from the server's first byte through discovery and download of the resource to the final render delay (source 3). Interactions are split into input delay, processing duration and presentation delay (source 1). The biggest part decides where we look next.

5. 05

   Write the findings

   Every finding states the cause, the evidence, the likely size of the gain in plain words, the effort, and any risk. Nothing is padded to make the report look longer.

What you receive

• A written report, of roughly 10 to 20 pages, with annotated trace screenshots and a summary your product lead can read in five minutes.
• A ranked list of changes, each tagged as quick, moderate or structural.
• The trace files we recorded, so your engineers can open them in their own DevTools.
• A 60-minute call to walk through the findings and answer questions.

We do not promise a particular score or percentage gain. What a change achieves depends on your code, your users' devices and the traffic mix, and field data takes time to reflect any change because the Chrome UX Report uses a rolling 28-day window (source 4).

What we need from you

A test account if routes sit behind a login, the build or deploy you want us to treat as the baseline, and read access to any monitoring dashboards you already use. Source code access is helpful but optional; many causes are visible from traces and source maps alone. If your app handles personal information, tell us early so we can test with seeded or anonymized accounts.

Where the analysis stops

The analysis tells you what to change and why. It does not include the engineering work itself. If you want us to help implement, that is quoted separately after the report, as described on the pricing page. It also does not cover back-end tuning in depth: if time to first byte dominates, we say so and describe what we see, but database and server work is best handled by the team that owns those systems.

An example of one finding

To make the format concrete, here is how a single finding might read in a report. This one is invented.

Every finding follows the same pattern: what happens, where the evidence is, what to change, how hard it is and what could break. That structure makes findings easy to turn into tickets, and easy to challenge if your team sees something different.

How findings are ranked

We rank by user effect first: how many visits hit the problem, how long it delays them, and whether it affects loading, responsiveness or stability. Effort comes second. A quick fix that helps few visits sits below a moderate change that helps most of them. Where two findings depend on each other, for example a hydration change that only pays off once a large dependency is removed, the report says so and orders them accordingly.

We also mark findings we are less sure about. If a cause is likely but the evidence is thin, perhaps because field data is sparse for that route, the finding carries a note explaining what would confirm it.

Questions about rendering analysis