Total Blocking Temps (TBT)

TL;DR — Total Blocking Temps (TBT) mesure comment long votre page est frozen — unable à respond à a click or tap — pendant que il charge. A lab outil comme Lighthouse ajoute up tout le temps le principal thread est bloqué entre le premier paint et quand lune page becomes interactive. Sous 200 ms est bon. c’est a lab-seulement number, c’est pas a Core Web Vital, et il ne va pas montrer up dans Search Console.

Ce que TBT is

Quand une page charge, le navigateur a un principal thread doing le heavy lifting — running JavaScript, building lune page, reacting à votre clicks. Il peut seulement faire un chose à a temps. Si a chunk de JavaScript hogs que thread pour aussi long, lune page goes momentarily unresponsive: vous tap a button et rien se produit jusqu’à le script finishes.

Total Blocking Temps est a measurement de exactly que frozen temps during charger. A testing outil comme Lighthouse charge votre page dans a controlled environment, watches le principal thread, et ajoute up tout le temps il était bloqué depuis responding à entrée.

The 50ms rule

«Not every bit of work counts. The browser can handle short tasks without you noticing. The line is 50 milliseconds: any task that runs longer than that is a “long task,” and only the part above 50 ms counts as blocking time. » (Traduction) (Résumé en français de la section huit, sous-partie un : le texte source est conservé pour vérification lors de la relecture francophone.)

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. Le three Core Web Vitals sont LCP, INP, et CLS. TBT est a lab outil que aide predict votre Interaction à Suivant Paint (INP) — le real-utilisateur metric Google en réalité utilise. Vous ne va pas trouver TBT dans la recherche Google Console or dans champ données, parce que c’est mesuré par simulating une page charger, pas par watching réel visitors.

Vouloir le complet mechanics — le worked exemple, pourquoi TBT carries le la plupart weight dans Lighthouse, le TBT-vs-INP difference, et comment en réalité corriger il? Switch à le Avancé tab.

TL;DR — TBT est le total amount de temps, entre Premier affichage de contenu et Temps d’interactivité, que le principal thread était bloqué long suffisant à empêcher entrée responsiveness. Il sums le blocking portion (duration − 50 ms) de chaque long task (quelconque main-thread task over 50 ms). c’est a lab metric — le unique largest weight (30%) dans le Lighthouse 10 score et le lab proxy pour INP — mais il est pas a Core Web Vital et jamais apparaît dans CrUX or Search Console. Mobile thresholds: bon ≤200 ms, poor >600 ms. Corriger il comme vous’d corriger INP: break up long JS tasks, code-split, defer/supprimer unused JS, tame tiers scripts. Mon honest prendre: corriger il pour utilisateurs, pas pour a classement bump.

Ce que TBT en réalité measures

Google’s definition est le placer à commencer. TBT est “le total amount de temps après Premier affichage de contenu (FCP) où le principal thread était bloqué pour long suffisant à empêcher entrée responsiveness.” Le navigateur’s principal thread processes un task à a temps; pendant que c’est busy avec a long chunk de fonctionner, il ne peut pas react à a click, a tap, or a keypress. TBT quantifies comment beaucoup de votre page-charger window est spent dans que bloqué state.

Two definitions do tout the fonctionner ici:

• A long task est “a task que exécute on le principal thread pour plus que 50 milliseconds.”
• Le blocking portion de a task est son duration minus 50 ms. Tasks à or sous 50 ms contribute exactly 0 ms.

TBT est le sum de ceux blocking portions entre FCP et Temps d’interactivité (TTI). Donc Premier affichage de contenu est le commencer line: rien avant le premier paint counts, parce que il y a rien on screen à interact avec yet.

The worked exemple

Google’s propre tableau est le clearest illustration. Imagine five tasks exécuter on le principal thread entre FCP et TTI:

Tasks three et four sont sous le 50 ms line, donc ils contribute rien. Task un bloque pour 250 − 50 = 200 ms, task five pour 155 − 50 = 105 ms. Ajouter le blocking portions — 200 + 40 + 0 + 0 + 105 — et vous obtenir 345 ms de TBT. c’est a “needs improvement” score, driven presque entirely par deux heavy tasks.

