CLS (Düzen Kayması) Skoru Yüksekse Hangi Tasarım Müdahaleleri Yapılmalı?

CLS skoru kaç olursa ‘yüksek’ sayılır ve neden önceliklendirme gerekir?

Cumulative Layout Shift (CLS), sayfa yüklenirken görünür öğelerin kullanıcının beklentisi dışında kaymasını ölçen bir Core Web Vitals metriğidir. Google’ın resmi CLS belgelerine göre iyi skor 0,1 ve altındadır; 0,1–0,25 arası iyileştirme gerektiren bölgeyi, 0,25 üzeri ise kötü performansı ifade eder. Metrik, etkilenen görünür alan oranı (impact fraction) ile mesafe oranının (distance fraction) çarpımıyla hesaplanır. Düzen kayması teriminin sözlük tanımına bakıldığında bu formülün, hangi öğenin ne kadar uzaklıkta kaydığını sayısal biçimde ifade ettiği görülür. Yüksek CLS kullanıcının yanlış öğeye tıklamasına ya da okuduğu içeriğin gözünün önünden kaymasına neden olur; bu hem dönüşüm oranını hem de arama sıralamasını olumsuz etkiler.

CLS, Google Search Central’ın Core Web Vitals sıralama sinyali belgelerinde hem kullanıcı deneyimi hem organik görünürlük açısından kritik bir faktör olarak tanımlanmaktadır. 2026 bağlamında önemli bir ayrıntı öne çıkıyor: INP (Interaction to Next Paint), FID’in yerini alarak en sık başarısız olunan Core Web Vitals metriği hâline geldi. 2025 Web Almanac verilerine göre mobil sayfaların yaklaşık %81’i halihazırda iyi CLS eşiğini karşılıyor; bu da CLS’i “düşük asılı meyve” — yani doğru müdahaleyle hızlı puan kazanılan bir metrik — konumuna taşıyor. Sonuç olarak CLS, 2026 itibarıyla düzeltilmesi en kolay Core Web Vitals metriği olarak öne çıkıyor.

Önceliklendirmenin önemi şuradan kaynaklanıyor: tüm kayma nedenleri eşit ağırlık taşımaz. Reklam alanından gelen tek bir kayma, beş küçük görsel sorununu gölgede bırakabilir. Hangi müdahalenin önce yapılacağını bilmek hem geliştirme zamanından tasarruf ettirir hem de sıralama takipçisiyle CWV kazanımını izleme sürecinde anlamlı bir referans noktası oluşturur. Doğru sırayla ilerlenmediğinde en düşük etkili müdahaleye harcanan zaman, gerçek sorunu geciktirir.

Önce kayan öğeyi bulun: CLS ölçüm ve teşhis araçları

Müdahaleye başlamadan önce hangi öğenin ne kadar kaydığını tespit etmek gerekir. Chrome DevTools’un Performance sekmesindeki Layout Shift Regions özelliği, kayan blokları renkli vurgularla işaretler; her kaydın CLS katkı değerini de görsel olarak gösterir. Web Vitals tarayıcı eklentisi ise sayfa yüklenirken anlık kaymaları izler ve hangi öğenin en fazla puan tükettiğini özetler. Performance panelinde kayma olaylarını zaman çizelgesinde inceleyerek kaymayı tetikleyen kaynağı — reklam scripti mi, font değişimi mi yoksa geç enjekte içerik mi — tam olarak belirleyebilirsiniz.

Ölçüm yaparken saha verisi ile lab verisi arasındaki farkı anlamak kritiktir. PageSpeed Insights’taki CrUX (Chrome User Experience Report) saha verisi, gerçek kullanıcı oturumlarından gelir; Lighthouse ise kontrollü bir lab ortamında sayfayı simüle eder. CLS, oturum penceresi (session window) mantığıyla raporlandığından ikisi sık sık farklı değerler gösterir. Google’ın oturum penceresi yaklaşımını anlatan resmi yazısına göre önceliklendirme her zaman saha verisine dayanmalıdır; reklam ağından gelen geç enjekte içerikler lab ortamında görünmeyebilir ancak gerçek kullanıcılarda büyük kaymalar oluşturabilir.

Teşhis adımlarını şu sırayla uygulayın:

• PageSpeed Insights’ta saha (CrUX) verisini kontrol edin; hangi URL veya URL grubu en yüksek CLS değerine sahip?
• Chrome DevTools → Performance sekmesini açın, sayfayı kayıt modunda yükleyin ve Layout Shift olaylarını zaman çizelgesinde filtreleyin.
• Web Vitals eklentisiyle kayma zamanlamasını inceleyin: reklam mı yükleniyor, yoksa font mu değişiyor?
• Mobil simülasyonla tekrarlayın; masaüstünde görünmeyen kaymaların büyük bölümü mobil cihazlarda ortaya çıkar.
• DevTools kaydını before durumu olarak kaydedin; sonraki karşılaştırma için referans olarak saklayın.

Hangi tasarım müdahalesi önce? Etki/efor önceliklendirme çerçevesi

