Üçüncü taraf scriptleri etkileşimi yavaşlatıyorsa nasıl izole edilir

Üçüncü taraf scriptleri sayfa etkileşimini yavaşlatıyorsa önce neye bakılır?

Üçüncü taraf scriptleri sayfa etkileşimini yavaşlatıyorsa nasıl izole edilir sorusunun ilk cevabı, gecikmenin ağ tarafında mı yoksa ana thread üzerinde mi oluştuğunu ayırmaktır. INP yükseliyorsa sorun çoğu zaman scriptin sadece geç yüklenmesi değildir; tıklama anında event handler, style recalculation, layout ve render kuyruğunu meşgul eden işlerin toplamıdır. Google’ın Optimize Interaction to Next Paint rehberi, iyi kullanıcı deneyimi için p75 INP değerinin 200 ms veya altında tutulmasını önerir. Bu yüzden bakmanız gereken şey tek bir puan değil, en yavaş etkileşimin hangi alt parçalardan oluştuğudur.

Burada INP, TBT ve long task birbirine karıştırılmamalıdır. INP saha odaklı bir yanıt verebilirlik metriğidir; TBT ise laboratuvar teşhisi için kullanışlıdır. Chrome’un resmi Reduce the impact of third-party code dokümanında üçüncü taraf kodun ana thread’i 250 ms ve üzeri bloke etmesi klasik Lighthouse denetiminin başarısızlık eşiği olarak açıklanıyordu. 2025’te bu mantık yeni insight akışına taşındı, ama teşhis prensibi değişmedi: üçüncü taraf script CPU zamanı tüketiyorsa etkileşim gecikmesini büyütebilir.

• Önce saha sinyali: INP hangi sayfa tipinde ve hangi etkileşimde bozuluyor?
• Sonra lab izi: Long task kümeleri tıklama öncesinde mi, sırasında mı, hemen sonrasında mı birikiyor?
• Vendor ayrımı: Ağ maliyeti düşük görünse bile CPU ve DOM maliyeti yüksek olabilir.
• Iframe etkisi: INP sayfa düzeyinde raporlandığı için gömülü içeriklerin gecikmesi de toplam deneyimi bozabilir.

Lab verisi ile saha verisini ayrı etiketlemek kritik noktadır. Lighthouse size tekrar üretilebilir bir senaryo verir; gerçek kullanıcı verisi ise sorunun ne sıklıkla yaşandığını söyler. Aynı web.dev INP rehberi içinde de vurgulandığı gibi, ideal akış saha verisiyle başlar, laboratuvar izleriyle kök neden bulunur. Yani Lighthouse raporunda üçüncü taraf uyarısı görmek faydalıdır, fakat tek başına hangi etkileşimin gelir kaybına veya form terkine yol açtığını söylemez.

Lighthouse, DevTools ve RUM ile suçlu script nasıl bulunur?

Lab teşhisi: önce vendor’ı, sonra etkileşimi ayırın

2025’te Chrome’un Insights sidebar in the DevTools Performance panel duyurusuyla birlikte Performance panelindeki 3rd parties görünümü, üçüncü taraf CPU ve ağ maliyetini aynı iz üzerinde ayırmayı ciddi biçimde kolaylaştırdı. En pratik akış şudur: önce Lighthouse ile genel uyarıları görün, sonra aynı sayfada Performance kaydı alın, 3rd parties görünümünde vendor bazlı yoğunlaşmayı bulun ve long task bloklarının tıklama zamanına denk gelip gelmediğini kontrol edin. Böylece sorunlu scriptin sadece yüklendiğini değil, gerçekten etkileşimi bozduğunu gösterebilirsiniz.

DevTools içinde iki şeyi ayrı okumak gerekir. Birincisi ağ keşfi: script ne kadar erken geliyor, bağımlılık zincirini uzatıyor mu, başka kaynakları tetikliyor mu? İkincisi çalıştırma maliyeti: parse, evaluate, event callback ve DOM işi ne kadar sürüyor? Özellikle GTM, chat widget ve video embed tarafında ağ maliyeti makul görünse bile etkileşim anında ana thread üstünde beklenmedik CPU patlamaları görmek yaygındır. Bu yüzden sadece kilobayta bakmak çoğu durumda eksik analizdir.

