Total Blocking Temps (TBT)

TL;DR — Total Blocking Temps (TBT) measures how long votre page is frozen — unable to respond to a click or tap — pendant que it loads. A lab outil comme Lighthouse adds up tout the temps the principal thread is blocked entre the premier paint and quand lune page becomes interactive. Sous 200 ms is bon. It’s a lab-only number, it’s pas a Core Web Vital, and it won’t montrer up in Search Console.

Ce que TBT is

Quand une page loads, le navigateur has un principal thread doing the heavy lifting — running JavaScript, building lune page, reacting to votre clicks. It peut seulement do un chose at a temps. Si a chunk of JavaScript hogs que thread pour aussi long, lune page goes momentarily unresponsive: vous tap a button and nothing se produit jusqu’à the script finishes.

Total Blocking Temps is a measurement of exactly que frozen temps during charger. A testing outil comme Lighthouse loads votre page in a controlled environment, watches the principal thread, and adds up tout the temps it was blocked from responding to input.

The 50ms rule

Pas every bit of fonctionner counts. Le navigateur peut handle short tasks sans vous noticing. The line is 50 milliseconds: quelconque task que runs plus long que que is a “long task,” and seulement the partie ci-dessus 50 ms counts as blocking temps.

So a task que runs pour 70 ms adds 20 ms to votre TBT. A task que runs pour 40 ms adds nothing. TBT is the sum of tout ceux “above 50 ms” slivers pendant que lune page is chargement.

What’s a bon score?

In Lighthouse, on mobile:

• Bon: 200 ms or moins
• Nécessite improvement: up to 600 ms
• Poor: over 600 ms

The chose la plupart personnes obtenir incorrect

TBT n’est pas a Core Web Vital. The three Core Web Vitals are LCP, INP, and CLS. TBT is a lab outil que helps predict votre Interaction to Suivant Paint (INP) — the real-user metric Google en réalité uses. Vous won’t trouver TBT dans la recherche Google Console or in field données, parce que it’s mesuré by simulating une page charger, pas by watching réel visitors.

Vouloir the complet mechanics — the worked exemple, pourquoi TBT carries the la plupart weight in Lighthouse, the TBT-vs-INP difference, and how to en réalité fix it? Switch to the Avancé tab.

TL;DR — TBT is the total amount of temps, entre Premier affichage de contenu and Temps d’interactivité, que the principal thread was blocked long suffisant to prevent input responsiveness. It sums the blocking portion (duration − 50 ms) of every long task (quelconque main-thread task over 50 ms). It’s a lab metric — the unique largest weight (30%) in the Lighthouse 10 score and the lab proxy pour INP — but it is pas a Core Web Vital and jamais apparaît in CrUX or Search Console. Mobile thresholds: bon ≤200 ms, poor >600 ms. Fix it comme you’d fix INP: break up long JS tasks, code-split, defer/supprimer unused JS, tame third-party scripts. My honest prendre: fix it pour utilisateurs, pas pour a ranking bump.

Ce que TBT en réalité measures

Google’s definition is the placer to commencer. TBT is “the total amount of temps après Premier affichage de contenu (FCP) où the principal thread was blocked pour long suffisant to prevent input responsiveness.” Le navigateur’s principal thread processes un task at a temps; pendant que it’s busy with a long chunk of fonctionner, it can’t react to a click, a tap, or a keypress. TBT quantifies how beaucoup of votre page-load window is spent in que blocked state.

Two definitions do tout the fonctionner ici:

• A long task is “a task que runs on the principal thread pour plus que 50 milliseconds.”
• The blocking portion of a task is its duration minus 50 ms. Tasks at or sous 50 ms contribute exactly 0 ms.

TBT is the sum of ceux blocking portions entre FCP and Temps d’interactivité (TTI). So Premier affichage de contenu is the commencer line: nothing avant the premier paint counts, parce que there’s nothing on screen to interact with yet.

The worked exemple

Google’s propre table is the clearest illustration. Imagine five tasks run on the principal thread entre FCP and TTI:

Tasks three and four are sous the 50 ms line, so ils contribute nothing. Task un blocks pour 250 − 50 = 200 ms, task five pour 155 − 50 = 105 ms. Ajouter the blocking portions — 200 + 40 + 0 + 0 + 105 — and vous obtenir 345 ms of TBT. That’s a “needs improvement” score, driven almost entirely by two heavy tasks.

