Üçüncü Parti Scriptlerin Performans Etkisi

Sunucunu iyileştirdin, görselleri sıkıştırdın, önbelleği açtın; ama sayfa hâlâ ağır açılıyor. Böyle durumlarda suçlu neredeyse her zaman aynı yerde çıkar: üçüncü parti scriptler. Canlı destek widget'ı, analitik kodu, reklam pikselleri, çerez onay bandı, harici font, A/B test aracı, sosyal medya butonları... Her biri tek başına "sadece birkaç kilobayt" gibi görünür, ama tarayıcı tarafında toplandıklarında ana iş parçacığını (main thread) saniyelerce meşgul edip Core Web Vitals metriklerini yerle bir ederler. Üçüncü parti scriptlerin performans etkisi, kendi kodunun etkisinden çok daha zor fark edilir; çünkü sunucu loglarında görünmez, htop çıktısında yer almaz ve genellikle pazarlama ekibi tarafından, senden habersiz eklenir.

Bu rehberde bir scriptin gerçekte neye mal olduğunu nasıl ölçeceğini, async ve defer arasındaki farkın neden yüzeysel bir çözüm olduğunu, hangi kodun etkileşime kadar tamamen ertelenebileceğini ve bir "script bütçesi" kurarak bu kalabalığı nasıl kontrol altında tutacağını anlatacağım. Kod örnekleri gerçek, ölçüm komutları çalışır durumda; hepsini kendi sitende doğrudan deneyebilirsin.

Üçüncü Parti Script Nedir ve Maliyeti Nereden Gelir#

Üçüncü parti script, senin kontrol etmediğin bir alan adından yüklenen JavaScript dosyasıdır. Kendi sunucundan gelen app.js birinci partidir; googletagmanager.com, embed.tawk.to, connect.facebook.net veya cdn.jsdelivr.net üzerinden gelen her şey üçüncü partidir. Bu ayrım önemlidir, çünkü üçüncü parti kodun boyutu, güncellenme sıklığı, bağlandığı sunucunun hızı ve kaç ek istek başlattığı tamamen o firmanın elindedir. Sen sabah temiz bir sayfa yayınlarsın, akşam sağlayıcı kendi dosyasını iki katına çıkarır ve senin LCP değerin bir gecede bozulur.

Maliyet dört ayrı katmanda birikir ve çoğu kişi yalnızca birincisini sayar. Birincisi ağ maliyeti: yeni bir alan adı demek yeni bir DNS sorgusu, yeni TCP el sıkışması ve yeni TLS anlaşması demektir; mobil bir bağlantıda bu üçlü tek başına 300-600 ms yiyebilir. İkincisi indirme maliyeti: dosyanın kendi boyutu. Üçüncüsü ve en sinsisi ayrıştırma ve çalıştırma maliyeti: 100 KB'lık sıkıştırılmış JavaScript, açıldığında 300 KB'lık kaynak koda dönüşür ve orta seviye bir Android telefonda ayrıştırılıp derlenmesi yüzlerce milisaniye sürer. Dördüncüsü zincirleme maliyet: birçok script yüklendikten sonra kendi başına başka scriptler çağırır; tek bir etiket kodu arka planda beş ayrı sağlayıcıya bağlanabilir.

Buradaki kritik nokta şu: ilk iki katman hızlı bağlantıda ucuzlar, üçüncüsü ucuzlamaz. CPU maliyeti kullanıcının telefonuna bağlıdır ve fiber bağlantı bunu kurtarmaz. Bu yüzden "bizim sunucu hızlı, script sorun olmaz" varsayımı yanlıştır; sorun senin sunucunda değil, ziyaretçinin cihazında yaşanır.

Bir Scriptin Gerçek Maliyetini Ölçmek#

Tahminle çalışmak burada işe yaramaz; ölçmen gerekir. En hızlı yöntem Chrome DevTools'un Network sekmesinde üçüncü parti alan adlarını filtrelemektir. Sayfayı yükle, Network sekmesinde filtre kutusuna -domain:firmaniz.com yaz; geriye kalan her satır üçüncü partidir. Alt bardaki toplam transfer boyutu, senin kontrolün dışındaki yükü doğrudan gösterir.

Daha net bir tablo için Performance sekmesinde kayıt al ve Bottom-Up görünümünde "Group by Product" seçeneğini kullan; Chrome tanıdığı üçüncü parti sağlayıcıları isimleriyle listeler ve her birinin ana iş parçacığında kaç milisaniye harcadığını gösterir. 200 ms üzerindeki her satır bir sorudur: bu kod bu parayı hak ediyor mu?

