Bu senaryo yalnızca bir kullanıcı deneyimi sorununu değil, ölçülebilir bir performans maliyetini de tanımlar. Cookie onay platformlarının (CMP — Consent Management Platform) büyük çoğunluğu sayfanın en başında yüklenmek üzere tasarlanmıştır. Bu tasarım tercihinin gerekçesi mantıklıdır: kullanıcı onay vermeden hiçbir izleme scripti çalışmamalıdır, dolayısıyla banner her şeyden önce hazır olmalıdır. Ancak bu yaklaşım, banner scriptinin parse ve execution maliyetini doğrudan LCP kritik yoluna taşır. Sayfa içeriği görünür hale gelmeden önce banner kütüphanesi indirilmeli, parse edilmeli ve çalışmalıdır.

Diğer tarafta ise askıdaki analitik scriptler durur. Kullanıcı onay verene kadar Google Analytics, GTM veya diğer izleme araçları çalışmamalıdır — bu yasal bir zorunluluktur. Ama bu bekleme süreci de kendi maliyetini taşır: scriptler ya tamamen devre dışı kalır ya da Consent Mode gibi bir mekanizma aracılığıyla kısmi işlevle çalışır. Her iki durumda da bu sürecin koordinasyonu ek kod, ek ağ bağlantısı ve ek execution süresi demektir.

Banner scriptinin yükleme zamanlaması ve LCP üzerindeki baskısı

Bir CMP scriptinin <head> içinde, async veya defer olmadan yerleştirilmesi, sayfanın kritik render yoluna girer. Tarayıcı HTML'yi ayrıştırırken bu scriptle karşılaştığında durur: script indirilir, parse edilir, execute edilir; ardından HTML ayrıştırması devam eder. Bu süre boyunca sayfanın görsel içeriği oluşturulmaz.

Büyük CMP sağlayıcılarının kütüphane boyutları genellikle 30–80 KB sıkıştırılmış boyut aralığındadır. Harici bir etki alanından geldiğinden DNS çözümlemesi, TCP bağlantısı ve TLS el sıkışması bu süreye eklenir. Yavaş bir mobil bağlantıda bu ek maliyet 200–400 ms arasında olabilir; içerik gelmeden önce kullanıcı bu kadar bekler. Güçlü bir masaüstü bağlantısında bu fark hissedilmez, ama gerçek kullanıcı koşullarını yansıtan alan verisi farklı bir tablo çizebilir.

LCP bu gecikmeyi doğrudan yansıtır. Sayfanın en büyük içerik öğesi — bir hero görsel, bir başlık bloğu — banner scripti tamamlanmadan önce ekranda beliriyor olsa bile, script parse süresince tarayıcının rendering işlemi beklemedeyse LCP zamanlaması öne alınamaz. Chrome'un Performance panelinde "Parse Stylesheet" ve "Evaluate Script" görevlerinin LCP işaretinden önce yer aldığı durumlar, banner scriptinin kritik yola müdahalesini gösterir.

Bu soruna karşı en sık önerilen yaklaşım banner scriptine async niteliği eklemektir. Ancak burada dikkatli olmak gerekir: bazı CMP sağlayıcıları async ile çalışmak üzere tasarlanmamıştır; banner görünmeden önce execute tamamlanmış olması beklenir. Script async yüklenirse banner geç belirebilir ya da banner çıkmadan önce izleme scriptleri kısa süreliğine çalışmış olabilir. Bu durum hem görsel tutarsızlık hem de yasal uyum riski üretir. Her CMP çözümünün belgeleri bu konuda farklı bir yönlendirme sunar ve bu yönlendirmeyi dikkate almadan yapılan değişiklik beklenmedik sonuçlara yol açabilir.

Banner'ın CLS üzerindeki etkisi ve içerik kayması

Cookie banner'ı sayfada yer kaplar. Bu alan bazen sayfa yüklendiğinde hemen tahsis edilmez; banner scripti execute olduktan sonra dinamik olarak eklenir. Sayfa içeriği zaten düzene girmiş, kullanıcı okumaya başlamışsa bu anda gelen bir banner öğeleri aşağı iter veya üst üste gelmeler oluşturur. CLS bu kaymanın büyüklüğünü ölçer ve banner kaynaklı kaymalar çoğu zaman beklenmedik biçimde yüksek CLS değerlerine neden olur.