Saha doğrulaması: RUM ve CrUX ile gerçekten kime zarar verdiğini görün

Gerçek kullanıcı tarafında en iyi yaklaşım, RUM olaylarına etkileşim türü eklemektir: click, tap, keypress, form submit gibi. web.dev rehberi, CrUX verisinin bağlam verdiğini ama olay düzeyinde kök nedeni göstermek için çoğu zaman yeterli olmadığını açık söyler. Bu yüzden kendi RUM akışınızda sayfa tipi, cihaz sınıfı, kritik selector grubu ve vendor varlığı gibi alanları tutmak gerekir. Böyle yaptığınızda sadece sayfa genelinde kötü INP görmekle kalmaz, örneğin ürün sayfasındaki video etkileşiminin mi yoksa checkout formundaki reCAPTCHA’nın mı sorun çıkardığını ayırırsınız.

• Lighthouse: genel riskli vendor’ları ve olası darboğazları görün.
• DevTools Performance: trace içinde long task ve vendor ilişkisini kanıtlayın.
• RUM: aynı vendor’ın gerçek kullanıcıdaki p75 INP etkisini doğrulayın.
• CrUX: saha eğilimini kontrol edin, fakat olay düzeyini RUM ile tamamlayın.

Bu üç katmanı birlikte okuduğunuzda yanlış optimizasyon riski düşer. Örneğin bir chat widget Lighthouse’ta ağır görünebilir ama sadece destek sayfasında çalışıyorsa önceliği düşüktür. Tersine GTM görece hafif görünüp ana sayfada her tıklama öncesi senkron kontrol yapıyorsa saha tarafında daha büyük zarar verebilir. İzolasyon kararı bu yüzden rapor puanına göre değil, işlev ve etkileşim maliyetine göre verilmelidir.

Async, defer, facade, Partytown ve sandbox arasında nasıl seçim yapılır?

İlk kural şudur: en hafif işe yarayan yöntem önce gelir. MDN’nin güncel script element referansı async ve defer kullanımının indirme blokajını azalttığını, fakat çalıştırma maliyetini ortadan kaldırmadığını net biçimde ayırır. Async, kaynak hazır olur olmaz çalışır; sırası garanti edilmez. Defer ise HTML parse tamamlandıktan sonra ve belge sırasıyla çalışır. type=module yaklaşımı da modern tarayıcı akışında faydalıdır, ancak üçüncü taraf vendor sizin kontrolünüzde değilse çoğu zaman bu kararı veremezsiniz.

Karar mantığı: sorun indirme mi, çalıştırma mı, erken görünme mi?

• Async: bağımsız analytics veya piksel kodunda, sıra kritik değilse uygundur.
• Defer: DOM’a ihtiyaç duyan ama ilk parse’ı bloke etmemesi gereken scriptlerde güvenlidir.
• Facade: YouTube, harita, sosyal embed ve chat giriş butonlarında ilk yükü keser.
• Partytown: DOM bağımlılığı düşük, veri gönderen scriptlerde worker offloading için düşünülür.
• Iframe sandbox: güvenmediğiniz veya tam izole etmek istediğiniz gömülerde mantıklıdır.
• Tam kaldırma: faydası düşük, ölçülemeyen veya yinelenen vendor’larda en doğru tercihtir.

Chrome’un facade dokümanı, özellikle video ve benzeri embed’lerde kullanıcı etkileşimine kadar hafif bir önizleme kullanmanın işe yaradığını anlatır. Burada önemli 2026 notu şu: facade tekniği geçerliliğini korusa da Lighthouse’ın bu denetimi artık raporda ayrı bir audit olarak görünmüyor. Chrome ekibinin 2025 geçiş duyurusu, third-party-facades denetiminin Lighthouse 13 akışında kaldırıldığını açıkça belirtir. Yani audit kalktı diye yöntem değersizleşmedi; sadece raporlama modeli değişti.

Partytown tarafında resmi Introduction ve Trade-Offs sayfaları çok net bir sınır çizer: worker’a taşıma fikri özellikle GTM, analytics ve pixel türü scriptlerde güçlüdür; ancak yoğun DOM işlemi yapan mini uygulama benzeri widget’larda uyumluluk riski vardır. UI ağırlıklı chat kutuları, form içi doğrulama akışları veya preventDefault davranışına dayanan scriptler bu yüzden dikkat ister. Iframe sandbox ise performans kadar güvenlik için de iyidir, fakat ana sayfa ile veri ve stil paylaşımını bilinçli kısıtlar; bu yüzden entegrasyon maliyeti async veya facade’dan yüksektir.