Google’ın resmi CLS optimizasyon rehberinde de vurgulanan en temel kural şudur: en yüksek etkili müdahale, medya ve reklam yuvalarına önceden yer ayırmaktır. Bir reklam banner’ı sayfaya geç yüklendiğinde altındaki tüm içeriği aşağı iter ve bu tek kayma bile CLS’i 0,25’in üzerine çıkarabilir. Oysa alana önceden min-height veya sabit bir placeholder konulduğunda, reklam geldiğinde hiçbir öğe hareket etmez. Bu müdahale, genellikle bir veya iki satır CSS ile uygulanabilir ve en kısa sürede en yüksek skoru getiren değişikliktir.

Etki/efor matrisi mantığıyla müdahaleler şu sıraya dizilir: en az efor, en yüksek CLS düşüşünü sağlayanlar önce yapılır. Aşağıdaki önceliklendirme tablosu, Google Publisher Tag rehberi ve web.dev verilerine dayanan etki tahminlerini özetlemektedir. Her müdahalenin tipik CLS katkısı ve uygulama zorluk düzeyi bu tabloda karşılaştırmalı olarak görülmektedir.

Müdahale sıralaması pratikte şöyle işler: reklam ve banner yuvasını rezerve etmek çoğunlukla tek başına CLS’i 0,1’in altına taşıyabilir. Bu başarılamazsa görsel ve video boyutlandırmaya geçilir; ardından web font yükleme stratejisi optimize edilir. Dinamik içerik için skeleton screen en son katmandır, çünkü geliştirme süresi görece daha uzundur ve etkisi diğer müdahalelere kıyasla daha az öngörülebilirdir.

Adım adım: yüksek CLS skorunu düşüren tasarım müdahaleleri

Aşağıdaki adımlar etki sırasına göre düzenlenmiştir. Her adımı uyguladıktan sonra PageSpeed Insights’ta lab skorunu kontrol edin; saha verisinin CrUX’ta güncellenmesi 28 günlük pencere nedeniyle birkaç hafta sürebilir; bu nedenle anlık geri bildirim için DevTools Layout Shift Regions kaydını kullanın.

1. Reklam ve embed alanlarına sabit yer ayırın: Google Publisher Tag rehberine göre yer ayrılmamış reklam slotları CLS’in en büyük kaynaklarından biridir. İlgili kapsayıcıya min-height CSS özelliği veya sabit boyutlu bir placeholder div ekleyin. 728×90’lık bir leaderboard banner için min-height: 90px tek satırla sorunu çözer. Iframe embed’ler için de aynı yöntem geçerlidir; özellikle sosyal medya widget’ları ve video embed’leri yer ayrılmadan yüklendiğinde büyük kaymalar oluşturur.
2. Görsel, video ve iframe’lere boyut verin: Tüm img ve video öğelerine HTML width ve height öznitelikleri ekleyin ya da CSS’te aspect-ratio kullanın. Tarayıcı medya yüklenmeden önce kapladığı alanı bildiğinden içerik kayıt yaratmadan yerinde kalır. Responsive tasarımlarda aspect-ratio: 16 / 9 veya aspect-ratio: 1 / 1 gibi oransal değerler, sabit piksel boyutuna göre daha esnek bir çözümdür.
3. Web font yüklemesini optimize edin: Kritik fontları link rel preload ile önceden yükleyin. Font CSS bildiriminde font-display: swap ve size-adjust özelliğini ekleyerek FOIT (Flash of Invisible Text) ve FOUT (Flash of Unstyled Text) kaynaklı metin yeniden çizimini ve buna bağlı kaymayı engelleyin. size-adjust özelliği, yedek font ile hedef font arasındaki boyut farkını dengeleyerek kayma miktarını önemli ölçüde azaltır.
4. Dinamik içerik için placeholder kullanın: JavaScript ile sonradan enjekte edilen içerikler — öneri kutuları, chatbot widget’ları, kişiselleştirme blokları — mevcut içeriğin üstüne eklendiğinde büyük kaymalar oluşturur. Bu alanlar için skeleton screen tasarlayın; ya da content-visibility: auto ve contain CSS özellikleriyle render alanını sabitleyin. Skeleton screen hem CLS’i azaltır hem de kullanıcıya içeriğin yükleneceğini görsel olarak haber verir.
5. Mevcut içeriğin üstüne ekleme yapmaktan kaçının: Kullanıcının görmekte olduğu içeriğin üstüne yeni bir öğe enjekte etmek CLS’in en kötü senaryosudur. Bildirim bantları ve sticky barlar için sayfanın başında var olan bir alana konumlandırın; içeriğin ortasına sonradan eklemeyin. Kullanıcı etkileşimiyle tetiklenen değişiklikler (butona tıklama gibi) CLS’e sayılmaz; tetikleyici olmayan dinamik eklemeler sayılır.

Bu adımları tamamladıktan sonra Chrome DevTools’ta Layout Shift Regions kaydını yeniden alın; hangi renk bloklarının ortadan kalktığını before/after karşılaştırması olarak belgeleyin. CrUX saha verisini Search Console’daki Core Web Vitals raporundan izleyin ve dört haftalık pencere içinde skor değişimini takip edin.