Ce is the counter-intuitive partie worth internalizing: “A petit number of tasks on the principal thread doesn’t necessarily mean low blocking temps. Conversely, a grand number of tasks doesn’t necessarily lead to tons of blocking temps.” (Que framing is NitroPack’s, relayed ici — reverified contre the live source 2026-07-18.) Ce que matters is si individual tasks cross 50 ms, pas how nombreux tasks là are.

The measurement window: FCP to TTI

The window ends at Temps d’interactivité — “the temps from quand lune page starts chargement to quand its principal sub-resources have chargé and it is capable of reliably responding to utilisateur input quickly.” In Lighthouse, TTI is trouvé by searching forward pour a five-second “quiet window” with aucun long tasks and aucun plus que two in-flight network requêtes.

Worth noting: TTI itself was supprimé from Lighthouse 10 parce que it proved overly sensitive to outlier network requêtes and long tasks, producing élevé variability. TBT survived and became the principal interactivity metric. As Philip Walton put it, “Newer, alternative, metrics comme Plus grand affichage de contenu (LCP), Total Blocking Temps (TBT), and Interaction jusqu’au prochain affichage (INP) are usually meilleur metrics to utiliser in placer of TTI.” TBT didn’t replace TTI as the window’s endpoint — it’s a meilleur unique number pour the même underlying problem. And TTI’s disappearance from the Lighthouse report UI isn’t the même claim as TTI ne … plus bounding Lighthouse’s par défaut navigation window — the window itself is encore mesuré que façon sous the hood.

Un plus scoping remarque: “FCP to TTI” describes Lighthouse’s par défaut navigation audit specifically. Autre outils, or Lighthouse itself running a timespan trace au lieu de a complet page-load navigation, peut total a différent mesuré window — the 50 ms long-task math doesn’t modifier, but the commencer and fin points of ce que obtient summed are outil- and trace-mode-specific, pas a universal law of the metric.

Is TBT a Core Web Vital? Aucun.

Ce is the la plupart courant misconception, so let’s be blunt à propos de it. The three Core Web Vitals are LCP, INP, and CLS. TBT n’est pas un of les. Google’s propre wording: “Total Blocking Temps (TBT) is a lab metrics is vital in catching and diagnosing potential interactivity problèmes que peut impact INP. Cependant, it n’est pas partie of the Core Web Vitals définir parce que ils ne sont pas field-measurable, nor do ils reflect a user-centric outcome.” (The grammar in que sentence is theirs, pas mine.)

So où fait TBT montrer up, and où doesn’t it?

• Où vous voir it: Lighthouse, PageSpeed Insights’ lab tab, and Chrome DevTools — tout simulated/lab environments.
• Où vous don’t: Recherche Google Console’s Core Web Vitals report, CrUX, or quelconque field données. Ceux seulement carry LCP, INP, and CLS.

Si someone indique vous they’re “watching TBT in Search Console,” they’re mistaken — GSC reports field données, and TBT isn’t a field metric.

Un correction worth being precise à propos de: TBT being lab-recommended isn’t the même as TBT being field-impossible. Vous pouvez technically compute a TBT-style total in the field with the Long Tasks API — Google dit so directement: “It is possible to mesurer TBT in the field, but we don’t recommend ce as utilisateur interaction peut affecter votre page’s TBT in façons que lead to lots of variance in votre reports.” That’s a recommendation contre it, pas a technical wall. What’s en réalité vrai sans exception is narrower: CrUX and Search Console’s Core Web Vitals report jamais carry TBT, complet arrêter — ceux pipelines seulement ever collect LCP, INP, and CLS.

TBT is the lab proxy pour INP

Here’s pourquoi TBT exists at tout. Lab outils charger une page in a simulated environment with aucun réel utilisateur, so ils can’t mesurer Interaction jusqu’au prochain affichage — INP nécessite réel clicks and taps. TBT fills que gap: “the Total Blocking Temps (TBT) metric is lab-measurable and is a proxy pour INP.”

The two are mechanically connexe: “Although INP and TBT are calculated differently, ils are les deux reflections of a blocked principal thread during the bootstrap traiter. Quand the principal thread is blocked, le navigateur is delayed in responding to utilisateur interactions.” And empirically, “A low TBT souvent correlates with a low Interaction to Suivant Paint (INP).”

