Ölçüm ve Analiz

Third-Party Script Performansı Nasıl Ölçülür?

Third-party scriptlerin network waterfall ve main thread üzerindeki etkisini gösteren teknik diyagram

First-party kodunuzu küçülttünüz, görselleri optimize ettiniz, kritik CSS'i ayırdınız — ama Lighthouse hâlâ sorun işaret ediyor. Çoğu durumda asıl ağır yük, sizin yazmadığınız koddan gelir. Analytics scripti, tag manager katmanı, destek widget'ı, A/B test aracı: bunların her biri bağımsız bir ağ isteği, ayrı bir parse maliyeti ve main thread üzerinde kendi gecikmesidir.

Third-party scriptlerin temel sorunu görünmezlikleridir. Kendi dosyalarınız DevTools'da net biçimde size aittir; üçüncü taraf kaynaklar farklı domain'lerden gelir, farklı zamanlarda yüklenir ve neden yavaşlattıklarını anlamak için ek çaba ister. Ölçülmeden yönetilemeyen bu yük, optimize ettiğiniz her şeyin önüne geçebilir.

Waterfall'da third-party isteğin görünümü

DevTools Network panelinde sayfanın waterfall görünümü açıldığında, third-party istekler çoğunlukla ilk boyama sonrasında uzayan çubuklar olarak göze çarpar. Kaynak domain'i farklıdır — analytics.google.com, cdn.hotjar.com gibi — ve bu çubukların ne kadar uzadığı, first-party kaynaklarla nasıl örtüştüğü kritik bir bilgidir.

Önemli olan, bu isteklerin hangi yükleme fazında tetiklendiğidir. Eğer bir third-party script <head> içinde async veya defer olmadan yer alıyorsa render blocking hale gelir. Body'nin altında bile olsa JavaScript parse ve execution maliyeti taşır; bu maliyet yalnızca indirme süresiyle ölçülmez. Waterfall'daki bir çubuğun boyutu ağ maliyetini gösterir; asıl darboğaz çoğu zaman indirme bittikten sonra başlar.

Network panelinde "Domain" sütununu etkinleştirmek bu analizi kolaylaştırır. İstekler domain'e göre gruplandırıldığında hangi üçüncü tarafın kaç istek gönderdiği ve toplam transfer boyutunun ne kadarını oluşturduğu tek bakışta görünür hale gelir.

Main thread üzerindeki engelleme etkisi

Third-party scriptlerin en sessiz maliyeti, main thread üzerinde açtıkları uzun görevlerdir. Bu kavram genellikle first-party kodla ilişkilendirilir; ancak üçüncü taraf scriptler de 50 ms'yi aşan görevler tetikleyebilir ve bu görevler sırasında tarayıcı kullanıcı girişine yanıt veremez.

DevTools Performance panelinde "Main" satırının üzerindeki uzun kırmızı bloklar bu maliyeti gösterir. Her bloğun üzerine gelindiğinde hangi script'ten kaynaklandığı görülebilir. Tag manager üzerinden yüklenen bir analytics kodunun tag manager → analytics sağlayıcı → veri katmanı üç ayrı yürütme zincirine yol açtığı ve bunların toplamının 200–300 ms'yi bulduğu nadir değildir.

Main thread bloklamayı azaltmak için third-party scriptlerin bu etkisini ayrıştırmak ilk adımdır. Performance panelinin "Bottom-Up" sekmesi, execution sürelerine göre sıralı liste verir; bu listede third-party domain'lerin call stack'i öne çıkıyorsa, main thread maliyetinin büyük kısmı orada demektir.

Tag manager'ın yük içindeki gerçek payı

Tag manager teoride script yönetimini kolaylaştırır. Uygulamada ise her yeni tag eklendikçe yük artar — çoğu zaman fark edilmeden. Tag manager'ın kendisi tek bir script gibi görünür ama içinden onlarca script tetiklenebilir; bunların her biri ayrı ağ isteği, ayrı parse, ayrı execution anlamına gelir.

Bu birikmeyi ölçmenin en doğrudan yolu, tag manager'ı devre dışı bırakarak bir Lighthouse testi yapıp ardından aktif halde tekrar çalıştırmaktır. İki test arasındaki fark, tag manager'ın net maliyetini sayısal olarak verir. Lighthouse'un "Reduce the impact of third-party code" uyarısı da container içindeki her tag'in bireysel ağ ve blocking maliyetini gösterir; bu liste hangi tag'in tartıştığını anlamak için başlangıç noktasıdır.

Tag manager audit'i düzenli yapılması gereken bir işlemdir. Bir kez eklenen ve unutulan tag'ler zamanla birikir; 50 tag içeren bir container, 5 tag içerenden çok daha farklı bir yük taşır ve bu fark kümülatif olarak sayfanın her yüklenişinde ödenir.