Ce est le counter-intuitive partie worth internalizing: “A petit number de tasks on le principal thread ne fait pas necessarily signifier faible blocking temps. Conversely, a grand number de tasks ne fait pas necessarily lead à tons de blocking temps.” (Que framing est NitroPack’s, relayed ici — reverified contre le actif source 2026-07-18.) Ce que matters est si individual tasks cross 50 ms, pas comment nombreux tasks là sont.

Le measurement window: FCP à TTI

Le window ends à Temps d’interactivité — “le temps depuis quand lune page commence chargement à quand son principal sub-resources ont chargé et il est capable de reliably responding à utilisateur entrée quickly.” Dans Lighthouse, TTI est trouvé par searching forward pour a five-deuxième “quiet window” avec aucun long tasks et aucun plus que deux dans-flight network requêtes.

Worth noting: TTI itself était supprimé depuis Lighthouse 10 parce que il proved overly sensitive à outlier network requêtes et long tasks, producing élevé variability. TBT survived et became le principal interactivity metric. As Philip Walton put il, “Newer, alternative, metrics comme Plus grand affichage de contenu (LCP), Total Blocking Temps (TBT), et Interaction jusqu’au prochain affichage (INP) sont généralement meilleur metrics à utiliser dans placer de TTI.” TBT n’a pas remplacer TTI as le window’s endpoint — c’est a meilleur unique number pour le même underlying problème. Et TTI’s disappearance depuis le Lighthouse rapport UI n’est pas le même claim as TTI ne … plus bounding Lighthouse’s par défaut navigation window — le window itself est encore mesuré que façon sous le hood.

Un plus scoping remarque: “FCP à TTI” décrit Lighthouse’s par défaut navigation audit précisément. Autre outils, or Lighthouse itself running a timespan trace au lieu de a complet page-charger navigation, peut total a différent mesuré window — le 50 ms long-task math ne fait pas modifier, mais le commencer et fin points de ce que obtient summed sont outil- et trace-mode-spécifique, pas a universal law de le metric.

Is TBT a Core Web Vital? Aucun.

Ce est le la plupart courant misconception, donc let’s être blunt à propos de il. Le three Core Web Vitals sont LCP, INP, et CLS. TBT n’est pas un de les. Google’s propre wording: “Total Blocking Temps (TBT) est a lab metrics est vital dans catching et diagnosing potential interactivity problèmes que peut impact INP. Cependant, il n’est pas partie de le Core Web Vitals définir parce que ils ne sont pas champ-measurable, nor faire ils reflect a utilisateur-centric résultat.” (Le grammar dans que sentence est theirs, pas mine.)

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

• Où vous voir il: Lighthouse, PageSpeed Insights’ lab tab, et Chrome DevTools — tout simulated/lab environments.
• Où vous ne pas: Recherche Google Console’s Core Web Vitals rapport, CrUX, or quelconque champ données. Ceux seulement carry LCP, INP, et 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.

«One correction worth being precise about: TBT being lab-recommended isn’t the same as TBT being field-impossible. You can technically compute a TBT-style total in the field with the Long Tasks API — Google says so directly: “It is possible to measure TBT in the field, but we don’t recommend this as user interaction can affect your page’s TBT in ways that lead to lots of variance in your reports.” That’s a recommendation against it, not a technical wall. What’s actually true without exception is narrower: CrUX and Search Console’s Core Web Vitals report never carry TBT, full stop — those pipelines only ever collect LCP, INP, and CLS. » (Traduction) (Résumé en français de la section trente-huit, sous-partie un : le texte source est conservé pour vérification lors de la relecture francophone.)

TBT is the lab proxy pour INP

Ici’s pourquoi TBT exists à tout. Lab outils charger une page dans a simulated environment avec aucun réel utilisateur, donc ils ne peut pas mesurer Interaction jusqu’au prochain affichage — INP nécessite réel clicks et taps. TBT fills que gap: “le Total Blocking Temps (TBT) metric est lab-measurable et est a proxy pour INP.”

Le deux sont mechanically connexe: “Although INP et TBT sont calculated differently, ils sont les deux reflections de a bloqué principal thread during le bootstrap traiter. Quand le principal thread est bloqué, le navigateur est delayed dans responding à utilisateur interactions.” Et empirically, “A faible TBT souvent correlates avec a faible Interaction à 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 mesure blocking during charger. Si votre utilisateurs ne pas en réalité essayer à interact during que bloqué window — ils wait pour lune page à regarder finished premier — leur INP peut être fine même avec an ugly TBT.
• Fine TBT, poor INP. INP aussi covers lent event handlers et rendu fonctionner que fire après charger, plus choses comme le navigateur’s 300 ms tap delay on non-mobile-optimized pages — none de qui TBT voit.

