Total Blocking Time (TBT) Nedir? Nasıl Optimize Edilir?

Total blocking time (TBT), Tarayıcının site ile alakalı oluşturma süreçlerinin 50 ms den uzun tasklar tarafından engellenme sürelerinin ölçümlendiği metriğe verilen isimdir. 

Özellikle Google’ın web dev blog içerisinde açıkladığı şekilde; Total Blocking Time (Toplam Engellenme Süresi – TBT) metriği, FCP yani anlamlı ilk içerik boyaması ile Time to interactive (TTI) kullanıcının sayfa ile etkileşime geçebileceği süre arasındaki tarayıcının işleme süreçlerinin ne kadar süre ile engellendiğini ölçümleyen metriktir.

Uzun tasklar (long task), tarayıcının sayfayı oluşturma, işleme süreçleri içerisinde 50 ms den uzun sürecek şekilde tarayıcıyı domine eden javascript kodlarına verilen isimdir.

Google’ın hızlı bir web sayfası için önerdiği maksimum javascript kod işleme süresi 50 ms yani 0.05 saniyedir çünkü bunun üzerine çıkan javascript kod işleme süreçleri, tarayıcının kullanıcının gözlemleyebildiği tarafta task bitene kadar işlevsiz bir şekilde kalmasına sebebiyet verecektir. Standart olarak herhangi bir task’ın işleme süreci içerisinde kullanıcıya sayfa ile alakalı herhangi farklı bir oluşturma işlemi yansıtılmaz ve tarayıcı task’ı işlemeyi bitirmeden oluşturma ile alakalı farklı bir işlemi hayata geçiremez.

Bu sebeple aşağıda biraz daha detaylandıracağımız şekilde Total Blocking Time (toplam engellenme süresi) doğrudan ve dolaylı olarak time to interactive ile yakından ilişkilidir.

Üstteki görselde tarayıcının ana iş parçacığının zaman çizelgesi olarak herhangi x bir sayfanın oluşturma süreci içerisinde işleme alınan 5 adet örnek task ve bu taskların işleme süreçleri gösterilmektedir.

Örneğin işleme süreci içerisinde ilk işleme alınan task 250 ms işleme süreci ile normalin çok çok üzerinde bir task dır. 50 ms’in üzerinde kalan 200 ms lik süre total blocking time metriğinin bir parçasıdır. Oluşturma süreci içerisinde normal bir delay (geçikme) süreci olan 50 ms süresinden hariç olarak buradaki ekstra 200 ms tarayıcının oluşturma sürecine 0.2 saniyelik bir geçikme olarak yansıyacaktır.

Buna ek olarak devamında gelen tasklar içerisinde de 35 ve 30 ms lik ideal işleme sürelerine sahip olan tasklar olduğu gibi 250 ms e yakın 90 ve 155 lik işleme süreçlerine sahip olan farklı tasklar da mevcuttur. Yine bu tasklardaki 50 ms’in üzerinde kalan süre farkları da total blocking time metriğinin içerisinde dahil edilecektir.

Üstteki görselde yer alan tasklar üzerinden ilerlediğimizde bu örnek için total blocking time süresi 200 + 40 +105 den toplamda 345 ms yani 0.345 saniyedir.

İdeal Total Blocking Time (Toplam Engellenme Süresi) Nedir?

Google’ın total blocking time için web dev blog da belirttiği kabul edilebilir (ideal) limitinin 300 ms ve altı olduğu düşünüldüğünde üstteki örneğimizin total blocking time skoru, hızlıya yakın ancak mevcut hali ile ortalama (kabul edilebilir – turuncu) seviyededir.

Total Blocking Time ile Time to Interactive Arasındaki İlişki Nedir?

Time to Interactive (TTI), bir sayfanın kullanıcı etkileşimine tamamen açık olduğu sürenin ölçümlendiği metriğe verilen isimdir. Bir sayfanın tamamen interaktif olabilmesi için kullanıcının sayfada gerçekleştireceği herhangi bir etkileşime (javascript kaynaklı işlem) tarayıcının tamamen cevap verebilir olması gereklidir.

Eğer tarayıcı, oluşturma süreci esnasında 5 saniye boyunca herhangi bir long task ile karşılaşmaz ise time to interactive tetiklenir.  Total blocking time ile TTI metriklerinin birbirine bağlantılı oldukları konu Total Blocking Time metriğini ölçümlemeden TTI metriği ile alakalı sağlıklı sonuçların elde edilemeyecek olmasıdır. Çünkü çalışma mantığı gereği TTI metriği bir sayfanın kullanıcı etkileşimine yanıt verebileceği süreyi ölçümlerken Total Blocking Time, bir sayfada ne kadar süre ile geçikme yaşadığının hesaplandığı metrikdir.