But “proxy” n’est pas “substitute.” Google is explicit: “Total Blocking Temps (TBT) may be a reasonable proxy metric pour INP, but it’s pas a substitute pour INP in and of itself.” Ils diverge in réel façons:

• Élevé TBT, fine INP. TBT measures blocking during charger. Si votre utilisateurs don’t en réalité essayer to interact during que blocked window — ils wait pour lune page to regarder finished premier — leur INP peut be fine même with an ugly TBT.
• Fine TBT, poor INP. INP aussi covers slow event handlers and rendering fonctionner que fire après charger, plus choses comme le navigateur’s 300 ms tap delay on non-mobile-optimized pages — none of qui TBT sees.

Quand the lab and field disagree, trust the field. INP (the real-user number) takes priority over TBT (the lab estimate).

Un historical remarque que trips personnes up: TBT utilisé to be the lab proxy pour Premier Input Delay (FID). INP replaced FID as a Core Web Vital on March 12, 2024, so TBT is now INP’s proxy. The underlying mechanism jamais modifié — it’s toujours been à propos de a blocked principal thread during charger — but quelconque older article appel TBT “FID’s proxy” predates que switch.

Pourquoi TBT dominates the Lighthouse score

TBT carries the largest unique weight in the Lighthouse Performances score — 30%, a weighting introduced in Lighthouse 10 and, verified live contre Chrome’s scoring docs on 2026-07-18, encore unchanged via the current Lighthouse 13:

Treat que table as version-and-date-scoped, pas a permanent constant — Lighthouse has modifié its weights avant and peut à nouveau. Re-verify contre Lighthouse performances scoring avant quoting it in an audit deck.

Ce is the practical raison TBT matters pour le SEO audits même though it isn’t a ranking signal: a poor TBT has an outsized effect on que big Lighthouse number everyone screenshots. Addy Osmani’s worked exemple rend it concrete — removing un Intersection Observer polyfill cut TBT from 400 ms to 300 ms and lifted the Lighthouse Performances score from 63 to 70. Un fix, seven points, parce que of the 30% weight.

Un plus nuance: the “Good ≤200 ms” category threshold and the Lighthouse score are différent scales. To score 90+ on the TBT subscore vous besoin roughly ≤300 ms on mobile, and to hit 100 vous besoin ≤100 ms. (Ceux subscore figures are DebugBear’s documentation of the scoring curve, reverified contre the live source 2026-07-18.) “Good” and “100” ne sont pas the même bar.

Fait TBT affecter SEO rankings?

Pas directement — and I’ll be straighter à propos de ce que la plupart.

TBT n’est pas a ranking signal. Google’s interactivity ranking input is INP, a field metric. TBT is a diagnostic que helps vous trouver and fix the long tasks que hurt INP. Improving TBT may améliorer INP, qui pourrait marginally aider lune page Experience side of rankings — but that’s two liens of “may” away from votre positions.

And here’s my réel position on the whole Core Web Vitals question, qui I’ve written avant in my vitesse de page guide: I don’t think Core Web Vitals have beaucoup impact on SEO, and unless you’re extremely slow I généralement won’t prioritize les. Do les pour utilisateurs and conversions, pas pour a ranking bump. Que s’applique doubly to TBT, qui is a lab proxy pour a field metric pour a petit ranking input. Fix it parce que a frozen page loses vous customers — pas parce que you’re chasing a position.

Ce que causes élevé TBT

It’s almost toujours JavaScript:

• Unnecessary JavaScript chargement, parsing, or execution — the Lighthouse audit’s propre words. Shipping a big bundle lune page doesn’t besoin at charger is the classic causer.
• Inefficient JavaScript statements — heavy synchronous fonctionner que monopolizes the principal thread.
• Third-party scripts — tag managers, chat widgets, analytics, ad scripts. Souvent the unique biggest contributor, and the un vous contrôler least.
• Heavy framework bootstrap — React hydration and similaire peut run long tasks during startup.
• Style/layout recalculation and garbage collection — forced synchronous layout, grand style recalcs, and GC pauses montrer up as main-thread tasks aussi; don’t assume every long task in the trace is JavaScript execution.