Quand le lab et champ disagree, confiance le champ. INP (le real-utilisateur number) takes priority over TBT (le lab estimate).

Un historical remarque que trips personnes up: TBT utilisé à être le lab proxy pour Premier Entrée Delay (FID). INP replaced FID as a Core Web Vital on March 12, 2024, donc TBT est maintenant INP’s proxy. Le underlying mechanism jamais modifié — c’est toujours été à propos de a bloqué principal thread during charger — mais quelconque older article appel TBT “FID’s proxy” predates que switch.

Pourquoi TBT dominates le Lighthouse score

TBT carries le largest unique weight dans le Lighthouse Performances score — 30%, a weighting introduced dans Lighthouse 10 et, verified actif contre Chrome’s scoring docs on 2026-07-18, encore unchanged via le actuel Lighthouse 13:

Treat que tableau as version-et-date-scoped, pas a permanent constant — Lighthouse a modifié son weights avant et peut à nouveau. Re-vérifier contre Lighthouse performances scoring avant quoting il dans an audit deck.

Ce est le practical raison TBT matters pour le SEO audits même though il n’est pas a classement signal: a poor TBT a an outsized effect on que big Lighthouse number everyone screenshots. Addy Osmani’s worked exemple rend il concrete — removing un Intersection Observer polyfill cut TBT depuis 400 ms à 300 ms et lifted le Lighthouse Performances score depuis 63 à 70. Un corriger, seven points, parce que de le 30% weight.

Un plus nuance: le “Bon ≤200 ms” category threshold et le Lighthouse score sont différent scales. À score 90+ on le TBT subscore vous besoin roughly ≤300 ms on mobile, et à hit 100 vous besoin ≤100 ms. (Ceux subscore figures sont DebugBear’s documentation de le scoring curve, reverified contre le actif source 2026-07-18.) “Bon” et “100” ne sont pas le 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 classement signal. Google’s interactivity classement entrée est INP, a champ metric. TBT est a diagnostic que aide vous trouver et corriger le long tasks que hurt INP. Improving TBT peut améliorer INP, qui pourrait marginally aider lune page Experience side de rankings — mais c’est deux liens de “peut” away depuis votre positions.

Et ici’s mon réel position on le entier Core Web Vitals question, qui j’ai written avant dans mon vitesse de page guide: Je ne pas think Core Web Vitals ont beaucoup impact on SEO, et unless vous êtes extremely lent Je généralement ne va pas prioritize les. Faire les pour utilisateurs et conversions, pas pour a classement bump. Que s’applique doubly à TBT, qui est a lab proxy pour a champ metric pour a petit classement entrée. Corriger il parce que a frozen page loses vous clients — pas parce que vous êtes chasing a position.

Ce que causes élevé TBT

It’s almost toujours JavaScript:

• Unnecessary JavaScript chargement, parsing, or execution — le Lighthouse audit’s propre words. Shipping a big bundle lune page ne fait pas besoin à charger est le classic causer.
• Inefficient JavaScript statements — heavy synchronous fonctionner que monopolizes le principal thread.
• Tiers scripts — balise managers, chat widgets, analytics, ad scripts. Souvent le unique biggest contributor, et le un vous contrôler le moins.
• Heavy framework bootstrap — React hydration et similaire peut exécuter long tasks during startup.
• Style/layout recalculation et garbage collection — forced synchronous layout, grand style recalcs, et GC pauses montrer up as main-thread tasks aussi; ne pas assume chaque long task dans le trace est JavaScript execution.

ne pas assume bundle transfer size est le entier story, soit. Trace attribution a réel gaps: cross-origin frames et worker threads ont privacy et security limites on ce que a long-task observer peut rapport à propos de les (voir Troubleshooting), donc an unattributed task dans votre trace n’est pas proof aucun tiers est involved — il peut simplement signifier le attribution API n’est pas allowed à tell vous.

Comment corriger élevé TBT

Le corrections sont le même family as le INP corrections — les deux come bas à a bloqué principal thread.