Yani engelleme süresi olan TTB hesaplanmadan TTI ile alakalı net ve sağlıklı verilerin elde edilmesi güçtür.

TTI Metriği hesaplanırken tasklar içerisinde long task olarak üstte detaylandırdığımız 50 ms den uzun taskların bitiş süreleri ve devamında gelen taskların engelleme durumları ölçümlenir. 10 adet task içeren ve içerisinde 5 adet 52 ms long tasklar barındıran bir sayfada long taskların sayfanın açılış süreci içerisindeki dağılımları ilgili sayfanın TTI metriğinin belirlenişini doğrudan etkiler.

Yani 52 ms lik çok sayıda task, x bir sayfanın toplam yükleme süresi olan 12 saniye boyunca sayfanın yükleme süresine, 2 saniye aralıklarla 10 saniyelik zaman zarfı boyunca yayılıyor ise ilgili sayfanın kullanıcı deneyimi ve interaktifliği TTB nin düşük olması sebebiyle yüksek olacak ancak TTI 10 saniye olarak belirlenecektir. Çünkü belirttiğimiz gibi 2 saniyelik aralıklarla 10 saniye boyunca 52 ms lik tasklar halinde yayılmaya (çalışmaya) devam eden long tasklar, TTI metriğinin 10.cu saniyede son long task’ın bitimi ile birlikte belirlenmesine sebep olacaktır. Bu sebeple gerçek kullanıcı deneyimi ile TTI arasında her zaman için %100 bir korelasyon olduğunu söylemek zordur.

Bu örnekte görebileceğiniz şekilde x bir sayfanın oluşturma süreci içerisinde toplamda 9 task dan oluşan bir işleme süreci için 2 long task’ın var olduğunu görüntülüyoruz. Üstte değindiğimiz şekilde bir sayfada üstteki örnekteki gibi bir yükleme süreci gerçekleştiğinde turuncu ile gösterilmiş iki long task dan sonuncu olan long task’ın bitiminden itibaren 5 saniye boyunca herhangi başka bir long task belirlenmediğinden kullanıcı sayfa ile etkileşime geçebilir durumdadır. Bu sebeple TTI yani time to interactive metriği işleme süreci 50 ms den büyük olan ikinci long task’ın bitiş süreci ile birlikte belirlenir.

Total Blocking Time (TBT) Nasıl Ölçümlenir?

Total blocking time, lab verisi olması sebebiyle özellikle page speed araçları üzerinde ölçümlenir. TBT metriği ile alakalı en net sonucu almak için Google Lighthouse aracını kullanabilirsiniz.

• Lighthouse
• Chrome Devtools
• Google PageSpeed
• WebpageTest.org

Burada yer alan 4 aracı kullanarak TBT sonuçlarınızı net olarak ölçümleyebilirsiniz.

Total Blocking Time (TBT) Artışının Nedenleri Nasıl Belirlenir?

Total Blocking Time, skorlarınız gerçekleştirdiğiniz kontrollerde yüksek geliyor ise yapmanız gereken özellikle Chrome Devtools aracının içerisinde yer alan performan sekmesini kullanarak sayfanızın açılışını analiz etmektir.

Chrome devtools üzerinde ölçüm gerçekleştireceğiniz sayfaya giriş yaptıktan sonra devtools üzerinde yer alan performan sekmesi altında sayfanızın ölçümünü gerçekleştirebilir ve aşağıda yer alan görselde görebileceğiniz gibi sayfanızın hız sonuçlarını görüntüleyebilirsiniz.

Chrome DevTools içerisinde yer alan performans sekmesinde sayfanızı kontrol ettiğinizde Google Web Vitals içeriğimizde ve TBT içeriğimizin tümünde bahsettiğimiz 50 ms den uzun long taskları üstteki görselde görebileceğiniz şekilde görüntüleyebilirsiniz.

50 ms den uzun süren tasklar DevTools içerisinde üstteki görseldeki gibi kırmızı çizgi çizgi gösterim ile testi gerçekleştiren kullanıcıya sunulur.

