Kümülatif Düzen Kayması (CLS)

TL;DR — Cumulative Layout Shift (CLS), bir sayfada siz okumaya veya dokunmaya çalışırken görünür içeriğin ne kadar beklenmedik biçimde hareket ettiğini ölçer — geç yüklenen ve metni aşağı iten görsel ya da siz tıklamak üzereyken sıçrayan düğme gibi. 0’dan başlayan bir puandır; 0,1 veya altı iyidir. Kaymaların çoğu, yüklenmeden önce alanını ayırmamış öğelerden kaynaklanır.

CLS nedir

Terimi hiç duymamış olsanız bile bunu yaşamışsınızdır. Bir makale okurken baktığınız yerin üstündeki bir reklam veya görsel yüklenmesini tamamlar ve bir anda tüm sayfa aşağı sıçrar. Ya da “Cancel” düğmesine dokunmak üzereyken bir banner belirir ve dokunuşunuz bunun yerine “Confirm” düğmesine denk gelir. Bu beklenmedik hareket bir düzen kaymasıdır; Cumulative Layout Shift ise Google’ın bunun ne kadar kötü olduğunu sayısal olarak ifade etme yöntemidir.

Üç Core Web Vitals metriğinden biridir — Google’ın izlediği sayfa deneyimi üçlüsü; yanında Largest Contentful Paint (ana içeriğin ne kadar hızlı yüklendiği) ve Interaction to Next Paint (dokunduğunuzda sayfanın ne kadar hızlı yanıt verdiği) bulunur. CLS, görsel kararlılıkla ilgilidir: sayfa sabit duruyor mu?

Puan kabaca nasıl çalışır

CLS süre değil, puandır. CLS’nin 0,05 olması herhangi bir şeyin 50 milisaniye sürdüğü anlamına gelmez — birimsiz bir sayıdır. Ekranın daha büyük bir bölümü ne kadar çok ve ne kadar uzağa hareket ederse puan (dolayısıyla sorun) o kadar büyür.

Hedefler basittir:

• 0,1 veya altı — iyi.
• 0,1–0,25 — iyileştirme gerekiyor.
• 0,25’in üzeri — kötü.

Güzel bir ayrıntı: sizin yaptığınız bir şeyin hemen ardından — bir düğmeye dokunmak, menü açmak — gerçekleşen kaymalar sayfaya karşı sayılmaz; çünkü bunlara siz neden oldunuz ve olmasını bekliyorsunuz. Yalnızca beklenmeyen hareket sayılır.

Neden olur (ve çözümü)

Neredeyse her layout shift aynı şeye iner: bir şey yüklendi ve sayfanın önceden ayırmadığı bir alanı kapladı. Başlıca nedenler:

• Boyutları belirtilmemiş görseller ve videolar. Tarayıcı, görsel yüklenene kadar ne kadar yüksek olacağını bilemez; görsel geldiğinde altındaki metin aşağı itilir. Çözüm: tarayıcının yerini ayırabilmesi için görsellere her zaman width ve height (veya CSS aspect-ratio) verin.
• Reklamlar, yerleştirilmiş içerikler ve iframe’ler. Aynı sorun burada da geçerlidir; bunlar için alan ayırın.
• Web fontları. Özel font yedek fontun yerini aldığında metnin satır düzeni değişebilir.
• Sonradan beliren öğeler. Çerez banner’ları, “you might also like” kutuları ve baktığınız içeriğin üstüne sonradan eklenen her şey.

Zihinsel kural şu: bir şey daha sonra görünecekse, göründüğünde başka hiçbir şeyin hareket etmemesi için ona doğru boyutta bir boşluk bırakın.

Gerçek formülü, “session window” kuralını, laboratuvar ve saha CLS sayılarının neden uyuşmadığını ve tüm nedenler/çözümler listesini mi istiyorsunuz? Advanced sekmesine geçin.

TL;DR — CLS, görsel kararlılık için Core Web Vital’dır. Her kaymanın puanı impact fraction × distance fraction’dır; metriğin kendisi, kaymalar arasındaki aralık ≤ 1 saniye ve pencere ≤ 5 saniye olacak şekilde, en büyük session window’dur — Haziran 2021’den önceki gibi yaşam boyu toplam değildir. İyi değer ≤ 0,1, iyileştirme gerekir değeri ≤ 0,25, kötü değer > 0,25’tir; saha verisinin 75. yüzdelik diliminde ölçülür. Yalnızca görünüm alanında görünen kaymalar sayılır; ayrık bir girdiden sonraki 500 ms içindeki kaymalar hariçtir (kaydırma hariç). Nedenler boyutu belirtilmemiş görseller/videolar/reklamlar/iframe’ler/embed’ler, web fontları ve mevcut içeriğin üstüne eklenen içeriktir; çözümler alan ayırmak, font-display/size-adjust kullanmak ve yalnızca transform ile animasyon yapmaktır. Kaçınılacak tuzak: Lighthouse (laboratuvar) çoğu zaman 0’a yakın okur; çünkü sayfayla etkileşime girmez veya tüm yaşam döngüsünü çalıştırmaz — Google’ın gerçekten ölçtüğü şey saha verisidir (CrUX).

CLS neyi ölçer

Google bunu şöyle ifade eder: “Cumulative Layout Shift (CLS) is a stable Core Web Vital metric. It’s an important, user-centric metric for measuring visual stability because it helps quantify how often users experience unexpected layout shifts.” Buradaki kilit sözcük beklenmediktir: kullanıcının bir eylemi nedeniyle değil, kendiliğinden hareket eden içerik.

