Reklam ve Performans
Reklam Kodları Site Hızını Nasıl Etkiler?
Reklam scriptlerinin async yüklendiği, bu nedenle sayfa hızını etkilemediği yaygın bir kabul. Teknik olarak kısmen doğru olan bu gözlem tam resmi göstermiyor. Async attribute, script'in HTML parse'ı engellemediği anlamına gelir — ama main thread üzerindeki yürütme maliyetini, bant genişliği tüketimini ve render sonrasında tetiklenen ikincil istekleri ortadan kaldırmaz.
Bir sayfada beş reklam slotu varsa sizi bekleyen şey beş ayrı script değildir. Her slot, açık artırma çağrıları, kazanan yaratıcının yüklenmesi, görüntülenebilirlik ölçümü ve takip pikselleriyle birlikte onlarca isteğe dönüşebilir. Toplam yük görünenden çok daha büyüktür.
Reklamların performansa etkisi sabit bir rakam değil. Hangi sağlayıcıyla çalışıldığına, kaç slot açıldığına, hangi sayfada göründüğüne ve yükleme stratejisine bağlı olarak sonuç dramatik biçimde değişir. Bu farkı ölçmeden almak, hangi kararın gerçekten işe yaradığını bilmeden optimizasyon yapmaya çalışmak demektir.
Reklam isteği bir değil, zincir açıyor
Standart bir display reklamı sayfaya yerleştiğinde tek bir HTTP isteği değil, bir istek zinciri başlar. İlk çağrı genellikle reklam ağının tag'ini yükler. Bu tag, SSP (Supply-Side Platform) veya exchange sunucusuna bir auction isteği gönderir. Auction kazanılırsa yaratıcı dosyası — görsel, HTML5 banner ya da video — ayrı bir CDN'den indirilir. Ardından impression tracking, click tracking ve viewability ölçüm scriptleri devreye girer.
Tek bir slot için bu zincir 10–30 ayrı isteğe ulaşabilir. Beş slot, kolayca 80–100 isteğin üstüne çıkabilir. Bu isteklerin tamamı aynı anda değil, sıralı veya kısmen paralel olarak gerçekleşir. Network'ü dolduran bu trafik diğer kaynakların yüklenmesini geciktirir. İlk yükleme iyi görünse bile toplam request sayısı sayfanın genel ağırlığını gizli biçimde artırır.
Async yükleme neden tam koruma sağlamıyor
Async attribute ile yüklenen bir reklam scripti HTML parse işlemini durdurmaz. Ama bu, etkisiz olduğu anlamına gelmiyor. Script indirilip çalıştırıldığında main thread'i meşgul eder. Uzun yürütme süreleri kullanıcı etkileşimini geciktirir ve INP (Interaction to Next Paint) değerini olumsuz etkiler.
Bant genişliği paylaşımı asıl görünmez maliyet kaynağıdır. Async script, ana kaynaklarla paralel indirilirken bant genişliğini onlarla paylaşır. Bağlantı hızı kısıtlıysa — mobil veya yavaş bir hat üzerinde — hero görsel ile reklam asset'i birbiriyle yarışır. Parse engeli olmasa da yükleme gecikmesi yaşanır. Async yükleme bir güvenlik ağı değil, yalnızca bir kural dışı yükleme yöntemidir.
Alan rezervasyonu yapılmayan slotlar ve CLS
Reklam slotu sayfaya yerleştirilmeden önce boyutu bilinmiyorsa ve konteynere minimum yükseklik atanmamışsa, reklam yüklendiğinde sayfadaki içerik aşağı kayar. Cumulative Layout Shift'in yakaladığı en yaygın senaryo budur. Bir içerik bloğunu okurken altındaki reklam yüklenip sayfayı aşağıya ittiğinde kullanıcı deneyimi ciddi biçimde bozulur.
Çözüm yükleme stratejisinden önce geliyor: slotun taşıyacağı en büyük formatı kapsayan bir alan önceden ayrılmalı, içerik bu alana göre konumlanmalıdır. CSS'te min-height veya aspect-ratio ile bu rezervasyon sağlanabilir. Reklam yüklenmeden önce alan tarayıcı tarafından bilinirse düzen kayması yaşanmaz. Responsive formatlarda slot boyutunun ekran genişliğine göre değiştiği durumlar da hesaba katılmalıdır.
Header bidding kitaplığının gerçek boyutu
Birden fazla SSP ile çalışan siteler genellikle Prebid.js gibi bir header bidding kitaplığı kullanır. Bu kitaplıklar küçük değildir; sıkıştırılmış haliyle 100–300 KB arası bir yük getirebilirler. Transfer boyutunun ötesinde parse ve compile süresi de eklenir.
Header bidding'in ek maliyeti auction sürecidir. Birden fazla SSP'ye aynı anda teklif isteği gönderilmesi gerekir. Bu istekler timeout değerine kadar — genellikle 1–2 saniye — beklenir. Bu süre zarfında slot boş kalır. Timeout değerini kısmak gelir kaybına yol açar; yüksek bırakmak kullanıcıyı bekletir. Yapılandırmaya bağlı olarak bu bekleme bazı senaryolarda LCP'yi de geciktirebilir. Denge noktasını bulmak ölçüm gerektirir.
LCP rekabeti: reklam scripti mi içerik mi önce?
Sayfanın en büyük içerik öğesi — hero görsel, büyük bir başlık veya öne çıkan bir blok — ile reklam yaratıcısı aynı anda indirilmeye çalışıyorsa bant genişliği ikisi arasında bölünür. Yavaş bir bağlantıda bu rekabet LCP süresini doğrudan uzatır.
Kritik içerik önceliklendirilmezse tarayıcı her iki kaynağı da eş zamanlı almaya çalışır. Bu durumda ne hero görsel hızlı gelir ne de reklam hızlı yüklenir. fetchpriority="high" attribute'u ile kritik görseli öne çekebilir, reklam asset'lerinin sırayı beklemesini sağlayabilirsiniz. Above-the-fold içerik her koşulda reklam yükleme süreçlerine öncelikli olmalıdır.
Reklam sunucusunun yanıt süresi ve TTFB ilişkisi
Sayfanın kendi TTFB'si iyi olabilir. Ama reklam kodu sayfaya eklendiği anda yeni bir bağlantı zinciri başlar: reklam sunucusuna DNS çözümlemesi, TCP bağlantısı, TLS el sıkışması ve auction yanıtı beklenir. Bu adımların her biri ek gecikme ekler.
Bir reklam ağının sunucusu kullanıcıdan coğrafi olarak uzaksa — ya da aşırı yüklüyse — auction yanıtı yüzlerce milisaniye gecikebilir. Bu sürede slot boş kalır, FCP etkilenmez ama sayfanın "tamamlanmış" hissi gecikir. Özellikle below-the-fold içerik yüklenmesini bekleyen bir yapı varsa bu gecikme daha belirgin olur. Sayfanın kendi performansı iyi olsa bile reklam sunucusunun gecikmesi fotoğrafı değiştirir.
Consent katmanının açık artırmayı geciktirmesi
GDPR ve benzeri düzenlemeler kapsamında çalışan sitelerde reklam yüklenmesi kullanıcı onayına bağlıdır. Kullanıcı consent banner'ını yanıtlamadan auction başlamaz. Bu bekleme doğrudan ölçülebilir bir gecikme değildir — kullanıcının karar verme süresi değişkendir — ama sayfa performans testi yapılırken göz ardı edilmemesi gereken bir katmandır.
Gerçek kullanıcı verisiyle test sonuçları arasında tutarsızlık yaşanıyorsa consent akışının test ortamında nasıl simüle edildiği kontrol edilmeli. Test sırasında consent otomatik kabul ediliyorsa gerçek kullanıcının yaşadığı bekleme süresi görünür olmayabilir. Ayrıca consent katmanının kendisi de ek bir script yükler; bu yük çoğu zaman reklam etkisiyle karıştırılır.
Ad refresh ve oturum boyunca kümülatif yük
Bazı reklam yapılandırmalarında slotlar belirli aralıklarla yenilenir — kullanıcı sayfada aktif kaldıkça 30–60 saniyede bir yeni bir auction tetiklenir. Her refresh başlangıçtaki yükün küçük bir tekrarı anlamına gelir: yeni auction çağrısı, yeni yaratıcı, yeni tracking isteği.
Sayfa ilk yüklendiğinde görülen performans değerleri bu durumu yansıtmaz. Lab testleri tek bir yükleme anını ölçer. Kullanıcı sayfada uzun süre kalıyorsa toplam network maliyeti ve main thread üzerindeki baskı zamanla katlanır. Bu durum özellikle haber sitelerinde, forum sayfalarında ve uzun biçimli içeriklerde belirgindir. Refresh aralığını uzatmak veya yalnızca kullanıcı etkileşiminde tetiklemek bu yükü azaltmanın pratik yollarından biridir.
Reklam sayısı arttıkça yük orantısız büyüyor
Sayfaya bir slot daha eklemek toplam yükü düzgün bir oranda artırmaz. Her slot kendi auction çağrısını, kendi yaratıcısını, kendi tracking katmanını getirir. Üç slot yerine beş slot açmak yüzde kırk ek yük değil, çok daha fazla istek ve bant genişliği talebi anlamına gelebilir. Çünkü yeni slotlar ayrı bağlantılar açmak zorunda kalır; paylaşılan bağlantı havuzu tükenir.
"Daha fazla slot daha fazla gelir" varsayımı bu nedenle performans maliyetiyle birlikte değerlendirilmeli. Ek her slotun gerçek yükünü — slot sayısını tek tek artırıp ölçerek — somutlaştırmadan karar vermek, sayfanın toplam hızını orantısız biçimde düşürebilir. Slot sayısı değil, slot başına düşen verimli yük asıl göstergedir.
Viewport dışındaki slotları geciktirmek
Sayfanın alt kısmındaki reklam slotları, kullanıcı oraya kaydırmadan önce yüklenmeye başlıyorsa hem bant genişliği gereksiz harcanır hem de üst tarafta yer alan kritik içerik gecikmeli yüklenir. Lazy loading mantığını reklam slotlarına uygulamak bu sorunu azaltır.
Intersection Observer API ile slot, viewport'a yaklaştığı anda auction süreci başlatılabilir. Kullanıcı zaten oraya kaydırmak üzereyken auction başlamış olur; görüntülenme oranı çok az etkilenir. Ama ilk sayfa yüklemesindeki bant genişliği tüketimi ve main thread üzerindeki baskı önemli ölçüde azalır. Çoğu modern reklam ağı bu yapıyı doğrudan destekler ya da bir yapılandırma seçeneği olarak sunar.
Render blocking reklam kaynakları hâlâ var mı?
Modern reklam ağlarının büyük çoğunluğu async yükleme standartlarına geçmiş olsa da eski veya daha küçük ağların ürettiği bazı tag'ler senkron script içerebilir. Bu scriptler HTML parse'ı engeller ve ilk boyama süresini doğrudan geciktirir. Render blocking kaynakları incelerken reklam etiketleri de listeye dahil edilmeli.
Chrome DevTools'un Network sekmesi veya Lighthouse'un "Render-blocking resources" uyarısı bu durumu tespit eder. Senkron bir reklam scripti varsa sağlayıcıyla iletişime geçerek async alternatif sürüme geçmek ya da script'in yerleşimini body kapanışına taşımak gerekir. Bazen sağlayıcının sunduğu tag versiyonu değiştiğinde bu sorun kendiliğinden çözülür; güncel tag dokümanları düzenli aralıklarla kontrol edilmeli.
Reklam sağlayıcısının altyapısı fark yaratır
İki farklı reklam ağının aynı slot sayısıyla çok farklı performans etkisi yaratması mümkündür. Nedenlerinden biri CDN kullanımıdır. Yaratıcı dosyalarını küresel bir CDN üzerinden sunan sağlayıcılar kullanıcıya coğrafi olarak yakın bir node'dan yanıt verir. CDN'siz sağlayıcılar tek bir origin sunucusuna bağımlıdır; bu gecikme özellikle kullanıcı ile sunucu arasındaki coğrafi mesafe arttıkça belirginleşir.
Ek olarak her sağlayıcının kendi tracking katmanları, viewability ölçüm kütüphaneleri ve çerez eşitleme mekanizmaları vardır. Bu katmanların toplamı slot başına istek sayısını ve main thread yükünü doğrudan etkiler. Sağlayıcı değiştirirken yalnızca CPM oranlarına bakmak gerçek maliyetin yalnızca yarısını görmek demektir. Yeni sağlayıcıyla test dönemi yürütmek ve ölçüm verisini karşılaştırmak bu seçimi daha sağlam temele oturtur.
Neyi ölçmeden karar vermek yanıltır
Reklam scriptlerinin performans etkisini izole etmek için en doğrudan yöntem karşılaştırmalı ölçümdür: reklam kodlarını geçici olarak devre dışı bırakarak aynı sayfayı yeniden test etmek. Chrome DevTools'ta belirli alan adlarından gelen istekler bloklanabilir; Network sekmesinde reklam alan adları filtrelenip önce/sonra karşılaştırması yapılabilir.
Third-party script ölçümünde kullanılan yöntemlerin aynısı reklam scriptleri için de geçerlidir. Reklamlar açıkken ve kapalıyken LCP, TBT ve toplam sayfa ağırlığı karşılaştırıldığında gerçek fark sayısal hale gelir. Bu karşılaştırma olmadan hangi sağlayıcının, kaç slotun, hangi sayfada ne kadar yük getirdiğini bilmeden alınan kararlar çoğunlukla sezgiye dayanır.
Gelir ve performans arasındaki denge
Reklam alanı azaltmak performansı iyileştirir, bu doğru. Ama her zaman en kolay veya en mantıklı başlangıç noktası değildir. Slot sayısını korurken yükleme stratejisini değiştirmek — viewport dışındaki slotları geciktirmek, header bidding timeout değerini optimize etmek, daha iyi altyapıya sahip sağlayıcılara geçmek — çoğu zaman daha erişilebilir bir ilk adım oluşturur.
Alan rezervasyonu yaparak CLS'i sıfırlamak, lazy load uygulayarak alt slotları ertelemek, consent yönetimini optimize ederek gereksiz gecikmeleri kesmek: bunların hiçbiri reklam gelirini azaltmadan uygulanabilir müdahalelerdir. Hangi müdahalenin ne kadar fark yarattığını ölçmek bu dengeyi kurmayı mümkün kılar.
Reklamlar performans sorunlarının tek kaynağı değildir, ama göz ardı edildiğinde en büyük beklenmedik maliyeti yaratan kaynaklar olabilirler. Tek bir slot yerine onlarca istek, layout shift, main thread rekabeti — bunların tamamı görünmez biçimde birikir. İlk sayfa yükü iyi görünse bile gerçek kullanıcı deneyiminde farklı bir tablo ortaya çıkabilir.
Ölçüm olmadan alınan kararların maliyeti zamanla daha belirgin hale gelir. Sağlayıcı değiştirmek, slot sayısını artırmak ya da reklam formatını güncellemek — bu değişikliklerin her biri ölçülebilir bir etkiye sahiptir. Bu etkiyi sayıya dökmek hem performans ekibine hem de gelir kararı verenlere aynı dili konuşma imkânı tanır.
Reklamların sayfa hızına etkisi kontrol edilebilir bir değişkendir, kader değil. Hangi slotun ne zaman yükleneceği, hangi sağlayıcının tercih edileceği ve sayfada kaç reklam alanının açılacağı mühendislik kararlarıdır ve sonuçları ölçülebilir.