Komut satırından tekrarlanabilir ölçüm istiyorsan Lighthouse'un CLI sürümü işini görür:

# Lighthouse'u kur ve mobil profilde ölç
npm install -g lighthouse
lighthouse https://firmaniz.com \
  --only-categories=performance \
  --preset=desktop \
  --output=json --output-path=./rapor.json

# Raporun içinden üçüncü parti özetini çek
cat rapor.json | jq '.audits["third-party-summary"].details.items[]
  | {sunucu: .entity, engelleme_ms: .blockingTime, boyut: .transferSize}'

Çıktı şuna benzer ve doğrudan hangi sağlayıcının pahalı olduğunu söyler:

{"sunucu":"Google Tag Manager","engelleme_ms":412,"boyut":128430}
{"sunucu":"Tawk.to","engelleme_ms":286,"boyut":214980}
{"sunucu":"Google Fonts","engelleme_ms":0,"boyut":41220}

Burada engelleme_ms (blocking time) en önemli sütundur, boyut değil. Görüldüğü gibi Google Fonts 41 KB indirdiği hâlde ana iş parçacığını hiç engellemez, çünkü CSS'tir; buna karşılık Tawk.to hem büyüktür hem de 286 ms boyunca tarayıcıyı meşgul eder. Toplam engelleme süresi (TBT) doğrudan bu satırların toplamıdır ve kullanıcının "sayfa açıldı ama tıklayamıyorum" hissini yaratan metrik budur.

Ölçümü yalnızca bir kez yapıp bırakma. Sağlayıcılar kodlarını haber vermeden büyütür, bu yüzden ayda bir aynı ölçümü tekrarlayıp karşılaştır. Sayfa hızını bir bütün olarak izlemek istiyorsan GTmetrix ile hız testi yazısındaki yöntem üçüncü parti dökümünü de içerir.

Yükleme Stratejileri: async, defer ve Gerçek Erteleme#

Bir script etiketini nasıl yazdığın, tarayıcının HTML ayrıştırmasını durdurup durdurmayacağını belirler. Üç temel biçim vardır ve aralarındaki fark, klasik bir mülakat sorusu olmanın ötesinde gerçek milisaniyeler kazandırır:

<script src="https://ucuncuparti.com/kod.js"></script>
<script async src="https://ucuncuparti.com/kod.js"></script>
<script defer src="https://ucuncuparti.com/kod.js"></script>

Sırasıyla: birincisi engelleyicidir, HTML ayrıştırması durur, dosya indirilir, çalıştırılır ve ancak sonra devam edilir. İkincisi (async) paralel indirilir ama indiği anda ayrıştırmayı keserek çalışır ve sıra garantisi vermez. Üçüncüsü (defer) paralel indirilir, HTML tamamen ayrıştırıldıktan sonra yazdığın sırayla çalışır.

Genel kural şudur: head içinde async veya defer olmayan hiçbir üçüncü parti script kalmamalı. defer, async'e göre neredeyse her zaman daha iyidir; çünkü async script indiği anda araya girip render'ı kesebilirken defer sıraya girip DOM hazır olana kadar bekler. Analitik kodları için async, işlevsel kodlar için defer mantıklı bir başlangıçtır.

Ancak burada bilmen gereken bir gerçek var: defer bile scripti sayfa yüklenirken çalıştırır. Yani ilk boyamayı geciktirmez ama TBT'yi ve etkileşime hazır olma süresini hâlâ bozar. Canlı destek, ısı haritası, anket widget'ı gibi kullanıcı etkileşimi olmadan hiçbir işe yaramayan kodlar için doğru cevap defer değil, tam ertelemedir: scripti ilk kullanıcı etkileşimine kadar hiç yükleme.

<script>
// Widget'ı ilk gerçek etkileşime ya da 6 saniyeye kadar hiç yükleme.
(function () {
  var yuklendi = false;
  var olaylar = ['pointerdown', 'keydown', 'touchstart', 'scroll'];

  function yukle() {
    if (yuklendi) return;
    yuklendi = true;
    olaylar.forEach(function (e) {
      window.removeEventListener(e, yukle, { passive: true });
    });
    var s = document.createElement('script');
    s.src = 'https://embed.ucuncuparti.com/widget.js';
    s.async = true;
    document.head.appendChild(s);
  }

  olaylar.forEach(function (e) {
    window.addEventListener(e, yukle, { passive: true });
  });
  // Hiç etkileşim olmazsa yine de yükle: ölçüm kaybı olmasın.
  setTimeout(yukle, 6000);
})();
</script>

