Üçüncü taraf scriptleri Core Web Vitals’ı nasıl bozar ve ertelenir

Üçüncü taraf scriptleri Core Web Vitals’ı hangi mekanizmalarla bozar?

2026 itibarıyla üçüncü taraf kod problemi artık sadece yavaş açılan sayfa meselesi değil; doğrudan Core Web Vitals meselesi. HTTP Archive’ın 2025 Web Almanac bölümüne göre web sayfalarının büyük çoğunluğu, yaklaşık yüzde 90-92 bandı, en az bir üçüncü taraf kaynağı yüklüyor. Aynı bölümde üçüncü taraf isteklerinin sayfa başına arttığı da görülüyor. Bu yüzden sorun, scriptin var olup olmaması değil; ne zaman, nerede ve hangi thread üstünde çalıştığıdır.

LCP tarafında zarar çoğunlukla ağ seviyesinde başlar. web.dev’in Load Third-Party JavaScript rehberine göre üçüncü taraf origin’leri için yapılan DNS, TCP ve TLS kurulumları kritik kaynaklarla bant genişliği yarıştırır. Script senkron yükleniyorsa HTML ayrıştırmasını durdurur, asenkron olsa bile erken istek yoğunluğu yaratabilir. Sonuç olarak hero görseli, kritik CSS veya ana yazı tipi daha geç keşfedilir ya da daha geç indirilir; kullanıcı ilk büyük içerik öğesini bekler.

INP ve TBT tarafında asıl maliyet ana iş parçacığındaki uzun görevlerdir. web.dev’in 2025 güncellenen INP dokümanı, INP’yi FID’nin halefi olarak tanımlar; yani 2026’da artık ilk tıklamadan çok tüm etkileşim akışını optimize ediyoruz. CMP, chat, A/B test, reklam ve etiket yöneticileri tıklama anında callback zinciri çalıştırıyorsa işlem ve sunum gecikmesi uzar. CLS ise geç yüklenen reklam slotu, video embed veya chat balonu için alan rezerve edilmediğinde ortaya çıkar; içerik aşağı kayar ve sayfa görsel olarak oynar.

LCP, INP, CLS ve TBT’yi bozan scriptleri nasıl tespit edersiniz?

İlk iş, sezgiyle değil envanterle başlamaktır. Tüm üçüncü taraf origin’leri, hangi sayfada yüklendiklerini, ne işe yaradıklarını ve iş hedefiyle bağlarını tek listede toplayın. Sonra Chrome DevTools Performance kaydı açın ve sayfayı ilk yükte, ardından gerçek bir kullanıcı akışı sırasında kaydedin. Burada görmek istediğiniz şey yalnızca dosya boyutu değil; hangi scriptin hangi anda long task ürettiği ve bu görevin LCP ya da etkileşim anıyla çakışıp çakışmadığıdır.

• Performance panelinde long task bloklarını ve event handler sürelerini inceleyin.
• Network waterfall içinde üçüncü taraf origin’leri erken bağlantı maliyetine göre sıralayın.
• Coverage ile indirilen ama hiç kullanılmayan JavaScript oranını görün.
• PageSpeed Insights ve Lighthouse raporunda üçüncü taraf kod etkisini teşhis olarak kullanın.

Ardından karar ağacı kurun: kaldır, geciktir, izole et. Bir etiket sadece raporlama tekrarından ibaretse kaldırma adayıdır. Yasal olarak zorunlu ama ilk boyada kritik değilse etkileşim sonrası veya onay sonrası yüklenebilir. web.dev’in Best practices for tags and tag managers rehberi, tek sayfada birden fazla container kullanımının ve büyük container boyutunun ek yürütme maliyeti ürettiğini açıkça vurgular. Özellikle GTM, CMP, reklam pikseli, chat widget ve video embed’leri bu matriste ayrı değerlendirilmelidir.

PageSpeed Insights burada teşhis ekranıdır; nihai hüküm değil. Laboratuvar skorunu gerçek kullanıcı davranışıyla eşleştirmeden karar vermek eksik olur. Örneğin script ilk yükte hafif görünebilir ama menü açılışında, sepet etkileşiminde ya da form gönderiminde patlayabilir. Bu yüzden yalnızca açılış performansına değil, kullanıcı akışı boyunca hangi üçüncü taraf callback’lerinin devreye girdiğine bakın.

Async, defer, preconnect ve facade ile ilk yük nasıl hafifletilir?

Erteleme tekniği scriptin görevine göre seçilir. web.dev rehberine göre async, scripti HTML ayrıştırması sürerken indirir ve hazır olur olmaz çalıştırır; bu yüzden bağımsız analitik scriptlerinde işe yarar ama yürütme sırası öngörülemez. defer ise yine paralel indirir fakat HTML tamamlandıktan sonra sırayla çalıştırır; bağımlı scriptlerde daha kontrollüdür. İkisi de parser blocking’i azaltır, fakat tek başına main thread maliyetini sıfırlamaz.

