CLS Sorunlarını Tespit Etme ve Kalıcı Azaltma

Butonun tam üstüne gelirken sayfanın zıpladığını gördüğünüz an, kullanıcı deneyimi bozulmuş olur. İşte CLS sorunları tam burada görünür hale gelir; küçük bir kayma gibi durur, ama tıklamaları, dönüşümü ve güveni etkiler.

İyi haber şu, CLS çoğu zaman rastgele oluşmaz. Kaynağı bulunur, ölçülür ve şablon düzeyinde düzeltildiğinde kalıcı olarak düşer. Aşağıdaki adımlar, teşhisten çözümün doğrulanmasına kadar pratik bir yol sunar.

CLS puanı neden bozulur?

CLS, “Cumulative Layout Shift” metriğidir. Sayfa yüklenirken ya da kullanıcı etkileşimi dışında bir anda eklenen öğeler yüzünden, ekrandaki blokların ne kadar kaydığını ölçer. Genel kabul, 0.1 ve altının iyi olduğudur. 0.1 ile 0.25 arası geliştirme ister, 0.25 üzeri ise belirgin sorundur.

Sorun yalnızca “sayfa biraz oynadı” düzeyinde kalmaz. Ürün kartı aşağı inebilir, form alanı yer değiştirebilir, reklam alanı aniden açılabilir. Sonuçta kullanıcı yanlış yere tıklar, okumayı bırakır ya da güven kaybeder.

CLS’nin sinsi tarafı şudur: Her zaman ilk yükleme anında olmaz. Bazen cookie bar, bazen font değişimi, bazen de sonradan yüklenen öneri modülü kaymaya yol açar. Bu yüzden yalnızca anasayfaya bakıp karar vermek yetmez.

Ayrıca saha verisi ile lab verisi aynı şeyi söylemeyebilir. Gerçek kullanıcıların yaşadığı kayma, test aracında görünmeyebilir. Bu yüzden önce gerçek kullanıcı verisini, sonra teknik teşhisi izlemek gerekir.

Saha verisi önceliği belirler, lab verisi ise nedenini buldurur.

CLS sorunlarını tespit etmek için doğru akış

Birçok ekip, PageSpeed puanına bakıp doğrudan kod düzenlemeye geçiyor. Oysa doğru sıra daha verimli çalışır ve yanlış optimizasyon riskini düşürür.

İzlenebilecek en temiz akış şudur:

1. Önce Search Console Core Web Vitals raporunda sorunlu URL gruplarını bulun.
2. Sonra PageSpeed Insights’ta saha verisi ile lab verisini birlikte okuyun.
3. Ardından Chrome DevTools Performance kaydında “Layout Shifts” izini açın.
4. Son olarak kaymanın hangi şablonda tekrar ettiğini doğrulayın.

Search Console tarafı size tekil URL değil, benzer sayfa grupları verir. Bu çok değerlidir. Çünkü sorun çoğu zaman tek sayfada değil, kategori şablonunda, ürün detayında ya da blog kart yapısında çıkar.

PageSpeed Insights’ta iki bölüm önemlidir. Üstteki saha verisi, gerçek kullanıcı oturumlarından gelir. Alttaki Lighthouse çıktısı ise kontrollü testtir. İkisini aynı kefeye koymayın. PageSpeed’i teşhis ekranı gibi okumak için PageSpeed Insights verilerini doğru yorumlama yaklaşımı işinizi ciddi biçimde hızlandırır.

DevTools tarafında ise Performance kaydı alın, ardından “Layout Shifts” satırını açın. Kayma elmaslarına tıkladığınızda hangi öğenin ne zaman hareket ettiğini görebilirsiniz. İlk yükleme sırasında mı oluyor, kullanıcı aşağı kaydırınca mı oluyor, bunu burada anlarsınız.

Bir de mobil görünümü atlamayın. Masaüstünde sabit duran bloklar, mobilde satır kırıldığı için kayabilir. CLS sorunları çoğu zaman dar ekranlarda daha sert hissedilir.

Araç çıktısını nasıl yorumlamalısınız?

PageSpeed Insights’ta “Avoid large layout shifts” uyarısını gördüğünüzde listedeki öğeleri doğrudan suçlu sanmayın. Orada görünen öğe bazen hareket eden bloktur, bazen de onu aşağı iten gerçek kaynaktır. Yani listeyi “etkilenen elemanlar” olarak okuyun, “kesin nedenler” olarak değil.

Yorumlarken üç soruya odaklanın:

• Kayma ilk yüklemede mi oluyor?
• Kullanıcı etkileşimi olmadan mı tetikleniyor?
• Aynı desen başka şablonlarda da var mı?

Örneğin ürün detay sayfasında yorum bileşeni sonradan açılıyor ve içerik aşağı itiliyorsa, sorun yalnızca o bileşende değildir. Aynı bileşen tüm ürün sayfalarında varsa, çözüm de bileşen düzeyinde olmalıdır.