Gerçek vaka: bir Türk e-ticaret sayfasında CLS 0,32’den 0,04’e

Türkiye’de faaliyet gösteren bir e-ticaret sitesinin kategori sayfaları, PageSpeed Insights CrUX saha verisinde 0,32 CLS skoru alıyordu; bu değer Google’ın kötü eşiğinin belirgin biçimde üzerindeydi. Chrome DevTools’ta Layout Shift Regions kaydı alındığında iki ana kaynak tespit edildi: sayfa üstündeki reklam banner’ı ve lazy-load ile geç yüklenen ürün görselleri. Her iki öğe de before kaydında renkli vurgularla işaretleniyordu ve katkı değerleri açıkça görülüyordu.

Adım 1 — Banner yuvası rezervasyonu: Reklam kapsayıcısına min-height: 100px eklendi. PageSpeed Insights lab ölçümü 0,32’den 0,18’e düştü. Bu tek değişiklik toplam düşüşün yarısından fazlasını tek başına sağladı ve müdahalelerin etki sırasına göre yapılmasının neden kritik olduğunu somut biçimde ortaya koydu. Geliştirici harcanan süre: beş dakikadan az.

Adım 2 — Ürün görseli boyutlandırma: Tema şablonundaki tüm ürün görseli HTML öğelerine width ve height öznitelikleri eklendi; ürün kartı CSS’ine aspect-ratio: 1 / 1 kuralı yazıldı. After kaydında ürün grid alanındaki renk vurguları neredeyse tamamen ortadan kalktı. Skor 0,18’den 0,08’e geriledi.

Adım 3 — Başlık fontu preload + size-adjust: Sayfa başlığında kullanılan özel font link rel preload ile yüklendi; @font-face bildiriminde size-adjust: 98% ve font-display: swap eklendi. After kaydında başlık bölgesindeki son renk bloğu da ortadan kalktı ve skor 0,04’e indi. Müdahale etki sırasına göre yapıldığında 0,32’den 0,04’e — 0,1 eşiğinin oldukça altına — ulaşmak yalnızca üç adımda ve birkaç saatlik geliştirme süresiyle mümkün oldu. Rastgele sırayla başlanılsaydı aynı kazanım çok daha uzun sürerdi.

CMS/framework’e özel pratikler ve CLS regresyonunu izleme

CLS müdahaleleri platform bağımsız değildir; her ortamın kendine özgü tuzakları vardır. WordPress‘te en sık rastlanan sorunlar şunlardır: lazy-load eklentilerinin görsel boyutlarını sıfırlaması, tema reklam widget alanlarına yer ayrılmaması ve eski şablonlarda img etiketlerinde width ve height özniteliklerinin bulunmaması. Bunu düzeltmek için wp_get_attachment_image fonksiyonunun doğru boyutları ilettiğini doğrulayın; Gutenberg’de reklam blokları için sabit yükseklik tanımlayan özel bir blok kullanın. Lazy-load eklentisi değiştirmeniz gerekebilir; bazı eklentiler boyut özniteliklerini kaldırdığı için CLS artışına neden olur.

Shopify‘da ürün görseli Liquid şablonlarına width ve height değerleri eklemek ve güncel Shopify image_tag helper’ını kullanmak büyük fark yaratır. Next.js ve React tabanlı projelerde yerleşik Image bileşeni otomatik boyut rezervasyonu sağlar; ancak üçüncü taraf embed veya reklam scriptleri için hâlâ manuel min-height ataması gereklidir. Font yükleme için next/font modülü size-adjust değerlerini otomatik hesaplar ve Google Fonts entegrasyonunu optimize eder. Her iki platformda da tema veya eklenti güncellemelerinin sonrasında CLS regresyonu riski taşıdığını unutmayın.

İyileştirme sonrası doğrulama için dağıtımın hemen ardından PageSpeed Insights’ta lab skorunu kontrol edebilirsiniz. Ancak CrUX saha verisi 28 günlük yuvarlayan pencereyle güncellenir; bu yüzden Google Search Console’daki Core Web Vitals raporunu en az dört hafta boyunca izleyin. CLS regresyonunu erken yakalamak için CI/CD pipeline’ına Lighthouse CLS eşik testi eklemek iyi bir pratiktir; böylece her yeni yayına girişte skor otomatik olarak kontrol edilir ve eşiği aşan değişiklikler dağıtımdan önce fark edilir.

CLS iyileştirmenizin tekrar bozulmaması için sürekli izleme şarttır. Site sağlığı taraması yapan SEOYEN, Core Web Vitals uyarılarını Türkçe arayüzde toplayarak CLS regresyonu oluştuğunda sizi bilgilendirir. Ahrefs veya SEMrush gibi uluslararası platformların sunamadığı biçimde SEOYEN, TL bazlı fiyatlandırma ve yerel Türkçe destekle tüm bu izleme ve raporlama sürecini tek platformdan yönetmenizi sağlar.

Sıkça Sorulan Sorular