Core Web Vitals
CLS Nedir? Cumulative Layout Shift ve Sayfa Kararlılığı
Bir kullanıcı sayfada bir bağlantıya tıklamak üzereyken içerik kayıyor ve tıklama yanlış öğeye gidiyor. Bazen geç yüklenen bir reklam tüm makaleyi aşağı itiyor, bazen bir görsel yerine oturduğunda okunan satır kayboluyor. Kullanıcı tam olarak ne olduğunu söyleyemeyebilir; ama sayfaya olan güven o an zedeleniyor. Cumulative Layout Shift (CLS), bu deneyimi sayıya döken metriktir.
CLS, Google'ın Core Web Vitals setinin görsel kararlılık bileşenidir. LCP sayfanın ne zaman anlamlı içerik gösterdiğini ölçerken, INP etkileşim gecikmesini ölçerken CLS sayfa öğelerinin ne kadar ve ne sıklıkla kaydığını hesaplar. Üç metrik arasında sonucu en doğrudan hissedilen CLS'tir; çünkü ölçülen şey gözle görülür.
Pek çok geliştirici CLS sorununu yalnızca boyutsuz görsellerle ilişkilendirir. Oysa kaynaklar çok daha geniş: web fontları, reklam slotları, dinamik eklenen bildirimler, bazı CSS animasyonları ve geç yüklenen üçüncü taraf widget'ları. Tek bir reklam banner'ının zamansız belirmesi, başka açıdan temiz bir sayfanın skorunu kritik eşiğin üstüne taşıyabilir.
Düzen kaymasının kullanıcıya gerçek maliyeti
CLS sıfırdan büyük olduğunda kullanıcı somut bir şey kaybeder: okuduğu yeri, tıklamak istediği öğeyi ya da yarı doldurduğu formu. Yüksek CLS olan sayfalarda yanlış öğeye tıklama ya da işlemi iptal etme eğilimi artıyor. Bunun ötesinde arama sıralama sinyali olarak da işlev görüyor; Google, Core Web Vitals'ı sayfa deneyimi değerlendirmesine dahil ettiğini resmi olarak açıkladı ve CLS bu üçlünün görsel kararlılık ayağı.
Pratik açıdan en çok zarar veren kayma türü, kullanıcının aktif olarak etkileşimde olduğu sırada gerçekleşen kayma. Sayfa yeni yüklenirken gerçekleşen kaymalar fark edilebilir ama tolere edilebilir; kullanıcı bir cümleyi okurken ya da butona doğru ilerlerken gerçekleşen kayma ise geriye dönüşü olmayan bir hayal kırıklığı yaratır. İkisi aynı skoru üretebilir ama kullanıcı üzerindeki etkisi çok farklıdır.
CLS skoru nasıl üretilir
CLS skoru bir oran değil, çarpım. Her düzen kayması olayı için iki değer hesaplanır: etki alanı oranı (impact fraction) ve mesafe oranı (distance fraction). Etki alanı, kaymadan etkilenen görünür alanın ekran yüzeyine oranıdır. Mesafe ise kaymanın en büyük eksen boyunca ne kadar ilerlediğinin viewport boyutuna oranı. İkisi çarpılır.
Somut örnek: bir öğe ekranın %50'sini kaplıyorsa ve görünür alanın %25'i kadar kayıyorsa, bu olay 0,50 × 0,25 = 0,125 üretiyor. İyi eşiği 0,1 ve altı; 0,25 üzeri "kötü" kategorisine giriyor. Bu çarpım mantığını anlamadan skoru iyileştirmeye çalışmak genellikle yanlış yere odaklanmaya yol açıyor: büyük öğelerin küçük kaymaları, küçük öğelerin büyük kaymalarından daha yüksek skor üretebilir.
Oturum penceresi ve maksimum skor
CLS tüm sayfa ömrü boyunca hesaplanır; ama hesap tek bir yığın değildir. Tarayıcı kaymaları oturum pencerelerine gruplayarak her pencerenin toplam skorunu bulur. Nihai CLS değeri, en yüksek puanlı pencereye ait skordur.
Bir oturum penceresi, en az 1 saniye arayla sonlanan ve en fazla 5 saniye süren kaymalar setidir. Sayfanın 10 saniye boyunca küçük kaymalar üretmesi, tek bir büyük kayma ile aynı etkiyi yaratmayabilir; ama yoğun sayfalarda — reklam yenileme, sonsuz kaydırma, canlı içerik güncellemesi — birden fazla yüksek pencere oluşabilir ve en kötüsü skoru belirler. Bu yüzden CLS optimizasyonu, yalnızca ilk yüklemeye değil sayfa ömrünün tamamına bakmayı gerektirir.
Görseller için alan tahsisi
CLS'in en yaygın ve en kolay çözümlenen kaynağı boyutsuz görsellerdir. Tarayıcı bir görselin boyutunu önceden bilmiyorsa, yüklenene kadar sıfır alan ayırır; görsel geldiğinde çevreleyen öğeler kayar.
Çözüm iki adım: HTML'de width ve height attribute'larını doğru vermek, ardından CSS'de height: auto ile oranı korumak. Modern tarayıcılar bu attribute'ları okuyarak yükleme tamamlanmadan doğru alanı tahsis eder. Alternatif olarak aspect-ratio CSS özelliği de aynı işi görür; özellikle boyutu değişken içerik için — farklı boyuttaki kullanıcı görselleri, API'den gelen karışık içerik — daha esnek bir çözüm sunar. Video için de aynı kural geçerlidir: <video> öğesine boyut vermek ve bir poster tanımlamak, düzen kaymasını büyük ölçüde ortadan kaldırır.
Font yüklemesi ve metin kayması
Web fontları yüklenene kadar tarayıcı iki tercihten birini kullanır: sistem fontunu gösterir ve font gelince değiştirir (FOUT — Flash of Unstyled Text) ya da metni tamamen gizler ve bekler (FOIT — Flash of Invisible Text). Her iki durumda da font geldiğinde metin yeniden düzenlenir; satır boyu, kelime sarması ve öğe yükseklikleri değişebilir. Bu yeniden düzenlenme, sayfa içindeki diğer öğeleri de aşağı itebilir.
font-display: swap FOUT üretir ve metin hemen görünür, ama düzen kayması riski doğar. Bunu sınırlamanın iki yolu var: birincisi, web fontunu sistem fontuna yakın ölçü özelliklerine sahip bir fallback ile eşleştirmek; size-adjust, ascent-override, descent-override gibi CSS descriptor'ları bu amaçla kullanılır. İkincisi, kritik fontları preload ile öne almak; font sayfa parse edilirken zaten indirilmiş olur ve kayma penceresini daraltır. Font origin'ine preconnect eklemek de bağlantı gecikme süresini kısaltarak bu süreci hızlandırır.
Dinamik içerik eklemenin zamanı
Kullanıcı etkileşimi dışında DOM'a eklenen içerik neredeyse her zaman düzen kayması üretir. Scroll'un üstüne eklenen bir banner tüm içeriği aşağı iter. Geç beliren bir bildirim çubuğu aynı etkiyi yaratır. Sayfanın altına eklenen bir chat widget'ı içerik akışını bozar.
Kuralı netleştirmek gerekirse: kullanıcı etkileşimi dışında, önceden tahsis edilmemiş bir alana eklenen içerik CLS üretir. Tarayıcı, kullanıcı tarafından tetiklenen etkileşimin ardından gerçekleşen kaymaları CLS hesabına katmaz. Bir dropdown açıldığında sayfa aşağı itiliyorsa bu hesaba girmez; ama otomatik açılan bir banner aynı etkiyi yapıyorsa hesaba girer. Bu ayrım, hangi davranışların kabul edilebilir olduğunu belirlerken pratik bir rehber sunar.
Reklam ve embed alanlarının önceden ayrılması
Reklam sistemleri genellikle sayfa yüklendikten çok sonra çalışır. Hangi kreatifin geleceği belirsizken bir slot HTML'e yerleştirilir ve slot dolduğunda içerik kayar. Yüksek CLS'in en sık görüldüğü senaryo budur; özellikle üst banner ya da sayfa içi reklam alanları barındıran içerik sitelerinde bu durum yaygındır.
Çözüm: slot için minimum alan tahsis etmek. Eğer slot 250px yüksekliğinde bir banner taşıyacaksa, bu yükseklik slot dolmadan önce CSS ile ayrılmalı. Daha küçük bir kreatif gelirse slot içinde kalır; daha büyük gelirse sınıra kadar görünür. Her iki durumda da çevreleyen içerik kaymaz. min-height bu senaryoda height'tan daha güvenlidir: içerik boyutu belirsiz olduğunda da sayfayı kırmaz. Üçüncü taraf embed'ler için aynı yaklaşım geçerlidir; sosyal medya kartları, video embed'leri, harita widget'ları — beklenen boyutu önceden CSS ile ayırmak yükleme tamamlandığında kaymayı engeller.
Hangi animasyonlar CLS'e girer, hangisi girmez
Tüm animasyonlar düzen kayması üretmez. Tarayıcı, düzeni etkileyen ve etkilemeyen CSS özelliklerini ayrı tutar. transform: translateY(), transform: scale() ve opacity compositor thread'inde çalışır; düzeni yeniden hesaplamaz ve CLS üretmez. Buna karşın top, left, margin, padding, width, height gibi özellikler düzeni tetikler ve kaymaya yol açar.
Bir öğeyi sayfada hareket ettirmenin CLS'e girmeyecek yolu transform: translate() kullanmaktır. İçerik akışını etkileyen bir animasyon gerekliyse — öğe aşağı kayıyor, genişliyor — öğeyi position: fixed ya da position: absolute ile akışın dışına çıkarmak diğer öğelerin kaymasını engeller. Kullanıcının tıklamaya hazırlandığı bir öğenin animasyon sırasında yer değiştirmesi, büyük olasılıkla CLS skoru üretiyor demektir.
Skeleton ekran ve yer tutucu yaklaşımları
İçerik yüklenene kadar yer tutucu göstermek hem kullanıcı algısını iyileştirir hem de düzen kaymasını engeller. Skeleton ekranlar — içeriğin şeklini taslak olarak gösteren gri bloklar — iki işlevi aynı anda görür: alan tahsis eder ve kullanıcıya yüklemenin sürdüğünü gösterir.
Yer tutucu kullanırken dikkat edilmesi gereken nokta, yer tutucunun gelecek içerikle yaklaşık aynı boyutta olması. Çok kısa bir yer tutucunun ardından uzun bir içerik gelmesi yine kayma üretir. Önceden oluşturulmuş statik sayfalarda bu tür kaymalar genellikle daha seyrek görülür; içeriğin büyük bölümü HTML'de zaten mevcut olduğundan dinamik yüklemenin açtığı boşluklar daha sınırlı kalır. Dinamik veri bağımlılığı olan bölümler için ise boyutu önceden bilinen yer tutucular kullanmak en güvenilir yol olmaya devam eder.
DevTools ile CLS kaynağını bulmak
Chrome DevTools'un Performance paneli, CLS olaylarını zaman ekseninde işaretler. Her kayma olayını tıklayınca hangi öğenin kaydığı, ne kadar kaydığı ve hangi skoru ürettiği görülür. Layout Shift olayları panelde işaretlenir; her birinin altında etkilenen öğe ve skor detayı bulunur.
Lighthouse, lab ortamında ölçer ve belirli koşullar altında tetiklenemeyen kaymaları yakalayamayabilir. CLS analizi için Chrome User Experience Report (CrUX) verileri ya da PageSpeed Insights'ın alan verisi bölümü daha gerçekçi tablo sunar. CLS'in belirli sayfa tiplerinde ya da yavaş bağlantılarda yoğunlaşıp yoğunlaşmadığını anlamak için gerçek kullanıcı verisine bakmak, lab ölçümünden çok daha yönlendirici olur; özellikle üçüncü taraf kaynaklı kaymalar geliştirici ortamında hiç tetiklenmeyebilir.
Yüksek CLS'in yoğunlaştığı sayfa tipleri
Her sayfa CLS için eşit risk taşımaz. Reklam ağırlıklı haber ve blog sayfaları düzen kaymasının en sık yaşandığı yerler arasında. Ürün listesi sayfaları, görsel boyutları tutarsız olduğunda ya da "stokta yok" bildirimleri geç yüklendiğinde kayma üretir. Checkout akışları, ödeme widget'larının geç belirmesiyle aynı sorunu yaşar.
Oturum açma gerektiren sayfalar ayrı bir kategori: oturum doğrulandıktan sonra kullanıcıya özel alanların belirmesi, sayfa yapısını gecikmeli olarak değiştirdiğinde ciddi CLS üretebilir. Bu tür içerikler için alan tahsisini önceden yapmak ya da oturum doğrulamasını sayfa bileşenlerinden önce tamamlamak en etkili yaklaşım. Kişiselleştirme ihtiyacı arttıkça bu trade-off daha dikkatli yönetilmesi gereken bir hal alır.
CLS düştüğünde diğer metriklere yansıması
CLS'i iyileştirmek çoğu zaman yalnızca tek bir metriği değil, genel yükleme deneyimini etkiler. Görsellere width/height attribute'ları eklemek tarayıcının layout hesaplama yükünü azaltır; bu da main thread'in bloke olma süresini dolaylı olarak kısaltabilir. Font kaymaları azaltıldığında LCP öğesi fontla ilişkiliyse LCP süresi de iyileşebilir.
Reklam slotlarına alan tahsis etmek sayfanın görsel kararlılığını artırır; bu da Lighthouse skoru üzerinde olumlu etki yaratır. Speed Index hesabı, öğelerin ne zaman ve hangi sırayla görünür hale geldiğine dayandığından, düzen kaymaları azaldıkça görsel yükleme sırası daha öngörülür bir hal alır. CLS ile başlayan bir iyileştirme süreci, fark edilmeden birkaç metriği birden ilerletebilir.
CLS, üç Core Web Vitals metriği arasında en az donanım ya da altyapı değişikliği gerektiren, ama en fazla uygulama ayrıntısına dikkat isteyen sorundur. LCP için CDN ya da sunucu optimizasyonu gerekebilir; INP için JavaScript mimarisine dokunmak gerekebilir. CLS çoğunlukla HTML attribute'larını doğru yazmak, CSS'de birkaç satır alan tahsisi eklemek ve dinamik içerik zamanlamasını gözden geçirmekle çözülür.
Bununla birlikte kaynakları bulmak zaman zaman görünenden karmaşıktır. Üçüncü taraf scriptlerin ürettiği kaymalar geliştirici ortamında hiç tetiklenmeyebilir; yavaş ağ koşullarında ya da belirli cihaz türlerinde ortaya çıkar. DevTools ve alan verisi bir arada kullanıldığında tablo netleşir ve düzeltme öncelikleri belirginleşir.
Sayfa kararlılığı, kullanıcının kontrolde hissettiği deneyimin temelidir. İçerik kayarken başka hiçbir performans metriği kullanıcıya iyi bir sayfa izlenimi veremez. CLS bu yüzden teknik bir skor olmaktan öte, ziyaretçi güveninin somut bir ölçüsüdür.