DevTools’ta zaman çizelgesindeki kayma kümeleri de önemlidir. Tek büyük kayma mı var, yoksa birkaç küçük kayma üst üste mi birikiyor? Birikimli puan yükseliyorsa, sayfada farklı kaynaklar zincirleme etki üretiyor olabilir.

Saha verisinde beklenmedik bir sıçrama gördüyseniz, tarayıcı taraflı ölçüm değişikliklerini de kontrol edin. Nadir olur, ama olur. Bunun için Chrome UX Report sürüm notları faydalı bir referanstır.

Kısa yol arıyorsanız, tek URL’ye takılmayın. Aynı bileşenin geçtiği tüm sayfaları listeleyin. Şablon bazlı yaklaşım, tek tek yama yapmaktan çok daha hızlı sonuç verir.

Kalıcı CLS çözümleri: en sık dört kaynak

Aşağıdaki tablo, sık görülen durumlarda geçici yama ile kalıcı çözüm farkını hızlıca gösterir.

Sorun	Geçici workaround	Kalıcı çözüm
Görsel boyutu yok	Rastgele min-height vermek	Gerçek width ve height tanımlamak, gerekirse aspect-ratio eklemek
Reklam sonradan açılıyor	Reklamı kaldırmak	Sabit slot ayırmak ve boş durumda da alanı korumak
Font değişince metin zıplıyor	Sadece font-display: swap kullanmak	Fallback metriğini ana fontla eşlemek, size-adjust kullanmak
Üstten banner ekleniyor	overflow: hidden ile gizlemek	Banner için önceden yer ayırmak ya da overlay modeline geçmek

Şimdi bu başlıkları kodla birlikte netleştirelim.

Görseller, video ve embed alanları

En klasik CLS nedeni, boyutu tanımsız görsellerdir. Tarayıcı öğenin yüksekliğini bilmediğinde, önce metni çizer, sonra görsel gelince sayfayı iter.

En doğru çözüm, HTML içinde gerçek boyutları yazmaktır:

<img
  src="/img/urun-detay.jpg"
  alt="Ürün görseli"
  width="1200"
  height="675"
  loading="lazy">

Responsive tasarım kullanıyor olsanız bile bu değerleri yazın. Tarayıcı oranı erkenden hesaplar. CSS ile genişliği esnek bırakabilirsiniz:

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

Iframe, video ve harita gömülerinde de aynı mantık geçerlidir. Eğer gerçek boyut sabitse kapsayıcıya oran verin:

.embed {
  aspect-ratio: 16 / 9;
  width: 100%;
}
.embed iframe {
  width: 100%;
  height: 100%;
}

Bu adım çoğu projede hızlı kazanç sağlar. Benzer önerileri Core Web Vitals denetim listesi içinde de görebilirsiniz.

Reklam slotları, cookie bar ve dinamik modüller

Reklam alanları, bülten kutuları ve promosyon barları CLS’yi sık bozar. Çünkü boş gelen alan, içerik yüklendikten sonra bir anda açılır ve tüm blokları aşağı iter.

Geçici yama, tüm reklamları kapatmaktır. Kalıcı çözüm ise her slot için sabit yer ayırmaktır:

.ad-slot {
  min-height: 280px;
  width: 100%;
  background: #f3f3f3;
}

Boş durumda bile bu alan korunmalı. Reklam gelmezse slot çökmemeli. Üst tarafta sonradan eklenen cookie bar için de aynı ilke geçerli. İçeriği aşağı itmek yerine, ya yükleme anında yer ayırın ya da position: fixed ile overlay modeli kullanın.

Dinamik blok eklerken DOM’a sonradan düzensiz içerik itmeyin. Önce yer açın, sonra içeriği doldurun:

const slot = document.querySelector('.promo-slot');
slot.style.minHeight = '120px';
fetch('/promo-fragment')
  .then(r => r.text())
  .then(html => { slot.innerHTML = html; });

Buradaki kalıcı mantık basit: Sonradan yüklenecek her bileşenin boyut sözleşmesi olmalı. Tasarım ekibi, reklam ekibi ve geliştirici aynı yüksekliği bilmeli.

Web fontları ve metin kayması

Sayfa önce sistem fontuyla açılır, sonra özel font gelir. Harflerin genişliği değişirse satır kırılır ve metin bloğu kayar. Bu da beklenenden yüksek CLS üretir.

font-display: swap faydalıdır, ama tek başına yeterli değildir.

Kalıcı çözüm, fallback fontun metriklerini ana fonta yaklaştırmaktır. Modern tarayıcılarda size-adjust işe yarar:

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


body {
  font-family: "Inter", "Inter Fallback", sans-serif;
}

