Mobilde ekran dışı görselleri erteleyin
Mobilde ekran dışı görselleri erteleyin

Mobilde Görsel Erteleme: standart
Mobil performans genellikle ağ gecikmesi (RTT) ve ana iş parçacığı CPU kullanılabilirliği tarafından kısıtlanır. Mobilde ekran dışı görsellerin ertelenmesi, kritik render yolundaki bant genişliği çekişmesini önleyerek ve görsel çözümleme maliyetlerini oturum süresine yayarak her iki sorunu da ele alır.
Bu belge, mobilde görsellerin nasıl etkili bir şekilde erteleneceğini, ne zaman kullanılacağını açıklar ve mobil görünüm alanlarının spesifik mekanik kısıtlamalarını ele alır.

1. Mobilde ekran dışı görselleri erteleyin: yerel tembel yükleme
Bir tarayıcı bir sayfayı yüklediğinde, sınırlı sayıda paralel bağlantı açar (birçok faktöre bağlıdır ancak alan adı başına 6 yaygın bir ortalamadır). Bu bağlantılar ekran dışı görsellerin indirilmesi için kullanılırsa (örneğin, bir alt bilgi logosu veya karusel slaydı), kritik kaynakların (genellikle LCP görseli, önemli betikler ve yazı tipleri) indirilmesi yuva ve bant genişliği için rekabet edecektir. Ağ Çekişmesi olarak bilinen bu olgu, Core Web Vitals değerlerini doğrudan olumsuz etkiler.
Yerel loading özniteliğini kullanarak ekran dışı görselleri erteleyerek, önemli kaynakları önceliklendirebilir ve Kritik Render Yolunu optimize edebiliriz. Tarayıcı yalnızca hemen görünür olanı getirir ve bant genişliğini First Contentful Paint (FCP) ile Largest Contentful Paint (LCP) değerlerini doğrudan etkileyen varlıklar için ayırır. Yerel tembel yükleme yöntemi, bu önceliklendirme mantığını tarayıcının çok daha hızlı dahili mekanizmasına devreder ve eski, yavaş JavaScript kütüphanelerine olan ihtiyacı ortadan kaldırır.
Uygulama
İlk görünüm alanının ("kıvrımın") altındaki tüm görseller için loading="lazy" özniteliğini ekleyin.
<!-- Standard Deferred Image -->
<img src="product-detail.jpg"
alt="Side view of the chassis"
width="800"
height="600"
decoding="async"> Tembel yükleme mobilde nasıl çalışır: Tarayıcı Sezgiseli
Yerel tembel yükleme, JavaScript çözümlerinden üstündür çünkü tarayıcı, yükleme eşiğini (bir görselin indirme için ne zaman tetikleneceğini) Etkin Bağlantı Türüne (ECT) göre ayarlar.
- 4G/WiFi'da: Blink motoru (Chrome/Edge) muhafazakâr bir eşik kullanır (örn. 1250px). Düşük gecikme varsayar ve görseli yalnızca kullanıcı görünüm alanına nispeten yakın olduğunda getirir.
- 3G/Yavaş-2G'de: Eşik genişler (örn. 2500px). Tarayıcı, yüksek gidiş-dönüş sürelerini telafi etmek için isteği kaydırma konumuna göre çok daha erken başlatır ve böylece görselin kullanıcı onu görünüm alanına kaydırmadan önce hazır olmasını sağlar.
Kritik İstisna: LCP Adayı
Geliştiriciler loading="lazy" özniteliğini Largest Contentful Paint (LCP) öğesine (genellikle ana görsel) uyguladığında yaygın bir performans gerilemesi meydana gelir. Bu, getirmeyi düzen tamamlanana kadar geciktirir.
Doğru LCP Stratejisi: LCP görseli istekli olarak yüklenmeli ve önceliklendirilmelidir.
<!-- Hero Image: Eager and Prioritized -->
<img src="hero.jpg"
alt="Summer Collection"
width="1200"
height="800"
> 2. Mobil karmaşıklıklar: Görünüm Alanı ve Dokunma
Mobil görünüm alanları, yerel uygulamanın betik tabanlı çözümlerden daha sağlam şekilde ele aldığı spesifik oluşturma zorlukları getirir.
- Görünüm Alanı: Tarayıcı penceresinin görünür dikdörtgen alanı. Mobilde bu dinamiktir; cihaz yönüne (dikey veya yatay) ve tarayıcı arayüzünün durumuna (URL çubuklarının geri çekilmesi) göre boyutları değişir.
- Kıvrım: Görünüm alanının tam alt kenarı. Görünür içeriği ekran dışı içerikten ayıran eşiktir.
- Kıvrımın Üstü: Sayfa yüklendiğinde kaydırma yapmadan hemen görünen içerik. Buradaki görseller genellikle kritiktir ve neredeyse hiçbir zaman tembel yüklenmemelidir.
- Kıvrımın Altı: Kıvrımın dikey olarak ötesinde bulunan içerik. Bu içerik Kritik Olmayan'dır ve kullanıcı yakınına kaydırana kadar ertelenmelidir.

