TBT (Total Blocking Time) Nedir?
Kısa tanım
TBT (Total Blocking Time), sayfada ilk içerik çizildikten (FCP) sonra ana iş parçacığının kullanıcı girdisine yanıt veremeyecek kadar meşgul kaldığı toplam süreyi ölçen bir laboratuvar metriğidir. 50 milisaniyeyi aşan her uzun görevin bu sınırın üstündeki kısmı toplanır. Gerçek kullanıcı etkileşimi gerektiren INP'nin laboratuvardaki yaklaşık göstergesi olarak kullanılır.
Diğer adları: Total Blocking Time, toplam engelleme süresi
Hesap: yalnızca 50 milisaniyenin üstü sayılır
Tarayıcının ana iş parçacığı (main thread) JavaScript çalıştırırken, stilleri hesaplarken ya da yerleşimi kurarken başka bir işe bakamaz. 50 ms'yi aşan her görev uzun görev sayılır ve bu sürenin 50 ms'nin üstünde kalan kısmı "engelleme süresi" olarak kabul edilir. TBT, FCP ile Time to Interactive (TTI) arasındaki tüm bu engelleme sürelerinin toplamıdır.
| Görev süresi | Engelleme payı |
|---|---|
| 250 ms | 200 ms |
| 90 ms | 40 ms |
| 35 ms | 0 ms |
| 30 ms | 0 ms |
| 155 ms | 105 ms |
| Toplam | TBT = 345 ms |
Bu örnekte ana iş parçacığı toplam 560 ms meşgul kalmış ama TBT 345 ms çıkmıştır. Kısa görevler, aralarına kullanıcı girdisi sıkıştırılabildiği için cezalandırılmaz. Aynı toplam süreyi tek bir dev görev yerine çok sayıda küçük göreve bölmek, bu yüzden TBT'yi doğrudan düşürür.
Neden sahada değil laboratuvarda?
TBT'nin sonucu, kullanıcının sayfayla ne zaman etkileşime geçtiğine bağlı değildir; sabit bir senaryoda ölçülür. Sahada bu yaklaşım çok fazla değişkenlik üretir, çünkü gerçek kullanıcılar sayfa yüklenirken farklı anlarda tıklar. Gerçek deneyim için Core Web Vitals metriği INP kullanılır. İkisi arasındaki ilişki şöyle özetlenebilir: düşük TBT çoğu zaman düşük INP ile birlikte görülür, ama TBT yalnızca yükleme aşamasına bakar. Sayfa açıldıktan sonra bir filtre menüsüne tıklandığında yaşanan yavaşlık TBT'de hiç görünmeyebilir, INP'de ise görünür.
Lighthouse'taki ağırlığı ve eşikler
Lighthouse performans puanında TBT %30 ile en yüksek ağırlığa sahip metriktir; JavaScript'i ağır bir sayfanın puanının neden bu kadar düştüğünü genellikle bu açıklar.
| Cihaz | Hızlı (yeşil) | Orta (turuncu) | Yavaş (kırmızı) |
|---|---|---|---|
| Mobil | 0–200 ms | 200–600 ms | > 600 ms |
| Masaüstü | 0–150 ms | 150–350 ms | > 350 ms |
web.dev'in hedefi, ortalama mobil donanımda test edildiğinde 200 ms'nin altında kalmaktır. Laboratuvar testinin işlemciyi yavaşlattığını unutmayın: geliştiricinin güçlü bilgisayarında akıcı görünen bir sayfa, mobil simülasyonda yüzlerce milisaniyelik TBT üretebilir.
TBT'yi düşüren müdahaleler
- Daha az JavaScript göndermek: Sayfada kullanılmayan kodu ayırmak için code splitting, ölü kodu atmak için tree shaking.
- Uzun görevleri bölmek: Büyük döngüleri parçalara ayırıp aralarda ana iş parçacığını serbest bırakmak.
- Hydration maliyetini azaltmak: Sunucuda render edilen sayfalarda tüm arayüzün tek seferde hydration sürecinden geçmesi büyük bir uzun görev yaratabilir; etkileşimsiz bölümleri istemciye hiç göndermemek bu yükü azaltır.
- Üçüncü taraf script'leri ertelemek: Sohbet widget'ları, reklam ve etiket kodlarını
deferile ya da kullanıcı etkileşiminden sonra yüklemek.
Hangi script'in sorumlu olduğunu bulmak için Chrome DevTools'un Performance panelinde kırmızı köşeli uzun görevlere bakmak en hızlı yoldur.