CLS Değerinin 0.1 Altında Olması

CLS (Cumulative Layout Shift), sayfa yaşam döngüsü boyunca meydana gelen beklenmedik layout kaymalarının toplam skorunu ölçen Core Web Vitals metriğidir. 2026 itibarıyla Google, 0.1 değerini "iyi" eşiği olarak belirlemiş olup bu eşiği aşan sayfaların mobil sıralamalarda ölçülebilir düşüş yaşadığı CrUX verileriyle doğrulanmıştır. Kullanıcının okumakta olduğu metnin veya tıklamak üzere olduğu butonun aniden kayması, hem deneyim kalitesini hem de dönüşüm oranını doğrudan yıkar.

CLS Hesaplama Formülü ve Session Window Mantığı

CLS skoru, her bir layout shift'in "impact fraction" ve "distance fraction" çarpımının toplamıyla hesaplanır. Impact fraction, kayan elemanın viewport içinde kapladığı alanın oranıdır. Distance fraction ise elemanın kayma mesafesinin viewport yüksekliğine oranıdır. Örneğin viewport'un %50'sini kaplayan bir eleman %25 oranında kayarsa, o shift'in skoru 0.5 × 0.25 = 0.125 olur.

CLS, bu shift'leri session window adı verilen zaman dilimlerine gruplar. Bir session window, en fazla 5 saniye sürer ve iki shift arasında en fazla 1 saniye boşluk bulunabilir. Toplam CLS skoru, en büyük session window'un skorudur; tüm shift'lerin toplamı değildir. Bu mantık, uzun sayfa ömründe biriken küçük shift'lerin skoru şişirmesini önlemek amacıyla tasarlanmıştır. Dolayısıyla tek bir büyük kayma, onlarca küçük kaymadan daha yıkıcı etki üretir.

Beklenen ve Beklenmeyen Layout Shift Ayrımı

CLS yalnızca beklenmeyen (unexpected) layout shift'leri ölçer. Kullanıcının doğrudan etkileşimiyle (tıklama, tuş basımı) tetiklenen kaymalar CLS'e dahil edilmez. Bir accordion bileşenine tıklandığında açılan içeriğin aşağıdaki elemanları itmesi, kullanıcının beklediği bir davranıştır ve CLS'e eklenmez. Ancak sayfa yüklendikten 3 saniye sonra beliren bir reklam banner'ının tüm içeriği aşağıya itmesi, beklenmeyen bir kaymadır ve CLS'e eklenir.

Bu ayrım, 500 ms zaman penceresiyle kontrol edilir. Kullanıcı etkileşiminden sonraki 500 ms içinde gerçekleşen kaymalar "beklenen" olarak işaretlenir. 500 ms sonrasındaki kaymalar ise beklenmeyen olarak CLS'e dahil edilir. Dolayısıyla bir butona tıklandığında ağır bir API çağrısı yapılıp 2 saniye sonra DOM güncellenmesi, CLS'e eklenir. Bu durumda skeleton screen veya sabit boyutlu placeholder kullanarak kaymanın önlenmesi gerekir.

Görsellerin Boyut Bilgisi Eksikliğinden Kaynaklanan Kaymalar

CLS sorunlarının en yaygın kaynağı, width ve height attribute'leri tanımlanmamış görsellerdir. Tarayıcı, boyut bilgisi olmayan bir görseli indirmeye başladığında, görselin kaplayacağı alanı bilemez ve sıfır yükseklikle yer ayırır. Görsel yüklendiğinde gerçek boyutuna genişler ve altındaki tüm içerik aşağıya kayar. Bu kayma, doğrudan CLS skoruna eklenir.

Çözüm basit ve kesindir: her <img> etiketine width ve height attribute'leri ekleyin. Tarayıcı bu değerlerden aspect ratio'yu hesaplar ve görsel yüklenmeden önce doğru alanı rezerve eder:

    
<img src="/gorsel.webp" alt="Açıklama" width="800" height="450" loading="lazy">
    