GTM, YouTube, chat widget ve reCAPTCHA’yı ayırınca ne değişti?

Yeniden üretilebilir izolasyon protokolü

Teknik auditlerde kullandığımız en temiz yöntem, tek değişken kuralı ile ilerlemektir: aynı şablon sayfayı sabit tutup sadece bir vendor’ı açıp kapatırız. Laboratuvar tarafında cache kapalı, aynı URL, aynı tarayıcı sürümü ve aynı kullanıcı akışıyla en az dört trace alınır; en uç iki koşu karar verdirmez, ortadaki kayıtlar karşılaştırılır. Mobil benzeri baskıyı görmek için 4x CPU slowdown kullanmak pratik bir standarttır. Saha tarafında ise aynı sayfa tipinde en az 14 günlük RUM p75 INP trendine bakılır. Böylece lab ile field aynı torbaya atılmaz.

Bu bölümdeki farklar temsili ölçüm mantığını anlatır; her sitede aynı rakamlar çıkmaz. Ancak örüntü nettir. YouTube embed tarafında en büyük sıçrama çoğu zaman facade ile gelir; çünkü asıl oynatıcı ve takip kodları ilk yükte hiç çalışmaz. GTM tarafında tek başına async çoğu zaman yeterli olmaz; asıl maliyet kapsayıcının içindeki etiketlerin ne zaman tetiklendiğidir. Chat widget için en iyi sonuç genelde route bazlı yükleme veya ilk etkileşim sonrasına ertelemedir. reCAPTCHA ise güvenlik ve form doğrulama akışına sıkı bağlı olduğundan worker veya agresif erteleme her zaman uygun değildir.

Vendor bazında kısa karar mantığı şöyle işler: GTM ve analytics scriptleri veri gönderme ağırlıklıysa Partytown aday olabilir; fakat container içindeki özel HTML etiketleri ve DOM bağımlılıkları uyumluluk testi ister. YouTube, harita ve sosyal gömülerde facade çoğu zaman ilk tercih olur. DOM gözlemcisi yoğun chat widget’larda requestIdleCallback veya kullanıcı niyeti sonrası yükleme daha güvenli olabilir. reCAPTCHA’da ise form açılmadan yüklememek, yalnızca gereken sayfalarda çalıştırmak ve gereksiz sayfalardan tamamen kaldırmak genelde en düşük riskli çözümdür. Partytown Trade-Offs sayfasının vurguladığı gibi, UI yoğun scriptler worker için her zaman iyi aday değildir.

Karşılaştırmayı değerlendirirken iki farklı başarı ölçütü kullanın: laboratuvarda long task toplamı ve etkileşim anındaki blokaj süresi azalıyor mu, sahada p75 INP aşağı geliyor mu? Sadece Lighthouse puanı yükseldi diye optimizasyonu tamamlanmış saymayın. Aynı şekilde sahada iyileşme yoksa, lab’de kazandığınız milisaniyelerin kullanıcı yolculuğunda yanlış yere uygulandığını kabul etmek gerekir. İzolasyonun amacı rapor güzelleştirmek değil, etkileşimi gerçekten daha erken yanıt verir hâle getirmektir.

Gereksiz scriptleri kaldırma ve SEOYEN ile sürekli izleme süreci

İzolasyonun son adımı çoğu zaman teknik değil, yönetişim işidir. Siteye eklenen her vendor’ın sahibi, amacı ve ölçülebilir çıktısı olmalıdır. Aksi hâlde zamanla GTM içinde yinelenen etiketler, artık kullanılmayan sohbet araçları, birden fazla heatmap scripti veya tüm sitede gereksiz çalışan güvenlik bileşenleri birikir. 2026 itibarıyla Chrome’un Connection Allowlists origin trial duyurusu da üçüncü taraf bağımlılıklarını yalnızca performans değil, veri çıkışı ve güvenlik açısından da yeniden düşünmek gerektiğini gösteriyor. Bu yaklaşım performans temizliğini daha kurumsal bir sürece dönüştürüyor.