Bu on beş satırlık kalıp, pratikte gördüğüm en yüksek getirili tek değişikliktir. Chat widget'ının 250 ms'lik engelleme süresi, ilk boyamadan tamamen çıkar; kullanıcı sayfaya dokunduğunda zaten içerik ekranda olduğu için gecikme hissedilmez. Aynı yaklaşımı ısı haritaları, öneri motorları ve sosyal paylaşım butonları için de uygulayabilirsin.

Bağlantı İpuçları ve Kendi Sunucundan Sunma#

Scripti tamamen silemiyorsan, en azından ağ katmanındaki gecikmeyi kısalt. Tarayıcıya "bu alan adına birazdan bağlanacağım, DNS ve TLS'i şimdiden hallet" demenin standart yolu preconnecttir:

<link rel="preconnect" href="https://www.googletagmanager.com" crossorigin>
<link rel="dns-prefetch" href="https://www.googletagmanager.com">

preconnect sadece gerçekten kullanacağın ve kritik olan iki-üç alan adı için kullanılmalıdır; her alan adına preconnect koymak tarayıcının bağlantı havuzunu tüketir ve ters teper. dns-prefetch daha ucuzdur ve destek vermeyen tarayıcılar için yedek görevi görür.

İkinci yöntem, mümkün olan yerde scripti kendi alan adından sunmaktır. Bir kütüphaneyi CDN'den çekmek yerine kendi sunucuna kopyaladığında üç kazanç elde edersin: yeni bir bağlantı kurulmaz, dosya kendi HTTP/2 bağlantın üzerinden çoğullanır ve önbellek sürelerini sen belirlersin. Nginx tarafında bu, birkaç satırlık bir iştir:

# Kendi sunduğun statik kütüphaneler için uzun ömürlü önbellek
location ^~ /vendor/ {
    root /var/www/firmaniz.com/public;
    add_header Cache-Control "public, max-age=31536000, immutable";
    access_log off;
}

Dosya adına içerik özeti (jquery.3.7.1.min.js gibi bir sürüm ya da hash) koyduğun sürece bu bir yıllık önbellek tamamen güvenlidir; sürüm değişince URL değişir ve tarayıcı yeni dosyayı çeker. Önbellek başlıklarının mantığını derinleştirmek istersen Cache-Control başlıkları yazısı bu kalıbın neden immutable ile birlikte kullanıldığını ayrıntısıyla anlatıyor.

Bu yöntemin iki sınırı var: sağlayıcı sürekli güncellenen bir kod sunuyorsa (analitik, reklam) kendi kopyanı tutmak lisans ihlali ya da işlevsel bozulma yaratabilir; ayrıca güvenlik yamalarını sen takip etmek zorunda kalırsın. Sabit kütüphaneler için kopyala, canlı servisler için preconnect ile yetin.

Sık Yapılan Hatalar ve Tuzaklar#

Bu alanda tekrar tekrar gördüğüm hatalar oldukça standarttır ve hepsinin ortak yanı, kimsenin kasten yapmamış olmasıdır. Sırayla gidelim.

1. Ölü scriptleri silmemek. İki yıl önce denenip bırakılan bir ısı haritası aracı hâlâ her sayfada yükleniyor olabilir. Yılda bir kez tüm <script> etiketlerini listeleyip her biri için "bu verinin sahibi kim, en son ne zaman baktı" diye sor. Sahibi bulunamayan script silinir.
2. Etiket yöneticisini çöp kutusuna çevirmek. Etiket yöneticileri tek satır kod eklemeyi kolaylaştırdığı için içleri hızla dolar. Yönetici kapsayıcısının kendisi hafiftir ama içine attığın her etiket ayrı bir üçüncü parti bağlantısıdır. Bunun ölçümü için Google Analytics ve Tag Manager hız etkisi yazısındaki yöntemi kullan.
3. Widget'ın düzeni kaydırmasına izin vermek. Sonradan yüklenen bir çerez bandı ya da duyuru çubuğu, içeriği aşağı iterek CLS puanını bozar. Yer tutucu yükseklik ayırmak ya da widget'ı position: fixed bir katmanda tutmak bunu çözer; ayrıntı için düzen kaymasını düzeltme yazısına bak.
4. Senkron script'i body sonuna koyup "hallettim" sanmak. Evet, ilk boyamayı engellemez; ama DOMContentLoaded olayını hâlâ geciktirir ve etkileşime hazır olma süresini uzatır. Kritik olmayan hiçbir şey senkron kalmamalı.
5. Sağlayıcının çökmesine karşı hazırlıksız olmak. Senkron yüklenen bir üçüncü parti script'in sunucusu yanıt vermezse sayfan zaman aşımı süresi boyunca boş kalır. async/defer bunu da azaltır: sağlayıcı çökse bile sayfan açılır.
6. Yalnızca masaüstünde test etmek. Ayrıştırma maliyeti CPU'ya bağlıdır. DevTools'ta CPU kısıtlamasını "4x slowdown" yapmadan alınan hiçbir ölçüm gerçeği yansıtmaz.