Core Web Vitals üçlüsünde Largest Contentful Paint (yükleme) ve Interaction to Next Paint (yanıt verebilirlik) ile birlikte yer alır. LCP ve INP milisaniye cinsinden ölçülürken CLS istisnadır: birimsiz oran puanıdır. Bu insanları sürekli şaşırtır. CLS’nin 0,05 olması 50 ms değildir; hiç zaman birimi yoktur.

Formül: etki × mesafe

Google bunu kayma başına şöyle tanımlar:

layout shift score = impact fraction × distance fraction

• Impact fraction, “measures how unstable elements impact the viewport area between two frames” — hareket eden öğelerin önce ve sonra kapladığı birleşik görünür alanın, görünüm alanına oranıdır.
• Distance fraction, “the greatest horizontal or vertical distance any unstable element has moved in the frame divided by the viewport’s largest dimension (width or height, whichever is greater).”

Her iki boyut da bağımsız olarak önemlidir. Ekranın çoğu boyunca ilerleyen küçük bir öğe ile yalnızca biraz kıpırdayan büyük bir öğenin puanları çok farklı olabilir. web.dev’in hesaplama örneğinde 0.75 impact fraction ve 0.25 distance fraction, 0.1875 layout shift puanı verir.

Oturum pencereleri: herkesin yanlış anladığı bölüm

CLS hakkında en sık yanlış söylenen ve özellikle akılda kalmasını istediğim gerçek şudur. CLS, sayfanın yaşamı boyunca oluşan tüm kaymaların toplamı değildir. Eskiden böyleydi — bu durum Haziran 2021’de değişti.

Bugünkü tanım şöyledir: “CLS measures the largest burst of layout shift scores for every unexpected layout shift that occurs during the entire lifecycle of a page.” Böyle bir kümelenme, oturum penceresi olarak adlandırılır: “one or more individual layout shifts occur in rapid succession with less than 1-second in between each shift and a maximum of 5 seconds for the total window duration.” CLS, bu pencerelerin en büyüğünün puanıdır; toplam veya ortalama değildir. Evidence for this claim CLS uses the largest session window of unexpected layout shifts, with gaps under one second and a maximum five-second window; recent discrete input can exclude a shift. Scope: Current CLS session-window and recent-input rules. Confidence: high · Verified: 2026-07-14 web.dev: Cumulative Layout Shift

Değişikliğin nedeni neydi? Eski, her şeyi toplayan tanım uzun ömürlü sayfaları sessizce cezalandırıyordu. Tek sayfalı bir uygulama veya sonsuz kaydırmalı akış, her bir kayma küçük ve aralıklı olsa bile yalnızca daha uzun süre var olarak daha fazla CLS biriktiriyordu. Chrome Speed Metrics ekibi süreyi cezalandırmamak için azami session window’a geçti ve ortalama yerine maksimumu seçti; böylece küçük, ikincil bir kaymayı düzeltmek puanı daha kötü yapmıyordu. Değişiklik yayıldığında hiçbir kaynak daha kötü puan almadı, çoğunda değişiklik olmadı ve yavaş arayüzlü ya da sonsuz kaydırmalı sayfaların bir bölümü iyileşti. Hâlâ “tüm kaymaların toplamı” diyen eski bir yazı okursanız güncel değildir.

Neler sayılır — neler sayılmaz

Gerçekte puanınıza neyin girdiğini üç istisna belirler:

• Görünüm alanının dışındaki kaymalar sayılmaz. Yalnızca mevcut görünüm alanında görünen içerikteki kaymalar puanlanır. Kullanıcının hiç kaydırmadığı uzun bir sayfanın alt bölümündeki kaymanın etkisi yoktur. Pratikte bu, görünüm alanındaki kaymaları düzeltmenin sayfanın çok aşağısındaki kaymaların peşine düşmekten neredeyse her zaman daha yüksek yatırım getirisi sağladığı anlamına gelir.
• Kullanıcının başlattığı kaymalara 500 ms tolerans tanınır. “Layout shifts that occur within 500 milliseconds of user input will have the hadRecentInput flag set, so they can be excluded from calculations.” Google’a göre, kullanıcı etkileşimlerine yanıt olarak gerçekleşen kaymalar “that occur in response to user interactions… are generally fine, as long as the shift occurs close enough to the interaction that the relationship is clear to the user.” Bir akordeonu açmak veya menüyü genişletmek beklenen hareketlerdir; bu nedenle hesaba katılmazlar.
• Ancak kaydırma muafiyet sağlamaz. 500 ms’lik istisna yalnızca dokunma, tıklama ve tuşa basma gibi ayrık olaylar için geçerlidir. Kaydırma ve parmaklarla yakınlaştırma gibi sürekli hareketler istisna penceresini tetiklemez. Kullanıcı kaydırırken içerik yer değiştirirse bu yine hesaba katılır. Bu ayrım birçok kaynakta yanlış aktarılır; doğru uyguladığınızdan emin olun. Evidence for this claim A layout shift occurring within 500 milliseconds of a qualifying recent user input has hadRecentInput set and is excluded from CLS. Scope: field and lab Confidence: high · Verified: 2026-07-16 Cumulative Layout Shift (CLS)

Eşikler ve puanın kaynağı

“To provide a good user experience, sites should strive to have a CLS score of 0.1 or less,” Bu değer, “the 75th percentile of page loads, segmented across mobile and desktop devices.” temel alınarak ölçülür. Aralıkların tamamı şöyledir: Evidence for this claim CLS is good at 0.1 or less and poor above 0.25, assessed at the 75th percentile of page loads. Scope: Current web.dev CLS field thresholds. Confidence: high · Verified: 2026-07-14 web.dev: Cumulative Layout Shift