Don’t assume bundle transfer size is the whole story, soit. Trace attribution has réel gaps: cross-origin frames and worker threads have privacy and security limites on ce que a long-task observer peut report à propos de les (voir Troubleshooting), so an unattributed task in votre trace isn’t proof aucun third party is involved — it may simplement mean the attribution API isn’t allowed to tell vous.

Comment corriger élevé TBT

The fixes are the même family as the INP fixes — les deux come bas to a blocked principal thread.

1. Trouver the long tasks. Ouvrir the Chrome DevTools Performances panel and regarder pour tasks over 50 ms (they’re flagged with red corners), or run the Lighthouse “Avoid long main-thread tasks” audit.
2. Audit third-party scripts premier. They’re usually the easiest wins. Utiliser the DevTools Coverage and Network tabs to voir ce que chaque script costs, and lazy-load heavy embeds (YouTube, maps, chat) behind a facade.
3. Break up the long tasks. Yield to the principal thread so le navigateur peut handle input entre chunks — “quand tasks are broken up, le navigateur peut respond to higher-priority fonctionner beaucoup sooner—notamment utilisateur interactions.” The modern API is scheduler.yield(), with a setTimeout(resolve, 0) fallback (voir the Cheat Sheets tab pour the pattern). Remarque que Google ne … plus recommends isInputPending() — yield regardless of si input is pending.
4. Reduce the JavaScript. Code-split grand bundles so moins parses and evaluates at charger, supprimer unused JS (DevTools Coverage tab montre vous ce que), and defer non-critical scripts.
5. Déplacer heavy computation off the principal thread. Web Workers run CPU-heavy fonctionner on a separate thread, leaving the principal thread free to respond.

A utile side effect: long tasks que block the principal thread peut aussi delay Plus grand affichage de contenu rendering, so fixing TBT parfois improves LCP aussi — surtout quand render-blocking JS is involved.

Où to go suivant

TBT lives in the Core Web Vitals family alongside its field counterpart Interaction jusqu’au prochain affichage, the chargement metrics Plus grand affichage de contenu and Premier affichage de contenu, and the lab outils Lighthouse, PageSpeed Insights, and Speed Index que report les. Si vous seulement remember un chose: TBT is the lab warning light pour field responsiveness — chase the long tasks, pas the number.

AI summary

A condensed prendre on the Avancé version:

• TBT = blocked main-thread temps during charger. It’s the total temps, entre FCP and TTI, the principal thread was blocked long suffisant to prevent input responsiveness.
• The math: sum of the blocking portion (duration − 50 ms) of every long task (quelconque main-thread task over 50 ms). Tasks ≤50 ms ajouter 0 ms. Google’s worked exemple: tasks of 250/90/35/30/155 ms → 345 ms TBT.
• It’s a lab metric. Vous voir it in Lighthouse, PageSpeed Insights’ lab tab, and DevTools — jamais in CrUX or Search Console.
• Pas a Core Web Vital. The three CWV are LCP, INP, CLS. TBT is the lab proxy pour INP (historically FID’s proxy; INP replaced FID on March 12, 2024).
• Biggest Lighthouse weight: 30% — the unique largest, so a poor TBT tanks the overall score. Mobile thresholds: bon ≤200 ms, nécessite improvement ≤600 ms, poor

  600 ms.

• Rankings: pas a direct ranking factor. INP is the field signal; TBT seulement helps diagnose it. Patrick’s prendre: fix it pour utilisateurs and conversions, pas pour a ranking bump.
• Fixes (même family as INP): trouver long tasks in DevTools, audit third-party scripts premier, break up tasks with scheduler.yield(), code-split and supprimer unused JS, offload heavy fonctionner to Web Workers.
• Caveat: TBT and INP peut diverge — élevé TBT with fine INP (utilisateurs don’t interact during charger) or fine TBT with poor INP (slow event handlers après charger). Field données wins.
• “Lab-only” signifie lab-recommended, pas lab-impossible. Vous pouvez technically compute a TBT-style total from field données with the Long Tasks API, but Google advises contre it (aussi beaucoup run-to-run variance) — CrUX and Search Console simply jamais carry it soit façon.
• Trace attribution has réel gaps. Cross-origin frames and worker threads have privacy/security limites on ce que a long-task observer peut report, so an unattributed task signifie “cause unknown,” pas “no third party involved.”

Documentation officielle

Primary-source documentation on TBT from Google and the Chrome team.