Analytics scriptleri genellikle küçük görünür — birkaç KB — ama DNS çözümlemesi, TLS el sıkışması ve sunucu yanıt süresi eklendiğinde gerçek maliyet farklı bir tablo ortaya koyar. Preconnect ve DNS prefetch kullanarak bu bağlantı kurulum maliyeti önceden ödenebilir; ancak bu yalnızca ağ gecikmesini azaltır, script'in execution maliyetini ortadan kaldırmaz.

Chat widget'lar bu kategorinin en ağır örneklerinden biridir. Görünürde küçük bir ikon, arka planda 200–400 KB JavaScript, birden fazla WebSocket bağlantısı ve sürekli çalışan event listener anlamına gelebilir. Kullanıcı hiç chat başlatmasa bile bu maliyet her sayfada ödenir. Yoğun trafik alan bir sitede bu durum, her oturumda gereksiz yere taşınan ciddi bir yüke dönüşür.

Render blocking third-party kaynaklar

Render blocking kaynaklar konusu genellikle first-party CSS ve JavaScript üzerinden ele alınır. Ancak <head> içine yerleştirilen third-party scriptler aynı sorunu yaratır. Bir consent management platformunun erken yüklenen kodu, sosyal medya widget'ının senkron scripti ya da bir font sağlayıcısından inline CSS, tarayıcının ilk boyamayı tamamlamasını geciktirir.

Lighthouse "Eliminate render-blocking resources" uyarısında bu kaynaklar first-party ve third-party ayrımı yapılmadan listelenir. Hangi satırın sizin kodunuz olmadığına dikkat etmek gerekir; çünkü müdahale yöntemi farklılaşır. Kendi kodunuzu defer yapabilirsiniz; ama tag manager üzerinden yüklenen bir scripte doğrudan attribute ekleyemezsiniz.

Bu durumda geçici çözüm olarak scripti mümkün olduğunca geç tetiklemek ya da yükleme sırasını tag manager'ın tetikleme kurallarıyla kontrol etmek uygulanabilir. Bazı consent araçları sayfanın ilk boyamasını tamamlayana kadar diğer scriptleri kasıtlı olarak bloke eder; bu davranışı değiştirmek için araç sağlayıcısının belgeleri incelenmelidir.

Geciktirme ve koşullu yükleme

Her third-party script sayfa yüklenir yüklenmez aktif olmak zorunda değildir. Kullanıcı etkileşimi gerektiren araçlar — chat widget, bazı A/B test varyantları, davranışsal analitik — ilk etkileşime ya da belirli bir süre geçmesine kadar ertelenebilir.

Yaygın yaklaşımlar şunlardır: requestIdleCallback ile düşük öncelikli yükleme; kullanıcı sayfayı kaydırana ya da belirli bir öğeye odaklanana kadar bekleme (IntersectionObserver ile tetikleme); 3–5 saniyelik setTimeout ile geciktirme. Bu yöntemler JavaScript yükleme stratejileriyle doğrudan örtüşür ve özellikle LCP üzerinde olumlu etki bırakır.

Dikkat edilmesi gereken nokta şudur: geciktirme veri kaybına yol açabilir. Bir analytics scripti geç yüklenirse kullanıcı sayfadan erken çıktığında o oturum kaydedilmeyebilir. Bu trade-off her araç için ayrı değerlendirilmeli; hangi araç için kabul edilebilir, hangisi için değil kararı net biçimde verilmelidir.

DevTools ile attribution: hangi script ne kadar yük taşıyor

Chrome DevTools'da third-party scriptlerin bireysel maliyetini görmek için birkaç panel birlikte kullanılır. Network panelinde istekleri domain'e göre gruplamak hangi kaynağın kaç istek gönderdiğini ve toplam byte'ın ne kadarını tükettiğini açıkça gösterir. Buradan elde edilen liste, sonraki analizin başlangıç noktasıdır.

Performance panelinin "Bottom-Up" sekmesi execution sürelerine göre sıralı bir call stack listesi verir. Third-party domain'ler bu listede üst sıralara çıkıyorsa, main thread maliyetinin büyük kısmı orada demektir. "Call Tree" sekmesi ise hangi fonksiyonun hangisini tetiklediğini gösterir; özellikle uzun zincirlerin kaynağını bulmak için kullanışlıdır.

WebPageTest, "Request Map" görünümüyle third-party bağımlılık zincirini görselleştirir. Bir script'in diğerini tetiklediği, onun da bir başkasını çağırdığı zincirler bu görünümde net biçimde ortaya çıkar. Lighthouse'un yakalamadığı, birden fazla domain arasında akan bu zincirleri görmek için WebPageTest değerli bir tamamlayıcıdır.