• İyi: ≤ 0,1
• İyileştirme gerekiyor: 0,1–0,25
• Kötü: > 0,25

0,1 eşiği keyfî değildir. Google’ın kullanıcı araştırması, “levels of shift from 0.15 and higher were consistently perceived as disruptive, while shifts of 0.1 and lower were noticeable but not excessively disruptive.” sonucuna ulaşmıştır. Üçüncü taraf yerleştirmeleri (reklamlar ve sosyal içerikler) çok sık kaymaya yol açtığından, daha katı bir sınırın gerçek web ortamında uygulanması zor olacaktı; 0,1 değerinin seçilmesinde bu da etkili oldu.

“Saha verisinin 75. yüzdelik dilimi” kısmı kritik önemdedir; bu da bizi en büyük ölçüm tuzağına getirir.

Laboratuvar ve saha: sayılar neden uyuşmaz

Çoğu kişinin yanıldığı yer burasıdır. Lighthouse ve diğer laboratuvar araçları genellikle 0,0’a yakın CLS bildirirken saha verisi — ve Google — çok daha kötü bir sonuç gösterebilir. Fark, araçlardan birinin dürüst olmamasından değil kapsamdan kaynaklanır. Laboratuvar çalıştırması tek ve kısa, betiklenmiş bir sayfa yüklemesidir: kaydırmaz, tıklamaz ve beklemez; bu nedenle yalnızca ilk yükleme kaymalarını yakalar. Saha verisi (CrUX), kayan bir pencere boyunca çok sayıda kullanıcı, cihaz ve gezinmedeki gerçek ziyaretleri birleştirir; CLS sayfanın tüm yaşam döngüsü üzerinden tanımlanır — menülerin açılması, kullanıcı kaydırırken tembel içeriğin yüklenmesi, geç gelen reklamların dolması ve oturum ne kadar sürerse sürsün. Kısa bir laboratuvar çalışması bunların çoğunu yapısal olarak göremez.

Pratik kural şudur: belirli bir kaymayı ayıklamak için laboratuvar verisini, gerçek puanınızı bilmek için saha verisini kullanın. Google, PageSpeed Insights ve Search Console’da sunulan Chrome User Experience Report (CrUX) saha verisine göre sıralama yapar. Lighthouse 0,0 okurken PageSpeed Insights 0,18 gösteriyorsa gerçek kullanıcılarınızı yansıtan sayı olarak saha sonucunu kabul edin; sonra sayfayla gerçek ziyaretçi gibi etkileşime girerek kaymayı laboratuvarda yeniden üretin. Bilinmesi gereken iki kapsam farkı daha var: Lighthouse dahil çoğu araç iframe layout shift’lerini üst belgenin puanına taşımaz; CrUX bunları yansıtabilir. Layout Instability API üzerine kurulu RUM da aynı iframe kör noktasını taşır; bu nedenle kendi izleme veriniz, ilk taraf ilişkilendirmeniz CrUX’tan daha iyi görünürken onun daha kötü görünen sayısını yeterince açıklamayabilir.

Yaygın nedenler

Bunları gördüğüm sıklığa göre kabaca sıralarsam:

1. Boyutları olmayan görseller ve videolar. Ayrılmış yükseklik olmayınca medya yüklenirken altındaki her şey sıçrar.
2. Ayrılmış alanı olmayan reklamlar, embed’ler ve iframe’ler. Reklam ağları dinamik boyutlar sunar; embed’ler yüklenmeden önce yüksekliklerini bildirmez.
3. Mevcut içeriğin üstüne dinamik olarak eklenen içerik. Cookie banner’ları, bildirim çubukları, “related” bileşenleri ve geç yüklenen promosyonlar; ekranda olanı aşağı iten her şey.
4. Web fontları (FOIT/FOUT). Özel font yedek fontun yerini alınca metrikleri farklıysa metin yeniden akar.
5. Layout tetikleyen özelliklerle animasyon. top, left, margin, box-shadow veya box-sizing animasyonu tarayıcıyı her karede sayfayı yeniden yerleştirmeye zorlar.

Çözümler

Her çözüm nedenini yansıtır:

• Görseller/videolar — alan ayırın. Tarayıcının en-boy oranını hesaplayıp kutu için yer ayırabilmesi amacıyla width ve height özniteliklerini ayarlayın; duyarlı davranış için bunları img { height: auto; width: 100%; } ile birlikte kullanın veya CSS aspect-ratio özelliğinden yararlanın. Çoğu sitede en fazla etki sağlayan CLS düzeltmesi budur.
• Reklamlar/yerleştirmeler/iframe’ler — bunlar için de alan ayırın. Kapsayıcıda min-height veya aspect-ratio kullanın. Google Publisher Tag’in reklam alanlarına ilişkin yönlendirmesi nettir: “Setting a fixed height and width directly on the ad slot div is the most effective way to do this.” Birden fazla boyutu destekleyen alanlarda yapılandırılmış en büyük boyut için yer ayırın. Kalan kaymaların görünüm alanının dışında gerçekleşmesi için geç yüklenen içeriği daha aşağıya yerleştirin.
• Dinamik içerik — belge akışına sonradan eklemeyin. Nihai boyutla eşleşen bir yer tutucu ayırın veya içeriği akışa eklemek yerine mevcut içeriğin üzerine bindirin. İskelet yükleyiciler yalnızca nihai boyutlarla tam olarak eşleşirlerse yardımcı olur; gerçek içerikten birkaç piksel kısa bir iskelet bile kaymaya yol açar. Beklenmedik eklemeler yerine kullanıcı tarafından tetiklenen yüklemeleri (“Load more”) tercih edin.
• Fontlar — metrikleri eşleştirin. font-display: optional, fiilen sıfır CLS riski taşıyan tek değerdir; swap görünmez metni azaltır ancak font değiştirilirken kaymaya yol açabilir. Daha da iyisi, yedek fontu web fontuyla aynı boyutlara getirmek ve geçişi sorunsuz kılmak için CSS metrik geçersiz kılmalarını — size-adjust, ascent-override, descent-override, line-gap-override — kullanın. Kritik fontları önceden yükleyin.
• Animasyonlar — yalnızca transform kullanın. top/left/margin yerine transform (translate, scale, rotate) ile animasyon uygulayın. Transform tabanlı animasyonlar birleştirme aşamasında işlenir ve düzen hesaplamasını tetiklemez; dolayısıyla hiçbir öğeyi kaydırmaz.