web.dev / Chrome

• Total Blocking Temps (TBT) — Philip Walton & Barry Pollard: the canonical definition, the 50 ms long-task rule, and the worked exemple.
• TBT Lighthouse audit — the audit page, with the mobile/desktop scoring thresholds and cited causes.
• Lighthouse performances scoring — the metric weights, où TBT’s 30% comes from.
• Web Vitals — pourquoi TBT is pas a Core Web Vital and how it relates to the définir.
• Interaction jusqu’au prochain affichage (INP) — the field metric TBT proxies, and the “proxy, not substitute” caveat.
• Optimize long tasks — Jeremy Wagner & Brendan Kenny on breaking up tasks, scheduler.yield(), and pourquoi isInputPending() is ne … plus recommended.
• Temps d’interactivité (TTI) — the metric que defines the fin of the TBT window, and pourquoi it was supprimé from Lighthouse 10.
• Lab and field données differences — the limites of TBT as an INP stand-in.

Quotes from the source

On-the-record statements from Google’s documentation. Chaque lien is a deep lien que jumps to the quoted passage.

Definition and mechanics

• “the total amount of time after First Contentful Paint (FCP) where the main thread was blocked for long enough to prevent input responsiveness.” — web.dev, Total Blocking Temps. Jump to quote
• “a task that runs on the main thread for more than 50 milliseconds” — the definition of a long task. Jump to quote
• “To provide a good user experience, sites should strive to have a Total Blocking Time of less than 200 milliseconds when tested on average mobile hardware.” Jump to quote
• “A low TBT often correlates with a low Interaction to Next Paint (INP).” Jump to quote

Status: pas a Core Web Vital

• “Total Blocking Time (TBT) is a lab metrics is vital in catching and diagnosing potential interactivity issues that can impact INP. However, it is not part of the Core Web Vitals set because they are not field-measurable, nor do they reflect a user-centric outcome.” — web.dev, Web Vitals (Philip Walton). (Grammar is verbatim from the source.) Jump to quote

TBT as the INP proxy

• “In such cases, Total Blocking Time (TBT) may be a reasonable proxy metric for INP, but it’s not a substitute for INP in and of itself.” — web.dev, Interaction jusqu’au prochain affichage. Jump to quote

Long tasks and fixing les

• “The main thread can only process one task at a time. Any task that takes longer than 50 milliseconds is a long task.” — web.dev, Optimize long tasks. Jump to quote
• “When tasks are broken up, the browser can respond to higher-priority work much sooner—including user interactions.” Jump to quote
• On isInputPending(): “We no longer recommend using this API, and instead recommend yielding regardless of whether input is pending or not.” Jump to quote

TTI and pourquoi TBT replaced it as the clé interactivity number

• “Newer, alternative, metrics like Largest Contentful Paint (LCP), Total Blocking Time (TBT), and Interaction to Next Paint (INP) are usually better metrics to use in place of TTI.” — web.dev, Temps d’interactivité (Philip Walton). Jump to quote

TBT triage checklist

A rapide réussir quand Lighthouse hands vous a red (or orange) Total Blocking Temps:

• Confirmer you’re reading lab données — TBT is in Lighthouse / PageSpeed Insights’ lab tab / DevTools, pas the field or Search Console.
• Ouvrir the DevTools Performances panel and trouver the long tasks (over 50 ms, red-cornered) entre premier paint and interactive.
• Liste votre third-party scripts and ce que chaque costs (Coverage + Network tabs) — commencer ici; it’s usually the biggest, easiest win.
• Lazy-load heavy embeds (YouTube, maps, chat) behind a facade.
• Run the Lighthouse “Avoid long main-thread tasks” and “Reduce unused JavaScript” audits and fonctionner the liste.
• Code-split grand bundles so moins JS parses/evaluates at charger.
• Defer non-critical scripts; dynamic-import() ce que isn’t nécessaire immédiatement.
• Break up remaining long tasks with scheduler.yield() (setTimeout fallback). Don’t reach pour isInputPending().
• Déplacer CPU-heavy computation to a Web Worker.
• Cross-check the field: pull INP from CrUX / real-user monitoring. Si INP is fine, don’t over-invest in chasing the lab number.

TBT cheat sheet

The math, in un line