Facade pattern ile ertelenmiş yükleme

Facade pattern, ağır bir third-party bileşenin ilk etapta yalnızca görsel karşılığını — statik bir ekran görüntüsü veya hafif bir placeholder — gösterip gerçek scripti ancak kullanıcı etkileşime geçtiğinde yüklemek anlamına gelir. YouTube embed'leri bu yöntemin en yaygın örneğidir: gerçek iframe yerine bir thumbnail gösterilir, kullanıcı tıkladığında asıl player yüklenir.

Aynı mantık chat widget'larına uygulanabilir. Widget ikonunu bir <img> ve <button> ile taklit etmek, tıklanınca asıl scripti yüklemek hem LCP hem de TBT üzerinde belirgin iyileştirme sağlar. Lighthouse bazı yaygın third-party araçlar için bu facade'ı otomatik olarak önerir; "Uses efficient cache policy on static assets" veya "Reduce third-party usage" uyarıları altında bu öneri görünebilir.

Facade'ın maliyeti tasarım ve uygulama gerektirmesidir. Tag manager üzerinden kontrol edilemeyen scriptler için doğrudan uygulanamaz; sayfa HTML'ine müdahale gerekir. Bu nedenle facade tercih edildiğinde hangi bileşenin gerçekten bu maliyete değdiği önceden değerlendirilmelidir.

Kaldır mı, tut mu kararı

Ölçüm yapıldıktan sonra bazı third-party scriptlerin maliyeti, sağladığı değerle orantısız çıkar. Bu noktada teknik değil, ürün kararı gerekir: bu aracı gerçekten kullanıyor muyuz, son 90 günde bu araçtan gelen veriye dayanarak karar alındı mı?

Cevap hayırsa araç kaldırılabilir demektir. Üç aylık kullanılmayan analytics event'i, hiç açılmayan chat oturumu, çalışmayan bir A/B test varyantı — bunlar temizlenmesi gereken yüktür. Performance budget çerçevesi bu kararı kolaylaştırır: JavaScript bütçesi belirlendiğinde hangi third-party scriptin bütçeyi aştığı sayısal olarak görünür hale gelir ve tartışma nesnel bir zemine taşınır.

Karar her zaman "kaldır" olmak zorunda değildir. Geciktirme, facade veya daha hafif bir alternatifle değiştirme de geçerli seçeneklerdir. Önemli olan, bu seçeneklerin bilinçli biçimde değerlendirilmesi ve maliyetin görünür kılınmasıdır.

Ölçüm sonrası önceliklendirme

Third-party yükü azaltmak için müdahale sırası önemlidir. Her şeye aynı anda dokunmak yerine maliyeti yüksek olanlardan başlamak çok daha verimlidir. Sıralama için iki kriter belirleyicidir: main thread blocking süresi ve LCP üzerindeki doğrudan etki.

Main thread'i en uzun süre bloke eden script öncelikli adaydır. Bu genellikle tag manager, consent yönetimi platformu ya da büyük bir analytics kütüphanesidir. LCP üzerinde doğrudan etkisi olan kaynaklar ikinci öncelik grubunu oluşturur; örneğin hero görselin render'ını geciktiren bir script ya da LCP öğesinin yüklenmesini engelleyen bir CSS-in-JS çözümü bu gruptadır.

Gerçek kullanıcı verisi — CrUX veya herhangi bir RUM çözümü — bu önceliklendirmeyi laboratuvar testinden çok daha doğru biçimde yapar. Lab verisi sabit bir ağ ve cihaz koşulunda çalışır; gerçek kullanıcı verisi ise third-party scriptlerin farklı cihaz ve bağlantı koşullarındaki dağılımını ve bunların Core Web Vitals dağılımına katkısını gösterir.

Third-party scriptlerin performans maliyeti çoğu zaman first-party optimizasyonların önüne geçer. Görselleri sıkıştırmak, kritik CSS ayırmak, JavaScript'i küçültmek — bunların tamamı doğru adımlardır; ama üçüncü taraf yük ölçülmeden bu adımların etkisi sınırlı kalır.

Ölçüm süreci karmaşık değildir. DevTools Network ve Performance panelleri, Lighthouse'un third-party uyarısı ve WebPageTest'in Request Map görünümü birlikte kullanıldığında hangi scriptin ne kadar yük taşıdığı net biçimde ortaya çıkar. Asıl zorluk bu verinin bir karar mekanizmasına bağlanmasıdır: hangi script geciktirilir, hangisi facade ile sarılır, hangisi kaldırılır. Performans ekibinin rolü bu kararları mümkün kılacak veriyi üretmektir.