50 ms den uzun süren long taskların neden daha uzun sürdüğünü anlamak için DevTools aracı üzerinde main bölümünde yer alan long tasklardan herhangi bir tanesine tıklamalı ve üstteki görselde kırmızı ok ile işaret ettiğimiz alttaki bölümde bottum-up sekmesine tıklayarak group by activity seçeneğini seçmelisiniz.

üstte belirttiğimiz işlemleri sırasıyla uyguladıktansonra üstteki görselde görebileceğiniz gibi uzun süren task’ın hangi javascript dosyasından yada hangi işlemden kaynaklı olarak uzun sürdüğünü görüntüleyebilir ve daha sonrasında ilgili alanda belirlediğiniz javascript kod ve işlemlerini optimize edebilirsiniz.

Örneğin bu görselde biz https://www.dijitalzade.com/google-core-web-vitals-nedir/ sayfası için kablolu internet bağlantısı + cpu yavaşlatma olmaksızın gerçekleştirdiğimiz hız testinde long task olarak işaretlenmiş bir javascript dosyasını belirledik ve üzerinde kontrol gerçekleştirdik. Görebileceğiniz şekilde 4g hız testi ile belirlediğimiz JS dosyası içerisine devTools da giriş yaptığımızda hangi kod bloğunun kaç ms’lik süre zarfında yüklendiği tarayıcı tarafından bize sunulmakta.

Bu bilgi ve kodlardan hareketle geçikmeye neden olan kod bloğumuzu optimize etmeli ve long task’ımızın işleme süresini kısaltmalıyız.

Total Blocking Time (TBT) Nasıl Optimize Edilir?

Total Blocking Time skorlarınızı optimize etmek için özellikle Lighthouse benzeri Google araçlarının önerilerine kulak vermeli ve Google tarafından üretilen kaynakları detaylıca analiz etmelisiniz. Özellikle site yapınıza ve skorlarınıza göre atmanız gereken adımların sayısı ve işlem gereksinimleriniz değişim göstereceğinden manuel analizler ve tool incelemeleri ile sitenizde hayata geçirilebilecek iyileştirmeleri belirlemelisiniz.

Bunun dışında hemen hemen tüm siteler için ortak olan ve dikkat edilmesi gereken belli başlı konuları proje, projelerinizde hayata geçirerek Total Blocking Time skorlarınızı optimize edebilirsiniz.

Özellikle üst kısımda belirttiğimiz şekilde devTools kullanarak belirlediğiniz 50 ms den uzun süren long taskları site genelinde optimize etmek için aşağıdaki işlemleri kontrol ederek sitenizde eksikliği bulunan işlemleri hızlıca hayata geçirmelisiniz.

• Site dışı harici kaynakların kullanımını site genelinde azaltın.
• Site dışı harici javascript kaynaklarının boyut ve istek sayılarını azaltın
• Tarayıcının Ana İş Parçacığını En Aza İndirin (Browser’s Main Thread Work)
• Sayfaların tamamında kullanılmayan yada ilgili sayfalar için gerekli olmayan CSS ve JS kodlarını sayfalardan temizleyin.
• Javascript ve CSS kaynaklarınıza sıkıştırma uygulayın. Gereğinden büyük JS dosyalarınızı mutlaka sıkıştırın.
• Sayfalarda yalnızca gerekli JS kodlarını sunmak için javascript kodlarınızı ayrıştırın (Code Splitting)
• Önemli JS Kaynaklarını Tarayıcı İpuçları (Pattern) ile Sayfalarda Çağırın (Preload, Prefetch, Prerender vb)
• TTFB (Sunucu İlk Yanıt Süresi) Başarılı olan, Yüksek Kaynaklı Sunucular Kullanın. (Sunucu kapasitesi TTB’yi doğrudan ve dolaylı olarak etkiler)
• Tarayıcı Ana iş Parçacığını yükünü ve TTB’yi azaltmak için CDN Kullanın.

Site Dışı (3.Parti) Javascript Kaynak Kullanımını Site Genelinde Azaltın

Sitenizde kullanmakta olduğunuz 3.parti facebook, criteo, yandex vb javascript kodlarından, yoğun olarak kullanmadıklarınızı sayfalarınızdan (site genelinden) kaldırarak sitenizin Total Blocking Time skorlarını optimize edebilirsiniz.

Sitenize kurmakta olduğunuz 3.parti araçlar sağladıkları ekstra avantajlar ve takip sistemleri ile siteler için belirli ölçüde gerekli olsalar da özellikle kısa süreçler için kurulmuş ancak daha sonrasında kullanılmayan ve siteden silinmeyen kodlar mutlaka belirlenerek siteden kaldırılmalıdır.