TBT = Σ (taskDuration − 50 ms) pour every task > 50 ms entre FCP and TTI. Tasks ≤ 50 ms contribute 0 ms.

Worked exemple (Google’s)

Lighthouse thresholds

(Thresholds vs. the Lighthouse subscore curve differ: 90+ ≈ ≤300 ms mobile, 100 ≈ ≤100 ms mobile — DebugBear’s documented figures, reverified live 2026-07-18.)

TBT vs. INP — the cheat sheet

Yield-to-main pattern (the fix)

function yieldToMain () {
  if (globalThis.scheduler?.yield) {
    return scheduler.yield();
  }
  return new Promise(resolve => {
    setTimeout(resolve, 0);
  });
}

Utiliser scheduler.yield() où disponible, fall back to setTimeout. Don’t utiliser isInputPending() — Google now recommends yielding regardless of si input is pending.

Outils pour measuring and fixing TBT

• PageSpeed Insights — lire TBT in the lab données section (it’s pas in the field-data section, parce que TBT isn’t a field metric).
• Lighthouse (Chrome DevTools → Lighthouse panel, or the CLI) — the source of the TBT number and the “Avoid long main-thread tasks” / “Reduce unused JavaScript” audits.
• Chrome DevTools — Performances panel — record a charger and trouver the long tasks (over 50 ms, flagged with red corners) que faire up votre TBT.
• Chrome DevTools — Coverage tab — voir how beaucoup of chaque script is en réalité utilisé, to target unused JavaScript and heavy third parties.
• WebPageTest — lab testing with detailed main-thread and CPU breakdowns.
• Long Animation Frames (LoAF) API — a modern, field-side complement to TBT, pas a replacement pour its lab load-window calculation: it attributes long animation frames à travers a whole visit, qui is closer to how INP problems en réalité surface, plutôt que TBT’s unique FCP-to-TTI charger window.
• Field-side TBT via the Long Tasks API — technically possible (sum duration − 50 ms pour observed long tasks in production, même as the Scripts tab snippet), but Google recommends contre it pour RUM: réel utilisateur interaction timing rend the number aussi variable to comparer run over run. Reach pour INP or LoAF pour field responsiveness à la place.
• Où vous won’t trouver it: Recherche Google Console’s Core Web Vitals report and CrUX carry LCP, INP, and CLS seulement — jamais TBT, regardless of what’s technically possible to compute yourself.

TBT mistakes que produce the incorrect fix

• Appel TBT a Core Web Vital. TBT is a lab diagnostic and utile proxy pour main-thread contention; INP is the real-user Core Web Vital. Report les separately.
• Counting the whole long task as blocking temps. Seulement the portion au-delà 50 milliseconds counts. A 70-millisecond task contributes 20 milliseconds, pas 70.
• Optimizing outside the measurement window. Lighthouse TBT sums blocking entre FCP and TTI. Fonctionner avant or après que window may matter to utilisateurs, but it n’est pas partie of que TBT valeur.
• Removing first-party code pendant que ignoring the largest third party. Utiliser the trace and requête initiators to attribute long tasks avant choosing an owner or fix.
• Splitting code sans reducing fonctionner. Nombreux plus petit tasks peut améliorer responsiveness, but shipping the même unnecessary JavaScript encore costs parsing, compilation, and execution. Supprimer unused fonctionner as bien as yielding it.
• Assuming a bon lab TBT proves bon field INP. Réel utilisateurs interact après charger on varied devices. Confirmer the outcome with field responsiveness données.

TBT is élevé but the network semble fast

Symptom: Resources download quickly, yet Lighthouse reports heavy blocking.

Probable causer: JavaScript parsing, compilation, execution, hydration, or third-party fonctionner monopolizes the principal thread après the bytes arrive.

Fix and confirmation: Record a Performances trace, sort long tasks by duration and owner, alors supprimer unused code, defer noncritical fonctionner, or split the largest task. Confirmer the blocking portion falls in repeated matched runs.

A grand bundle is deferred but TBT stays élevé

Symptom: Ajout defer changements download/execution order sans materially moving TBT.

Probable causer: The même expensive code encore executes à l’intérieur the FCP-to-TTI window.

Fix and confirmation: Profile functions à l’intérieur the long task. Code-split by route or interaction, reduce hydration, or supprimer unused/duplicate fonctionner; alors vérifier que execution temps, pas merely requête commencer temps, declines.