CSS tarafında responsive davranış için:

    
img {
  max-width: 100%;
  height: auto;
}
    

Bu kombinasyon, görselin responsive olmasını sağlarken aspect ratio'yu korur. Görsel yüklendiğinde hiçbir kayma olmaz. Boyut attribute'ü eksik görseller, CLS sorunlarının %60'ından fazlasının doğrudan kaynağıdır. Bu tek düzeltme, birçok sitede CLS skorunu 0.1 altına çekmeye yeterlidir.

CSS aspect-ratio Özelliği ile Modern Oran Koruması

CSS aspect-ratio özelliği, elemanın en-boy oranını CSS seviyesinde tanımlar. Bu özellik, width ve height attribute'lerine ek olarak veya onların yerine kullanılabilir. Özellikle dinamik içerik alanlarında, iframe'lerde ve video container'larında sabit oran koruması sağlar:

    
.video-container {
  width: 100%;
  aspect-ratio: 16 / 9;
}

.product-image {
  width: 100%;
  aspect-ratio: 1 / 1;
}
    

Bu tanımla container, içerik yüklenmeden önce doğru oranı korur ve layout shift oluşmaz. aspect-ratio özelliği tüm modern tarayıcılarda desteklenmektedir. Eski tarayıcı desteği gereken projelerde padding-top hack'i fallback olarak kullanılabilir: padding-top: 56.25% ifadesi 16:9 oranı sağlar. Ancak 2026 itibarıyla padding-top yaklaşımı eskimiştir; aspect-ratio doğrudan kullanılmalıdır.

Reklam Alanlarının Sabit Boyutla Rezerve Edilmesi

Reklam banner'ları, CLS'in en problemli kaynaklarından biridir. Reklam ağları (Google AdSense, programatik reklamlar), reklam içeriğini sayfa yüklendikten sonra asenkron olarak yükler. Reklam alanı önceden rezerve edilmemişse, reklam yüklendiğinde çevresindeki tüm içerik kayar. Bu kayma, özellikle above-the-fold alanında meydana geldiğinde büyük CLS skoru üretir.

Çözüm, reklam container'ına sabit boyut vermektir:

    
.ad-slot-leaderboard {
  min-height: 90px;
  width: 728px;
  max-width: 100%;
}

.ad-slot-rectangle {
  min-height: 250px;
  width: 300px;
}
    

min-height kullanımı kritiktir. Reklam dolmazsa (fill rate düşükse) alan boş kalır ancak layout stabil olur. Reklam dolduğunda ise min-height aşılmaz çünkü reklam boyutları zaten bu değerlerle uyumludur. Bu yaklaşım, reklam kaynaklı CLS'i sıfıra indirir.

Web Fontlarının Tetiklediği Layout Shift ve FOUT Kontrolü

Web fontları yüklendiğinde, sistem fontundan web fontuna geçiş sırasında metin boyutu ve satır yüksekliği değişebilir. Bu değişim, metin bloğunun boyutunu değiştirir ve altındaki içeriğin kaymasına neden olur. Bu fenomene FOUT (Flash of Unstyled Text) denir ve doğrudan CLS'e eklenir.

font-display: swap kuralı FOUT'u tamamen önlemez; yalnızca metnin görünmez kalmasını (FOIT) engeller. Font swap sırasında sistem fontu ile web fontu arasındaki metrik fark layout shift üretir. Bu farkı minimize etmek için size-adjust, ascent-override ve descent-override CSS kuralları kullanılır:

    
@font-face {
  font-family: 'CustomFont';
  src: url('/fonts/custom.woff2') format('woff2');
  font-display: swap;
}

@font-face {
  font-family: 'CustomFont-Fallback';
  src: local('Arial');
  size-adjust: 105%;
  ascent-override: 90%;
  descent-override: 22%;
  line-gap-override: 0%;
}

body {
  font-family: 'CustomFont', 'CustomFont-Fallback', sans-serif;
}
    