Banner'ın ekranın altına sabitlendiği ("sticky" pozisyon) durumlar görece daha az kaymaya yol açar çünkü bu tasarım sayfa akışını itmez; yalnızca görünür alanı daraltır. Ama ekranın ortasına veya üstüne yerleştirilen modal banner'lar ya da sayfanın üst kısmını aşağı iten banner blokları, yerleşim düzeni önceden ayrılmamışsa layout kaymasına yol açar.

Çözüm, banner için sayfanın başlangıç düzeninde yer ayırmaktır. Banner scripti yüklenip DOM'a eklenmeden önce o alan zaten tahsis edilmiş olmalıdır; böylece içerik scriptin gelmesiyle kayma yaşamaz. Bu yaklaşım CSS ile minimum bir yükseklik rezervasyonu veya placeholder bir element aracılığıyla uygulanabilir. Yer tahsisi sayfanın görsel tasarımına bağlıdır ve her CMP entegrasyonunda ayrıca ele alınması gereken bir konudur; otomatik çözümü yoktur.

Consent Mode ve analitik scriptlerin koşullu yüklenmesi

Google'ın Consent Mode mekanizması, kullanıcı onay vermeden önce analitik ve reklam scriptlerinin sınırlı biçimde çalışmasına olanak tanır. Script tamamen bloke edilmez; bunun yerine onay durumuna göre farklı davranışlar tetiklenir. Consent Mode v2 ile birlikte iki temel sinyal tanımlanır: analytics_storage ve ad_storage. Bu sinyallerin başlangıç değeri "denied" olarak ayarlanır; kullanıcı banner üzerinden onay verdiğinde "granted" durumuna geçer.

Bu yapının performans boyutu şöyledir: Consent Mode sinyallerini başlatmak için bir gtag bloğunun sayfada çalışması gerekir. Bu blok banner scriptinden önce yerleştirilir ve inline JavaScript olarak yazılır. Sonra GTM veya GA4 scripti yüklenir; bu script Consent Mode sinyallerini okur ve onay durumuna göre davranışını belirler. Onay verildiğinde ise veri modelleme ve dönüşüm gözlemleme için ek istekler başlatılabilir. Her bu adım ağ trafiği ve execution süresi üretir.

// Consent Mode başlangıç ayarı — inline, banner scriptinden önce
window.dataLayer = window.dataLayer || [];
function gtag(){dataLayer.push(arguments);}

gtag('consent', 'default', {
  'analytics_storage': 'denied',
  'ad_storage': 'denied',
  'wait_for_update': 500
});

// Kullanıcı onay verdiğinde banner bu fonksiyonu çağırır
function onConsentAccepted() {
  gtag('consent', 'update', {
    'analytics_storage': 'granted',
    'ad_storage': 'granted'
  });
}

wait_for_update parametresi dikkat gerektiren bir ayrıntıdır. Bu parametre, Consent Mode'un onay kararını bekleyeceği maksimum süreyi milisaniye cinsinden belirtir. 500 ms olarak ayarlandığında script bu süre içinde onay gelmezse varsayılan "denied" durumunu kullanarak ilerler. Bu değerin çok düşük ayarlanması, banner yavaş yüklendiyse onay kararının kaçırılmasına yol açabilir; çok yüksek ayarlanması ise analytics işleminin gecikmesi anlamına gelir. Doğru değer, banner scriptinin gerçek yükleme süresine göre belirlenir — bu süreyi ölçmeden ideal bir sayı seçmek güçtür.

Analitik scriptlerin bloklama maliyeti ve gecikmeli yükleme seçeneği

Consent Mode olmayan bir yapıda — kullanıcı onay vermeden hiçbir script çalışmamalıdır ilkesiyle çalışan daha katı bir yaklaşımda — GTM ve GA4 gibi scriptler kullanıcı etkileşimine kadar tamamen bloke edilir. Bu süre birkaç saniye olabileceği gibi, kullanıcı banner'ı kapatmadan ayrılırsa bu scriptler hiç yüklenmez.

Bu yaklaşımın veri toplama üzerindeki etkisi ayrı bir konudur. Performans açısından ise tam tersine bir iyileşme sağlar: sayfa yüklendiğinde ana içerik daha az script yükü altında render edilir. GTM'in <head> içine yerleştirilen senkron bloğu çalışmadığından bu scriptin parsing maliyeti kritik yoldan kalkar. LCP daha erken gerçekleşebilir; TTFB üzerindeki etki olmasa da render başlangıcı öne alınır.

