Bu scriptlerin büyük çoğunluğu geliştirici değil pazarlama veya büyüme ekibi tarafından eklenir; genellikle bir tag manager arayüzü üzerinden. Git geçmişinde izi yoktur, kod incelemesinden geçmez ve deploy döngüsüne bağlı değildir. Üçüncü parti scriptler bağımsız olarak güncellenir: bir analytics aracının yeni sürümü daha fazla işlem yapıyor olabilir, bir sohbet widget'ının son güncellemesi yeni bir alt kaynak ekliyor olabilir. Bu değişiklikler sitenin performansını sessizce etkiler; bildirim gelmez, deploy log'u oluşmaz.

Tarayıcı için ise bunlar sıradan scriptlerdir. Birinci parti kodla aynı main thread'i paylaşırlar, aynı parse ve execution maliyetini doğururlar ve ek olarak harici bir ağ bağlantısı kurma yükü getirirler. Sayfa yükü sırasında bu maliyetlerin toplamı, kendi yazdığınız tüm JavaScript'in maliyetini kolayca geçebilir; ama kaynak kodunuza bakıldığında hiçbiri görünmez.

Tarayıcı, üçüncü parti scripti birinci partiden ayırt etmez

Tarayıcı HTML ayrıştırırken karşılaştığı her <script src="..."> etiketini aynı süreçten geçirir: kaynak indirilir, parse edilir, bytecode'a derlenir, execute edilir. Bu adımların tamamı main thread üzerinde gerçekleşir. Scriptin üçüncü bir partiden gelmesi bu süreci değiştirmez; tarayıcı açısından anlamlı bir ayrım değildir.

Birinci parti scriptlerden farklı olan iki nokta vardır. İlki, üçüncü parti scriptlerin farklı bir etki alanından gelmesidir. Bu, tarayıcının önce DNS çözümlemesi yapması, ardından TCP bağlantısı kurması, ardından TLS el sıkışması tamamlaması gerektiği anlamına gelir. Bu üç adım birlikte çoğu zaman 100–300 ms arasında sürer. Script içeriği küçük olsa bile bağlantı kurma maliyeti sabit bir taban oluşturur. İkincisi, bu scriptler üzerinde doğrudan kontrol yoktur: ne kadar büyük oldukları, ne kadar işlem yaptıkları, hangi alt kaynakları çektikleri bir kara kutu içinde kalır ve her güncellemeyle sessizce değişebilir.

<link rel="preconnect"> ile kritik üçüncü parti etki alanlarına önceden bağlantı açmak, bu taban maliyeti ödeme anını öne alır. Tarayıcı bağlantıyı sayfa yüklenir yüklenmez başlatır; script indirilmeye hazır olduğunda bekleme süresi çoğunlukla sıfırlanmış olur. Ama preconnect sınırsız uygulanmamalıdır: gerçekten kullanılmayan bir etki alanı için açılan bağlantı boşuna tüketilen kaynaktır ve belirli bir eşikten sonra preconnect'in kendi maliyeti belirginleşir.

Render blocking zinciri ve script yükleme sırası

Bir script <head> içine async veya defer niteliği olmadan yerleştirildiğinde, tarayıcı HTML ayrıştırmayı o noktada durdurur ve scriptin indirilmesini ve çalıştırılmasını bekler. Bu süre boyunca sayfada hiçbir şey görünmez; kullanıcı boş veya kısmen yüklü bir ekranla karşılaşır. Tek bir blocking script bile LCP'yi ciddi biçimde geciktirebilir — özellikle ağ koşullarının zorlu olduğu mobil bağlantılarda.

Google Tag Manager'ın önerilen kurulum kodu senkron biçimde <head> içine eklenir. GTM yüklendikten sonra kendi içinde tanımlanan her tag sırayla execute edilir. Beş analytics etiketi, bir sohbet widget'ı etiketi ve iki dönüşüm izleme etiketi tanımlanmışsa GTM bunları art arda çalıştırır. Her biri main thread'i meşgul eder; bir önceki bitmeden sonraki başlamaz. Bu zincirleme yürütme sürecinin toplamı, tek başına ölçüldüğünde makul görünen her scriptin bireysel maliyetini katlar.

defer ve async nitelikleri bu zinciri kırar. defer ile yüklenen bir script HTML ayrıştırması tamamlanana kadar execute edilmez; sıra garantisi korunur. async ile yüklenen bir script indirildiği anda çalışır; sıra garantisi yoktur. Üçüncü parti scriptler için defer çoğunlukla daha güvenli bir seçimdir: sayfa içeriği önce görünür, script sonra execute edilir. Hangi niteliğin hangi senaryoda uygun olduğunu defer ve async arasındaki fark konusundan takip edebilirsiniz.

Birden fazla üçüncü parti scriptin blocking olarak yüklenmesi bir render blocking zinciri oluşturur. İlk script indirilip execute olana kadar HTML ayrıştırması durur; bu sırada ikinci scriptin indirme işlemi de başlayamamış olabilir. Peş peşe gelen blocking scriptler, ağ gecikmelerini katlar ve toplam etkiyi büyütür. Render engelleyen kaynakları azaltmak bu anlamda yalnızca birinci parti JavaScript ve CSS için değil, üçüncü parti yükler için de geçerlidir.