Bu yapıda fallback font, web fontunun metriklerine yaklaştırılır. Font swap gerçekleştiğinde metin boyutu neredeyse aynı kalır ve layout shift minimuma iner. Next.js'in next/font modülü bu hesaplamayı otomatik yapar.

Dinamik İçerik Enjeksiyonunun CLS Etkisi

Sayfa yüklendikten sonra DOM'a eklenen dinamik içerikler (cookie consent banner, bildirim çubuğu, newsletter popup, canlı sohbet widget'ı) mevcut elemanları iterek layout shift üretir. Bu elemanlar genellikle JavaScript ile asenkron olarak yüklenir ve kullanıcı etkileşimi olmadan sayfaya eklenir; dolayısıyla beklenmeyen shift olarak CLS'e dahil edilir.

Bu sorunun üç çözüm yolu vardır. Birincisi, dinamik elemanları position: fixed veya position: absolute ile akış dışı konumlandırmaktır. Sabit konumlandırılmış elemanlar, diğer elemanları itmez ve layout shift üretmez. Cookie consent banner'ı sayfanın alt kısmında position: fixed; bottom: 0; ile konumlandırıldığında CLS etkisi sıfıra iner. İkincisi, dinamik eleman için DOM'da önceden sabit boyutlu bir placeholder bırakmaktır. Üçüncüsü, elemanı CSS transform ile animasyonla göstermektir; transform layout shift tetiklemez.

Skeleton Screen ve Placeholder Stratejisi