CLS sıralamalara nasıl dahil olur (oranı koruyun)

CLS, Google’ın page experience sinyalindeki girdilerden biridir. Google, Core Web Vitals’ın sıralama sistemlerinin kullandığı şeyler olduğunu söylüyor; ancak güncel Arama belgeleri kesin bir CLS ağırlığı, eşitlik bozma kuralı veya sıralama garantisi yayımlamıyor. Bu yüzden “eşitlik bozucudur” dahil belirli mekanizmaları belgelenmiş gerçek değil, işe yarayan bir yaklaşık açıklama olarak ele alın. Core Web Vitals hakkında yazdığım her şeyde tavsiyem şu: “iyi” bandına girin ve ilerleyin. Çoğu site 0,08’i 0,02’ye indirmekten anlamlı bir sıralama veya iş kazanımı görmez; tek bir puan da gelir ya da dönüşüm sonucunu nadiren tek başına açıklar. CLS temel eşiği geçme meselesidir — eşiği aşmak istersiniz ama LCP, INP veya açıkçası asıl içeriğiniz pahasına SEO programınızın merkezine dönüşmemelidir.

Kafa karışıklığını ciddi biçimde azaltan iki operasyon notu:

• CrUX yaklaşık 28 gün geriden gelir. 28 günlük kayan bir pencere kullandığından, bugün yayımladığınız bir düzeltme PageSpeed Insights veya Search Console’a haftalar boyunca tam olarak yansımaz. Ertesi sabah sayı değişmediğinde paniğe kapılmayın.
• İlişkilendirilen öğe çoğu zaman kök neden değildir. Layout Shift Attribution API hangi öğenin hareket ettiğini söyler; ancak web.dev’in belirttiği gibi, “it’s possible that these elements are only indirectly related to the ‘root cause’ of layout instability.” Sıçrayan metin çoğu zaman üstündeki, boyutları belirtilmemiş bir görselin geç yüklenmesinden etkilenen öğedir; belirtiyi değil nedeni düzeltin. Sorunu zaman damgasından tetikleyiciye uzanan bir döngü olarak inceleyin: kaymanın başlangıç zamanını not edin, ardından aynı zaman aralığında başka nelerin değiştiğini — bir ağ isteğinin tamamlanması, görsel veya fontun yüklenmesi, yeniden boyutlandırma ya da sınıf/stil değişikliği — kontrol edin. İlişkilendirilen düğümü bu tetikleyiciyle eşleştirene kadar onu kanıt değil, ipucu olarak değerlendirin.

AI özeti

Advanced sürümünün yoğunlaştırılmış özeti:

• CLS = görsel kararlılık; görünür içeriğin beklenmedik hareketi için Core Web Vital. Largest Contentful Paint ve Interaction to Next Paint’in yanında yer alır.
• Birimsiz puandır, süre değildir. 0,05 bir orandır; 50 ms değildir.
• Kayma başına formül: impact fraction × distance fraction — görünüm alanının ne kadarının hareket ettiği ile görünüm alanının en büyük boyutuna göre ne kadar uzağa hareket ettiği.
• Metrik en büyük session window’dur (kaymalar arasında ≤ 1 sn, toplam pencere ≤ 5 sn) — yaşam boyu toplam değildir. Uzun yaşayan/SPA sayfaları cezalandırmamak için Haziran 2021’de değiştirildi; ortalama yerine maksimum seçildi.
• Eşikler (75. yüzdelik dilim, saha verisi): İyi ≤ 0,1 · İyileştirme gerekiyor ≤ 0,25 · Kötü > 0,25.
• İstisnalar: ekran altındaki kaymalar sayılmaz; ayrık girdiden (dokunma/tıklama/tuş) sonraki 500 ms içindeki kaymalar hariçtir — kaydırma muaf değildir.
• Nedenler: boyutu belirtilmemiş görseller/videolar/reklamlar/iframe’ler/embed’ler; mevcut içeriğin üstüne eklenen içerik; web fontları; layout tetikleyen özelliklerin animasyonu.
• Çözümler: width/height veya aspect-ratio ayarlamak; dinamik içerik için alan ayırmak (iskeletler tam boyutla eşleşmeli); font-display + size-adjust; yalnızca transform ile animasyon.
• Laboratuvar ≠ saha. Lighthouse sayfayla etkileşime girmediği veya yaşam döngüsünü çalıştırmadığı için çoğu zaman 0’a yakın okur; Google’ın sıralamada kullandığı veri saha verisidir (CrUX/PageSpeed Insights). Iframe kaymaları genellikle ne laboratuvar ne de RUM araçlarında üst puana aktarılır.
• Sıralama: Google’ın sıralama sistemlerinin page experience içinde kullandığını söylediği girdilerden biri; belgelenmiş ağırlık veya eşitlik bozucu kural yoktur. Belirli bir mekanizmayı kovalamak yerine “iyi” bandına ulaşın. CrUX yaklaşık 28 gün geriden gelir; ilişkilendirilen öğe çoğu zaman kök neden değildir.

