Üçüncü Taraf Betikler Siteyi Nasıl Yavaşlatır? Pixel, Sohbet ve Etiketler

Biz Talha Aslan ve ekibi olarak hız denetimlerinde sorunun çoğu zaman sitenin kendi kodunda değil, yıllar içinde eklenip unutulan bu harici kodlarda biriktiğini görüyoruz. Bu rehberde ölçmeyi, ertelemeyi ve gereksizleri temizlemeyi adım adım anlatıyoruz. Ayrıca en hassas noktayı, yani dönüşüm ölçümünü bozmadan nasıl ilerleyeceğinizi de ele alıyoruz.

Genel JavaScript optimizasyonu için JavaScript'in site hızına etkisi yazımıza bakabilirsiniz; burada yalnız dışarıdan gelen kodlara odaklanıyoruz.

Hangi kodları üçüncü taraf olarak görmelisiniz?

Basit bir ölçüt var: kod sizin alan adınızdan değil de başka bir sunucudan geliyorsa üçüncü taraftır. Örneğin example.com üzerinde çalışan bir mağaza düşünün. Sayfada bir analiz etiketi, iki reklam pikseli, bir sohbet balonu, gömülü bir video ve bir yorum aracı varsa, bunların her biri ayrı bir dış kaynaktır.

Tipik gruplar şunlardır:

• Reklam ve dönüşüm pikselleri (arama ve sosyal medya reklam platformları).
• Analiz ve ısı haritası araçları.
• Canlı sohbet, destek ve chatbot eklentileri.
• Etiket yöneticisi konteyneri ve içine eklenen etiketler.
• Gömülü video, harita ve sosyal medya akışları.
• A/B testi, kişiselleştirme ve çerez onay araçları.

Ancak her dış kod kötü değildir. Bazıları gelir, ölçüm ya da yasal zorunluluk için gerçekten gerekir. Asıl soru, her birinin sağladığı değerin hız maliyetini karşılayıp karşılamadığıdır. Bu nedenle ilk iş, neyin nereden geldiğini ortaya çıkarmaktır.

Üçüncü taraf betikler ağ tarafında neden gecikme yaratır?

Her yeni alan adı, tarayıcı için yeni bir bağlantı demektir. Tarayıcı önce adı çözer, sonra güvenli bağlantıyı kurar, ardından dosyayı ister. web.dev'in üçüncü taraf JavaScript yükleme rehberi de çok sayıda farklı sunucuya istek göndermenin sayfayı yavaşlattığını açıkça belirtir.

Üstelik bu kodlar çoğu zaman kendi başına kalmaz. Bir piksel yüklendiğinde arkasından ek istekler, ek kütüphaneler ve bazen sizin sitenizde zaten bulunan bir kütüphanenin ikinci kopyası gelir. Yani tek satırlık bir kurulum, perde arkasında onlarca isteğe dönüşebilir.

Bir başka risk de dış sunucunun yavaşlamasıdır. Kod eşzamanlı (senkron) yükleniyorsa ve karşı taraf yanıt vermiyorsa, tarayıcı sayfanın geri kalanını işlemeyi bekletebilir. Kısacası sizin kontrolünüzde olmayan bir sunucu, sizin sayfanızın açılış süresini belirlemeye başlar. Bu yüzden ağ tarafında iki hedef koyuyoruz: daha az alan adı ve kritik yolun dışında kalan yüklemeler.

Ana iş parçacığı neden tıkanır?

Tarayıcının ana iş parçacığı (main thread), sayfayı çizen, kodu çalıştıran ve tıklamalara yanıt veren tek bir hattır. Bir kod uzun süre çalışırsa bu hat meşgul kalır. O sırada kullanıcı bir düğmeye bassa bile tarayıcı yanıtı ancak iş bitince verebilir.

Üçüncü taraf kodlar burada iki şekilde zarar verir. İlk olarak indirildikten sonra ayrıştırılıp çalıştırılmaları gerekir; büyük bir sohbet eklentisi bu aşamada ciddi işlemci zamanı harcar. Ayrıca birçok etiket sayfadaki tıklama ve kaydırma olaylarını dinler. Böylece her etkileşimde sizin kodunuzun yanında onların kodu da çalışır.