Bir de sessiz bir güvenlik boyutu var: üçüncü parti script senin sayfanda, senin alan adında, tam yetkiyle çalışır. Sağlayıcının kodu ele geçirilirse ziyaretçinin oturum bilgilerine erişebilir. Sabit dosyalar için integrity özniteliği (SRI) bu riski kapatır:

<script src="https://cdn.ornek.com/lib-1.4.2.min.js"
        integrity="sha384-oqVuAfXRKap7fdgcCY5uykM6+R9GqQ8K/uxy9rx7HNQlGYl1kPzQho1wx4JwY8wC"
        crossorigin="anonymous" defer></script>

Dosyanın içeriği değişirse tarayıcı onu çalıştırmayı reddeder. Sürekli güncellenen servislerde SRI kullanılamaz; bu da "hangi scripte gerçekten güveniyorum" sorusunu bir kez daha sormanı gerektirir.

Script Bütçesi Kurmak ve Sürdürmek#

Tek seferlik temizlik işe yarar ama üç ayda eski hâline döner. Kalıcı çözüm bir bütçe belirlemek ve bunu ölçülebilir hâle getirmektir. Pratikte işe yarayan eşikler şöyledir:

Bu tabloyu ekiple paylaş ve yeni bir araç talebi geldiğinde tek soruyu sor: "Bütçeyi aşıyorsa hangi mevcut scripti kaldırıyoruz?" Bu, teknik bir tartışmayı bütçe tartışmasına çevirir ve pazarlama tarafında çok daha net anlaşılır.

Otomatik denetim için basit bir kontrol de kurabilirsin. Aşağıdaki komut, yayınlanan HTML'de kaç ayrı harici script alan adı olduğunu sayar ve eşiği aşarsa hata döner; bunu CI hattına koyabilirsin:

#!/usr/bin/env bash
# Yayındaki sayfada harici script alan adlarını say
LIMIT=6
SAYI=$(curl -s https://firmaniz.com/ \
  | grep -oE 'src="https?://[^"]+' \
  | sed -E 's#src="https?://([^/"]+).*#\1#' \
  | grep -v 'firmaniz.com' \
  | sort -u | tee /dev/stderr | wc -l)

echo "Harici script alan adı sayısı: $SAYI (limit $LIMIT)"
[ "$SAYI" -le "$LIMIT" ] || { echo "BÜTÇE AŞILDI"; exit 1; }

Sunucu tarafındaki yanıt süren zaten iyiyse bu tür kazanımlar doğrudan kullanıcıya yansır. Yanıt süren dalgalıysa önce alt yapıyı sağlamlaştırmak gerekir; VDS gibi kaynağı garantili bir sunucuda tarayıcı tarafındaki iyileştirmeler çok daha net ölçülür.

Sıkça Sorulan Sorular#

Üçüncü parti scriptler SEO'yu etkiler mi#

Dolaylı ama gerçek bir etkisi vardır. Google, sayfa deneyimi sinyalleri arasında Core Web Vitals metriklerini kullanır ve üçüncü parti scriptler özellikle LCP ile INP değerlerini bozar. Ayrıca tarama bütçesi açısından da fark yaratır: ağır sayfalar daha yavaş taranır. Scriptin kendi içeriği indekslenmez, ama yavaşlığın maliyeti sıralamaya yansır.

async mı defer mi kullanmalıyım#