1. Trouver le long tasks. Ouvrir le Chrome DevTools Performances panel et regarder pour tasks over 50 ms (ils sont flagged avec red corners), or exécuter le Lighthouse “Avoid long main-thread tasks” audit.
2. Audit tiers scripts premier. ils sont généralement le easiest wins. Utiliser le DevTools Coverage et Network tabs à voir ce que chaque script coûts, et lazy-charger heavy embeds (YouTube, maps, chat) behind a facade.
3. Break up le long tasks. Yield à le principal thread donc le navigateur peut handle entrée entre chunks — “quand tasks sont broken up, le navigateur peut respond à higher-priority fonctionner beaucoup sooner—notamment utilisateur interactions.” Le modern API est scheduler.yield(), avec a setTimeout(resolve, 0) fallback (voir le Cheat Sheets tab pour le modèle). Remarque que Google ne … plus recommends isInputPending() — yield regardless de si entrée est pending.
4. Reduce le JavaScript. Code-split grand bundles donc moins parses et evaluates à charger, supprimer unused JS (DevTools Coverage tab montre vous ce que), et defer non-critical scripts.
5. Déplacer heavy computation off le principal thread. Web Workers exécuter CPU-heavy fonctionner on a séparé thread, leaving le principal thread gratuit à 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 dans le Core Web Vitals family alongside son champ counterpart Interaction jusqu’au prochain affichage, le chargement metrics Plus grand affichage de contenu et Premier affichage de contenu, et le lab outils Lighthouse, PageSpeed Insights, et Speed Indexer que rapport les. Si vous seulement remember un chose: TBT est le lab warning light pour champ responsiveness — chase le long tasks, pas le number.

AI summary

A condensed prendre on the Avancé version:

• TBT = bloqué main-thread temps during charger. c’est le total temps, entre FCP et TTI, le principal thread était bloqué long suffisant à empêcher entrée responsiveness.
• Le math: sum de le blocking portion (duration − 50 ms) de chaque long task (quelconque main-thread task over 50 ms). Tasks ≤50 ms ajouter 0 ms. Google’s worked exemple: tasks de 250/90/35/30/155 ms → 345 ms TBT.
• c’est a lab metric. Vous voir il dans Lighthouse, PageSpeed Insights’ lab tab, et DevTools — jamais dans CrUX or Search Console.
• Pas a Core Web Vital. Le three CWV sont LCP, INP, CLS. TBT est le lab proxy pour INP (historically FID’s proxy; INP replaced FID on March 12, 2024).
• Biggest Lighthouse weight: 30% — le unique largest, donc a poor TBT tanks le overall score. Mobile thresholds: bon ≤200 ms, nécessite improvement ≤600 ms, poor

  600 ms.

• Rankings: pas a direct facteur de classement. INP est le champ signal; TBT seulement aide diagnose il. Patrick’s prendre: corriger il pour utilisateurs et conversions, pas pour a classement bump.
• Corrections (même family as INP): trouver long tasks dans DevTools, audit tiers scripts premier, break up tasks avec scheduler.yield(), code-split et supprimer unused JS, offload heavy fonctionner à Web Workers.
• Caveat: TBT et INP peut diverge — élevé TBT avec fine INP (utilisateurs ne pas interact during charger) or fine TBT avec poor INP (lent event handlers après charger). Champ données wins.
• “Lab-seulement” signifie lab-recommended, pas lab-impossible. Vous pouvez technically compute a TBT-style total depuis champ données avec le Long Tasks API, mais Google advises contre il (aussi beaucoup exécuter-à-exécuter variance) — CrUX et Search Console simplement jamais carry il soit façon.
• Trace attribution a réel gaps. Cross-origin frames et worker threads ont privacy/security limites on ce que a long-task observer peut rapport, donc an unattributed task signifie “cause unknown,” pas “no third party involved.”

Documentation officielle

Primary-source documentation on TBT depuis Google et le Chrome team.