Resmî belgeler

Google / Chrome ekibinden birincil kaynak belgeleri.

Temel CLS belgeleri

• Cumulative Layout Shift (CLS) — kanonik tanım, impact × distance formülü, session window’ları, eşikler ve hadRecentInput istisnası (Milica Mihajlija ve Philip Walton).
• Optimize Cumulative Layout Shift — görseller, reklamlar/embed’ler, eklenen içerik, fontlar ve animasyonlar için resmî nedenler/çözümler rehberi.
• Debug layout shifts — Chrome DevTools’ta kaymaları bulma, Layout Shift Regions kaplaması ve LayoutShiftAttribution API (Katie Hempenius ve Barry Pollard).

Arka plan ve ölçüm

• Evolving Cumulative Layout Shift in web tooling — metriğin tüm kaymaların toplamından Haziran 2021’de en büyük session window’a neden geçtiği (Annie Sullivan ve Hongbo Song, Chrome Speed Metrics Team).
• How the Core Web Vitals metrics thresholds were defined — 0,1 / 0,25 bantlarının arkasındaki kullanıcı araştırması ve erişilebilirlik verileri.
• Getting started with measuring Web Vitals — laboratuvar ve saha verisi ile laboratuvar CLS’sinin neden yapay biçimde düşük görünebildiği.
• Font best practices — font-display, metrik geçersiz kılmaları ve font kaynaklı CLS için ön yükleme.

Reklamlar ve Arama

• Minimize layout shift — reklam alanı için yer ayırmaya yönelik Google Publisher Tag rehberi.
• Understanding Core Web Vitals and Google Search results — CLS dahil CWV’nin Arama’daki rolü.

Kaynaktan alıntılar

Google / Chrome ekibinin kayda geçmiş açıklamaları. Her bağlantı, kaynak sayfadaki alıntılanan bölüme doğrudan gider.

Google — CLS nedir

• “Cumulative Layout Shift (CLS) is a stable Core Web Vital metric. It’s an important, user-centric metric for measuring visual stability because it helps quantify how often users experience unexpected layout shifts.” Alıntıya git
• “CLS measures the largest burst of layout shift scores for every unexpected layout shift that occurs during the entire lifecycle of a page.” Alıntıya git

Google — formül

• “layout shift score = impact fraction * distance fraction” Alıntıya git
• “The impact fraction measures how unstable elements impact the viewport area between two frames.” Alıntıya git
• “The distance fraction is the greatest horizontal or vertical distance any unstable element has moved in the frame divided by the viewport’s largest dimension (width or height, whichever is greater).” Alıntıya git

Google — session window

• “A burst of layout shifts, known as a session window, is when one or more individual layout shifts occur in rapid succession with less than 1-second in between each shift and a maximum of 5 seconds for the total window duration.” Alıntıya git

Google — eşikler ve kullanıcı girdisi

• “To provide a good user experience, sites should strive to have a CLS score of 0.1 or less… a good threshold to measure is the 75th percentile of page loads, segmented across mobile and desktop devices.” Alıntıya git
• “Layout shifts that occur within 500 milliseconds of user input will have the hadRecentInput flag set, so they can be excluded from calculations.” Alıntıya git
• “Layout shifts that occur in response to user interactions (such as clicking or tapping a link, pressing a button, or typing in a search box) are generally fine, as long as the shift occurs close enough to the interaction that the relationship is clear to the user.” Alıntıya git

Google — eşikler nasıl seçildi

• “levels of shift from 0.15 and higher were consistently perceived as disruptive, while shifts of 0.1 and lower were noticeable but not excessively disruptive.” Alıntıya git

Google — reklam alanı için yer ayırma

• “Setting a fixed height and width directly on the ad slot div is the most effective way to do this.” Alıntıya git

Google — ilişkilendirilen öğe ve kök neden

• “elements listed as sources are the elements that shifted during the layout shift. However, it’s possible that these elements are only indirectly related to the ‘root cause’ of layout instability.” Alıntıya git

CLS nedenleri → çözümleri kontrol listesi

Yukarıdan aşağı çalışın; ilk iki madde gerçek dünyadaki CLS’nin çoğunu düzeltir.

• Her <img> ve <video> öğesinde width + height (veya CSS aspect-ratio) bulunur; duyarlı layout’lar için img { height: auto; width: 100%; } kullanılır.
• Reklam alanları, iframe’ler ve embed’ler min-height / aspect-ratio ile alan ayırır; çok boyutlu reklam alanları yapılandırılmış en büyük boyut için yer ayırır.
• Geç yüklenen içerik mümkünse ekranın altında bulunur; böylece kalan kayma sayılmaz.
• Eklenen içerik (cookie banner’ları, promosyonlar, “related” bileşenleri) üstüne yerleştirilir veya önceden alan ayırır — mevcut içeriğin üstüne eklenmez.
• İskelet yer tutucular son içeriğin tam boyutlarıyla eşleşir (birkaç piksel fark bile kaydırır).
• Web fontları, uygun olduğunda font-display: optional kullanır; ya da yedek metriklerle eşleşmek için swap / size-adjust ile ascent-override kullanır; kritik fontlar önceden yüklenir.
• Animasyonlar yalnızca transform kullanır — asla top, left, margin, box-shadow veya box-sizing değil.
• Puanı yalnızca Lighthouse’ta değil, saha verisinde (PageSpeed Insights / Search Console / CrUX) kontrol ettiniz.
• Kaymaları sayfayla etkileşime girerek yeniden ürettiniz — yalnızca ilk yüklemede değil, kaydırarak, menü açarak ve tembel yüklemeleri tetikleyerek.
• Reklam/iframe kaymaları sahada doğrulandı (laboratuvar araçları bunları çoğu zaman üst puana taşımaz).

