Görsellerde CLS Sorunu Nasıl Önlenir?

Sayfa açılırken içerik bir anda aşağı kayıyor, kullanıcı tam bir bağlantıya tıklayacakken buton yer değiştiriyor ya da paragrafın ortasına yeni bir görsel alanı giriyorsa, orada yalnızca görsel yüklenme gecikmesi değil yerleşim istikrarı problemi vardır. CLS tam olarak bunu ölçer: sayfa yüklenirken beklenmedik görsel kaymalar ne kadar yaşanıyor? Görseller bu kaymaların en yaygın sebeplerinden biridir çünkü çoğu projede görsel dosyası sonradan gelir, ama onun kaplayacağı alan baştan rezerve edilmez.

Bu sorunun can sıkıcı tarafı görünür olmasıdır. Dosya boyutu biraz büyükse kullanıcı bunu her zaman bilinçli fark etmez. Ama üstteki başlık bir anda aşağı itilirse, hissedilen kalite doğrudan bozulur. Hele ilk ekranda hero görsel, kart resmi ya da yazı içi büyük medya kullanıyorsanız, küçük görünen markup hataları bile tüm sayfanın daha kırılgan hissettirmesine yol açar.

Üstelik CLS yalnızca “resim geç geldi” sorunu değildir. Görsel alanının en-boy oranını bilmemek, responsive yerleşimde yanlış sizes kurmak, lazy loading’i her görsele ezbere uygulamak, CSS arka plan görsellerini ölçüsüz kullanmak ya da CMS tarafından sonradan gelen medya boyutlarını baştan hesaba katmamak aynı sonuca çıkar. Sorunun kökü çoğu zaman performans değil, yer rezervasyonudur.

İyi çözüm, görseli daha hızlı indirmek kadar, sayfa açılırken nereye oturacağını baştan netleştirmektir. Hangi durumda gerçek kayma, hangisinde yalnızca geç yükleme olduğunu ayırt etmek; width ve height'ın ne zaman yeterli, ne zaman yetersiz kaldığını bilmek bu kararın başlangıç noktasıdır.

CLS tam olarak neyi ölçer?

CLS, Cumulative Layout Shift ifadesinin kısaltmasıdır. Türkçesiyle sayfa yüklenme sürecinde veya kullanıcı etkileşimi dışında oluşan beklenmedik yerleşim kaymalarının birikimli etkisini ölçer. Basit anlatımla, kullanıcı ekranda bir düzen beklerken bu düzen sonradan değişiyorsa CLS yükselir. Görsel bunun başlıca sebeplerindendir çünkü DOM içinde yeri vardır ama gerçek boyutu çoğu zaman dosya geldikten sonra netleşir.

Ölçüm mantığında kaba eşikler önemlidir. Yaklaşık 0.1 altı iyi kabul edilirken, 0.25 üstü belirgin sorun bölgesidir. Fakat yalnızca skora bakmak yeterli olmaz. Aynı skor iki farklı sitede farklı hissedilebilir. Üst bölümde tek büyük kayma varsa kullanıcı bunu çok net fark eder; alt kısımda küçük hareketler varsa rapor benzer görünse de deneyim başka olabilir. Bu yüzden CLS raporu yorumlanırken bileşenin gerçekten nerede kaydığı mutlaka görülmelidir.

Görseller özelinde kritik ayrım şudur: geç yüklenme ile yerleşim kayması aynı şey değildir. Bir görsel geç gelebilir ama alanı baştan ayrılmışsa sayfa sabit kalır. Tersi durumda dosya hızlı inse bile, alan sonradan açılıyorsa CLS oluşur. Bu yüzden çözüm her zaman “görseli küçültelim” diye başlamaz. Bazen dosya boyutu ikinci plandadır; asıl düzeltme, sayfa iskeletine görselin oran bilgisini önceden yerleştirmektir.

Görseller neden yerleşim kaymasına yol açar?

En klasik sebep, görsel etiketi içinde boyut bilgisinin olmamasıdır. Tarayıcı yalnızca src görür, ama dosya gelmeden bu elemanın sayfada ne kadar alan kaplayacağını kesin olarak bilemez. Sonuçta çevresindeki metin yukarı yerleşir, görsel yüklenince alan açılır ve her şey aşağı itilir. Bu davranış özellikle blog içi görsellerde ve kart listelerinde sık görülür.

İkinci yaygın sebep, responsive yerleşimde oranın korunmamasıdır. Örneğin CMS tarafında farklı oranlarda yüklenmiş görseller aynı kart bileşeninde kullanılıyorsa, her kartın yüksekliği dosyaya göre değişebilir. Görsel yüklenmeden önce kaba bir yer tutucu kullanılsa bile gerçek oran sonradan değişirse kayma kaçınılmaz hale gelir. Burada sorun yalnızca HTML özniteliği eksikliği değil, içerik giriş disiplinidir.