• Self-hosting: Vendor izin veriyorsa statik dosyayı kendiniz barındırın, ama güncelleme sorumluluğunu unutmayın.
• Tag cleanup: GTM içindeki yinelenen ve ölçülmeyen etiketleri kapatın.
• Route bazlı yükleme: Chat, harita ve video scriptlerini sadece gereken sayfalara taşıyın.
• Etkileşim sonrası yükleme: Kritik olmayan vendor’ları ilk tıklama veya idle sonrasına bırakın.
• Tam kaldırma: Dönüşüme etkisi kanıtlanmayan scripti sitede tutmayın.

Süreklilik tarafında SEOYEN’in Türkçe arayüzlü yapısı burada anlamlıdır. Teknik düzeltme sonrasında site sağlığı raporu ile yeni eklenen script ve sayfa şişmesini düzenli izlemek, sıralama takibi ile hız iyileştirmesinin görünürlüğe eşlik edip etmediğini görmek, AI görünürlük analizi ile teknik iyileştirmelerin yeni arama yüzeylerinde nasıl yankı bulduğunu okumak daha net bir operasyon akışı kurar. Ahrefs ve SEMrush gibi platformlar geniş veri katmanlarıyla bilinir; SEOYEN bu ihtiyacı Türkiye pazarına uyarlanmış, tek platformda toplanmış araçlar, TL bazlı yapı ve yerel destekle karşılar. Plan ve abonelik tarafı için en doğru referans paket detayları sayfasıdır.

Kısacası üçüncü taraf script optimizasyonu tek seferlik bir PageSpeed işi değildir. Yeni kampanya etiketi, yeni video gömüsü veya yeni sohbet aracı geldiğinde aynı disiplin tekrar uygulanmalıdır: ölç, ayır, en hafif çözümü seç, doğrula, işe yaramayanı kaldır. Bu döngü kurulmadan alınan hız kazanımları birkaç sprint içinde geri verilir.

Adım Adım Üçüncü taraf scriptleri izole etme akışı

Pratikte en az hata üreten akış, teşhis ile uygulamayı aynı düzende ilerletmektir. Aşağıdaki sıralama, hem teknik SEO hem de geliştirme ekipleri için yeniden kullanılabilir bir çalışma planı verir.

1. Temel performans ölçümünü kaydet. Önce aynı sayfa tipinde mevcut Lighthouse raporunu, DevTools trace kaydını ve varsa RUM p75 INP değerini çıkarın. Başlangıç noktası yazılı değilse yapılan iyileştirmenin gerçek etkisini tartışamazsınız. Lab ve saha verisini ayrı etiketlemek burada ilk zorunluluktur.
2. Suçlu vendor ve etkileşimi bulun. 3rd parties görünümünde hangi vendor’ın CPU ve ağ maliyeti yarattığını ayırın. Sonra long task bloklarının hangi kullanıcı eylemiyle çakıştığını bulun: tıklama, form, menü açma ya da video oynatma. Sadece ağır dosyayı değil, ağır etkileşimi hedefleyin.
3. En hafif izolasyon tekniğini seçin. Sorun sadece erken indirmeyse async veya defer yeterli olabilir. Sorun erken görünmesi gerekmeyen embed ise facade daha iyi sonuç verir. Sorun veri gönderme ağırlıklı bir vendor ise Partytown denenebilir; güvenlik veya sert ayrım gerekiyorsa sandbox düşünülür.
4. Uyumluluk ve gelir etkisini test edin. Etkileşimden sonra yüklediğiniz bir etiketin dönüşüm kaydını bozmadığını, chat’in gerçekten açıldığını, form doğrulamasının çalıştığını ve consent akışının kırılmadığını kontrol edin. Performans kazancı ile işlev kaybı arasında görünmeyen bir takas oluşmamalıdır.
5. Canlıda izleyip gereksiz kodu temizleyin. Değişiklikten sonra RUM ve düzenli audit ile iyileşmenin kalıcı olduğunu doğrulayın. Etkisi düşük kalan vendor’ı route bazlı çalıştırın, self-host edin veya tamamen kaldırın. En iyi optimizasyon, kullanıcıya değer üretmeyen üçüncü taraf kodun artık yüklenmemesidir.

Sıkça Sorulan Sorular