Chrome'un Lighthouse belgelerinde yer alan "Reduce the impact of third-party code" denetimi, üçüncü taraf kodun yükleme sırasında ana iş parçacığını toplamda 250 milisaniye veya daha uzun süre engellediği sayfaları işaretler. Lighthouse sürümleri ilerledikçe bu denetimin adı ve yeri değişebilir; yine de mantık aynı kalır. Dolayısıyla yalnız dosya boyutuna değil, işlemci süresine de bakmanız gerekir.

Reklam pikselleri hızı ne kadar etkiler?

Tek tek bakınca reklam pikselleri küçük bir yük gibi durur. Ancak tipik bir e-ticaret sitesinde birden fazla platformun pikseli, her biri kendi kütüphanesini de getirir. Üstelik aynı platformun pikseli hem sayfa kodunda hem de etiket yöneticisinde aynı anda bulunabilir; bu durumda hem hız hem veri kalitesi zarar görür.

Örnek senaryo: example.com'da biri Meta pikselini tema dosyasına elle koymuş; aynı piksel bir de etiket yöneticisinden çalışıyor. Sonuçta tarayıcı kodu iki kez indiriyor ve platform satın alma olayını iki kez sayıyor. Bu çift sayım sorununu Meta pikseli ve Dönüşümler API'si yinelenen etkinlik yazımızda ayrıca anlattık.

Pikselleri kaldırmak çoğu zaman seçenek değildir, çünkü reklam optimizasyonu bu veriye dayanır. Bu nedenle hedef, pikselleri silmek yerine tek bir yerden, tek kopya halinde ve doğru zamanda yüklemektir. Bunun yanında kullanılmayan eski kampanyaların piksellerini ayıklamak, çoğu sitede en hızlı kazanımdır. Örneğin bir yıl önce biten bir kampanyanın piksel kodu, kimse fark etmeden her ziyaretçide çalışmaya devam edebilir.

Canlı sohbet eklentileri neden bu kadar ağırdır?

Canlı sohbet eklentileri yalnız bir balon göstermez; mesajlaşma arayüzünü, bildirim mantığını, bazen yazı tiplerini ve ek kütüphaneleri de getirir. web.dev'in tembel yükleme rehberleri de sohbet eklentilerinin çoğunun önemli miktarda JavaScript indirdiğini ve bunun yüklemeyi ve kullanıcı girdisine yanıtı olumsuz etkileyebileceğini belirtir.

İşin ilginç tarafı şu: ziyaretçilerin küçük bir bölümü sohbeti gerçekten açar. Ama tarayıcı eklentiyi her sayfa görüntülemesinde, herkes için indirir. Yani maliyeti herkes öder, faydayı az kişi görür.

Bu yüzden sohbet eklentileri, erteleme ve "cephe" yöntemi için en uygun adaylardır. Sohbeti kapatmanız gerekmez; yalnız gerçek eklentinin ne zaman yükleneceğini değiştirirsiniz. Örneğin balon ekranda kalır, ama asıl kod kullanıcı balona yaklaştığında ya da tıkladığında gelir. Bu yöntemi aşağıda ayrı bir başlıkta adım adım anlatıyoruz. Sohbet ve chatbot entegrasyonlarının iş tarafı için web sitesinde yapay zeka kullanımı yazımıza da göz atabilirsiniz.

Mobil cihazlarda etki neden daha belirgindir?

Masaüstü bilgisayarda fark etmediğiniz bir yük, orta seviye bir telefonda belirgin bir gecikmeye dönüşebilir. Çünkü telefon işlemcileri JavaScript'i daha yavaş işler ve mobil bağlantılar daha değişkendir. Bu nedenle web.dev'in yavaş kod tespit rehberi de ölçümleri mobil profil ve işlemci yavaşlatmasıyla yapmayı önerir.

Search Console da mobil ve masaüstü verisini ayrı gösterir. Örneğin masaüstünde "İyi" görünen bir şablon, mobilde INP nedeniyle zayıf kalabilir. Böyle bir tabloda ilk şüpheliniz, mobilde de her sayfada çalışan ağır dış kodlar olmalıdır.