Üçüncü sebep, CSS ile sonradan yüksekliği belirlenen alanlardır. Görsel kapsayıcısı başlangıçta boş olabilir, sonra JavaScript ya da geç gelen sınıf yüzünden yüksekliği açılabilir. Özellikle slider, galeri ve sonsuz akış bileşenlerinde bu tür davranışlar çok görülür. Geliştirici çoğu zaman suçu dosya yüklenme hızına atar; ama asıl problem, bileşenin baştan stabil yükseklik taşımamasıdır.

Dördüncü sebep de yanlış lazy loading kullanımıdır. İlk ekrandaki büyük görseli bile loading="lazy" ile işaretlemek, görsel alanının geç oluşmasına ya da placeholder zincirinin geç kurulmasına yol açabilir. Bu durum dosyanın inmesini geciktirirken, çoğu zaman kaymanın görünürlüğünü de artırır. İlk ekran öğeleri için performans kuralı ile yerleşim kuralı aynı anda düşünülmelidir.

İlk savunma hattı: `width` ve `height`

Görsellerde CLS önlemenin en temel ve en etkili yolu, görsel etiketine gerçek width ve height değerlerini vermektir. Bu, tarayıcıya dosya gelmeden en-boy oranını hesaplama imkanı sağlar. Eleman sonradan akışa girmez; baştan yer tutar. Modern tarayıcılar bu iki özniteliği sadece sabit piksel olarak okumaz, oran bilgisini çıkarıp akışkan yerleşimde de kullanır.

Bu yüzden görsel responsive gösterilecekse bile boyut özniteliklerinden vazgeçmek doğru değildir. Aşağıdaki gibi bir kurgu çoğu içerik görseli için güvenli başlangıçtır:

<img
  src="/img/ornek-1280.webp"
  width="1280"
  height="820"
  alt="Örnek görsel"
  style="max-width: 100%; height: auto;">

Buradaki değerler, dosyanın orijinal piksel ölçüsünü temsil eder. Sayfada 640 piksel genişlikte de gösterilse, tarayıcı oranı bilir ve yüksekliği baştan ayırır. Bu küçük ayrıntı, CLS tarafında çoğu zaman büyük fark yaratır. srcset kurulumunda da aynı mantık devam eder; hangi kaynağın seçildiğinden bağımsız olarak yerleşim oranı sabit tutulur.

Fakat burada bir incelik var. Eğer CMS yanlış oran üretiyor ya da aynı bileşen içinde farklı oranlı görseller zorla kullanılıyorsa, yalnızca öznitelik eklemek yetmeyebilir. Tarayıcı oranı doğru rezerv eder ama tasarım sisteminiz farklı oranları aynı kutuya sığdırmaya çalışıyorsa kayma kadar kırpım ve hizalama sorunu da görürsünüz. Yani bu adım zorunludur, ama her senaryoda tek başına yeterli değildir.

Kırılımlar değişirken kutu yüksekliği nasıl sabit tutulur?

Responsive yerleşim, CLS riskini azaltmak kadar artırabilir de. Çünkü masaüstünde geniş görünen bir görsel mobilde dar bir kolona iner, kart yüksekliği değişir, farklı kırılımlarda farklı kaynaklar seçilir. Eğer bu akışta oran bilgisini tutarlı yönetmezseniz, her viewport geçişi potansiyel kayma alanı olur. Burada picture kullanımı ve srcset planı kadar, kapsayıcı elemanın CSS davranışı da önemlidir.

Özellikle kart yapılarında aynı satırdaki görsellerin farklı oranlarda gelmesi tasarımı oynatır. Bu noktada iki yaklaşım vardır: ya içerik girişinde tek bir oran standardı zorunlu tutulur, ya da kapsayıcıya sabit oran verilip görsel object-fit: cover ile yerleştirilir. Hangisinin doğru olduğu sayfanın amacına bağlıdır. Blog kartında tutarlı yükseklik çoğu zaman daha önemlidir; ürün detay görselinde ise gerçek oranı korumak gerekebilir.

Örnek olarak şu yapı kart görseli için daha stabil sonuç verir:

.cardMedia {
  aspect-ratio: 16 / 10;
  overflow: hidden;
}

.cardMedia img {
  width: 100%;
  height: 100%;
  object-fit: cover;
}

Burada kapsayıcı alanı baştan ayrılır. Dosya geç gelse bile kart yüksekliği sonradan açılmaz. Bu teknik, özellikle ana sayfa listelemelerinde kullanışlıdır. Ama yine bir trade-off vardır: Eğer içeriğin tamamını göstermek önemliyse cover kırpım yaratabilir. Bu yüzden her stabil çözüm her tasarım amacı için doğru değildir.