Long task fabrikası: execution maliyeti birikir

Bir scriptin ağdan indirilmesi tamamlandıktan sonra asıl iş başlar. Parse, compile ve execute aşamaları main thread üzerinde çalışır. Bu süre boyunca kullanıcı etkileşimleri, animasyonlar ve DOM güncellemeleri sıraya girmek zorunda kalır.

Üçüncü parti scriptlerin problematik tarafı, execution süreleri üzerinde kontrol bulunmamasıdır. Bir analytics scripti sayfa görüntülemesini kayıt altına alırken çerez değerlerini okuyabilir, oturum verisi hesaplayabilir ve ağ isteği başlatabilir. Bir sohbet widget'ı bağlantı kurabilir, mesaj geçmişini senkronize edebilir ve DOM güncellemesi yapabilir. Reklam scriptleri kendi alt scriptlerini çeker; bu alt scriptler ek ağ bağlantıları ve execution görevleri ekler. Bu görevler kümülatif olarak ölçülür; toplamları 50 ms'yi aşan bölümler long task olarak işaretlenir ve TBT değerine yansır.

INP metriği bu birikimin doğrudan göstergesidir. Kullanıcı bir düğmeye tıkladığında sayfanın yanıt vermesi için main thread'in o anda müsait olması gerekir. Eğer bir üçüncü parti script bu noktada long task üretiyorsa etkileşim yanıtsız kalır ya da belirgin bir gecikmeden sonra yanıt gelir. INP değerinin yüksek olduğu sayfalarda üçüncü parti script maliyeti sıklıkla görülen nedenlerden biridir ve Performance panelinde uzun "Evaluate Script" görevleri olarak izlenebilir.

Üçüncü parti scriptlerin sessiz bir riski daha vardır: güncellenir. Sitenize dokunmadan, deploy yapmadan, bilginiz olmadan bir scriptin yeni sürümü devreye girebilir. Bu sürüm daha fazla işlem yapıyor, yeni bir alt kaynak çekiyor ya da yükleme sırasını değiştiriyor olabilir. Periyodik ölçüm yapılmıyorsa bu değişiklik kayıt dışında kalır; yavaşlayan bir sayfa rakipsiz kaynak gibi görünür.

Ağ maliyeti: her etki alanının bağlantı yükü

Her üçüncü parti etki alanı kendi ağ maliyetini getirir. HTTP/2 bağlantı çoğullaması yalnızca aynı origin içinde geçerlidir; farklı etki alanlarından gelen on script on ayrı bağlantı döngüsü demektir. Aynı CDN'den gelen iki script bir bağlantıyı paylaşabilir; farklı sağlayıcıların scriptleri paylaşamaz.

Waterfall diyagramı bu maliyeti somutlaştırır. WebPageTest veya Chrome DevTools Network panelinde bir üçüncü parti scriptin zaman çizelgesi incelendiğinde DNS lookup, TCP bağlantısı ve TLS el sıkışması her etki alanı için bağımsız bloklar olarak görünür. 20 KB bir script 280 ms'de indiriliyorsa bu sürenin büyük bölümü içeriği aktarmakla değil bağlantı kurmakla geçmiş olabilir. Script boyutu küçük görünür ama toplam maliyet beklentinin üzerinde kalır.

Bazı scriptler kendi alt scriptlerini dinamik olarak çeker. GTM bir tag tetiklediğinde o tag kendi kaynağını indirebilir. Analytics araçları belirli koşullarda ek endpoint'lere istek atabilir. Reklam sistemleri kendi sağlayıcı kütüphanelerini yükleyebilir. Sayfa başında görünen on istek, tüm yükleme tamamlandığında yirmi isteğe dönüşebilir. Bu zincir, Network panelinde "Initiator" sütunu takip edilerek adım adım izlenebilir; hangi scriptin neyi tetiklediği orada görünür.

Gecikmeli yükleme ve facade stratejileri

Üçüncü parti scriptlerin maliyetini azaltmanın en etkili yolu, kritik yükleme yolundan çıkarmaktır. Kullanıcı sayfayı görene kadar chatbot açık değilse sohbet widget'ının JavaScript kütüphanesi o ana kadar yüklenmiş olmak zorunda değildir.

Facade pattern bu ertelemenin görsel bütünlüğünü korur. Gerçek widget yerine görsel olarak aynı görünen hafif bir yer tutucu gösterilir. Kullanıcı tıkladığında veya üzerine geldiğinde gerçek script yüklenir ve widget aktif hale gelir. Bu yaklaşım özellikle sohbet widget'ları ve video embed'leri için yaygın kullanılır. YouTube'un lite embed çözümleri bu mantığı hayata geçirir: kullanıcı video küçük resmini görür; tıkladığında asıl oynatıcı ve kütüphanesi yüklenir. Ana sayfa yükleme sırasında yüzlerce kilobayt JavaScript ve ağ bağlantı maliyeti sıfırlanmış olur.

