Sayfadaki 1920 piksel genişliğindeki bir görsel, telefon kullanıcısına da eksiksiz indirilir ve ekranda 390 piksele küçültülür — beş kat bant genişliği ve boşuna yavaş bir yükleme. srcset, tarayıcının ekrana uyan sürümü seçmesini sağlar; yeter ki o sürümleri üretmiş olun.
Neden tek görsel yetmez
Core Web Vitals içindeki LCP değeri çoğunlukla sayfanın üst kısmındaki büyük görseldir. Telefona 1920 genişliğinde, 400KB'lık bir dosya verirseniz LCP nadiren 2,5 saniyeye sığar; aynı bağlantıda 480 genişliğinde, 40KB'lık sürüm bir kat daha hızlıdır. Google'ın sayfa deneyimi sinyali de bu sayıyı doğrudan okur.
Tersine, büyük bir masaüstü ekranda 768 genişliğinde bir görsel yumuşak ve bulanık durur. Bu yüzden birkaç boyut gerekir ve seçimi tarayıcı yapar.
Pratik bir kırılma noktası tablosu
Kırılma noktaları viewport genişliğini değil, görselin sayfada gösterildiği genişliği izler. İki yaygın durum için, tam genişlik bannerlar ve makale içi görseller:
- Tam genişlik görseller (hero, banner): 480, 768, 1200, 1920. Telefon, tablet, dizüstü, büyük ekran.
- Makale görselleri (içerik sütunu yaklaşık 800'e kadar): 400, 800, 1200; 1200 sürümü 1,5x–2x yoğunluktaki ekranlara hizmet eder.
- Küçük resimler ve kartlar (yaklaşık 300 gösterilir): 300 ve 600.
Daha çok basamak daha iyi değildir. Her basamak ek bir dışa aktarma ve saklanacak ek bir dosyadır; tarayıcılar da küçük uyumsuzlukları hoş görür. Bu yüzden 1,5–2 kat aralıklı basamaklar tatlı noktadır. Dört basamak, cihaz kombinasyonlarının onda dokuzundan fazlasını karşılar.
2x sürümler gerekli mi?
Retina ve çoğu telefon ekranı 2x–3x yoğunlukta çalışır; 400 genişliğinde gösterilen bir görselin orada net durması için 800 piksele ihtiyacı vardır. Tablodaki büyük basamaklar, küçüklerin 2x sürümü işini zaten görür — 768, 390 genişlikli telefon için 2x; 1200 ise 600 genişlikli sütun için 2x'tir.
Dolayısıyla ayrı bir "@2x" setine gerek yok. Basamaklar arasında yaklaşık 2 kat aralık bırakın; tarayıcı yoğunluğa göre yüksek olanı seçer.
Biçim: önce WebP, yedek olarak JPG
Aynı kalitede WebP, JPG'den yüzde 25–35 daha küçüktür ve tüm modern tarayıcılar destekler. Her boyutta WebP dışa aktarın, eski tarayıcılar için picture öğesiyle bir JPG yedeği tutun; 2020 öncesi tarayıcılar kitleniz için önemli değilse tek başına WebP yeterlidir.
AVIF daha da küçüktür ama tarayıcıda kodlanması çok daha yavaştır ve büyük toplu işlerde can sıkar. AVIF, WebP ve JPEG karşılaştırması bu dengeyi ayrıntılı ele alıyor.
Tüm seti toplu dışa aktarma
Kaynak görselleri Toplu Görsel İşleme aracına bırakın ve her basamak için bir kez çalıştırın; her seferinde genişliği ve son eki değiştirin:
- Boyut: genişlik 480, Büyütmeye izin ver kapalı, çıktı yüzde 80 kalitede WebP, son ek -480.
- Aynı ayarlar 768 için -768 son ekiyle; sonra 1200; sonra 1920.
- JPG yedeği için çıktıyı JPG yapın, son ekleri koruyun ve yeniden çalıştırın.
Her çalıştırma saniyeler sürer ve ZIP içinde hazır hero-480.webp, hero-768.webp gibi dosyalar bulunur; görsel klasörüne atmanız yeter. Büyütmeye izin ver seçeneğini kapalı tutun ki 1000 piksellik bir orijinal hiçbir zaman 1920'ye gerilmesin.
Tek bir görselde her basamağın boyut farkını görmek için Görsel Boyutlandırma aracını tek dosyada deneyin.
HTML'i yazmak
Tam genişlik bir görsel için:
<img src="hero-1200.jpg"
srcset="hero-480.webp 480w, hero-768.webp 768w, hero-1200.webp 1200w, hero-1920.webp 1920w"
sizes="100vw" width="1920" height="1080" alt="...">Makale görsellerinde sizes değerini gerçek genişliğe ayarlayın, örneğin sizes="(max-width: 840px) 100vw, 800px". width ve height değerlerini daima yazın; tarayıcı yeri ayırsın, sayfa zıplamasın.
Bunu yaptıktan sonra görseller nasıl daha hızlı yüklenir yazısındaki tembel yükleme ve sıkıştırma önerilerini de ekleyin; performans puanınızın görsel kısmı fiilen tavan yapar.