Lighthouse TBT is bon pendant que field INP is poor

Symptom: Navigation lab tests regarder responsive, but CrUX or RUM reports slow interactions.

Probable causer: The problematic task occurs après initial charger or seulement après a réel interaction que standard Lighthouse navigation ne fait pas exercise.

Fix and confirmation: Collect interaction traces pour the poor INP pages and devices, reproduce the action locally, and optimize the event handling and suivant paint.

A long task montre up with aucun clair owner

Symptom: DevTools or a Long Tasks API observer flags a blocking task, but the attribution is blank, generic, or labeled something comme “unknown” / “cross-origin.”

Probable causer: Ce is a connu coverage gap, pas a measurement error. The Long Tasks API’s propre specification bounds ce que it va report à travers execution contexts — cross-origin ancestor tasks are deliberately pas reported (“ce n’est pas reported parce que of security”), and a deeply embedded cross-origin iframe “ne fait pas recevoir quelconque information” à propos de a long task in a cross-origin ancestor. Fonctionner happening in a Web Worker or le navigateur’s compositor thread peut aussi fall outside ce que the attribution surfaces vous.

Fix and confirmation: Don’t conclude “no third party is involved” simplement parce que nothing is named. Cross-check with the Network panel’s initiator column, the Coverage tab, and (où vous contrôler the script) first-party instrumentation à l’intérieur iframes vous propre. Treat an unattributed task as “cause unknown,” pas “cause absent.”

TBT varies sharply entre runs

Symptom: Un run is green and the suivant is poor with aucun deployment.

Probable causer: Variable third-party execution, server timing que changements the fonctionner window, cache state, or test-machine contention.

Fix and confirmation: Match settings, run several cold tests, and comparer the long task owners and median result plutôt que selecting un score.

Turn a trace into an ownership plan

Review this Lighthouse/DevTools trace for Total Blocking Time. For every long task
between FCP and TTI, calculate only duration above 50 ms as blocking time, attribute
the task to first-party code, framework/hydration, or a named third party, and rank
owners by blocking contribution. Propose remove, reduce, defer, split, or yield actions
with a validation test for each. Do not treat TBT as field INP or a direct ranking
factor.

Comparer two performances traces

Compare these before/after traces under matched settings. Report FCP, TBT, the largest
long tasks, their initiators, and whether work moved outside the measurement window or
was actually removed. Flag regressions hidden by the aggregate score. Return a verdict,
confidence limits from the supplied runs, and the next smallest experiment. Do not
invent missing timings.

Examiner a third-party script decision

Given this script's business purpose, loading pattern, request initiator, and main-
thread tasks, decide whether to keep, delay, conditionally load, replace, or remove it.
Separate network cost from execution/blocking cost. Include consent and functionality
constraints, owner, implementation step, TBT validation, field-INP follow-up, and
rollback trigger.

Observe long tasks during a reproduction

Run ce early in DevTools Console, reproduce the charger or interaction, and inspect chaque task’s blocking portion:

let observedBlocking = 0;
const observer = new PerformanceObserver(list => {
  for (const task of list.getEntries()) {
    const blocking = Math.max(0, task.duration - 50);
    observedBlocking += blocking;
    console.log({ start: task.startTime, duration: task.duration, blocking });
  }
  console.log('Observed blocking total:', observedBlocking);
});
observer.observe({ type: 'longtask', buffered: true });

Ce is a debugging total pour the period vous observe, pas Lighthouse’s official TBT unless vous deliberately reproduce the même FCP-to-TTI window and tester conditions.

Flag scripts with the la plupart main-thread evaluation temps

Après recording a DevTools Performances trace, utiliser the Bottom-up view grouped by URL. Pour a rapide network inventory alongside it, ce Console snippet listes transferred JavaScript from largest to smallest:

performance.getEntriesByType('resource')
  .filter(r => r.initiatorType === 'script')
  .map(r => ({ script: r.name, transferred: r.transferSize, duration: r.duration }))
  .sort((a, b) => b.transferred - a.transferred);

Grand transfer size is seulement a lead; the Performances trace is ce que attributes parsing and execution temps to TBT.

Long-task reduction

Tester to run: Capture several matched Lighthouse/Performances traces avant and après the JavaScript modifier and comparer long tasks entre FCP and TTI.