GTM bağlamında tetikleyici bazlı yükleme benzer bir kazanım sağlar. Her tag her ziyarette execute edilmek zorunda değildir. Dönüşüm izleme tagları yalnızca belirli bir form gönderiminde çalışması gereken scriptlerdir; her sayfa görüntülemesinde execute etmek için bir neden yoktur. Belirli bir sayfada, belirli bir olay gerçekleştiğinde veya kullanıcı scroll eşiğini geçtiğinde tetiklenecek şekilde yapılandırılan taglar, ana yükleme sırasındaki execution yükünü belirgin biçimde azaltır.

Sayfanın load olayı tetiklendikten sonra veya kısa bir setTimeout gecikmesiyle scripti dinamik olarak enjekte etmek basit ama etkili bir yaklaşımdır:

window.addEventListener('load', function() {
  var script = document.createElement('script');
  script.src = 'https://widget.example.com/loader.js';
  script.async = true;
  document.head.appendChild(script);
});

Bu yöntem kritik yükleme yolunu temizler: sayfa içeriği önce görünür, widget sonra devreye girer. Kullanıcı sayfanın kullanılabilir hale gelmesini beklemez; widget yüklenirken etkileşime geçebilir.

Üçüncü parti maliyetini ölçmek ve izole etmek

Hangi scriptin ne kadar maliyet taşıdığını görmeden öncelik belirlemek güçtür. Birkaç araç bu görünürlüğü sağlar.

Chrome DevTools Network panelinde kaynak listesi "Domain" başlığına göre sıralandığında birinci ve üçüncü parti istekler ayrışır. Her etki alanı için toplam transfer boyutu ve istek sayısı görünür hale gelir. Performance panelinde kaydedilen bir oturumda "Bottom-Up" veya "Call Tree" sekmeleri hangi scriptin ne kadar execution süresi harcadığını gösterir; üçüncü parti URL'ler bu listede tanımlanabilir. "Timings" satırında FCP ve LCP işaretleri görülürse, bu işaretlerin hemen öncesindeki script execute olayları incelemeye değer adaylardır.

Lighthouse'un "Reduce the impact of third-party code" uyarısı her üçüncü parti kaynağı listeler ve ana iş parçacığı bloklama süresini ms cinsinden gösterir. Bu liste hangi scriptin en fazla yük getirdiğini belirlemek için doğrudan kullanılabilir. Lighthouse uyarılarını önceliklendirirken bu başlığın Opportunity kategorisinde yer aldığını — yani bir metrik iyileştirmesine doğrudan işaret ettiğini — akılda tutmak önemlidir.

WebPageTest'in "Waterfall" görünümü tüm istekleri zaman çizelgesinde sunar; farklı etki alanları renk kodlamasıyla ayrıştırılır. "Request Map" sekmesi sayfanın hangi üçüncü parti etki alanlarına bağlandığını ve bu bağlantıların birbirini nasıl tetiklediğini ağ grafiği olarak gösterir. Alt script zincirlerini izlemek için bu görünüm özellikle değerlidir: bir scriptin başka scriptleri dinamik olarak çekip çekmediği burada net biçimde ortaya çıkar.

Üçüncü parti scriptler için en zor olan görünmezlikleridir. Kaynak kodunda doğrudan bir <script> etiketi olarak değil, çoğunlukla bir tag manager arayüzü üzerinden yaşarlar. Denetim yapılmadığı sürece hangi scriptlerin etkin olduğu, kaç isteğin üretildiği ve her birinin ne kadar main thread maliyeti taşıdığı bilinemez. Üç veya altı ayda bir Lighthouse raporu almak, Network panelinde üçüncü parti istekleri saymak bu görünmezliği ortadan kaldırmanın en pratik yoludur.

Her eklenen scriptin işlevsel bir gerekçesi olmalıdır. Aktif olarak kullanılmayan bir analytics etiketi, kapatılmış bir A/B test denemesinin kalan kodu veya değiştirilmiş ancak eski scripti hâlâ yüklü olan bir araç, gerçek bir hizmet sunmadan maliyet üretmeye devam eder. Bu scriptleri kaldırmak başka bir optimizasyon tekniği uygulamaktan çok daha kolay ve çok daha anlık bir kazanım sağlar. Üçüncü parti script maliyeti hiçbir zaman sıfıra indirilemez — bu scriptlerin büyük bölümünün gerçek bir işlevi vardır. Ama blocking olarak yüklenen bir script defer ile yüklenebilir, her ziyarette çalışan bir tag belirli olaylarla sınırlandırılabilir, sayfa açılır açılmaz yüklenen bir widget tıklamaya kadar ertelenebilir. Bu kararların her biri ayrı ayrı küçük görünür ama TBT, LCP ve Core Web Vitals üzerindeki kümülatif etkisi ölçüm sonuçlarına yansır.