Pratik bir öneri: ölçümlerinizi kendi güçlü bilgisayarınızda değil, kısıtlama açık bir mobil profilde yapın. Ayrıca mümkünse gerçek bir orta seviye telefonda sayfayı açıp sohbet balonunun, çerez bandının ve reklam alanlarının ne zaman belirdiğine bakın. Kullanıcılarınızın çoğu mobildeyse, kararlarınızı da mobil sonuca göre verin. Kısacası masaüstündeki temiz bir test sonucu, mobildeki gerçek deneyimin yerini tutmaz; özellikle kampanya trafiğinin büyük bölümü sosyal medyadan ve telefonlardan geliyorsa bu fark daha da önem kazanır.

Bu işte ekip içinde kim neyi üstlenir?

Dış kod sorunları çoğu zaman teknik değil, organizasyoneldir. Pazarlama ekibi piksel ister, destek ekibi sohbet ister, yazılım ekibinden hız beklenir; ama kimse resmin tamamını görmez. Bu yüzden rolleri baştan netleştirmenizi öneriyoruz.

• Pazarlama: Hangi pikselin hangi kampanya için gerektiğini ve bitiş tarihini belirler.
• Yazılım: Yükleme yöntemini, erteleme ve cephe uygulamasını yönetir.
• Analiz sorumlusu: Dönüşüm olaylarının değişiklik öncesi ve sonrası tutarlılığını kontrol eder.
• SEO sorumlusu: Search Console verisini ve laboratuvar ölçümlerini takip eder.

Böylece bir kodu silme kararı tek bir kişinin tahminine kalmaz. Ayrıca yeni bir kod talebi geldiğinde hangi ekibin onay vereceği de bellidir; bu da konteynerin yeniden dağılmasını önler. Küçük ekiplerde bu rollerin hepsini bir veya iki kişi üstlenebilir; önemli olan, rollerin yazılı olması ve her değişikliğin kayda geçmesidir. Üstelik her değişikliğin bir sahibi olduğu için geri alma da kolaylaşır.

Etiket yöneticisi yükü nasıl birikir?

Etiket yöneticisi, kod değiştirmeden etiket eklemeyi kolaylaştırır. Bu kolaylık ise zamanla bir yüke dönüşür. Kampanya biter, ajans değişir, test bitir; ama etiketler konteynerde kalır. Google Tag Manager nedir yazımızda temel kurulumu anlattık; burada performans tarafına bakıyoruz.

web.dev'in etiket ve etiket yöneticisi en iyi uygulamaları sayfası önemli bir gözleme yer verir: etiket yöneticilerinin boyutu ile daha zayıf INP puanları arasında bir ilişki gözlemlenmiştir. Aynı kaynak, bir sayfada birden fazla konteynerin ciddi performans sorunları yaratabileceğini de belirtir.

Yükün tipik kaynakları şunlardır:

• Kullanılmayan ama hâlâ yerinde duran etiketler, tetikleyiciler ve değişkenler.
• Her sayfada tetiklenen ama yalnız birkaç sayfada gereken etiketler.
• Özel HTML etiketleriyle gelen büyük kütüphaneler.
• Aynı sayfada çalışan birden fazla konteyner.

Kısacası etiket yöneticisi tek başına sorun değildir; sorun, kimsenin sahiplenmediği dağınık bir konteynerdir.

Bu kodlar Core Web Vitals metriklerini nasıl bozar?

Google'ın Core Web Vitals sayfası, LCP için ilk 2,5 saniyeyi, INP için 200 milisaniyenin altını ve CLS için 0,1'in altını hedef olarak gösterir. Bu metriklerin ne anlama geldiğini Core Web Vitals nedir yazımızda ayrıntılı anlattık.

Üçüncü taraf kodların her metrikle ilişkisi farklıdır:

• LCP: Kritik yolda yüklenen dış kodlar, ana görselin ya da başlığın görünmesini geciktirir.
• INP: Ana iş parçacığını meşgul eden etiketler, tıklamalara yanıtı yavaşlatır.
• CLS: Sonradan beliren sohbet balonları, reklam alanları ve bannerlar sayfa düzenini kaydırır.