CLS kopya kağıdı

Sayılar

Tanım, tek satırda

• layout shift score = impact fraction × distance fraction (kayma başına).
• CLS = kaymaların en büyük session window’u — kaymalar arasında ≤ 1 sn, toplam pencere ≤ 5 sn. Yaşam boyu toplam değildir (Haziran 2021 öncesi durum buydu).
• Birimsiz puandır, süre değildir.

Neler hariçtir

• Ekranın altındaki (mevcut görünüm alanında olmayan) kaymalar.
• Ayrık girdiden (dokunma/tıklama/tuş) sonraki 500 ms içindeki kaymalar — hadRecentInput.
• Hariç olmayan: kaydırma veya pinch sırasında oluşan kaymalar (sürekli hareketler).

Nedenler → çözümler

Ölçüm tuzakları

• Lighthouse (laboratuvar) çoğu zaman ~0 okur — sayfayla etkileşime girmez veya tüm yaşam döngüsünü çalıştırmaz. Google’ın sıralamada kullandığı CrUX / PageSpeed Insights (saha) verisidir.
• CrUX yaklaşık 28 gün geriden gelir — düzeltmelerin görünmesi haftalar sürer.
• Iframe kaymaları laboratuvar araçlarında genellikle üst puana taşınmaz.
• İlişkilendirilen öğe hareket edendir, kök neden olmak zorunda değildir.

CLS’yi ölçmek ve ayıklamak için araçlar

Saha verisi (Google’ın sıralamada kullandığı)

• PageSpeed Insights — sayfa ve kaynak düzeyinde CrUX saha CLS’si ile yanında Lighthouse laboratuvar çalıştırması. Laboratuvar-saha farkını kendiniz görmenin en hızlı yolu.
• Search Console — Core Web Vitals raporu — tüm sitenizdeki URL gruplarına göre saha CLS’si, durumla gruplanmış biçimde.
• CrUX (Chrome User Experience Report) — temel saha veri kümesi; CrUX panoları / BigQuery ile geçmişi inceleyin.

Laboratuvar verisi (ayıklama için)

• Chrome DevTools — Performance paneli — bir iz kaydedin, sonra Layout Shifts izini okuyun; bir kaymaya tıklamak hareket eden öğeleri vurgular ve kayma puanını gösterir. Live Metrics, etkileşim sırasında CLS’yi gerçek zamanlı günceller.
• Layout Shift Regions kaplaması — DevTools → Settings → More tools → Rendering → Layout Shift Regions. Yenileyin; kayma alanları yanıp sönerek onları görmenizi sağlar.
• Lighthouse — hızlı laboratuvar CLS’si; ancak yalnızca ilk yükleme kaymalarını yakaladığını unutmayın.
• WebPageTest — film şeridi ve iz ile laboratuvar CLS’si.

RUM (kendi saha veriniz)

• web-vitals JavaScript kütüphanesi — onCLS() kendi ziyaretçilerinizden gerçek kullanıcı CLS’sini (~2 KB) bildirir; insanların gerçekte yaşadığının en doğru görünümüdür.
• PerformanceObserver (layout-shift) — kütüphanenin sardığı ham API; ayrıca hangi öğelerin hareket ettiğini gösteren LayoutShiftAttribution sources verisi.

Araçların kendisi nasıl puanlıyor

Bu sayfanın anlattığı metriğin canlı bir örneği — tanınmış sayfa hızı ve izleme hizmetleri, kendi gerçek kullanıcı mobil CLS’lerine göre sıralanmıştır (Chrome UX Report saha verisi):

Önce hangi CLS düzeltmesini yapmalısınız?

Gerçek sorunu gizleyen CLS hataları

Temiz bir Lighthouse çalıştırmasını kanıt saymak

Lighthouse, izin banner’ı, reklam veya etkileşimle tetiklenen bir kayma gerçekleşmeden önce tamamlanabilir. Ayıklama için laboratuvar çalıştırmasını kullanın; ancak sorunun düzeldiğini ilan etmeden önce CrUX’ı veya kendi gerçek kullanıcı izlemenizi kontrol edin.

Yalnızca DevTools’un hareket ettiğini söylediği öğeyi düzeltmek

Hareket eden öğe çoğu zaman kurbandır. Üstündeki geç yüklenen öğe neden olabilir. İzi yeniden oynatın ve hareketten hemen önce neyin eklendiğini veya yeniden boyutlandığını inceleyin.

Alanı tahmin edilmiş sabit bir yükseklikle ayırmak

Duyarlı içerik daha uzun veya daha kısa olduğunda sabit bir yer tutucu ikinci bir kayma yaratabilir. İçeriğin oranları biliniyorsa doğal boyutlar veya aspect-ratio kullanın.

Layout özelliklerini animasyonla değiştirmek

top, left veya margin’leri değiştirmek çevredeki içeriği hareket ettirebilir. Etkinin belge akışını değiştirmesi gerekmiyorsa transform ile animasyon yapın.

Belirtiye göre CLS sorununu teşhis edin

Saha CLS’si kötü ama laboratuvar puanı sıfıra yakın

