Frequently asked questions

Three metrics: LCP for how fast the main content loads, INP for how quickly pages react to input, and CLS for how much content moves unexpectedly. They are assessed at the 75th percentile of page loads, separately for mobile and desktop (source 1). INP replaced First Input Delay on March 12, 2024 (source 2).

For a "good" rating: LCP of 2.5 seconds or less (source 3), INP of 200 ms or less (source 1) and CLS of 0.1 or less (source 4). Poor starts above 4 seconds for LCP, above 500 ms for INP and above 0.25 for CLS.

A lab run is one simulated page load with no real interactions. Field data covers real devices, networks and every interaction during real visits. INP in particular cannot be measured well in a single lab load. Our INP guide explains how to find the interactions behind field values.

Any task on the browser's main thread that runs longer than 50 ms. While it runs, the browser cannot respond to input or paint (source 5). See breaking up long tasks.

It tends to show content sooner, but full hydration afterwards can keep the page unresponsive, and per-request rendering slows the first byte. The best choice differs per route. Our strategy comparison covers the trade-offs.

The step where a framework downloads and runs component code in the browser to attach event handlers and state to HTML the server already rendered.

Most major frameworks now offer a form of it: Vue 3.5 and later for async components, Nuxt through Lazy component props, Angular through incremental hydration and @defer, Astro through client directives, and React through Suspense boundaries and Server Components. Details are in the hydration guide.

Guides are written by Isabella Ward, the pen name of our editor. Reviews are carried out by the engineering side of the business that publishes this site. We do not name a team or list credentials we cannot show you.

We work remotely and focus on product teams in Canada. We can work with teams elsewhere in the same time zones, but our writing, pricing and legal notes are prepared for Canadian clients.

No, but it helps. Traces and source maps reveal most causes; code access lets us point to exact components.

No. Results depend on your code, users and traffic, and nobody can promise search rankings. We promise clear findings with evidence and an honest view of what each change is likely to do.

Starting prices in Canadian dollars are on the pricing page. Every engagement gets a fixed written quote first.

Traces are recorded in Chrome because its DevTools and the Long Animation Frames API give the most detail. We check key findings in Firefox and Safari where behaviour may differ, and we note when a technique depends on a browser feature with limited support.

We use CPU and network throttling for repeatable comparisons, and real Android devices through remote debugging when a problem depends on hardware. The report states which was used for each trace.

Yes. Walkthrough calls are open to as many engineers as you like, and the traces and notes are yours to keep. A handover session focused on the method can be added to any quote.

Yes. A narrower scope, such as one route family or two interactions, can be quoted below the starting prices. The quote states exactly what the smaller scope covers and what it leaves out.

We can work through a test account on a staging environment, a temporary account in your identity provider, or a screen-sharing session for the parts we cannot reach directly. The quote notes which approach we agreed.

Yes. Agencies can bring us in for a client project. The quote and findings can be addressed to the agency, and we do not contact the end client unless you ask us to.

They are yours to share. Each report opens with a short summary written for non-engineers, followed by the technical detail.

No. It uses no analytics, advertising or tracking scripts and sets no cookies, except a session cookie on the contact page when you load the form. The cookie notice has the details.

No. All three tools calculate in your browser and make no network requests.