Öte yandan Google bu metriklerde iyi sonuç almayı arama başarısı için önerir, ama tek başına sıralama garantisi sunmaz. Biz de hız iyileştirmesini sıralama vaadi olarak değil, kullanıcı deneyimi ve dönüşüm için yaptığımız bir yatırım olarak konumluyoruz. INP tarafında daha derine inmek isterseniz INP iyileştirme rehberimiz işinize yarar.

Search Console'da sorunun izini nasıl sürersiniz?

Search Console'daki Core Web Vitals raporu, gerçek kullanıcı verisine (alan verisi, field data) dayanır. Resmi yardım sayfasına göre rapor benzer sayfaları gruplar ve grubun durumunu en zayıf metriğe göre belirler. Grup durumları "Zayıf", "İyileştirme gerekli" ve "İyi" olarak çıkar.

Üçüncü taraf kaynaklı sorunlarda tipik bir işaret şudur: aynı şablonu kullanan tüm sayfalar birlikte kötüleşir. Örneğin sohbet eklentisi tüm ürün sayfalarına eklendiyse, ürün sayfası grubu toplu olarak INP sorunu gösterebilir. Bu durumda tek tek sayfalara değil, şablona ve o şablonda çalışan dış kodlara bakarsınız.

Düzeltmeyi yaptıktan sonra sorun ayrıntı sayfasında doğrulamayı başlatırsınız (Türkçe arayüzde "İzlemeyi Başlat", İngilizcede "Start Tracking"). Google bu aşamada yaklaşık 28 günlük bir izleme dönemi uygular, çünkü gerçek kullanıcı verisinin birikmesi zaman alır. Raporun genel kullanımını Google Search Console rehberimizde ayrıca bulabilirsiniz.

Üçüncü taraf betikleri tek tek nasıl ölçersiniz?

Raporlar size "sorun var" der, ama hangi kodun sorumlu olduğunu söylemez. Bunun için laboratuvar ölçümü gerekir. Biz şu sırayı izliyoruz:

1. Lighthouse ile mobil profilde bir performans testi alın ve üçüncü taraf kaynaklarını gösteren bölümlere bakın. Ayrıntılı kullanım için Lighthouse ile site performans testi yazımıza göz atın.
2. Chrome Geliştirici Araçları'nda Network panelini açın, şüpheli isteğe sağ tıklayın ve isteği engelleme seçeneğini (Block request URL) kullanın.
3. Sayfayı ağ ve işlemci kısıtlamasıyla yeniden yükleyin, sonucu engelsiz sürümle karşılaştırın.
4. Her ölçümü en az üç kez tekrarlayın ve ortanca değeri kullanın.
5. Farkı bir tabloya yazın: kod adı, alan adı, engellendiğinde değişen metrik.

web.dev'in yavaş üçüncü taraf kodları tespit rehberi de bu engelleme yöntemini ve en az üç ölçümün ortancasını önerir. Böylece "sohbet eklentisi yavaş" gibi bir his yerine, ölçtüğünüz bir farkla karar verirsiniz.

Sitede hangi araçların yüklü olduğunu hızlıca görmek için site altyapı tespiti aracımızı da kullanabilirsiniz.

Betik envanterini adım adım nasıl çıkarırsınız?

Ölçmeden önce listeyi çıkarmak gerekir. Envanter, temizliğin temelidir; neyin neden orada olduğunu bilmeden hiçbir şeyi güvenle silemezsiniz.

1. Ana sayfa, kategori, ürün, sepet ve teşekkür sayfası gibi temsil edici şablonları seçin.
2. Her şablonda Network panelinden dış alan adlarını listeleyin.
3. Tema dosyalarında, eklentilerde ve etiket yöneticisinde aynı kodun kaç kez geçtiğini kontrol edin.
4. Her kod için bir sahip yazın: pazarlama, satış, destek ya da yazılım.
5. Her kodun amacını tek cümleyle not edin: hangi raporu besliyor, hangi kararı destekliyor?
6. Son kullanım tarihini sorun; kimse bilmiyorsa kod "aday" listesine girer.