«web.dev / Chrome » (Traduction) (Résumé en français de la section soixante-quinze, sous-partie un : le texte source est conservé pour vérification lors de la relecture francophone.) «- Total Blocking Time (TBT) — Philip Walton & Barry Pollard: the canonical definition, the 50 ms long-task rule, and the worked example. » (Traduction) (Résumé en français de la section soixante-quinze, sous-partie deux : le texte source est conservé pour vérification lors de la relecture francophone.) «- TBT Lighthouse audit — the audit page, with the mobile/desktop scoring thresholds and cited causes. » (Traduction) (Résumé en français de la section soixante-quinze, sous-partie trois : le texte source est conservé pour vérification lors de la relecture francophone.) «- Lighthouse performance scoring — the metric weights, where TBT’s 30% comes from. » (Traduction) (Résumé en français de la section soixante-quinze, sous-partie quatre : le texte source est conservé pour vérification lors de la relecture francophone.) «- Web Vitals — why TBT is not a Core Web Vital and how it relates to the set. » (Traduction) (Résumé en français de la section soixante-quinze, sous-partie cinq : le texte source est conservé pour vérification lors de la relecture francophone.) «- Interaction to Next Paint (INP) — the field metric TBT proxies, and the “proxy, not substitute” caveat. » (Traduction) (Résumé en français de la section soixante-quinze, sous-partie six : le texte source est conservé pour vérification lors de la relecture francophone.) «- Optimize long tasks — Jeremy Wagner & Brendan Kenny on breaking up tasks, scheduler.yield(), and why isInputPending() is no longer recommended. » (Traduction) (Résumé en français de la section soixante-quinze, sous-partie sept : le texte source est conservé pour vérification lors de la relecture francophone.) «- Time to Interactive (TTI) — the metric that defines the end of the TBT window, and why it was removed from Lighthouse 10. » (Traduction) (Résumé en français de la section soixante-quinze, sous-partie huit : le texte source est conservé pour vérification lors de la relecture francophone.) «- Lab and field data differences — the limits of TBT as an INP stand-in. » (Traduction) (Résumé en français de la section soixante-quinze, sous-partie neuf : le texte source est conservé pour vérification lors de la relecture francophone.)

«## Quotes from the source » (Traduction) (Résumé en français de la section soixante-dix-huit, sous-partie un : le texte source est conservé pour vérification lors de la relecture francophone.)

«On-the-record statements from Google’s documentation. Each link is a deep link that jumps to the quoted passage. » (Traduction) (Résumé en français de la section soixante-dix-neuf, sous-partie un : le texte source est conservé pour vérification lors de la relecture francophone.)

«Definition and mechanics » (Traduction) (Résumé en français de la section quatre-vingts, sous-partie un : le texte source est conservé pour vérification lors de la relecture francophone.)

«- “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 Time. Jump to quote » (Traduction) (Résumé en français de la section quatre-vingt-un, sous-partie un : le texte source est conservé pour vérification lors de la relecture francophone.) «- “a task that runs on the main thread for more than 50 milliseconds” — the definition of a long task. Jump to quote » (Traduction) (Résumé en français de la section quatre-vingt-un, sous-partie deux : le texte source est conservé pour vérification lors de la relecture francophone.) «- “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 » (Traduction) (Résumé en français de la section quatre-vingt-un, sous-partie trois : le texte source est conservé pour vérification lors de la relecture francophone.) «- “A low TBT often correlates with a low Interaction to Next Paint (INP).” Jump to quote » (Traduction) (Résumé en français de la section quatre-vingt-un, sous-partie quatre : le texte source est conservé pour vérification lors de la relecture francophone.)

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 » (Traduction) (Résumé en français de la section quatre-vingt-trois, sous-partie un : le texte source est conservé pour vérification lors de la relecture francophone.)

TBT as le 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 to Next Paint. Jump to quote » (Traduction) (Résumé en français de la section quatre-vingt-cinq, sous-partie un : le texte source est conservé pour vérification lors de la relecture francophone.)

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 » (Traduction) (Résumé en français de la section quatre-vingt-sept, sous-partie un : le texte source est conservé pour vérification lors de la relecture francophone.) «- “When tasks are broken up, the browser can respond to higher-priority work much sooner—including user interactions.” Jump to quote » (Traduction) (Résumé en français de la section quatre-vingt-sept, sous-partie deux : le texte source est conservé pour vérification lors de la relecture francophone.) «- On isInputPending(): “We no longer recommend using this API, and instead recommend yielding regardless of whether input is pending or not.” Jump to quote » (Traduction) (Résumé en français de la section quatre-vingt-sept, sous-partie trois : le texte source est conservé pour vérification lors de la relecture francophone.)

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, Time to Interactive (Philip Walton). Jump to quote » (Traduction) (Résumé en français de la section quatre-vingt-neuf, sous-partie un : le texte source est conservé pour vérification lors de la relecture francophone.)