Hangi yanlış uygulamalar CLS'yi büyütür?

Birinci yanlış uygulama, ilk ekrandaki görselleri de geç yüklenen, boyutu sonradan netleşen medya gibi ele almaktır. Özellikle hero alanında ya da yazı kapağında bu yaklaşım hissedilen kaliteyi bozar. İlk ekranda duran büyük medya için hem yer ayrılmalı hem de gereksiz tembellik uygulanmamalıdır. Kaynak ailesi değişiyorsa picture, yalnızca boyut değişiyorsa uygun srcset kurgusu yeterlidir; ama her durumda yer baştan ayrılmalıdır.

İkinci yanlış uygulama, CSS arka plan görsellerini içerik medyası yerine kullanmaktır. Arka plan görselleri, özellikle içerik anlamı taşıyan büyük alanlarda, HTML tarafında boyut ve öncelik kontrolünü zorlaştırır. Hero tasarımında bu bazen kaçınılmaz olabilir; fakat geliştirici bu tercihin CLS ve LCP üzerindeki etkisini ayrıca düşünmelidir. Görselin kendisi içerik öğesiyse çoğu zaman img daha doğru seçimdir.

Üçüncü yanlış uygulama, kullanıcı yüklemeli sistemlerde her görseli serbest oranla kabul etmektir. Editör farklı boyutlarda kapak yükler, tema yine de bunları aynı modüle yerleştirir. Sonra kartlar satır satır kayar, görsel gelince metin aşağı itilir ve sorun “performans” diye etiketlenir. Oysa asıl ihtiyaç çoğu zaman girişte oran standardı koymaktır.

Riskli davranışlar

Boyut özniteliği olmadan görsel basmak
İlk ekran görseline ezbere lazy loading vermek
Farklı oranlı görselleri aynı kart yapısına kontrolsüz sokmak
Yer tutucu alanı sonradan JavaScript ile açmak

Daha güvenli davranışlar

Gerçek oranı baştan belirtmek
Kritik alanlarda kapsayıcı yüksekliği önceden tanımlamak
CMS içinde oran standardı koymak
Responsive bileşenleri ara kırılımlarda da test etmek

Dördüncü yanlış uygulama, placeholder kullanınca sorunun çözüldüğünü sanmaktır. Evet, skeleton veya düşük kaliteli önizleme bazen algıyı iyileştirir. Ama placeholder gerçek alanı tutmuyorsa, sadece kaymayı estetik bir katmanla gizlemiş olursunuz. CLS düşmeyebilir. Göz boyayan çözüm ile yerleşim çözümü aynı şey değildir.

Tema ve medya akışı bu sorunu nasıl büyütür?

WordPress, medya yüklerken farklı boyutlar üretir ve birçok tema bu boyutları otomatik çağırır. Bu rahatlık sağlar, ama bazen görünmez risk de üretir. Tema kart alanını 16:10 oranında tasarlamış olabilir; editör ise farklı oranlarda kapak yükler. Eğer tema kapsayıcıyı baştan sabitlemiyorsa, görsel gelene kadar alan dengesiz kalır. Bu yüzden WordPress görsel akışında yalnızca dosya sıkıştırmaya değil, oran yönetimine de bakmak gerekir.

Özellikle öne çıkan görsel, blok editör içi medya ve galeri bileşenleri ayrı ayrı incelenmelidir. Çünkü aynı CMS içinde farklı bileşenler farklı davranabilir. Yazı gövdesinde görüntü stabil kalırken, arşiv kartları kayma üretiyor olabilir. Sorunun kaynağı çoğu zaman “WordPress yavaş” gibi genellenir; halbuki temadaki tek bir medya kutusu bu etkiyi büyütüyor olabilir.

CDN kullanan yapılarda da benzer bir durum vardır. Görsel dosyası kenarda yeniden boyutlandırılır, ama HTML kapsayıcısı hâlâ belirsiz kalırsa CLS devam eder. Yani dosya hizmet katmanı ile yerleşim katmanı birlikte ele alınmalıdır. Sadece daha küçük dosya göndermek, sonradan açılan kutuyu kendi başına düzeltmez.

Kaymanın kaynağını doğru ayırmak

CLS sorununu gerçekten çözmek için rapor ekranından öteye geçmek gerekir. İlk bakılacak yer tarayıcı geliştirici araçlarındaki performans kaydıdır. Burada layout shift izleri hangi anda oluşuyor, hangi eleman sorumlu görünüyor, görsel alanı ne zaman açılıyor; bunları görmek mümkündür. Sadece skor düşmüş mü diye bakmak yetmez. Aynı bileşen başka sayfada hâlâ kayıyor olabilir.