Örnek senaryo: example.com'da envanter sonunda on dört dış kod çıkıyor; bunların dördünün sahibi yok, ikisi kapanmış bir kampanyaya ait. İşte bu tablo, sonraki adımdaki kararların hammaddesidir. Özellikle "sahibi yok" sütunu, en hızlı temizlik fırsatlarını gösterir.

Hangi kodu kaldırmalı, hangisini ertelemelisiniz?

Envanterden sonra her kod için dört seçenekten birini seçersiniz. web.dev'in önerisi nettir: kod sitenize açık bir değer katmıyorsa kaldırın. Kalanlar için aşağıdaki tabloyu karar aracı olarak kullanıyoruz.

Tablo bir başlangıç çerçevesidir, kesin kural değildir. Örneğin bir B2B sitesinde sohbet, satış görüşmesinin ana kaynağı olabilir; bu durumda erteleme yöntemini daha dikkatli seçersiniz.

async ve defer arasında nasıl seçim yaparsınız?

Dış kodların çoğu, sayfanın çizilmesi için gerekli değildir. web.dev rehberi bu nedenle kritik görüntüleme yolunda zorunlu olmadıkça üçüncü taraf kodlar için her zaman async ya da defer kullanılmasını önerir.

İkisinin farkını kısaca şöyle özetleyebiliriz:

• async: Kod arka planda iner ve hazır olduğu anda çalışır. Sıra garantisi yoktur; bağımsız etiketler için uygundur.
• defer: Kod arka planda iner, ama sayfa ayrıştırması bitince ve sırayla çalışır. Birbirine bağlı kodlar için daha güvenlidir.

Ancak aynı rehber önemli bir uyarı da yapar: async kullanmak, birçok izleme kodunun sayfa yüklemesini yavaşlatmasını tek başına engellemez. Çünkü kod yine iner ve yine ana iş parçacığında çalışır. Yani async, kodun engelleyiciliğini azaltır ama maliyetini ortadan kaldırmaz.

Bu yüzden async ve defer'i ilk adım olarak görüyoruz. Asıl kazanım, kodu daha geç tetiklemekten, yalnız gereken sayfalarda çalıştırmaktan ve gereksizini silmekten gelir. Tema ya da eklenti bu ayarları vermiyorsa, değişikliği geliştiricinizle birlikte test ortamında yapın.

Cephe yöntemi sohbet ve video için nasıl çalışır?

Cephe (facade), gerçek eklentiye benzeyen ama işlevi olmayan, çok hafif bir yer tutucudur. Chrome'un cephe belgesi akışı üç aşamada anlatır:

1. Sayfa açılırken tarayıcı gerçek eklenti yerine hafif cepheyi indirir.
2. Kullanıcı imleci cepheye getirdiğinde, cephe üçüncü taraf sunuculara önceden bağlantı kurar.
3. Kullanıcı tıkladığında cephe kendini gerçek eklentiyle değiştirir.

Örnek senaryo: example.com'da sohbet balonu, aynı görünümde bir düğmeye dönüşüyor. Ziyaretçi düğmeye tıklayana kadar sohbet kodu hiç inmiyor. Böylece sohbeti açmayan çoğunluk, eklentinin maliyetini ödemiyor.

Bunun da bedeli var. Aynı belge, cephelerin gerçek eklentinin tüm işlevlerini sunmadığını hatırlatır; örneğin yeni mesaj rozeti gerçek kod yüklenene kadar görünmeyebilir. Ayrıca tembel yüklenen videolarda otomatik oynatma tutarlı çalışmayabilir. Not: Bu belge Lighthouse'un yeni sürümünde ilgili denetimin kaldırıldığını da belirtir; yani rapor size artık cephe önermeyebilir, ama yöntem geçerliliğini korur. Bu nedenle kararı rapordaki bir uyarıya değil, kendi engelleme ölçümünüze dayandırın.

Etiket yöneticisini nasıl hafifletirsiniz?

web.dev'in etiket rehberi, temizlik için net bir yol çizer. Biz de denetimlerde aşağıdaki sırayla ilerliyoruz:

1. Kullanılmayan etiketleri tetikleyici istisnasıyla engellemek yerine duraklatın ya da silin; ardından onlara ait tetikleyicileri ve değişkenleri de temizleyin.
2. Kritik olmayan etiketleri sayfa tamamen yüklendikten sonra (Window Loaded) tetikleyin; kaynak, bir etiket ne kadar erken tetiklenirse performansa etkisinin o kadar büyük olduğunu belirtir.
3. Tetikleyici koşullarını daraltın; etiket yalnız gerektiği sayfalarda çalışsın.
4. Sayfa başına tek konteyner kullanın.
5. Özel HTML etiketleri yerine mümkünse hazır şablonları tercih edin.
6. Her etikete bir sahip ve kısa bir açıklama ekleyin.

Ayrıca erişimi sınırlayın. web.dev, etiket yöneticisine erişimi olan herkesin siteye JavaScript ekleyebileceğini hatırlatır. Dolayısıyla eski ajans hesaplarını, ayrılan çalışanları ve kullanılmayan kullanıcıları düzenli olarak kaldırmak hem güvenlik hem hız için önemlidir.

Bu adımlar küçük gibi durur, ama birikmiş bir konteynerde sonuç belirgin olabilir. Yine de her değişikliği yayınlamadan önce önizleme ve hata ayıklama modunda test edin.

Dönüşüm ölçümünü bozmadan nasıl temizlik yaparsınız?

Hız çalışmasının en büyük riski, satış ve potansiyel müşteri verisini kaybetmektir. Bir pikseli yanlış zamana ertelediğinizde ya da yanlış tetikleyiciye bağladığınızda, reklam platformu dönüşümü göremez. Bu nedenle temizliği her zaman ölçüm planıyla birlikte yürütüyoruz.

1. Önce hangi olayların iş için kritik olduğunu yazın: satın alma, form gönderimi, arama, telefon tıklaması gibi.
2. Bu olayların hangi kod ve hangi tetikleyiciyle gönderildiğini envantere işleyin.
3. Değişiklikten önce son iki haftanın olay sayılarını not edin.
4. Değişikliği önizleme modunda deneyin, olayların hâlâ gittiğini doğrulayın.
5. Yayından sonra birkaç gün boyunca olay sayılarını eski dönemle karşılaştırın.

Önemli bir kural: dönüşüm etiketlerini "sayfa tamamen yüklendikten sonra" gibi geç tetikleyicilere taşımadan önce, kullanıcının o ana kadar sayfada kaldığından emin olun. Aksi halde hızlı çıkan kullanıcıların dönüşümü kaybolabilir.

Çerez onayı da bu denkleme dahildir. Onay alınmadan hangi etiketin çalışmayacağını Google Consent Mode v2 yazımızda anlattık; hız temizliği bu ayarları bozmamalıdır.

Önceden bağlantı ve kendi sunucunuzda barındırma işe yarar mı?

Bazı dış kodlar gerçekten gereklidir ve sayfanın erken aşamasında yüklenmelidir. Bu durumda bağlantı süresini kısaltmak anlamlıdır. web.dev rehberi iki ipucu verir: alan adı çözümlemesini erkene almak için dns-prefetch, güvenli bağlantıyı önceden kurmak için preconnect.

Ancak bu ipuçlarını her dış alan adına eklemek ters etki yapabilir, çünkü tarayıcı gereksiz bağlantılarla meşgul olur. Biz yalnız sayfanın ilk saniyelerinde gerçekten kullanılan bir veya iki dış alan adı için öneriyoruz.

Kendi sunucunuzda barındırma (self-hosting) da bir seçenektir. Aynı kaynak, üçüncü taraf sunucu yavaşsa kodu kendi sunucunuzda barındırmayı düşünebileceğinizi söyler. Öte yandan bu durumda kod güncellemeleri kendiliğinden almaz; güncellemeyi siz takip etmek zorunda kalırsınız. Ayrıca bazı platformlar kodun yalnız kendi sunucularından yüklenmesini bekler. Kısacası bu yöntem, bakım sorumluluğunu üstlenebilecek ekipler için uygundur. Ölçüm kodlarını sunucu tarafına taşıma fikri için sunucu tarafı entegrasyon yazımıza bakabilirsiniz.