TBT triage checklist

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

• Confirmer vous êtes reading lab données — TBT est dans Lighthouse / PageSpeed Insights’ lab tab / DevTools, pas le champ or Search Console.
• Ouvrir le DevTools Performances panel et trouver le long tasks (over 50 ms, red-cornered) entre premier paint et interactive.
• Liste votre tiers scripts et ce que chaque coûts (Coverage + Network tabs) — commencer ici; c’est généralement le biggest, easiest win.
• Lazy-charger heavy embeds (YouTube, maps, chat) behind a facade.
• Exécuter le Lighthouse “Avoid long main-thread tasks” et “Reduce unused JavaScript” audits et fonctionner le liste.
• Code-split grand bundles donc moins JS parses/evaluates à charger.
• Defer non-critical scripts; dynamic-import() ce que n’est pas nécessaire immédiatement.
• Break up remaining long tasks avec scheduler.yield() (setTimeout fallback). ne pas reach pour isInputPending().
• Déplacer CPU-heavy computation à a Web Worker.
• Cross-vérifier le champ: pull INP depuis CrUX / real-utilisateur monitoring. Si INP est fine, ne pas over-invest dans chasing le lab number.

«## TBT cheat sheet » (Traduction) (Résumé en français de la section quatre-vingt-dix-huit, sous-partie un : le texte source est conservé pour vérification lors de la relecture francophone.)

«The math, in one line » (Traduction) (Résumé en français de la section quatre-vingt-dix-neuf, sous-partie un : le texte source est conservé pour vérification lors de la relecture francophone.)

«TBT = Σ (taskDuration − 50 ms) for every task > 50 ms between FCP and TTI. Tasks ≤ 50 ms contribute 0 ms. » (Traduction) (Résumé en français de la section cent, sous-partie un : le texte source est conservé pour vérification lors de la relecture francophone.)

Worked exemple (Google’s)

Lighthouse thresholds

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

«TBT vs. INP — the cheat sheet » (Traduction) (Résumé en français de la section cent six, sous-partie un : le texte source est conservé pour vérification lors de la relecture francophone.)

«| | TBT | INP | | --- | --- | --- | | Type | Lab | Field | | Core Web Vital? | No | Yes | | Measures | Main-thread blocking during load | Real interaction latency across the whole visit | | Window | FCP → TTI | Every click/tap/key, at the 75th percentile | | Seen in | Lighthouse, PSI lab, DevTools | CrUX, Search Console, RUM | | Ranking signal? | No | Yes (Page Experience) | | Relationship | Lab proxy for INP (was FID’s proxy pre-2024) | The thing TBT estimates | » (Traduction) (Résumé en français de la section cent sept, sous-partie un : le texte source est conservé pour vérification lors de la relecture francophone.)

«Yield-to-main pattern (the fix) » (Traduction) (Résumé en français de la section cent huit, sous-partie un : le texte source est conservé pour vérification lors de la relecture francophone.)

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.

«## Tools for measuring and fixing TBT » (Traduction) (Résumé en français de la section cent treize, sous-partie un : le texte source est conservé pour vérification lors de la relecture francophone.)