3.Parti JS kodları hem boyutları hem de sayfa networkleri üzerinde yarattıkları çok sayıda istek ile sayfaların açılış hızlarını önemli ölçüde yavaşlatmaktadırlar.

Bu noktada üstte TBT skorlarının ölçümlemesi için önerdiğimiz Google PageSpeed ve Lighthouse benzeri araçları kullanarak sitenizde ekstra yük oluşturan kaynakları görüntüleyebilir ve kullanmadığınız kaynakları sitenizden kaldırabilirsiniz.

3. Parti Javascript Kaynaklarının Boyutlarını Azaltın

Sitenize eklediğiniz 3.parti javascript kaynaklarının boyut kontrolü genelde sizde olmasa da kodlar üzerinde inceleme yaparak (teknik bilgiye sahipseniz) gereksiz gördüğünüz kod bloklarını kodları aldığınız firmalara iletebilir ve kaynak kodlarında optimizasyonlar yapılmasını isteyebilirsiniz.

Tarayıcının Ana İş Parçacığını En Aza İndirin

Üstteki maddelerde ve aşağıda başlıklar halinde belirttiğimiz iyileştirmeleri hayata geçirdiğinizde aslında tarayıcı ana iş parçacığını da optimize etmiş oluyorsunuz ancak burada ayrı bir başlık olarak belirtmekte faydalı olacaktır.

• Üçüncü taraf komut dosyalarını optimize edin
• Web Workers teknolojisi ile Main Thread’ın çalışmasını azaltın
• Uzun ve karmaşık girdi işleyicilerden kaçının
• Stil hesaplamaları için değişkenlerin kapsamını azaltın
• Javascript ve CSS’i Küçültün, Sıkıştırın ve Optimize Edin
• Kullanılmayan Tüm Kodları temizleyin
• Kritik olmayan CSS ve Javascript’i erteleyin (Defer Edin)
• Javascript Yüklerini azaltmak için kod bölme kullanın (Code Splitting) – https://web.dev/reduce-javascript-payloads-with-code-splitting/

Tarayıcının ana iş parçacığının işleme yükünü gözlemek için Google PageSpeed, Chrome DevTools ve Lighthouse araçlarını kullanabilirsiniz.

Özellikle Lighthouse ve PageSpeed araçları tarayıcının ana iş parçacığı üzerinde en çok yük oluşturan işlemleri toplu şekilde harcanan süreleri ile birlikte üstteki görselde görebileceğiniz şekilde iletmektedir.

Bu araçları kullanarak öncesinde hangi işlemlerin sayfalarınızda ne kadar süre aldığını görüntüleyebilir ve daha sonrasında Chrome Devtools aracında yer alan performans sekmesini kullanarak hangi kaynağın ne şekilde sayfada çalıştırıldığını görüntüleyebilir ve sayfalarınızda çağrılan kaynakları optimize edebilirsiniz.

Sayfalarda Gerekli Olmayan JS ve CSS Kaynaklarını Temizleyin

Sayfalarınızda çağrılan ancak ilgili sayfa için gerekli olmayan dahili (iç) JS ve CSS kaynaklarını temizleyin. Özellikle site genelinde eklentilerden yada farklı uygulamalardan kaynaklı tüm sayfalarda çağrılan ancak yalnızca belirli sayfalar için kullanımda olan JS ve CSS kaynaklarını DevTools kullanarak yada Lighthouse analizleri ile belirleyebilir ve gereksiz kaynakları sayfalardan kaldırabilirsiniz.

Chrome DevTools üzerinde herhangi bir sayfayı incelerken sol alt bölümde yer alan coverage sekmesine tıklayıp coverage raporunu başlatırsanız ilgili sayfada yüklenen CSS, JS kaynaklarını görüntüleyebilir ve bu kaynakların % kaçlık bölümünün ilgili sayfada kullanılmadığını görüntüleyebilirsiniz.

Özellikle ilgili alanı kullanarak tüm içerik sayfalarında üstteki görselde ki örnekte işaretlediğimiz örneğe benzer şekilde %100 olarak kullanılmayan CSS ve JS kaynakları belirleyebilir ve ilgili sayfalarda bu kaynakların çağrılma işlemini iptal edebilirsiniz.

CSS ve JS Kaynaklarınızı Küçültün (Minify) Edin