Örnek senaryo: example.com'da bir temizlik turu nasıl ilerler?

Aşağıdaki akış gerçek bir müşteri vakası değildir; yöntemi somutlaştırmak için kurguladığımız bir örnek senaryodur.

example.com bir ev tekstili mağazası olsun. Search Console'da ürün sayfası grubu INP nedeniyle "İyileştirme gerekli" durumunda duruyor. Ekip envanteri çıkarıyor ve şu tabloyu buluyor: iki reklam pikseli hem temada hem etiket yöneticisinde, bir ısı haritası aracı tüm sayfalarda, sohbet eklentisi her sayfada ve eski bir A/B testi kodu hâlâ aktif.

Ardından ekip şu adımları atıyor:

• Temadaki yinelenen piksel kodlarını kaldırıp yalnız etiket yöneticisindeki sürümü bırakıyor.
• Biten A/B testinin kodunu siliyor.
• Isı haritasını yalnız iki kampanya sayfasıyla sınırlıyor.
• Sohbet eklentisini cephe yöntemine geçiriyor.
• Satın alma ve sepete ekleme olaylarını önizleme modunda test ediyor.

Sonra laboratuvar ölçümlerini tekrarlıyor ve Search Console'da doğrulamayı başlatıyor. Sonucun ne olacağını önceden bilemezsiniz; alan verisi gerçek kullanıcılardan gelir ve zaman alır. Ama süreç ölçülebilir ve geri alınabilir olduğu için risk düşük kalır.

Üçüncü taraf betikler için kalıcı bir düzeni nasıl kurarsınız?

Tek seferlik temizlik birkaç ay içinde geri döner, çünkü yeni kampanyalar yeni kodlar getirir. Bu yüzden asıl hedef bir yönetişim düzenidir. Bizim önerdiğimiz basit kurallar şunlardır:

• Yeni dış kod eklemeden önce amacını, sahibini ve bitiş tarihini yazın.
• Her çeyrekte envanteri yeniden gözden geçirin.
• Etiket yöneticisine erişimi yalnız aktif ekip üyelerine verin.
• Yeni bir kod ekledikten sonra kısa bir hız ölçümü alın.
• Search Console'daki Core Web Vitals raporunu ayda bir kontrol edin.

Bu düzeni sitenizde kendi başınıza kurmakta zorlanıyorsanız, bu sorunu sitenizde biz çözer, takip ederiz. SEO danışmanlığı hizmetimiz kapsamında envanteri çıkarıyor, ölçüm planını koruyarak temizliği yapıyor ve sonuçları raporluyoruz. Sıralama garantisi vermiyoruz; ama sitenizin yavaşlamasının nedenini ortaya çıkarıyor ve yönetilebilir hale getiriyoruz.

Sonuç: nereden başlamalısınız?

Üçüncü taraf betikler modern bir sitenin parçasıdır; onları tamamen kaldırmak ne mümkün ne de gerekli. Önemli olan, her birinin neden orada olduğunu bilmek ve maliyetini ölçmektir.

Başlamak için üç adım yeterli: envanteri çıkarın, en ağır kodları engelleme yöntemiyle ölçün ve sahibi olmayan kodları ayıklayın. Ardından sohbet ve video gibi ağır eklentileri erteleyin, etiket yöneticisini sadeleştirin ve her adımda dönüşüm olaylarını test edin. Genel bir hız ve SEO ilişkisi için site hızı SEO'yu nasıl etkiler yazımız iyi bir tamamlayıcıdır.

Bu işi ekip olarak sizin yerinize yürütmemizi isterseniz, SEO danışmanlığı sayfamızdan sitenizin adresiyle teklif isteyebilirsiniz. Mevcut kodlarınızı inceleyip size özel bir temizlik ve takip planı hazırlarız.

Temel rehber: Dijital Pazarlama Nedir? Türleri, örnekleri ve nasıl yapıldığı, beynin içinden geçen etkileşimli bir filmle tek sayfada.