«- PageSpeed Insights — read TBT in the lab data section (it’s not in the field-data section, because TBT isn’t a field metric). » (Traduction) (Résumé en français de la section cent quatorze, sous-partie un : le texte source est conservé pour vérification lors de la relecture francophone.) «- 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. » (Traduction) (Résumé en français de la section cent quatorze, sous-partie deux : le texte source est conservé pour vérification lors de la relecture francophone.) «- Chrome DevTools — Performance panel — record a load and find the long tasks (over 50 ms, flagged with red corners) that make up your TBT. » (Traduction) (Résumé en français de la section cent quatorze, sous-partie trois : le texte source est conservé pour vérification lors de la relecture francophone.) «- Chrome DevTools — Coverage tab — see how much of each script is actually used, to target unused JavaScript and heavy third parties. » (Traduction) (Résumé en français de la section cent quatorze, sous-partie quatre : le texte source est conservé pour vérification lors de la relecture francophone.) «- WebPageTest — lab testing with detailed main-thread and CPU breakdowns. » (Traduction) (Résumé en français de la section cent quatorze, sous-partie cinq : le texte source est conservé pour vérification lors de la relecture francophone.) «- Long Animation Frames (LoAF) API — a modern, field-side complement to TBT, not a replacement for its lab load-window calculation: it attributes long animation frames across a whole visit, which is closer to how INP problems actually surface, rather than TBT’s single FCP-to-TTI load window. » (Traduction) (Résumé en français de la section cent quatorze, sous-partie six : le texte source est conservé pour vérification lors de la relecture francophone.) «- Field-side TBT via the Long Tasks API — technically possible (sum duration − 50 ms for observed long tasks in production, same as the Scripts tab snippet), but Google recommends against it for RUM: real user interaction timing makes the number too variable to compare run over run. Reach for INP or LoAF for field responsiveness instead. » (Traduction) (Résumé en français de la section cent quatorze, sous-partie sept : le texte source est conservé pour vérification lors de la relecture francophone.) «- Where you won’t find it: Google Search Console’s Core Web Vitals report and CrUX carry LCP, INP, and CLS only — never TBT, regardless of what’s technically possible to compute yourself. » (Traduction) (Résumé en français de la section cent quatorze, sous-partie huit : le texte source est conservé pour vérification lors de la relecture francophone.)

TBT mistakes que produce the incorrect fix

• Appel TBT a Core Web Vital. TBT est a lab diagnostic et utile proxy pour main-thread contention; INP est le real-utilisateur Core Web Vital. Rapport les séparément.
• Counting le entier long task as blocking temps. Seulement le portion au-delà 50 milliseconds counts. A 70-millisecond task contributes 20 milliseconds, pas 70.
• Optimizing à l’extérieur le measurement window. Lighthouse TBT sums blocking entre FCP et TTI. Fonctionner avant or après que window peut matter à utilisateurs, mais il n’est pas partie de que TBT valeur.
• Removing premier-party code pendant que ignoring le largest tiers. Utiliser le trace et requête initiators à attribut long tasks avant choosing an owner or corriger.
• Splitting code sans reducing fonctionner. Nombreux plus petit tasks peut améliorer responsiveness, mais shipping le même unnecessary JavaScript encore coûts parsing, compilation, et execution. Supprimer unused fonctionner as bien as yielding il.
• Assuming a bon lab TBT proves bon champ INP. Réel utilisateurs interact après charger on varied devices. Confirmer le résultat avec champ responsiveness données.

TBT is élevé but the network semble fast

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

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

Corriger et confirmation: Record a Performances trace, sort long tasks par duration et owner, alors supprimer unused code, defer noncritical fonctionner, or split le largest task. Confirmer le blocking portion falls dans repeated matched exécute.

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.

Corriger et confirmation: Profile functions à l’intérieur le long task. Code-split par 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.

Corriger et confirmation: Collect interaction traces pour le poor INP pages et devices, reproduce le action locally, et optimize le event handling et suivant paint.

A long task montre up with aucun clair owner

Symptom: DevTools or a Long Tasks API observer flags a blocking task, mais le attribution est blank, générique, or labeled quelque chose comme “unknown” / “cross-origin.”

«Likely cause: This is a known coverage gap, not a measurement error. The Long Tasks API’s own specification bounds what it will report across execution contexts — cross-origin ancestor tasks are deliberately not reported (“this is not reported because of security”), and a deeply embedded cross-origin iframe “does not receive any information” about a long task in a cross-origin ancestor. Work happening in a Web Worker or the browser’s compositor thread can also fall outside what the attribution surfaces you. » (Traduction) (Résumé en français de la section cent trente-cinq, sous-partie un : le texte source est conservé pour vérification lors de la relecture francophone.)

Corriger et confirmation: ne pas conclude “no third party is involved” simplement parce que rien est named. Cross-vérifier avec le Network panel’s initiator column, le Coverage tab, et (où vous contrôler le script) premier-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 exécuter est green et le suivant est poor avec aucun deployment.

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

Corriger et confirmation: Match paramètres, exécuter plusieurs cold tests, et comparer le long task owners et median résultat plutôt que selecting un score.

Turn a trace dans 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 » (Traduction) (Résumé en français de la section cent cinquante et un, sous-partie un : le texte source est conservé pour vérification lors de la relecture francophone.)

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 });