Bağlantı gecikmesini azaltmak için dns-prefetch ve preconnect ekleyin. Bu özellikle GTM, video CDN’i, chat sağlayıcısı ve reklam origin’leri ayrı alan adlarında çalışıyorsa fark yaratır. web.dev, üçüncü taraf bağlantı kurulumunu erkene almanın kritik yol üzerindeki beklemeyi düşürdüğünü belirtir. Ekip içinde bu teknikleri standartlaştırmak istiyorsanız teknik terimler sözlüğü gibi ortak bir referans da iletişim maliyetini azaltır.

Facade pattern ilk yükte en yüksek kazancı genelde video, harita ve canlı destek bileşenlerinde verir. Chrome for Developers dokümanında YouTube için hafif facade bileşenleri ve canlı destek için lazy loader örnekleri önerilir. Lighthouse 13 ilgili denetimi kaldırmış olsa da teknik geçerliliğini korur: kullanıcı tıklayana kadar sadece temsili arayüz gösterilir, gerçek embed daha sonra yüklenir. Bu, ilk açılışta görünmeyen ama pahalı olan widget’ları kritik yolun dışına iter.

• YouTube ve Vimeo için hafif facade kullanın.
• Chat widget’ı tıklama, scroll veya idle sonrasına taşıyın.
• Gömülü iframe’lerde lazy yaklaşım ve uygun izolasyon uygulayın.

Partytown, server-side tagging ve CMP ertelemesi ne zaman gerekir?

Basit erteleme yetmiyorsa iki üst seviye çözüm gündeme gelir: worker’a taşıma ve sunucu tarafına kaydırma. Partytown, uygun üçüncü taraf scriptleri Web Worker içinde çalıştırarak ana iş parçacığındaki baskıyı azaltmayı hedefler. Analytics ve bazı tag senaryolarında çok faydalı olabilir. Ancak DOM’a sıkı bağlı çalışan, anlık görsel güncelleme bekleyen veya özel browser API’lerine bağımlı scriptlerde uyumluluk sorunu yaşanabilir. Bu yüzden Partytown canlıya değil, önce laboratuvar testine alınmalıdır.

Server-side tagging ise farklı bir yaklaşım sunar. Cloudflare Zaraz veya Server-Side GTM, tarayıcıdan çıkan istek sayısını düşürerek üçüncü taraf yükünü doğrudan istemci tarafında azaltabilir. Bunun bedeli, kurulum karmaşıklığı, consent akışının yeniden tasarlanması, veri eşleşmesi kontrolleri ve operasyon disiplinidir. Kısacası tarayıcı tarafı rahatlar; ama ölçüm mimarisi daha ciddi bir mühendislik işi hâline gelir. Teknik olarak doğru seçim, ekip olgunluğu ve veri gereksinimine bağlıdır.

CMP scriptleri en sık gözden kaçan INP sorunlarından biridir. Kullanıcı onay butonuna bastığında birden fazla vendor çağrısı, storage işlemi ve event tetikleniyorsa görünüşte basit etkileşim uzun bir gecikmeye dönüşebilir. Burada dürüst yaklaşım şudur: onay öncesi yalnızca gerekli minimum kodu yükleyin, onay sonrası ise kategori bazlı ek scriptleri açın. Bu sayede yasal gereklilik korunur ama tüm reklam ve analitik yükü sayfanın ilk milisaniyelerine yığılmaz.

18 tag’li GTM testinde hangi erteleme tekniği ne kazandırdı?

18 tag’li bir GTM container’ını üç ayrı senaryoda değerlendirdiğimiz laboratuvar akışında en öğretici bulgu şuydu: asıl problem etiket sayısından çok, hangi etiketin hangi anda çalıştığıydı. Standart yüklemede en pahalı bloklar çoğunlukla remarketing pikseli, chat açıcı ve CMP callback’lerinde toplandı. Flame chart içinde bunlar farklı dosyalar gibi görünse de kullanıcı tarafında tek bir deneyim oluşuyor: sayfa tıklamada ağırlaşıyor, bazen de ilk boyada gereksiz ağ rekabeti yaratıyor.

Burada sık görülen yanılgı, script’e yalnızca async ekleyince problemin çözüldüğünü sanmak. İndirme anını gevşetirsiniz ama aynı etiket tıklama anında uzun görev üretmeye devam ediyorsa INP ve TBT kayda değer biçimde düzelmez. DebugBear’in 2025 tarihli Partytown vaka çalışması bunu net gösteriyor: örnek sitede Lighthouse performans skoru yaklaşık 70’ten 99’a çıkarken asıl fark, yavaş scriptlerin main thread’den worker’a taşınmasıyla oluşuyor. Yani zamanlama kadar yürütme yeri de kritik.

