When Lighthouse blames your page, ask for the blocking-work receipt

The mobile report did not look catastrophic.

The homepage still scored 85 in Lighthouse. It painted. It held together. It looked, at a glance, like a page a team could live with for another week.

Then the Total Blocking Time row asked a better question: why was the browser still too busy to answer a tap for 560 milliseconds?

That is the moment where performance review can go sideways. Someone blames analytics. Someone blames the animation library. Someone blames the framework chunk because Lighthouse named a first-party runtime file. An AI agent, handed the same report, may do the fastest version of the same thing: remove the visible suspect, rerun once, and declare the page faster.

The safer move is slower. Ask for the blocking-work receipt.

A blocking-work receipt is a small proof record. It says which route was tested, what Lighthouse measured, what the browser was doing, which cause is confirmed, which explanation is still only a hypothesis, what the fix must preserve, and which comparable rerun will prove the change helped.

It turns a score into a reviewable artifact.

Total Blocking Time is a waiting-room metric

Chrome defines Total Blocking Time as the time a page is blocked from responding to user input, including mouse clicks, screen taps, and keyboard presses.

Lighthouse counts the blocking portion of long tasks between First Contentful Paint and Time to Interactive. A task longer than 50 milliseconds is a long task; only the time after that first 50 milliseconds counts against TBT. Chrome's own example is simple: a 70 ms task contributes 20 ms of blocking time.

MDN describes a long task as an uninterrupted period where the main UI thread is busy for 50 ms or longer. That work can include event handlers, expensive reflows or rerenders, and browser work between event-loop turns.

For a site owner, the translation is less technical: the page may be visible while the browser is still in the back room finishing JavaScript, document work, layout, or other main-thread jobs. A customer can tap the menu, open search, press a CTA, or start moving through the page while that work is still occupying the thread.

TBT is the waiting room between "I can see the page" and "the page can answer me."

The first receipt separates evidence from suspicion

In the audit set behind this article, the homepage mobile report showed 560 ms TBT. The services page showed 390 ms. A representative blog article showed 220 ms. The desktop homepage still showed 240 ms, which made the finding broader than a mobile-only paint quirk.

Those numbers are evidence. They are not yet a fix.

The same reports showed an empty third-party summary. In that artifact set, the early blocking work was not explained by Vercel Analytics, WebMCP remote code, Mux, or another vendor script appearing early in the Lighthouse window.

That does not mean third-party scripts are always innocent. It means this evidence did not show them as the early TBT owner.

The largest recurring long-task owner was first-party runtime and document work. The services route also carried the strongest Style & Layout signal, about 650 ms in the reviewed mobile report.

Those are useful findings, but they still need discipline. A first-party runtime chunk is a clue, not a villain. The chunk name tells you where the browser accounted for work. It does not prove that the framework itself is the product problem.

The source-level hypotheses were narrower:

• Reducing the initial service-card and proof-module payload may reduce document and layout work.
• Keeping header, search, modal, CTA analytics, and decorative behavior native, deferred, or intent-loaded may reduce early hydration risk.
• Compacting blog CTA analytics attributes may be enough if shared runtime improvements bring the representative article close to budget.

Each of those sentences includes a may. That word matters. A receipt should keep confirmed evidence and plausible implementation bets in separate columns until a comparable rerun closes the loop.

A chunk name should send you back to source ownership

When Lighthouse points at a first-party runtime or document task, the wrong next question is "How do we remove this file?"

The better questions are smaller and closer to the page:

• Which client references are present before interaction?
• Which components are decorative, supporting, analytics-only, or below the fold?
• Which text, schema, links, service summaries, article bodies, and CTAs must remain server-rendered and crawlable?
• Which behavior can wait for a click, idle period, viewport, desktop breakpoint, or later route?

That last group is where performance review becomes product review.

A services page can be heavy because it is doing useful work. It may explain offers, show proof, expose links, preserve conversion paths, and give search engines enough structure to understand the business. Removing that material can make a report look better while making the page worse.

The receipt should force a source-owner decision instead of a purge. Keep critical content early. Server-render what needs to be visible and crawlable. Defer behavior that does not help the first tap. Intent-load tools that only matter after the visitor asks for them. Simplify decorative mobile effects before cutting explanation, schema, or conversion paths.

That is also the AI-development lesson. An agent asked to "fix Lighthouse" needs a stronger instruction than "reduce JavaScript." It needs a receipt that names what must stay intact.

The blocking-work receipt

