Sitene Google Analytics ekledin, sonra pazarlama ekibi Tag Manager istedi; derken GTM konteynerinin içine reklam pikselleri, ısı haritası, form takibi ve üç ayrı dönüşüm etiketi doldu. Bir süre sonra PageSpeed raporunda "üçüncü parti kodun etkisini azaltın" uyarısı görünmeye başladı ama kimse hangi etiketin ne kadara mal olduğunu bilmiyor. Google Analytics ve Tag Manager'ın hız etkisi tam da böyle, görünmez şekilde birikir: tek tek bakınca hiçbiri felaket değildir, toplamı ise ana iş parçacığını (main thread) saniyelerce meşgul eder ve Total Blocking Time'ı yukarı çeker.
Bu rehberde GA4 ile GTM'nin tarayıcıda gerçekte ne yaptığını, maliyetin hangi katmanlarda oluştuğunu, bunu hem lab hem saha verisiyle nasıl ölçeceğini, konteyneri nasıl temizleyeceğini ve gerekirse sunucu taraflı etiketlemeye nasıl geçeceğini anlatacağım. Amacım "analitiği kaldır" demek değil; ölçemediğin işi yönetemezsin. Amacım aynı veriyi çok daha ucuza toplamanı sağlamak.
GA4 ve GTM Tarayıcıda Ne Yükler#
Önce kafa karışıklığını gidereyim: GA4 ile GTM aynı şey değil, ama neredeyse her zaman birlikte yüklenirler. Doğrudan GA4 kurduysan sayfana gtag.js gelir. Tag Manager kurduysan önce gtm.js gelir; konteynerin içinde bir GA4 etiketi tanımlıysa GTM, aynı sunucudan ikinci bir dosya olarak gtag.js'i de çeker. Yani GTM kullanmak GA4'ün maliyetini ortadan kaldırmaz, üstüne kendi maliyetini ekler.
Klasik iki kurulum şu şekilde görünür. Önce doğrudan GA4 kurulumu, yani gtag.js:
<script async src="https://www.googletagmanager.com/gtag/js?id=G-XXXXXXXXXX"></script>
<script>
window.dataLayer = window.dataLayer || [];
function gtag(){ dataLayer.push(arguments); }
gtag('js', new Date());
gtag('config', 'G-XXXXXXXXXX');
</script>
Ardından Tag Manager konteyner kodu:
<script>
(function(w,d,s,l,i){
w[l]=w[l]||[]; w[l].push({'gtm.start': new Date().getTime(), event:'gtm.js'});
var f=d.getElementsByTagName(s)[0], j=d.createElement(s), dl=(l!='dataLayer'?'&l='+l:'');
j.async=true; j.src='https://www.googletagmanager.com/gtm.js?id='+i+dl;
f.parentNode.insertBefore(j,f);
})(window,document,'script','dataLayer','GTM-XXXXXXX');
</script>
Dikkat edilecek nokta şudur: async özniteliği dosyanın indirilmesini engellemez, sadece HTML ayrıştırmasını bloklamamasını sağlar. Dosya indiği anda tarayıcı onu çalıştırmak için ana iş parçacığını durdurur. Yani async sana ağ paralelliği kazandırır, CPU maliyetinden kurtarmaz. Bu ayrımı üçüncü parti scriptlerin performans etkisi yazısında daha geniş anlattım; buradaki analiz onun GA4'e özel hâli.
Maliyet Nerede Oluşuyor#
Maliyeti dört kalemde düşün. Çoğu kişi sadece ilk ikisini sayar, oysa asıl acıyı üçüncü ve dördüncü verir.
| Kalem | Neyi tüketir | Ne zaman ortaya çıkar | Nerede görürsün |
|---|---|---|---|
| Bağlantı kurulumu | Ağ (DNS + TCP + TLS) | İlk ziyarette | Network sekmesi, Connection satırı |
| İndirme | Bant genişliği | Her yeni sürümde | Transfer Size sütunu |
| Ayrıştırma ve çalıştırma | CPU / ana iş parçacığı | Dosya indikten hemen sonra | Performance sekmesi, Script Evaluation |
| Etiket çalıştırma | CPU + ek istekler | Sayfa yüklendikçe ve olay tetiklendikçe | Initiator zinciri |
googletagmanager.com senin alan adın olmadığı için tarayıcı sıfırdan bir bağlantı kurar: DNS çözümlemesi, TCP el sıkışması ve TLS anlaşması. Mobil bir bağlantıda bu üçlü tek başına birkaç yüz milisaniye yiyebilir. Üstelik GTM konteyneri açıldıktan sonra içindeki etiketler kendi sağlayıcılarına bağlanır; tek bir gtm.js isteği arka planda dört beş farklı alan adına yeni bağlantı doğurabilir. Zincirleme maliyet dediğim şey budur ve raporlarda "üçüncü parti" satırının neden beklediğinden büyük çıktığını açıklar.
En sinsi kalem ayrıştırma ve çalıştırmadır. Sıkıştırılmış hâlde küçük görünen bir JavaScript dosyası, açıldığında birkaç katı büyüklüğünde kaynak koda dönüşür ve orta seviye bir Android telefonda ayrıştırılıp derlenmesi masaüstündekinin kat kat üstünde sürer. Kendi bilgisayarında "hiç fark etmiyor" demenin sebebi budur; ölçümü mutlaka kısıtlanmış CPU ile yapmalısın.
Gerçek Maliyeti Ölçmek#
Tahminle çalışma. Önce lab ortamında tek bir kontrollü ölçüm al, sonra saha verisiyle doğrula.
Lab tarafı için Chrome DevTools yeterlidir:
- Gizli pencerede siteyi aç, DevTools'u aç ve Network sekmesine geç.
- Sağ üstteki hız kısıtlamasını Slow 4G, Performance sekmesindeki CPU kısıtlamasını 4x slowdown yap.
- Performance sekmesinde kaydı başlatıp sayfayı yenile, kayıt bitince alt taraftaki Bottom-Up görünümünde gruplamayı "Group by domain" yap.
googletagmanager.comsatırındaki toplam süreyi not al. Bu, GA4 ve GTM'nin ana iş parçacığında geçirdiği süredir.- Aynı ölçümü bir de konteyneri devre dışı bırakarak tekrarla; iki sonucun farkı senin gerçek maliyetindir.
Konteyneri geçici olarak kapatmanın en kolay yolu isteği engellemektir: Network sekmesinde gtm.js isteğine sağ tıklayıp Block request URL demen yeterli. Sunucu tarafında da hızlı bir boyut kontrolü yapabilirsin:
# Konteynerin sıkıştırılmış ve açılmış boyutunu karşılaştır
curl -s -H 'Accept-Encoding: gzip' \
-o /tmp/gtm.js.gz -w 'Sikistirilmis: %{size_download} bayt\n' \
'https://www.googletagmanager.com/gtm.js?id=GTM-XXXXXXX'
gzip -dc /tmp/gtm.js.gz | wc -c # acilmis bayt sayisi
Saha tarafı için Chrome User Experience Report (CrUX) verisine bak ya da web-vitals kütüphanesiyle kendi ölçümünü topla. Lab ölçümü sana "neden" sorusunu, saha ölçümü "kaç kullanıcıyı etkiliyor" sorusunu cevaplar. Bu ikisini karıştırmamak önemlidir: tek bir Lighthouse skoru düşük çıktı diye panikleyip çalışan bir ölçüm altyapısını sökmek, çoğu zaman kârdan çok zarar getirir. LCP metriğini ayrıca iyileştirmek istiyorsan LCP nasıl iyileştirilir yazısındaki sıralamayı takip et; analitik genellikle LCP'yi değil TBT'yi bozar.
Konteyneri Şişiren Şeyler#
GTM'nin kendi çekirdeği görece küçüktür. Konteyneri asıl şişiren, içine yıllar içinde eklenip bir daha hiç kaldırılmayan etiketlerdir. Tipik bir kurumsal konteynerde şunları görürüm: iki farklı Analytics sürümü (biri kapatılmış ama silinmemiş), üç reklam platformunun dönüşüm pikseli, bir ısı haritası aracı, kullanılmayan bir A/B test kodu, bir zamanlar denenmiş bir chat widget'ı ve "acaba lazım olur mu" diye bırakılmış özel HTML etiketleri.
Bu tabloyu düzenli olarak çıkar ve her satır için tek soru sor: bu etiketin verisine son 90 günde kim baktı?
| Etiket türü | Tipik maliyet | Silmek kolay mı | Not |
|---|---|---|---|
| GA4 yapılandırma | Orta | Hayır, çekirdek | Tek konfig etiketi yeter |
| Reklam dönüşüm pikseli | Orta-yüksek | Kampanya bitince evet | Aktif kampanyaya bağla |
| Isı haritası / oturum kaydı | Çok yüksek | Genellikle evet | Örnekleme oranını düşür |
| Özel HTML etiketi | Değişken | Evet | En sık unutulan kalem |
| Sosyal medya pikseli | Orta | Evet | Birden fazla varsa tekilleştir |
Pratik temizlik adımları şöyle işler. Önce GTM'nin Preview modunu açıp ana sayfada tetiklenen etiketleri say; ana sayfada tetiklenmesi gereken etiket sayısı genellikle beşten azdır. Sonra "Tüm Sayfalar" tetikleyicisine bağlı ne varsa gözden geçir; bunların çoğunun aslında yalnızca belirli sayfalarda çalışması yeterlidir. Ardından etiket sıralamasını gözden geçir: dönüşüm pikselleri gibi kritik olmayan etiketleri DOM Hazır yerine Pencere Yüklendi tetikleyicisine taşımak ilk boyamayı belirgin biçimde rahatlatır. Son olarak konteynerin sürüm geçmişine bak; "test" adıyla yayınlanmış ve unutulmuş sürümler şaşırtıcı sıklıkta canlıdadır.
Yükleme Stratejileri ve Consent Mode#
Ölçümü tamamen kaybetmeden maliyeti düşürmenin birkaç kademesi var. Aşağıdakileri sırayla dene; yukarıdan aşağı gittikçe kazanç artar, uygulama zorluğu da artar.
Birinci kademe, bağlantıyı erkenden kurmaktır. Bu maliyeti azaltmaz, ama bekleme süresini kısaltır:
<link rel="preconnect" href="https://www.googletagmanager.com" crossorigin>
<link rel="dns-prefetch" href="https://www.googletagmanager.com">
İkinci kademe, konteyneri ilk etkileşime veya boşta kalma anına ertelemektir. Sayfanın ilk boyaması bittikten sonra yüklemek, hemen çıkan ziyaretçilerin verisini biraz kaybettirir ama TBT'yi ciddi biçimde düşürür:
<script>
// GTM'i ilk etkileşimde ya da 4 saniye sonra yukle
(function () {
var loaded = false;
function loadGtm() {
if (loaded) return;
loaded = true;
var s = document.createElement('script');
s.async = true;
s.src = 'https://www.googletagmanager.com/gtm.js?id=GTM-XXXXXXX';
document.head.appendChild(s);
}
['pointerdown', 'keydown', 'touchstart', 'scroll'].forEach(function (evt) {
window.addEventListener(evt, loadGtm, { once: true, passive: true });
});
setTimeout(loadGtm, 4000);
})();
</script>
Üçüncü kademe Consent Mode'dur ve Türkiye'de KVKK açısından da işine yarar. Ziyaretçi çerez onayı vermeden önce varsayılanı reddedilmiş olarak ayarlarsın; onay gelince güncellersin. Bu hem hukuki olarak doğru davranıştır hem de onay vermeyen ziyaretçilerde bazı ağ isteklerinin hiç yapılmamasını sağlar:
<script>
window.dataLayer = window.dataLayer || [];
function gtag(){ dataLayer.push(arguments); }
gtag('consent', 'default', {
ad_storage: 'denied',
ad_user_data: 'denied',
ad_personalization: 'denied',
analytics_storage: 'denied',
wait_for_update: 500
});
</script>
Dördüncü kademe, scripti tamamen ana iş parçacığından çıkarmaktır. Partytown gibi çözümler üçüncü parti kodu bir web worker içinde çalıştırır; CPU maliyeti ana iş parçacığından ayrılır. Kazancı gerçektir ama her etiket worker içinde sorunsuz çalışmaz, bu yüzden canlıya almadan önce her etiketin verisini karşılaştırmalı olarak doğrulaman şart.
Sunucu Taraflı Etiketleme#
Asıl köklü çözüm, ölçümü tarayıcıdan sunucuya taşımaktır. Sunucu taraflı GTM'de tarayıcı tek bir hafif istek atar; etiketleri çalıştırma, veriyi zenginleştirme ve reklam platformlarına gönderme işini senin kontrol ettiğin bir sunucu üstlenir. Kazançlar somut: tarayıcıda çalışan JavaScript miktarı düşer, üçüncü parti alan adı sayısı azalır, istekler kendi alan adından gittiği için içerik engelleyicilerden ve tarayıcı kısıtlamalarından daha az etkilenir.
Bedeli de gerçektir ve peşinen bilmelisin: bir sunucu çalıştırman, ölçeklendirmen ve faturasını ödemen gerekir. Trafik arttıkça bu sunucu da büyümelidir. Kendi altyapında tutmak istersen VDS ya da bulut sunucu üzerinde bir konteyner çalıştırmak makul bir başlangıçtır; bakımını üstlenmek istemezsen sunucu yönetimi hizmeti bu yükü alır. Ayrıca ölçüm uç noktası kendi alan adının altında olacağı için önüne bir CDN koymak isteyeceksin; nasıl çalıştığını CDN nedir, nasıl çalışır yazısında bulabilirsin.
Karar verirken şu eşiği kullanıyorum: aylık birkaç yüz bin sayfa görüntülemenin altındaysan ve etiket sayın azsa, iyi temizlenmiş bir istemci taraflı kurulum fazlasıyla yeterlidir. Bunun üstünde, özellikle reklam harcaman ölçüm kalitesine bağlıysa, sunucu taraflı kurulum hem hız hem veri doğruluğu açısından kendini amorti eder.
Sık Yapılan Hatalar#
En yaygın hata, hem doğrudan gtag.js hem de GTM üzerinden GA4 kurmaktır. Site iki kez ölçüm gönderir, hem veri bozulur hem de maliyet ikiye katlanır. Kaynak koda bakıp googletagmanager.com geçen tüm satırları saymak bunu ilk dakikada ortaya çıkarır.
İkinci hata, konteyneri <head> içinde senkron çalıştırmaktır. GTM'nin resmî snippet'i zaten async kullanır; bunu elle değiştirip senkron hâle getiren temalar gördüm ve sonuç her zaman ilk boyamanın gecikmesi oldu.
Üçüncü hata, ısı haritası veya oturum kaydı araçlarını yüzde yüz örneklemeyle çalıştırmaktır. Bu araçlar kullanıcı etkileşimlerini sürekli dinler ve DOM'u izler; en pahalı üçüncü parti kategorisi genellikle budur. Örnekleme oranını düşürmek veriyi anlamlı biçimde bozmaz ama maliyeti doğrudan azaltır.
Dördüncü hata, ölçümü tamamen kaldırıp hız skorunu düzeltmiş gibi görünmektir. Skor yükselir, ama artık hangi sayfanın dönüşüm getirdiğini bilemezsin. Doğru yaklaşım, gereksiz etiketleri silip kalanları geciktirmektir. Beşinci ve son hata, değişiklik sonrası ölçmemektir: her temizlikten sonra aynı koşullarda tekrar ölçüp kazancı rakamla görmezsen, bir sonraki eklemede aynı yere geri dönersin.
Sıkça Sorulan Sorular#
Google Analytics siteyi gerçekten yavaşlatır mı#
Evet, ama etkisi büyük ölçüde kurulumuna bağlıdır. Tek başına iyi yapılandırılmış bir GA4 kodu modern bir sitede genellikle fark edilir bir gecikme yaratmaz. Sorun, GA4'ün yanına eklenen ısı haritası, reklam pikselleri ve özel HTML etiketleriyle birlikte ana iş parçacığında biriken toplam süredir. Ölçmeden karar verme; DevTools'ta domain bazlı gruplamayla kendi rakamını çıkar.
GTM kullanmak GA4'ü doğrudan eklemekten daha mı yavaş#
Kesinlikle daha ağırdır, çünkü GTM önce kendi konteynerini indirir, sonra içindeki GA4 etiketini yükler. Yani iki dosya ve iki ayrı çalıştırma maliyeti oluşur. Buna karşılık GTM sana etiketleri koda dokunmadan yönetme, geciktirme ve tetikleyiciyle sınırlama imkânı verir. Tek bir etiketin varsa doğrudan GA4 daha hafiftir; beş üstü etiketin varsa GTM'nin yönetim kazancı maliyetini karşılar.
GTM'i sayfanın sonuna taşırsam sorun olur mu#
Teknik olarak çalışır, ancak sayfa başında tetiklenen bazı olayları kaçırma riskin olur; özellikle kullanıcı hızlı çıkarsa ölçüm hiç gitmez. Daha kontrollü yöntem, konteyneri ilk etkileşimde veya birkaç saniyelik gecikmeyle yüklemektir. Böylece hem kritik yükleme dönemi boş kalır hem de olay dinleyicileri erken kurulur.
Sunucu taraflı GTM ücretsiz mi#
Yazılım tarafı ücretsizdir, altyapı tarafı değildir. Konteyneri çalıştıracağın sunucunun maliyetini ve bakımını sen üstlenirsin; trafiğin arttıkça bu sunucuyu ölçeklendirmen gerekir. Küçük ölçekli bir siteye genellikle değmez, reklam harcaması yüksek ve ölçüm doğruluğu kritik olan sitelerde ise kısa sürede kendini amorti eder.
Analitik yüzünden düşen PageSpeed skorunu nasıl kontrol ederim#
En hızlı yöntem karşılaştırmalı ölçümdür. Aynı sayfayı iki kez ölç: bir kez normal, bir kez DevTools'ta gtm.js isteğini engelleyerek. İki sonuç arasındaki Total Blocking Time farkı analitiğin gerçek maliyetidir. Bu farkı gördükten sonra hangi etiketin sorumlu olduğunu GTM Preview modunda tetiklenen etiketleri sayarak daraltabilirsin.
Consent Mode hız kazandırır mı#
Doğrudan bir hız aracı değildir, asıl amacı hukuki uyumdur. Ancak onay vermeyen ziyaretçilerde bazı istekler hiç yapılmadığı veya çerezsiz sinyale düştüğü için pratikte ortalama maliyet düşer. Onay bandının kendisinin ağır bir üçüncü parti script olmamasına dikkat et; yoksa bir yandan kazanıp diğer yandan kaybedersin.
Kapanış#
Analitik, ölçmeden yönetemeyeceğin bir iştir; ama ölçüm aracının kendisi sayfanı yavaşlatıyorsa elindeki veri de giderek gerçek kullanıcıyı temsil etmez. Akılda tutulması gereken dört alışkanlık şu: konteyneri düzenli aralıklarla temizle ve kimsenin bakmadığı etiketi sil, kritik olmayan etiketleri ilk etkileşime ertele, ölçümü mutlaka kısıtlanmış CPU ve ağ ile yap, her değişikliğin kazancını rakamla doğrula. Bu dördünü uygularsan aynı veriyi çok daha ucuza toplarsın.
Altyapı tarafında yardıma ihtiyacın olursa Clou.TR bu işi büyük ölçüde senin yerine üstlenebilir. Sunucu taraflı etiketleme için tam root erişimli VDS veya esnek bulut sunucu paketlerimizi kullanabilir, kurulum ve bakımı bize bırakmak istersen sunucu yönetimi hizmetimizden yararlanabilirsin. Statik dosyalarını uç noktalara taşıyıp toplam yükleme süresini kısaltmak istersen CDN ve hız karşılaştırmamıza göz atmanı, hız odaklı bir barındırma arıyorsan WordPress hosting paketlerimizi incelemeni öneririm.