Skeleton screen, asenkron olarak yüklenen içeriğin yerini tutan, içeriğin genel yapısını taklit eden gri blok placeholder'dır. Bu teknik, kullanıcıya içeriğin yüklenmekte olduğunu görsel olarak bildirir ve CLS'i önler. Skeleton, gerçek içerikle aynı boyutları koruduğunda, içerik yüklendiğinde hiçbir kayma olmaz.

    
.skeleton-card {
  width: 100%;
  min-height: 320px;
  background: linear-gradient(90deg, #f0f0f0 25%, #e0e0e0 50%, #f0f0f0 75%);
  background-size: 200% 100%;
  animation: shimmer 1.5s infinite;
  border-radius: 8px;
}

@keyframes shimmer {
  0% { background-position: 200% 0; }
  100% { background-position: -200% 0; }
}
    

Kritik nokta, skeleton'un min-height değerinin gerçek içeriğin yüksekliğiyle tutarlı olmasıdır. Skeleton 200px, gerçek içerik 400px ise, içerik yüklendiğinde 200px'lik kayma oluşur. Bu tutarsızlık, skeleton'un CLS'i önleme amacını tamamen ortadan kaldırır. Dolayısıyla skeleton boyutlarının içerik boyutlarıyla test edilmesi zorunludur.

Lazy Loading ve Above-the-Fold İçerik Ayrımı

loading="lazy" attribute'ü, viewport dışındaki görsellerin yüklenmesini erteler. Bu erteleme, görselin viewport'a girdiğinde yüklenmesini tetikler. Eğer görselin boyut bilgisi eksikse, yükleme anında layout shift oluşur. Ancak boyut bilgisi tanımlıysa, alan zaten rezerve edilmiştir ve shift oluşmaz.

Above-the-fold görsellerde loading="lazy" kullanmak hem LCP hem de CLS açısından risklidir. LCP elemanının gecikmeli yüklenmesi LCP süresini uzatır; aynı zamanda viewport hesaplamasındaki zamanlama farkları, above-the-fold görselde bile anlık bir shift tetikleyebilir. Kural nettir: viewport içinde görünen ilk görsellerde loading="eager" (varsayılan) kullanın. loading="lazy" yalnızca kullanıcının scroll etmeden göremeyeceği içeriklere uygulanmalıdır.

iframe ve Embed İçeriklerin CLS Yönetimi

YouTube videoları, harita embed'leri, sosyal medya kartları ve üçüncü parti widget'lar, <iframe> veya JavaScript embed olarak sayfaya eklenir. Bu elemanlar, yüklenene kadar sıfır boyutla render edilir ve yüklendiğinde genişleyerek çevrelerindeki içeriği iter. Bu etki, özellikle metin içine gömülü embed'lerde ciddi CLS üretir.

Her iframe için sabit boyut veya aspect-ratio tanımlamak zorunludur:

    
<div style="aspect-ratio: 16/9; width: 100%;">
  <iframe src="https://www.youtube.com/embed/VIDEO_ID"
          style="width: 100%; height: 100%; border: 0;"
          loading="lazy" allow="accelerometer; autoplay; encrypted-media"
          allowfullscreen></iframe>
</div>
    

Bu wrapper <div>, iframe yüklenmeden önce 16:9 oranında alan rezerve eder. iframe yüklendiğinde wrapper boyutunu değiştirmez ve kayma oluşmaz. Sosyal medya embed'leri (Twitter kartları, Instagram gönderileri) genellikle değişken yüksekliğe sahip olduğundan, bu embed'ler için ortalama bir min-height değeri belirleyerek kısmi koruma sağlanabilir.

CSS contain Özelliği ile Layout İzolasyonu

CSS contain özelliği, tarayıcıya bir elemanın layout hesaplamalarının diğer elemanlardan bağımsız olduğunu bildirir. contain: layout kuralı, elemanın iç yapısındaki değişikliklerin dış layout'u etkilemesini engeller. Bu izolasyon, dinamik içerik yüklemelerinde shift propagasyonunu durdurur.

    
.dynamic-content-area {
  contain: layout style;
  min-height: 400px;
}
    

Bu yapıda .dynamic-content-area içindeki herhangi bir boyut değişikliği, dışarıdaki elemanları etkilemez. content-visibility: auto ile birleştirildiğinde, viewport dışındaki elemanların render maliyeti de sıfıra iner. Ancak contain: layout kullanırken elemanın sabit bir boyutla (width, height veya min-height) tanımlanması gerekir. Boyutsuz bir elemana contain: layout uygulamak, elemanın sıfır boyutla render edilmesine neden olabilir.

Hydration Mismatch Kaynaklı Layout Shift

SSR ile üretilen HTML'in istemcide JavaScript tarafından hydrate edilmesi sırasında, sunucu ve istemci çıktıları arasında fark varsa (hydration mismatch), React DOM'u yeniden oluşturur. Bu yeniden oluşturma sırasında elemanların boyutları ve konumları değişebilir ve layout shift oluşur. Bu shift, CLS skoruna doğrudan eklenir.

Hydration mismatch'in en yaygın kaynakları: sunucu ve istemci arasındaki saat dilimi farkından kaynaklanan tarih formatı farklılıkları, window.innerWidth gibi browser API'lerine dayalı koşullu render, Math.random() veya UUID üreteçleri ve kullanıcıya özel içerik (login durumu, sepet bilgisi). Bu değişkenleri useEffect hook'u içinde tanımlamak ve ilk render'da sunucu çıktısıyla tutarlı bir varsayılan kullanmak, mismatch kaynaklı CLS'i ortadan kaldırır.

Responsive Tasarımda Breakpoint Kaynaklı Kaymalar

CSS media query breakpoint'leri, farklı ekran boyutlarında farklı layout uygulanmasını sağlar. Ancak sayfa yükleme sırasında tarayıcının viewport boyutunu hesaplaması ile CSS kurallarının uygulanması arasındaki zamanlama farkı, geçici bir layout shift üretebilir. Özellikle JavaScript ile breakpoint kontrolü yapılıyorsa bu risk artar.

CSS-only breakpoint'ler bu sorunu minimize eder; çünkü CSS kuralları ilk paint'ten önce uygulanır. JavaScript ile breakpoint kontrolü (örneğin window.matchMedia ile bileşen değiştirme) ise hydration sonrasında DOM değişikliği yaparak CLS üretir. Sahadaki gerçek tecrübemiz gösteriyor ki, responsive layout kararlarını CSS'e bırakıp JavaScript'i yalnızca davranış değişiklikleri için kullanan projelerde, breakpoint kaynaklı CLS sorunları neredeyse sıfıra iniyor.

Sticky ve Fixed Elemanların CLS Etkisi

position: sticky ve position: fixed elemanlar, normal document flow'dan çıktıkları için diğer elemanları itmez ve doğrudan CLS üretmez. Ancak sticky elemanın aktifleşme anında yüksekliğinin değişmesi veya fixed elemana dönüşürken placeholder bırakılmaması, dolaylı layout shift tetikleyebilir.

Sticky header'ın scroll sırasında yükseklik değiştirmesi (örneğin 80px'den 50px'e küçülmesi) yaygın bir senaryodur. Bu yükseklik değişimi, header'ın altındaki içeriğin yukarı kaymasına neden olur ve CLS üretir. Çözüm, sticky header'ın sabit yüksekliğini korumak veya yükseklik değişikliğini transform: scale() ile uygulamaktır. transform layout değişikliği tetiklemez; yalnızca görsel ölçekleme yapar ve CLS'e eklenmez.

Infinite Scroll ve Virtualization'da CLS Kontrolü

Sonsuz scroll uygulamalarında, kullanıcı aşağı kaydırdıkça yeni içerik eklenir. Bu ekleme, mevcut içeriklerin konumunu değiştirmezse CLS üretmez. Ancak iki yaygın hata CLS'e neden olur. Birincisi, yükleme sırasında "Yükleniyor..." mesajının eklenip kaldırılmasıdır. İkincisi, footer elemanının yeni içeriklerle sürekli aşağıya itilmesidir.

Virtualization (react-virtual, tanstack/virtual) bu sorunu kökten çözer. Yalnızca viewport'ta görünen elemanlar DOM'da tutulur ve container'ın toplam yüksekliği transform ile yönetilir. Yeni içerik eklendiğinde container yüksekliği değişir ancak mevcut elemanların konumu değişmez. Footer elemanını sonsuz scroll alanının dışında, position: fixed ile konumlandırmak da footer kaynaklı CLS'i ortadan kaldırır.

Tab ve Accordion Bileşenlerinde Layout Shift Önleme

Tab ve accordion bileşenleri, kullanıcı tıklamasıyla içerik gösterir veya gizler. Kullanıcı etkileşimiyle tetiklenen kaymalar (500 ms içinde) CLS'e eklenmez. Ancak bileşenin açılma/kapanma süresi 500 ms'yi aşarsa, geç gerçekleşen layout değişiklikleri CLS olarak kaydedilir.

Bu riski ortadan kaldırmak için accordion içeriğinin açılma animasyonunu max-height geçişi yerine transform ile uygulamak etkili bir yöntemdir. Alternatif olarak, accordion içeriğinin max-height değerini JavaScript ile hesaplayıp CSS transition'a aktarmak, 500 ms zaman penceresinde kaymanın tamamlanmasını sağlar. Tab bileşenlerinde ise tüm tab içeriklerinin DOM'da yer alması ve display: none / block ile gösterilmesi, layout shift'i sıfırlar; çünkü gizli elemanlar layout hesaplamasına dahil olmaz.

Toplu DOM Manipülasyonu ve Batch Güncelleme

JavaScript ile yapılan DOM manipülasyonlarında, her DOM değişikliği tarayıcının layout'u yeniden hesaplamasını tetikleyebilir. Ardışık DOM değişiklikleri, her biri ayrı bir layout hesaplaması ve potansiyel layout shift üretir. Bu durum özellikle liste güncelleme, veri tablosu render ve dinamik form alanları ekleme gibi işlemlerde belirgin hale gelir.

Çözüm, DOM manipülasyonlarını batch'lemektir. DocumentFragment kullanarak tüm değişiklikleri bellekte yapın ve tek seferde DOM'a ekleyin. React ve Vue gibi framework'ler, state güncellemelerini otomatik batch'ler ve tek bir render döngüsünde DOM'u günceller. React 18'in automatic batching özelliği, asenkron fonksiyonlar içindeki state güncellemelerini de batch'ler ve bu sayede event handler dışındaki güncellemelerde bile gereksiz layout shift'ler önlenir.

CSS transform ve opacity ile Shift-Free Animasyonlar

Layout shift yalnızca elemanın geometrik özelliklerinin (width, height, top, left, margin, padding) değişmesiyle tetiklenir. CSS transform ve opacity özellikleri, layout hesaplamasını atlar ve yalnızca composite aşamasında çalışır. Dolayısıyla bu özelliklerle yapılan animasyonlar ve geçişler CLS üretmez.

    
/* CLS üreten yaklaşım */
.notification {
  margin-top: 0;
  transition: margin-top 0.3s;
}
.notification.visible {
  margin-top: 60px; /* Layout shift tetikler */
}

/* CLS üretmeyen yaklaşım */
.notification {
  transform: translateY(-100%);
  transition: transform 0.3s;
}
.notification.visible {
  transform: translateY(0); /* Shift-free */
}
    

Bu ilke, tüm UI animasyonlarına uygulanmalıdır. Elemanları konumlandırmak için top/left yerine transform: translate(), boyutlandırmak için width/height yerine transform: scale(), görünürlük için display yerine opacity kullanmak, animasyon kaynaklı CLS'i tamamen ortadan kaldırır.

Chrome DevTools ile CLS Kaynağının Tespiti

Chrome DevTools, CLS kaynaklarını tespit etmek için birden fazla araç sunar. Performance sekmesinde kayıt alın ve "Experience" lane'inde layout shift olaylarını inceleyin. Her shift olayına tıkladığınızda, kayan elemanın DOM konumu, kayma mesafesi ve shift skoru gösterilir. Bu bilgi, hangi elemanın CLS'e katkıda bulunduğunu doğrudan ortaya koyar.

Daha hızlı bir yöntem için Console sekmesinde Layout Shift'leri gerçek zamanlı izleyebilirsiniz:

    
new PerformanceObserver(list => {
  for (const entry of list.getEntries()) {
    if (!entry.hadRecentInput) {
      console.log('CLS:', entry.value.toFixed(4));
      for (const source of entry.sources) {
        console.log('Element:', source.node);
        console.log('Previous:', source.previousRect);
        console.log('Current:', source.currentRect);
      }
    }
  }
}).observe({ type: 'layout-shift', buffered: true });
    

Bu script, her layout shift'in kaynağını, önceki ve yeni konumunu ve CLS skorunu konsola yazdırır. hadRecentInput: false filtresi, yalnızca beklenmeyen shift'leri gösterir. Bu veriyle doğrudan sorunlu elemana müdahale edilebilir.

Web Vitals Attribution ile CLS Kaynağının RUM Bazlı Takibi

Lab ortamında tespit edilemeyen CLS sorunları, gerçek kullanıcı verilerinde (field data) ortaya çıkabilir. LinkedIn üzerindeki performans mühendisliği topluluklarında tartışılan vaka analizleri gösteriyor ki, lab ve field CLS verileri arasında ortalama %30-50 fark oluşuyor. Bu fark, gerçek kullanıcıların farklı cihaz boyutları, ağ koşulları ve etkileşim kalıplarından kaynaklanır.

Web Vitals kütüphanesinin attribution build'i ile CLS kaynağını gerçek kullanıcı verilerinden izlemek mümkündür:

    
import { onCLS } from 'web-vitals/attribution';

onCLS(metric => {
  const data = {
    value: metric.value,
    largestShiftTarget: metric.attribution.largestShiftTarget,
    largestShiftTime: metric.attribution.largestShiftTime,
    largestShiftValue: metric.attribution.largestShiftValue,
    loadState: metric.attribution.loadState
  };
  navigator.sendBeacon('/analytics', JSON.stringify(data));
});
    

loadState alanı, shift'in sayfa yükleme sırasında mı yoksa yükleme sonrasında mı gerçekleştiğini gösterir. Bu ayrım, sorunun yükleme optimizasyonuyla mı yoksa runtime davranışıyla mı çözüleceğini belirler.

Sayfa Yükleme Sonrası (Post-Load) CLS Sorunları

Çoğu uzman aksini iddia etse de, CLS sorunlarının önemli bir kısmı sayfa yüklendikten sonra (post-load) gerçekleşir. Geç yüklenen reklamlar, cookie consent banner'ları, push notification izin diyalogları, geç render edilen üçüncü parti widget'lar ve infinite scroll tetiklemeleri, sayfa yüklendikten dakikalar sonra bile CLS üretebilir.

Post-load CLS'i önlemek için tüm dinamik eklenen elemanları position: fixed veya position: absolute ile konumlandırın. Geç yüklenen reklamlar için sabit boyutlu container'lar kullanın. Push notification diyaloğunu sayfanın üstüne overlay olarak gösterin, DOM akışına dahil etmeyin. Canlı sohbet widget'larını sabit konumda tutun. Bu yaklaşımların ortak ilkesi, dinamik elemanların mevcut içeriğin konumunu hiçbir zaman değiştirmemesidir.

CLS Optimizasyonu İçin Teknik Kontrol Listesi

CLS'i 0.1 altında tutmak için her teknik denetimde uygulanması gereken kontrol noktaları şunlardır:

• Tüm görsellere width ve height attribute'ü ekleyin: Tarayıcının alan rezervasyonu yapmasını sağlayarak görsel kaynaklı shift'leri ortadan kaldırın.
• Reklam alanlarını min-height ile rezerve edin: Her reklam slotu için sabit boyutlu container tanımlayarak reklam yüklenmesinde oluşan kaymaları engelleyin.
• Web fontlarında font-display: swap ve metrik override kullanın: Font swap sırasındaki metin boyutu değişimini minimize ederek font kaynaklı shift'leri kontrol altına alın.
• Dinamik içerikleri akış dışı konumlandırın: Cookie banner, bildirim çubuğu ve popup gibi elemanları position: fixed ile yerleştirerek DOM akışını etkilemesini önleyin.
• iframe ve embed'lere aspect-ratio tanımlayın: Video, harita ve sosyal medya embed'leri için sabit oran container'ları oluşturarak yükleme anındaki kaymaları engelleyin.
• Animasyonlarda transform ve opacity kullanın: Layout tetikleyen CSS özelliklerinden kaçınarak animasyon kaynaklı shift'leri sıfırlayın.

CI/CD Pipeline'ında CLS Bütçesi ve Regresyon Önleme

Teoride doğru görünen ama pratikte patlayan nokta şudur: CLS optimizasyonu bir kez yapılıp bırakıldığında, sonraki deployment'larda eklenen yeni bileşenler, güncellenen reklam kodları ve değiştirilen layout yapıları CLS'i sessizce bozabilir. Bir geliştirici boyut bilgisi olmayan bir görsel eklediğinde veya tasarımcı animasyonlu bir bildirim çubuğu tasarladığında, CLS skoru bir gecede 0.1'in üzerine çıkabilir.

Bu riski yönetmek için Lighthouse CI ile CLS bütçesi tanımlayın ve her deployment öncesinde otomatik kontrol uygulayın. lighthouserc.js dosyasında assertions bloğuna cumulative-layout-shift eşiğini 0.1 olarak ekleyin. Bu kapı, eşiği aşan build'leri başarısız kılar ve regresyonun üretime ulaşmasını engeller. Gerçek kullanıcı verilerini Web Vitals attribution ile izleyerek field CLS'i takip edin. Bu iki katmanlı kontrol, CLS performansının uzun vadede 0.1 altında kalmasını sağlayan tek sürdürülebilir mekanizmadır.