Olası neden: kayma etkileşimden sonra, daha uzun bir oturum sırasında veya yalnızca kullanıcıların bir bölümünde gerçekleşiyor. Çözüm: Performance panelini kaydederken gerçek yolculuğu yeniden üretin, ardından gerçek kullanıcı izlemesine web-vitals ilişkilendirmesi ekleyin. Doğrulama: sorunlu etkileşim ve hareket eden öğe izde veya RUM kaydında görünür.

Özel font geldiğinde metin sıçrıyor

Olası neden: yedek font ve web fontu farklı metrikler kullanıyor. Çözüm: yalnızca uygun olduğunda kritik fontu önceden yükleyin ve metrik geçersiz kılmalarıyla yedeği eşleştirin. Doğrulama: önbellek devre dışıyken yeniden oynatın ve Layout Shifts izinin artık değişimi kaydetmediğini doğrulayın.

Bir banner veya reklam sayfayı aşağı itiyor

Olası neden: içerik gelmeden önce alanın ayrılmış boyutları yok. Çözüm: kararlı bir kapsayıcı ayırın veya mesajı görünür içeriği itmeyeceği bir yere koyun. Doğrulama: yüklemeyi yavaşlatın ve alanın kapladığı yeri koruduğunu izleyin.

CLS testlerde iyileşiyor ama PageSpeed Insights’ta iyileşmiyor

Olası neden: CrUX, anlık dağıtım kontrolü değil kayan bir saha veri kümesidir. Çözüm: önce değişikliği laboratuvarda ve RUM’da doğrulayın, sonra saha penceresinin dönmesini bekleyin. Doğrulama: kamuya açık CrUX toplamı iyileşmeden önce kendi yayın sonrası saha dağılımınızın iyileştiğini görün.

Tarayıcıdaki layout shift’leri yakalayın

Sorunu yeniden üretmeden önce bunu DevTools Console’a yapıştırın. Yakın zamanda kullanıcı girdisiyle ilişkili kaymaları yok sayar ve puanla birlikte tarayıcının ilişkilendirdiği öğeleri yazdırır.

const observer = new PerformanceObserver((list) => {
  for (const entry of list.getEntries()) {
    if (entry.hadRecentInput) continue;
    console.table({
      value: entry.value,
      time: Math.round(entry.startTime),
      elements: entry.sources?.map((source) => source.node),
    });
  }
});

observer.observe({ type: 'layout-shift', buffered: true });

İlişkilendirilen düğüm bir ipucudur; nedenin otomatik kanıtı değildir. Zaman damgasını aynı izdeki ağ istekleri, font yüklemeleri ve DOM eklemeleriyle karşılaştırın.

CLS düzeltmesinin işe yaradığını kanıtlayın

Ayrılmış alan testi

Yapılacak test: önbelleği devre dışı bırakın, bağlantıyı yavaşlatın, yenileyin ve Performance panelindeki Layout Shifts izini kaydedin. Beklenen sonuç: medya veya embed yüklenmeden önce ve sonra aynı alanı korur. Başarısızlık yorumu: kapsayıcı boyutlar için hâlâ geç gelen içeriğe bağlıdır. İzleme penceresi: izde hemen. Geri alma tetikleyicisi: yeni yer tutucu kırpma, fazla boş alan veya duyarlı bir kırılma noktasında yeni bir kayma yaratır.

Font değişimi testi

Yapılacak test: metni ve Layout Shifts izini izlerken önbelleği devre dışı bırakarak yeniden yükleyin. Beklenen sonuç: yedek fonttan web fontuna geçiş ölçülebilir bir kayma yaratmaz. Başarısızlık yorumu: yedek metrikler hâlâ farklıdır veya kritik font çok geç gelir. İzleme penceresi: tekrarlanan laboratuvar çalışmalarında hemen. Geri alma tetikleyicisi: değişiklik metni daha uzun süre gizler veya nihai tipografiyi anlamlı biçimde bozarsa.

Saha doğrulaması

Yapılacak test: değiştirilen şablon için yayın sonrası onCLS() verisini yayın öncesi temel değerle karşılaştırın, ardından CrUX’ı izleyin. Beklenen sonuç: gerçek kullanıcı p75’i iyileşir ve önemli yolculuklarda kuyruk kötüleşmez. Başarısızlık yorumu: başka bir geç gelen veya etkileşimle tetiklenen kaynak kalmıştır. İzleme penceresi: trafik geldikçe RUM; kayan 28 günlük pencere boyunca CrUX. Geri alma tetikleyicisi: yayın sonrasında CLS veya kullanıcı etkileşimi hataları sürekli kötüleşirse.

İzlemeye değer CLS metrikleri

p75’te gerçek kullanıcı CLS’si

Metrik: her önemli şablon ve cihaz sınıfı için 75. yüzdelik dilimdeki CLS. Ne anlatır: ziyaretlerin çoğunun görsel kararlılık hedefini karşılayıp karşılamadığını. Nasıl alınır: CrUX, PageSpeed Insights veya web-vitals RUM. Karşılaştırma / gerçekçi aralık: 0,1 veya altı iyi; 0,1–0,25 iyileştirme gerekiyor; 0,25’in üstü kötü. Sıklık: yayınları RUM’da izleyin ve kayan saha eğilimini aylık inceleyin.

Kötü ziyaret oranı

Metrik: CLS’si 0,25’in üzerinde olan gerçek ziyaretlerin payı. Ne anlatır: kabul edilebilir bir p75’in zarar verici bir kuyruğu gizleyip gizlemediğini. Nasıl alınır: onCLS() olaylarını şablon ve yolculuğa göre gruplandırın. Karşılaştırma / gerçekçi aralık: bir site tabanı oluşturun ve kötü kutuyu küçültün; trafik karışımı evrensel bir hedefi yanıltıcı kılar. Sıklık: yüksek trafikli şablonlar için haftalık ve layout yayınlarından sonra.