İkinci kontrol, gerçek kullanım akışında yapılmalıdır. Mobil bağlantı simülasyonu, yüksek piksel yoğunluklu cihazlar, dar pencere genişlikleri ve kart listeleri özellikle önemlidir. Masaüstünde her şey stabil görünürken tablet benzeri ara genişlikte satır kırılması ve medya yüksekliği beklenmedik kayma üretebilir. Bu yüzden yalnızca tek bir ekran boyunda test yapmak, CLS gibi yerleşim problemlerinde çoğu zaman eksik sonuç verir.

Üçüncü kontrol gözle yapılır. Kullanıcı ölçüm aracına bakmaz; ekranda oynama var mı ona bakar. Bu yüzden test ederken tıklanabilir öğelerin, başlıkların ve ilk paragrafın kayıp kaymadığına özellikle dikkat etmek gerekir. Bazen skor teknik olarak makul seviyededir ama ilk ekrandaki tek bir büyük kayma, hissedilen kaliteyi yine de bozar. CLS ölçümü ile deneyim gözlemi birlikte yürümelidir.

Son olarak çözümün gerçekten görsel kaynaklı olduğundan emin olunmalıdır. Reklam slotları, sonradan açılan çerez bantları ya da web font değişimleri de benzer semptom üretir. Fakat görseller çoğu projede ilk şüphelidir. Bu yüzden önce onları stabilize etmek iyi başlangıç sağlar. Çoğu zaman yalnızca birkaç medya bileşenini düzeltmek, sayfanın hissedilen kararlılığını şaşırtıcı derecede iyileştirir.

En kırılgan medya alanları hangileri?

Bütün görseller eşit risk taşımaz. CLS açısından en tehlikeli alanlar, kullanıcının ilk karşılaştığı medya yüzeyleri ve tekrar eden liste bileşenleridir. Hero alanı bunların başında gelir. Çünkü sayfanın üst kısmında yer aldığı için, oradaki tek bir kayma bütün metni aşağı iter. Kullanıcı daha okumaya başlamadan sayfa güvensiz görünür. Bu yüzden hero görsellerde hem oran rezervasyonu hem de yükleme önceliği birlikte düşünülmelidir.

İkinci riskli alan kart listeleridir. Ana sayfa, kategori listesi ve önerilen yazılar gibi modüllerde çok sayıda görsel birlikte yer alır. Bir kartın yüksekliği sonradan değişirse, genelde sadece o kart değil tüm satır oynar. Bu yüzden liste bileşenlerinde tek tek görselden çok, bütün modülün ızgara davranışı test edilmelidir. Kapsayıcı oranını sabit tutmak burada çoğu zaman en temiz çözümdür.

Üçüncü alan kullanıcı yüklemeli veya editör kontrollü içeriklerdir. Yazar farklı görsel oranları kullanır, sonra tema hepsini aynı genişlikte göstermeye çalışır. Bu akışta sorun tek bir dosyada değil, tüm içerik üretim alışkanlığında ortaya çıkar. Teknik çözüm markup tarafında başlar; ama editoryal disiplinle desteklenmezse sorun zamanla yeniden büyür. CLS'yi kalıcı biçimde düşüren ekipler genelde yalnızca kodu değil, içerik giriş kurallarını da düzenler.

Küçük kaymanın kabul edilebilir olduğu sınırlar

Her piksel hareketini sıfırlamak pratikte mümkün olmayabilir. Özellikle kullanıcı etkileşimiyle açılan galeriler, isteğe bağlı medya genişletmeleri veya isteğe bağlı yorum görselleri farklı değerlendirilir. Eğer değişim kullanıcı eylemiyle tetikleniyorsa ve bağlamı açıksa, bu her zaman klasik CLS problemi gibi ele alınmaz. Burada önemli olan beklenmedik kaymayı azaltmaktır.

Ama bu esneklik yanlış anlaşılmamalı. “Nasıl olsa çok az oynuyor” diyerek ilk ekran metnini aşağı iten hero alanlarını görmezden gelmek doğru değildir. Görsel bileşenler kullanıcının okumaya başladığı bölümde yer alıyorsa, küçük görünen kayma bile güven hissini bozar. Özellikle blog, içerik ve dokümantasyon sitelerinde bu etki daha nettir; çünkü kullanıcı sabit, okunabilir bir akış bekler.

Kural kabaca şöyle kurulabilir: kullanıcı bir şey yapmadan önce yerleşim sabit olmalı. Görsel sonrası alan açılıyorsa, çözüm hâlâ eksiktir. Bu yüzden CLS önleme işini yalnızca performans optimizasyonu değil, arayüz güvenilirliği işi olarak görmek daha doğru olur. En iyi sonuç genelde bu bakışla gelir.