Gecikmeli yükleme bu dengeyi pratik biçimde kurmanın bir yoludur. Banner onayını bekleyen scriptleri kullanıcı etkileşimine kadar yüklememek, sayfanın başlangıç yükleme performansını iyileştirir. Onay alındıktan sonra GTM dinamik olarak enjekte edilir:

function loadGTM(containerId) {
  var script = document.createElement('script');
  script.async = true;
  script.src = 'https://www.googletagmanager.com/gtm.js?id=' + containerId;
  document.head.appendChild(script);
}

// Banner onay callback'inden çağrılır
function onConsentGranted() {
  loadGTM('GTM-XXXXXXX');
}

Bu yaklaşımın sınırı, GTM içindeki tag'ların onay öncesi sayfa görüntülemesini kayıt edemeyeceğidir. Consent Mode bu sınırı kısmen aşar: script daha erken yüklenir ama onay durumuna göre farklı davranır. Hangi yaklaşımın seçileceği yalnızca performans kararı değil; yasal gereksinimler, veri kalitesi ihtiyacı ve kullanılan CMP platformunun desteğiyle birlikte değerlendirilmesi gereken bir dengedir.

Ölçüm: banner maliyetini performans verilerinden ayırt etmek

Banner'ın performans üzerindeki etkisini izole etmek için en güvenilir yöntem karşılaştırmalı ölçümdür. WebPageTest'te banner scripti devre dışı bırakılmış bir test profili ile normal bir profil karşılaştırıldığında LCP ve TBT farkı sayısal olarak görünür hale gelir. Bu fark bazen beklentinin üzerinde çıkar; özellikle büyük CMP kütüphanelerinde yalnızca banner scriptinin kaldırılması LCP'yi 300–600 ms öne alabilir.

Chrome DevTools Performance panelinde banner scriptinin etkisini okumak için kayıt başlatılıp sayfa yenilenir. "Timings" satırında FCP ve LCP işaretleri görülür; bu işaretlerden önce gelen "Evaluate Script" ve "Parse Stylesheet" görevleri incelenir. Bir script bloğu bu işaretlerden hemen önce konumlanmışsa ve URL'si bir CMP sağlayıcısına işaret ediyorsa banner'ın LCP'ye katkısı orada görünür.

CLS etkisini ölçmek için "Layout Shift" kayıtlarına bakılır. DevTools'ta Performance panelinde "Experience" satırı layout shift olaylarını işaretler; her birinin skoru ve tetikleyen element bilgisi gösterilir. Banner ile ilişkili kaymalar genellikle sayfa yüklendikten 1–3 saniye sonra gerçekleşir; bu zaman aralığındaki kayma olayları banner'ın DOM'a eklenmesiyle örtüşüyorsa neden açıktır.

Core Web Vitals raporlarında banner maliyeti ayrı bir sinyal olarak görünmez; LCP, CLS ve INP değerleri tüm etkenlerin toplamını yansıtır. Ancak alan verisi (CrUX) ile lab verisi arasında belirgin bir LCP farkı varsa — lab ortamında iyi görünen bir sayfa gerçek kullanıcılarda kötü görünüyorsa — bu farkın bir bölümü banner'ın farklı ağ koşullarında değişen yükleme süresiyle açıklanabilir. Mobil cihazlar ve yavaş bağlantılar, banner yükünü çok daha ağır taşır.

Cookie banner'ı kaldırmak bir seçenek değildir; yasal zorunluluktur. Ama bu zorunluluğun performansa yansıma biçimi büyük ölçüde uygulama kararlarına bağlıdır. Hangi CMP sağlayıcısının kullanıldığı, scriptin nerede ve nasıl yüklendiği, banner için başlangıçta yer ayrılıp ayrılmadığı, Consent Mode'un yapılandırılıp yapılandırılmadığı — bu kararların her biri ayrı ayrı küçük görünür ama birlikte LCP, CLS ve TBT üzerinde ölçülebilir bir fark yaratır. Analitik sistemin veri kalitesiyle sayfanın yükleme hızını dengelemek, tek seferlik bir ayarlama değil; ölçümle desteklenen bir süreç gerektiren bir tercih sorusudur.