A blocking-work receipt is not a performance wish list. It is a compact record a reviewer can read before approving the change.

A reviewer should be able to read that table and understand the trade. If the proposed change removes a proof module, what user or crawler value disappears with it? If it defers a search dialog, can a keyboard user still reach it? If it changes CTA analytics, can the team still prove which action a visitor took? If it claims the page improved, where is the comparable run?

Without that record, the fix depends on memory and trust. With it, the next person can review the evidence instead of re-litigating the diagnosis.

Confirmed versus hypothesis belongs in the same room

The most dangerous performance note is the one that sounds certain too early.

"Third-party scripts caused TBT" is a useful finding when the third-party summary and long-task attribution support it. In this audit set, they did not.

"The framework caused TBT" is tempting when the repeated owner is a runtime chunk. It is also too broad. The browser may be spending time in the runtime because the app gave it too much early work: route payload, client startup, layout, event wiring, repeated content, or document work.

"Simplifying service cards will reduce Style & Layout by a specific amount" is also premature until someone changes the page and reruns the same kind of sample.

A good receipt lets all three kinds of statements coexist without collapsing them into one claim:

Scroll sideways to see all 2 columns.

Confirmed	Still a hypothesis
Homepage mobile TBT was about 560 ms in the reviewed production report.	A particular code change will bring it below 200 ms.
Third-party summary was empty in all six reviewed reports.	Removing an analytics vendor would improve this artifact set.
Services mobile had about 650 ms of Style & Layout work.	Simplifying service-card and proof markup will reduce that cost by a specific amount.
A first-party runtime/document owner appeared in recurring long tasks.	The framework chunk itself is the root cause.

That separation is especially useful when AI-assisted implementation is involved. Agents are good at acting on a confident instruction. They are less reliable when the instruction quietly mixes proof, suspicion, and product preference.

The receipt gives the agent and the reviewer different lanes: this is known, this is the bet, this must not break, and this is how we will know.

The decisions the receipt should force

The receipt should not end with "reduce TBT." That is a target, not a decision.

It should force the team to decide which work earned the right to run early.

Service summaries, article bodies, internal links, metadata, schema, primary CTAs, and visible explanation usually earn that right. They help humans understand the page. They help crawlers and AI systems understand the business. They help a visitor decide whether to keep moving.

Decorative mobile effects have a weaker claim. Repeated below-fold proof modules have a weaker claim. Analytics wrappers that hydrate an entire component just to record a click may have a weaker claim if a native delegated listener can preserve the same receipt later.

Header and search affordances sit in the middle. They are interaction paths, so they cannot disappear or become keyboard-hostile. But they do not always need the heaviest possible startup path before the first tap.

The point is not to make every site follow the same checklist. The point is to make every performance fix state its preservation rule.

If the team cannot say what must stay crawlable, accessible, measurable, and conversion-ready, it is not ready to approve the optimization.

What proof should come back after the change

The final proof should look boring.

Run comparable Lighthouse samples. Keep the route, device profile, and conditions as close as practical. Record TBT and the nearby context, not only the overall performance score. If the article or implementation note claims movement in long-task count, main-thread work, document size, or Style & Layout, keep that evidence with the claim.

Then run the preservation checks the receipt promised:

• The H1/H2 outline still makes sense.
• Schema or JSON-LD still renders where the page depends on it.
• Service summaries, article text, and primary CTAs remain visible.
• Header, search, and CTA paths still work with keyboard interaction.
• Analytics attributes or delegated tracking behavior remain present where expected.
• The browser console and network panel are clean enough for the change being reviewed.

If the results are mixed, say so. A receipt is still useful when it proves a hypothesis was wrong. That is better than shipping a speculative cut and leaving the next reviewer to discover the regression later.

Keep the receipt with the page, not in someone's memory

Performance fixes should leave behind more than a screenshot of a green score.

They should leave a small record that tells the next person what the browser was doing, which work earned the right to run early, what moved later, what stayed intact, and how the team proved the business path still worked.

That habit is useful for human developers. It is essential for AI-assisted website work. If an agent changes a production page, the team needs to know more than whether the diff compiled. It needs the evidence trail that made the change safe to accept.

BaristaLabs helps teams build those evidence trails into the work itself: performance receipts, source-owner decisions, preservation rules, and verification packets that make a website change reviewable before the next deploy spends the main thread again.

Bring one slow page and one Lighthouse run. The first useful deliverable is not a promise that the score will turn green. It is the receipt that tells you what can safely change.