Ayrıca kritik fontları preload etmek de ilk boyamayı dengeler. Yine de asıl konu hız değil, metrik uyumudur. Font değişiminden doğan kayma için geliştiricilerin paylaştığı yazı tipi değişimindeki CLS tartışması iyi bir pratik referanstır.

Animasyonlar ve sonradan açılan arayüz parçaları

Accordion, sticky header, arama çubuğu, filtre paneli ve mobil menü de kaymaya yol açabilir. Burada hata çoğu zaman top, left, height gibi yerleşimi etkileyen özellikleri animasyonla değiştirmektir.

Yerleşimi oynatmak yerine transform ve opacity kullanın:

.banner {
  transform: translateY(-100%);
  opacity: 0;
  transition: transform .25s ease, opacity .25s ease;
}
.banner.is-open {
  transform: translateY(0);
  opacity: 1;
}

Eğer üstte sabit başlık açılacaksa, sayfanın başlangıç yüksekliği buna göre planlanmalıdır. Sonradan büyüyen header, tüm içeriği aşağı itmemeli. Şablon bazında yayılmış sorunlarda Core Web Vitals odaklı hız optimizasyonu yaklaşımı daha düzenli sonuç verir.

Geçici workaround ile kalıcı çözüm arasındaki fark

CLS tarafında en sık hata, sorunu görünmez yapıp çözülmüş sanmaktır. Büyük bir min-height vermek, ekranın üstünü boş bırakabilir. overflow: hidden eklemek, kaymayı saklayabilir. Reklamı bir süre kapatmak da skoru geçici olarak düşürebilir.

Bunlar bazen yangını söndürür, ama nedeni kaldırmaz. Kalıcı çözüm, bileşenin ne kadar yer kaplayacağını daha render başlamadan belli etmektir. Yani çözüm, “hareketi gizlemek” değil, “hareket ihtiyacını ortadan kaldırmak” olmalıdır.

Bunu bir bileşen sözleşmesi gibi düşünün. Görselin oranı bellidir, reklam slotunun yüksekliği bellidir, açılır panelin davranışı bellidir. Kod, tasarım ve içerik tarafı aynı boyut kurallarıyla çalışıyorsa CLS kalıcı biçimde düşer.

Bir de şu ayrımı unutmayın: İlk yükleme CLS’si ile etkileşim sonrası kaymalar aynı kökten gelmeyebilir. Bu yüzden deploy öncesi ve sonrası manuel akış testi yapmak gerekir. Sadece Lighthouse skoru yeşile döndü diye iş bitmiş sayılmaz.

Kısa CLS azaltma checklist’i

Aşağıdaki liste, yayın öncesi hızlı kontrol için yeterlidir:

• Tüm görsellerde width ve height var mı?
• Video, iframe ve embed alanlarında aspect-ratio tanımlı mı?
• Reklam ve promosyon blokları boş durumda da yer koruyor mu?
• Cookie bar ve üst banner içerikleri aşağı itiyor mu?
• Web fontlarında fallback metrikleri ayarlandı mı?
• Animasyonlarda transform kullanılıyor mu?
• Mobil görünümde satır kırılması yeni kayma üretiyor mu?
• Aynı sorun şablonun tüm varyasyonlarında test edildi mi?

Bu kontrol, tekil sayfa yerine bileşen bazında yapılınca daha güvenilir sonuç verir.

Sık yapılan hatalar

En yaygın hata, sadece anasayfayı test etmektir. Oysa kategori, ürün, blog ve kampanya şablonları farklı davranır.

Bir diğer hata, saha verisini beklemeden panikle onlarca küçük yama geçmektir. Önce hangi URL grubunun bozulduğunu bulun. Sonra aynı bileşeni tek seferde düzeltin.

Font tarafında sadece font-display: swap eklemek de sık görülen bir yanlış. Bu ayar görünmez metni azaltır, ama metrik farkı sürüyorsa kayma devam eder.

Reklam ekipleriyle boyut sözleşmesi kurmamak da pahalıya patlar. “Bu alan bazen 90 px, bazen 320 px” yaklaşımı, CLS’yi rastgele hale getirir.

Son hata ise başarıyı yalnızca tek araçla ölçmektir. Search Console, PageSpeed ve DevTools birlikte okunmalı. Ancak o zaman kalıcı iyileşme ile test şansı birbirinden ayrılır.

Sonuç

CLS’yi düşürmenin yolu, puanı kovalamak değil, yerleşimi öngörülebilir hale getirmektir. Sayfadaki her geç yüklenen bileşen, yüklenmeden önce ne kadar alan kaplayacağını söylemelidir.

Gerçek ilerleme, tek URL düzeltmekle değil, şablon ve bileşen düzeyinde standart kurmakla gelir. CLS sorunları bu bakışla ele alındığında, skor da kullanıcı deneyimi de aynı anda düzelir.

This post may contain affiliate links. If you make a purchase through these links, I may earn a small commission at no extra cost to you.