Tarayıcı ana iş parçacığını yoğun çalıştıran ve total blocking time skorlarını arttıran CSS ve JS kaynaklarında yorum bölümleri, boşluklar vb gereksiz alanlardan kurtularak dosyalarınızı minify edebilir ve kaynaklarınızın oluşturma süreçlerinde çok daha hızlı yüklenmesini sağlayabilirsiniz.

Teknik bilginiz yeterli ise CSS ve JS kaynaklarınızı manuel olarak inceleyip küçültebilir veya aşağıda yer alan online küçültme site ve toollarını kullanarak kaynaklarınızı küçültebilirsiniz.

• https://javascript-minifier.com/ – Javascript Kaynaklarını Otomatik Küçültebileceğiniz Web Sitesi
• https://cssminifier.com/ – CSS Kaynaklarını Otomatik Olarak Küçültebileceğiniz Web Sitesi

Üstte belirtiğimiz en sık kullanılan 2 online aracı kullanarak CSS ve Javascript kaynaklarınızı online olarak küçültebilirsiniz. Bu tarz online araçlarda IT ekiplerinizin yada sizin manuel olarak inceleme yolu ile küçültmenize kıyasla hata alma oranı biraz daha yüksektir ancak teknik bilgisi yetersiz olan ve mevcutta IT desteği bulunmayan web siteleri için bu tarz araçlar oldukça işlevlidir.

Sayfa Kaynak Boyutu ve İstek Sayısını Azaltın

TTB ile yakından ilişkili tarayıcı ana iş parçacığı yükünü azaltmak için üstte belirttiğimiz Kod eksiltme, gereksiz kaynakları silme, küçültme gibi işlemleri hayata geçirdiğinizde harici ve dahili kaynakların yarattığı yavaşlık ile alakalı sorunların önemli bir bölümünü elemine edebilir ve sayfalarınızın oluşturma süreçlerini hızlandırabilirsiniz. Özellikle sayfalarınızda kullandığınız ekstra CSS ve JS kaynaklarında yapacağınız azaltmalar TTB skorlarınızı optimize etmede oldukça kritik ve başarılı bir çalışma olacaktır.

Bunlara ek olarak yine sayfalarınızda HTML küçültme (minify) optimizasyonu, resimlerin sıkıştırılması (webp vb), Font dosyalarının sıkıştırılması ve, veya gereksiz (harici) font dosyalarının silinmesi gibi işlemlerle sayfa network’ü üzerinde ekstra istek oluşturan büyük boyutlu sayfa kaynaklarını azaltabilir (silebilir) ve sayfa açılış hızlarını önemli ölçüde arttırabilirsiniz.

Örneğin ;

Dijitalzade için Lighthouse üzerinde bir kontrol sağladığımızda Seo Nedir? sayfamızın network üzerinde 32 istek barındırdığını ve bu isteklerin toplam byte boyutunun 402 kb olduğunu görüntülüyoruz. Yani SEO Nedir sayfamız ile alakalı sunucuya istek gönderen bir tarayıcı toplamda 402 kb lık bir sayfanın oluşturma süreci ile ilgilenmektedir.

Gerçekleştirdiğimiz bu Ligthouse kontrolü ile hangi kaynakların ne sayıda istek oluşturduğu ve bu isteklerin sayfa boyutu üzerindeki toplam dağılımlarını görüntülüyoruz. Örneğin SEO Nedir sayfamızda toplamda 2 font dosyası çalıştırıyoruz ancak bu 2 font dosyasının total boyutu 103 kb yani sayıca az olmalarına rağmen sayfadaki pek çok kaynaktan daha büyükler.

Bu noktada site genelinde bir sayfa boyut optimizasyonu yapmak ve ana iş parçacığının yükünü azaltmak için font dosyalarını detaylı olarak inceleyebilir, küçültme uygulanmadıysa bu kaynakları küçültebilir veya bu font dosyaları harici kaynak ise dış kaynak (gfonts vb) kullanımı yapmak yerine tarayıcıların default olarak desteklediği font kullanımlarını sitede aktif hale getirerek font dosyalarımızın boyutunda küçülmeye gidebiliriz.

Özellikle bu örnek için font dosyalarında yapacağımız 20 30 50 kb lık bir küçültme ay ve yıl’a vurduğumuzda hem arama motoru botlarının tarama yükünde hem tarayıcıların sayfaları oluşturma süreçlerinde bize hız ve taranabilirlik noktasında önemli avantajlar sağlayacaktır.