Dinamik Görünüm Alanı
Mobil tarayıcılarda görünüm alanı yüksekliği (vh) akışkandır. Kullanıcı dokunmatik kaydırma başlattığında, URL çubuğu ve gezinme kontrolleri genellikle geri çekilir ve görünür alan boyutunu değiştirir.
JavaScript tabanlı görsel erteleme kütüphaneleri genellikle görünüm alanı yüksekliğini (window.innerHeight) yalnızca sayfa yüklemesinin başında bir kez hesaplar. Mobil tarayıcılar kaydırma sırasında URL çubuğunu gizleyerek görünür alanı dinamik olarak yeniden boyutlandırdığında, JavaScript yöntemleri eski, daha küçük yükseklik değerini kullanmaya devam eder. Bu, görsellerin fiziksel olarak genişletilmiş görünüm alanına girmelerine rağmen yüklenmemiş kalmasına neden olarak ziyaretçiler için kötü bir UX deneyimine yol açar.
Yerel İşleme bu sorunu çözer çünkü tarayıcının dahili düzen motoru görsel görünüm alanını otomatik olarak takip eder ve tetikleyicilerin görünüm alanı boyut değişikliklerinden bağımsız olarak çalışmasını sağlar.
3. Mobil Görsel Çözümleme ve CPU Kısıtlama
Mobil cihazların sınırlı CPU kapasitesi vardır ve mobilde görsel çözümleme nispeten yavaş ve maliyetli olabilir. Bir JPEG'i bit eşleme dönüştürmek birçok CPU döngüsü gerektirir. Bir mobil işlemcide, bir dizi büyük görseli çözümlemek ana iş parçacığını her biri için 50ms–100ms boyunca bloke edebilir ve giriş gecikmesine neden olabilir.
Çözüm: content-visibility
Bunu çözmek için CSS özelliği ve değerini content-visibility: auto kullanabiliriz. Bu özellik, "Tembel Oluşturma" için bir standart görevi görür. Tarayıcıya ekran dışı öğeler için düzen ve boyama aşamalarını tamamen atlaması talimatını verir. Öğe DOM'da var olur ancak görünüm alanına yaklaşana kadar Render Ağacında mevcut değildir.
Bu optimizasyon bir öğenin alt ağacının oluşturulmasını atlayarak çalıştığı için, doğrudan bir <img> etiketine (alt ağacı olmayan) uygulanamaz. conten-visibility özelliğini bu görselleri ve içeriğini barındıran ürün kapsayıcısına veya görsel kartına uygulamalısınız
@media (max-width: 768px) {
.image-card, .product-card {
/* Skip rendering of the container and its children */
content-visibility: auto;
/* Essential: Prevents container from collapsing to 0px height */
contain-intrinsic-size: auto 300px;
}
}
Bu, bir görsel indirilmiş olsa bile tarayıcının kullanıcı gerçekten ona kaydırana kadar düzen/boyama maliyetini ödemediğini garanti eder.
4. Eski Yöntemler: Neden kaçınmalısınız
Yerel destek öncesinde, geliştiriciler mobil görsel erteleme için JavaScript'e güveniyorlardı. Bu yöntemler hâlâ yaygın olarak kullanılmaktadır ancak teknik borç olarak değerlendirilmelidir!
"Scroll Handler" Dönemi (2010–2016)
İlk uygulamalar olay dinleyicilerini scroll olayına bağlıyordu.
// OBSOLETE: Do not use
window.addEventListener('scroll', () => {
images.forEach(img => {
if (img.getBoundingClientRect().top < window.innerHeight) {
img.src = img.dataset.src;
}
});
}); Ana İş Parçacığı Engelleme: Scroll olayı saniyede düzinelerce kez tetiklenir. Etkin kaydırma sırasında mantık yürütmek ve düzen hesaplamak (getBoundingClientRect) kare düşüşlerine (takılmaya) neden oluyordu.
Düzen Çırpınması: Geometrik özellikleri sorgulamak, tarayıcıyı düzen stilini senkron olarak yeniden hesaplamaya zorlar; bu mobil CPU'larda hesaplama açısından pahalı bir işlemdir.
IntersectionObserver Dönemi (2016–2019)
IntersectionObserver API, öğe görünürlüğündeki değişiklikleri asenkron olarak gözlemleyerek performansı iyileştirdi.
// DEPRECATED: Use native loading where possible
const observer = new IntersectionObserver((entries) => {
entries.forEach(entry => {
if (entry.isIntersecting) {
const img = entry.target;
img.src = img.dataset.src;
observer.unobserve(img);
}
});
});Betik Bağımlılığı: JavaScript yürütülmesini gerektirir. Ana iş parçacığı bir çerçeveyi (React/Vue) hidrate etmekle meşgulse, görseller görünüm alanında olsalar bile yüklenmeden kalır.
Ağ Farkındalığı Eksikliği: Yerel yüklemeden farklı olarak, IntersectionObserver sabit marjlar kullanır (örn. rootMargin: '200px'). Yavaş ağlarda tamponunu otomatik olarak genişletmez ve zayıf bağlantıya sahip kullanıcılarda "beyaz parlamalara" yol açar.
Compare your segments.
Is iOS slower than Android? Is the checkout route failing INP? Filter by device, route, and connection type.
- Device filtering
- Route Analysis
- Connection Types