Nedene göre kayma ilişkilendirmesi

Metrik: layout-shift girdilerinin öğe veya bileşene göre gruplanması. Ne anlatır: hangi yinelenen uygulamanın en fazla kararsızlığa sahip olduğunu. Nasıl alınır: web-vitals’ın ilişkilendirme derlemesi veya PerformanceObserver. Karşılaştırma / gerçekçi aralık: evrensel bir aralık yoktur; bileşenleri toplam etki ve etkilenen ziyaretlere göre karşılaştırın. Sıklık: her şablon veya bileşen yayınında inceleyin.

Zamanınıza değer kaynaklar

Resmî, ayrıntılı

• Cumulative Layout Shift (CLS) — kanonik başvuru.
• Optimize Cumulative Layout Shift — resmî düzeltme rehberi.
• Debug layout shifts — DevTools iş akışı.
• Evolving Cumulative Layout Shift in web tooling — Haziran 2021’deki session-window değişikliği, bunu yapan ekip tarafından açıklanıyor.

Uygulamacılardan

• How To Fix Cumulative Layout Shift (CLS) Issues — Barry Pollard, Smashing Magazine. Font tanımlayıcılarını ve “hareket eden öğe kök neden değildir” sorununu derinlemesine ele alır.
• Cumulative Layout Shift in Practice — Nic Jansma (Cloudflare; W3C Web Performance WG). Ölçüm ayrıntıları için en iyi yazı: iframe ilişkilendirme boşlukları, beş öğelik ilişkilendirme örneği ve araçlar arası farklılıklar.
• Measure and Optimize Cumulative Layout Shift — DebugBear.
• The Almost-Complete Guide to Cumulative Layout Shift — Jess Peck. SPA gezinme kaymaları ve sürekli hareket istisnalarının ayrıntıları dahil uç durumları kapsamlı biçimde ele alır.
• Layout shift culprits — CLS culprit içgörü paneli hakkında Chrome DevTools belgeleri; web.dev debug rehberine yararlı eşlikçi.
• How to Fix Cumulative Layout Shift (CLS) — Kinsta. WordPress’e özgü nedenleri (galeri görselleri, geç yüklenen widget’lar, cookie banner’ları) kapsayan pratik CMS yürüyüşü.
• Layout Instability API — WICG spesifikasyonu. CLS’nin üzerine kurulduğu temel tarayıcı API’si; özel RUM oluşturuyorsanız veya tam hadRecentInput anlamını bilmeniz gerekiyorsa yararlı.

Kendi çalışmamda yeri

• CLS, Core Web Vitals kapsamımda “temel eşik” metriği olarak görünür — izleyin, iyi banda girin ve LCP, INP ve içeriğinize göre oranını koruyun. Google kesin bir CLS ağırlığı veya eşitlik bozma kuralı yayımlamadığı için bu, oyunun tamamı değil, izlenecek girdilerden biridir.

Alıntılamaya değer istatistikler

• 0,1 eşiği algı araştırmasına dayanır. Google’ın kullanıcı çalışmaları, 0,15 ve üzerindeki kaymaların sürekli rahatsız edici algılandığını; 0,1 ve altındaki kaymaların ise fark edilir ama aşırı rahatsız edici olmadığını buldu. Kaynak
• CLS, geçilmesi en kolay Core Web Vital’dır. Kurumsal denetimlerimdeki desen tutarlı: sitelerin büyük çoğunluğu CLS eşiğini (çoğu zaman ~%80+) geçer; ancak üç metriğin tamamını birlikte yalnızca yarıdan biraz fazlası geçer — CLS sizi geride tutan metrik nadiren olur.
• Haziran 2021 değişikliği hiçbir zaman zarar vermedi. CLS en büyük session window’a geçtiğinde hiçbir kaynak daha kötü puan almadı, çoğunda değişiklik olmadı ve sonsuz kaydırmalı/yavaş arayüzlü sayfaların bir bölümü iyileşti. Kaynak
• Boyutsuz medya hâlâ her yerde. Sektör taramaları (Web Almanac), açık boyutları olmayan görseller yayımlayan sayfaların payının sürekli yüksek olduğunu bulur — en yaygın CLS nedeni ve düzeltilmesi en kolay olanıdır.
• Dünya genelindeki web sitelerinin %72’si artık iyi CLS’ye ulaşıyor (2025 Web Almanac / HTTP Archive verisi); bu CLS’yi geçilmesi en kolay Core Web Vital yapıyor, ancak mobil sayfaların %62’si hâlâ açık boyutları olmayan en az bir görsel yayımlıyor; bu da en yaygın neden. Kaynak: HTTP Archive / Web Almanac
• İş etkisi: Rakuten 24, düşük CLS yaşayan kullanıcılar için ziyaretçi başına gelirde %53,37 artış bildirdi — sık alıntılanan bir vaka çalışmasıdır; belirli bir CLS sayısının başka sitelerde belirli bir iş sonucuna neden olduğunun kanıtı değildir. Kaynak: corewebvitals.io vaka çalışmaları

Videolar

• Google Search Central / Chrome for Developers (YouTube) — Layout Shifts izi ve Layout Shift Regions kaplamasının DevTools demoları dahil Core Web Vitals ve Debug layout shifts yürüyüşleri. Kanal

Kendinizi test edin: Cumulative Layout Shift

Görsel kararsızlığı ölçme ve düzeltme hakkında beş kısa soru. Her biri için bir yanıt seçin, sonra kontrol edin.

Değişiklik günlüğü