Pratikte sıralama genelde şöyle çalışır: yalnızca bağlantıyı erkene almak istiyorsanız preconnect; yürütmeyi parse sonrasına itmek istiyorsanız defer; görünmeyen widget’ı ilk yükten çıkarmak istiyorsanız facade; tarayıcı yükünü kökten azaltmak istiyorsanız worker veya server-side yaklaşımı. Bu hiyerarşi kurulmadan yapılan tek ayarlık denemeler çoğu zaman skor üretmez. Özellikle GTM içinde hangi trigger’ın hangi kullanıcı anında ateşlendiğini görmeden yapılan optimizasyonlar yüzeyde kalır.

Script denetimini SEOYEN site sağlığı ile nasıl sürekli izlersiniz?

Sürekli izleme yoksa üçüncü taraf scriptler geri büyür. Yeni kampanya etiketi, yeni chat aracı ya da tekrar eklenen bir video embed’i birkaç hafta içinde aynı sorunu geri getirebilir. Bu yüzden sayfa bazlı script denetimini dönemsel bir teknik SEO rutini hâline getirmek gerekir. Türkçe arayüzde ağır JavaScript, render-blocking kaynaklar ve sorunlu sayfaları birlikte görmek için site sağlığı raporu gibi merkezi bir görünüm, sadece geliştirici ekibine değil işletme sahibine de anlaşılır bir takip zemini sunar.

Ahrefs ve SEMrush geniş veri kümeleriyle güçlü platformlardır; SEOYEN ise bu ihtiyacı Türkiye pazarına uyarlanmış, tek platformda sunar. Teknik izleme, içerik ekipleri ve işletme tarafı aynı ekran dilini kullandığında aksiyon almak kolaylaşır. Karar aşamasında Ahrefs karşılaştırması ve SEMrush karşılaştırması sayfaları iş akışı farklarını netleştirir. Plan tarafında sabit rakam yerine paket detayları üzerinden güncel seçeneklere bakmak daha sağlıklıdır.

Bu yaklaşımın pratik avantajı, performans sorununu yalnızca geliştirici konsolunda bırakmamasıdır. SEO uzmanı, küçük işletme sahibi ve geliştirici aynı sorunu aynı dille izlediğinde hangi scriptin kaldırılacağı, hangisinin geciktirileceği ve hangisinin iş hedefi nedeniyle korunacağı daha hızlı kararlaştırılır. SEOYEN’in yerel Türkçe desteği ve TL bazlı konumlandırması da bu operasyonel akışı Türkiye pazarı için daha uygulanabilir hâle getirir.

Adım Adım Üçüncü taraf script yükünü erteleyip Core Web Vitals’ı temizleme

Aşağıdaki akış, teknik SEO ve geliştirme ekiplerinin aynı sayfada kalmasını sağlar. Her adımın sonunda yeniden ölçüm yapın; aksi halde yaptığınız değişikliklerin gerçekten LCP, INP, CLS veya TBT üzerinde fark yaratıp yaratmadığını anlayamazsınız.

1. Script envanteri ve etki haritası çıkar. Tüm üçüncü taraf origin’leri, hangi sayfalarda yüklendiklerini ve hangi iş hedefini desteklediklerini tek listede toplayın. Kim ekledi, neden hâlâ gerekiyor ve ilk boyada şart mı soruları burada gereksiz kodu doğal biçimde ayıklar.
2. DevTools ve PSI ile suçluyu doğrula. Performance kaydında long task bloklarını, Network panelinde üçüncü taraf waterfall’ı, Coverage içinde de kullanılmayan kod oranını inceleyin. En pahalı scripti, sayfa açılışında mı yoksa etkileşim anında mı maliyet ürettiğine göre sınıflandırın.
3. Önemsiz kodu async veya defer yap. Bağımsız çalışan analitik scriptleri için async, sıra bağımlılığı olan ama kritik olmayan yükler için defer daha öngörülebilir olur. Parser blocking zinciri kırıldığında ilk render daha rahat nefes alır.
4. Widget ve embed’leri facade ile gizle. YouTube, harita ve chat gibi bileşenlerde kullanıcı etkileşimine kadar hafif bir temsil katmanı gösterin. Böylece ilk yükte büyük oyuncu ve widget kodunu taşımamış olursunuz.
5. GTM, CMP ve pikselleri worker veya sunucuya taşı. DOM bağımlılığı düşük scriptlerde Partytown deneyin; daha köklü azaltım gerekiyorsa Zaraz veya server-side GTM değerlendirin. Consent akışını da buna göre yeniden kurgulayın.
6. SEOYEN ile tekrar ölç ve izlemeye al. İyileşmeyi tek seferlik başarı olarak değil, sürekli denetim konusu olarak görün. Yeni eklenen etiketlerin geri bozulma üretmesini düzenli raporla yakalamak, ilk optimizasyon kadar önemlidir.

Sıkça Sorulan Sorular