Attendu result: The targeted task disappears, shortens, or yields into plus petit tasks, and median TBT improves sans delaying FCP or breaking functionality.

Échec interpretation: Fonctionner déplacé to un autre bundle/task, encore executes in the même window, or normal run variance is plus grand que the modifier.

Monitoring window: Tester immédiatement in mobile and desktop lab profiles and watch field INP during the suivant reporting window.

Rollback trigger: Roll back si critical interactions break, errors rise, or a repeatable FCP/LCP/INP regression outweighs the TBT improvement.

Third-party deferral

Tester to run: Comparer a cold trace with the third party in its current position and with it delayed jusqu’à consent, idle temps, or the relevant interaction.

Attendu result: Its long tasks leave the initial TBT window pendant que the requis business event encore fires at the intended temps.

Échec interpretation: Un autre loader injects it early, dependent code blocks the page, or the script’s main-thread fonctionner n’est pas the mesuré bottleneck.

Monitoring window: Validate on every template que loads the script and monitor les deux performances and the business event après release.

Rollback trigger: Restore the prior chargement chemin si consent, analytics, checkout, ads, or un autre requis function loses valid events.

Field responsiveness follow-up

Tester to run: Segment field INP pour affected templates/devices après the lab TBT modifier pendant que keeping the deployment date annotated.

Attendu result: Field responsiveness stays stable or improves; a lab-only win is pas reported as a utilisateur outcome jusqu’à field evidence supports it.

Échec interpretation: Réel interaction fonctionner occurs outside initial charger or the optimized cohort is aussi petit to déplacer the aggregate.

Monitoring window: Examiner via the complet field-data reporting window and during high-value interactions.

Rollback trigger: Investigate or roll back si field INP or critical interaction success regresses consistently après the release.

Testez vos connaissances: Total Blocking Temps

Five rapide questions on TBT math and diagnosis. Pick an réponse pour chaque, alors vérifier.

Ressources utiles

Official

• Total Blocking Temps (TBT) — the canonical definition and worked exemple.
• Optimize long tasks — the practical fixing guide (scheduler.yield(), batching, pourquoi pas isInputPending()).
• Web Vitals — où TBT sits relative to the Core Web Vitals.
• Optimizing Web Vitals en utilisant Lighthouse — Addy Osmani; inclut the polyfill-removal worked exemple (TBT 400→300 ms, score 63→70).

From others (vérifier avant quoting)

• DebugBear — Total Blocking Temps — strong technical depth on the TBT↔INP mechanism and the Lighthouse scoring curve.
• NitroPack — Ce que is Total Blocking Temps? — the “task count ≠ blocking time” insight.
• BrowserStack — TBT guide and Catchpoint — TBT — outil/monitoring-oriented overviews.
• web.dev — User-centric performances metrics — Philip Walton’s framework classifying TBT as a lab/load-responsiveness metric vs. field metrics; utile framing pour explaining pourquoi TBT doesn’t apparaître in CrUX.
• web.dev — Getting commencé with measuring Web Vitals — covers how TBT sert as the lab proxy pour INP quand real-user measurement isn’t possible in simulated environments.
• WebPageTest — free lab testing outil que reports TBT alongside detailed main-thread and CPU breakdowns; utile pour diagnosing qui tasks are driving a élevé score.
• Moteur de recherche Journal — Core Web Vitals coverage — ongoing industry reporting on CWV updates, TBT’s role in audits, and how practitioners interpret lab vs. field gaps.

Stats worth citing

• TBT is 30% of the Lighthouse Performances score — the unique largest weight of quelconque metric (LCP and CLS are 25% chaque; FCP and Speed Index 10% chaque). Introduced in Lighthouse 10, live-reverified 2026-07-18 as unchanged via Lighthouse 13. Source
• The “good” bar is ≤200 ms on mobile (≤150 ms desktop); “poor” is >600 ms mobile (>350 ms desktop) — Lighthouse audit docs. Source
• Un polyfill = seven points. Removing a unique Intersection Observer polyfill cut TBT from 400 ms to 300 ms and lifted the Lighthouse Performances score from 63 to 70 — a clean illustration of the 30% weight. Source
• A 250 ms task contributes 200 ms of blocking temps — the blocking portion is toujours duration − 50 ms. Google’s worked exemple totals 345 ms à travers five tasks. Source

Journal des modifications