«This is a debugging total for the period you observe, not Lighthouse’s official TBT unless you deliberately reproduce the same FCP-to-TTI window and test conditions. » (Traduction) (Résumé en français de la section cent cinquante-quatre, sous-partie un : le texte source est conservé pour vérification lors de la relecture francophone.)

«## Flag scripts with the most main-thread evaluation time » (Traduction) (Résumé en français de la section cent cinquante-cinq, sous-partie un : le texte source est conservé pour vérification lors de la relecture francophone.)

«After recording a DevTools Performance trace, use the Bottom-up view grouped by URL. For a quick network inventory alongside it, this Console snippet lists transferred JavaScript from largest to smallest: » (Traduction) (Résumé en français de la section cent cinquante-six, sous-partie un : le texte source est conservé pour vérification lors de la relecture francophone.)

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 est seulement a lead; le Performances trace est ce que attributs parsing et execution temps à TBT.

Long-task reduction

Tester à exécuter: Capture plusieurs matched Lighthouse/Performances traces avant et après le JavaScript modifier et comparer long tasks entre FCP et TTI.

Attendu résultat: Le targeted task disappears, shortens, or yields dans plus petit tasks, et median TBT améliore sans delaying FCP or breaking functionality.

Échec interpretation: Fonctionner déplacé à un autre bundle/task, encore executes dans le même window, or normal exécuter variance est plus grand que le modifier.

Monitoring window: Tester immédiatement dans mobile et desktop lab profiles et watch champ INP during le suivant reporting window.

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

Third-party deferral

Tester à exécuter: Comparer a cold trace avec le tiers dans son actuel position et avec il delayed jusqu’à consent, idle temps, or le pertinent interaction.

Attendu résultat: Son long tasks laisser le initial TBT window pendant que le requis entreprise event encore fires à le prévu temps.

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

Monitoring window: Valider on chaque template que charge le script et monitor les deux performances et le entreprise event après release.

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

Field responsiveness follow-up

Tester à exécuter: Segment champ INP pour affected templates/devices après le lab TBT modifier pendant que keeping le 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 le complet champ-données reporting window et during élevé-valeur 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 et diagnosis. Pick an réponse pour chaque, alors vérifier.

Ressources utiles

Official

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

Depuis others (vérifier avant quoting)

• DebugBear — Total Blocking Temps — strong technique depth on le TBT↔INP mechanism et le Lighthouse scoring curve.
• NitroPack — Ce que est Total Blocking Temps? — le “task count ≠ blocking time” insight.
• BrowserStack — TBT guide et Catchpoint — TBT — outil/monitoring-oriented overviews.
• web.dev — Utilisateur-centric performances metrics — Philip Walton’s framework classifying TBT as a lab/charger-responsiveness metric vs. champ metrics; utile framing pour explaining pourquoi TBT ne fait pas apparaître dans CrUX.
• web.dev — Getting commencé avec measuring Web Vitals — covers comment TBT sert as le lab proxy pour INP quand real-utilisateur measurement n’est pas possible dans simulated environments.
• WebPageTest — gratuit lab testing outil que rapports TBT alongside detailed main-thread et CPU breakdowns; utile pour diagnosing qui tasks sont driving a élevé score.
• Moteur de recherche Journal — Core Web Vitals coverage — ongoing industry reporting on CWV mises à jour, TBT’s role dans audits, et comment practitioners interpret lab vs. champ gaps.

Stats worth citing

• TBT est 30% de le Lighthouse Performances score — le unique largest weight de quelconque metric (LCP et CLS sont 25% chaque; FCP et Speed Indexer 10% chaque). Introduced dans Lighthouse 10, actif-reverified 2026-07-18 as unchanged via Lighthouse 13. Source
• Le “bon” bar est ≤200 ms on mobile (≤150 ms desktop); “poor” est >600 ms mobile (>350 ms desktop) — Lighthouse audit docs. Source
• Un polyfill = seven points. Removing a unique Intersection Observer polyfill cut TBT depuis 400 ms à 300 ms et lifted le Lighthouse Performances score depuis 63 à 70 — a clean illustration de le 30% weight. Source
• A 250 ms task contributes 200 ms de blocking temps — le blocking portion est toujours duration − 50 ms. Google’s worked exemple totals 345 ms à travers five tasks. Source

Journal des modifications