Çoğu durumda defer daha güvenlidir, çünkü scriptler HTML tamamen ayrıştırıldıktan sonra yazdığın sırayla çalışır ve render'ı ortasından kesmez. async yalnızca birbirinden tamamen bağımsız, sırası önemsiz ve mümkün olduğunca erken çalışması gereken kodlar (klasik analitik kodları) için mantıklıdır. Kullanıcı etkileşimi olmadan işe yaramayan widget'lar içinse ikisi de yetersizdir; onları tamamen ertelemelisin.

Chat widget'ını kaldırmadan hızlandırabilir miyim#

Evet, ve genellikle kaldırmaya gerek kalmaz. Widget'ı sayfa yüklenirken değil, ilk kullanıcı etkileşiminde (kaydırma, dokunma, tuş) yükleyen küçük bir sarmalayıcı yazmak çoğu zaman 200-400 ms engelleme süresini tamamen ortadan kaldırır. Kullanıcı sohbet balonuna tıklamak istediğinde yükleme birkaç yüz milisaniye sürer ama bu, ilk açılıştaki gecikmeden çok daha az rahatsız edicidir.

Kaç tane üçüncü parti script fazla sayılır#

Kesin bir sayı yoktur; önemli olan toplam engelleme süresidir. Yine de pratik bir eşik vermek gerekirse, dört ayrı üçüncü parti alan adının üzerine çıktığında dikkatli olmalısın; sekizin üzeri neredeyse her zaman sorunludur. Sayıdan çok şuna bak: Lighthouse raporundaki üçüncü parti engelleme toplamı 150 ms'yi aşıyorsa bütçen dolmuş demektir.

Scriptleri kendi sunucumdan sunmak her zaman daha mı hızlı#

Genellikle evet, ama istisnası var. Sabit sürümlü kütüphaneler için kendi sunucundan sunmak yeni bir DNS/TLS turunu ortadan kaldırdığı için nettir. Buna karşılık sürekli güncellenen analitik ve reklam kodlarını kopyalamak hem işlevi bozabilir hem de güvenlik yamalarını senin takip etmeni gerektirir. Sabit olanı kopyala, canlı olanı preconnect ile hızlandır.

Üçüncü parti script'in çökmesi siteyi tamamen durdurur mu#

Senkron yüklüyorsan büyük ölçüde evet: tarayıcı o dosyayı beklerken HTML ayrıştırmasını durdurur ve zaman aşımı süresince ekran boş kalabilir. async ya da defer kullandığında bu risk ortadan kalkar; sağlayıcı yanıt vermese bile sayfan normal şekilde açılır, sadece ilgili işlev çalışmaz. Bu tek başına bile senkron etiketleri terk etmek için yeterli bir gerekçedir.

Etkiyi ölçmenin en hızlı yolu nedir#

Chrome DevTools'ta sayfayı bir kez normal, bir kez de tüm üçüncü parti alan adlarını engelleyerek yükle. Network sekmesinde ilgili alan adına sağ tıklayıp "Block request domain" diyerek engelleyebilirsin. İki ölçüm arasındaki LCP ve TBT farkı, o scriptin gerçek maliyetidir. Bu yöntem tahmin yürütmeyi tamamen ortadan kaldırır ve beş dakika sürer.

Kapanış#

Üçüncü parti scriptler tek tek bakıldığında masum, toplandığında sayfanın en pahalı parçasıdır. Aklında kalması gereken dört alışkanlık şudur: her scripti eklemeden önce sahibini ve gerekçesini yaz, ölçümü boyuta değil engelleme süresine göre yap, etkileşim gerektiren her widget'ı ilk dokunuşa kadar ertele ve yılda en az bir kez ölü scriptleri temizle. Bu dördü uygulandığında çoğu sitede toplam engelleme süresi yarıya iner, üstelik tek bir satır uygulama kodu değişmeden.

Tarayıcı tarafındaki bu iyileştirmeler, altındaki sunucu yanıt süresi sağlam olduğunda gerçekten hissedilir. Kaynağı paylaşmayan bir altyapıya geçmek istersen VDS ve bulut sunucu paketlerimiz sabit CPU ve bellek garantisi verir; WordPress tarafında eklenti kaynaklı script şişmesiyle uğraşıyorsan WordPress hosting paketlerimizdeki hazır önbellek katmanı iyi bir başlangıç noktasıdır. Ölçüm ve optimizasyon işini tamamen devretmek istersen SEO ve sunucu yönetimi hizmetlerimiz bu denetimi düzenli olarak senin yerine yapar.