Tembel Yükleme

TL;DR — Tembel yükleme, tarayıcıya görselleri ve gömmeleri, onlara kaydırmaya yaklaşana kadar indirmeyi ertelemesini söyler; böylece sayfa başlangıçta daha hızlı yüklenir. Kolay ve kod gerektirmeyen yol, bir loading="lazy" veya <img> öğesine <iframe> eklemektir. Hatırlanması gereken tek kural: sayfanın üstündeki büyük görseli tembel yüklemeyin — bu, sayfayı daha hızlı değil, daha yavaş hissettirir.

Tembel yükleme nedir

Normalde, bir tarayıcı bir sayfayı açtığında, üzerindeki her şeyi — her görseli, her katıştırılmış haritayı veya videoyu — hemen indirmeye çalışır. Çok sayıda görsel içeren uzun bir sayfada, asla kaydırıp görmeyebileceğiniz şeyler için çok fazla indirme anlamına gelir.

Tembel yükleme bunu düzeltir. Ekran dışındaki görsellerin ve gömmelerin indirilmesini, onları görünüme kaydırana kadar erteler. Sayfa, üstteki içeriği hızlıca gösterir ve geri kalanı siz ilerledikçe yüklenir. Başlangıçta daha az veri, daha hızlı bir ilk izlenim anlamına gelir; ayrıca bant genişliği ve pil tasarrufu sağlar — bu en çok telefonlarda önemlidir.

Kolay yol: loading özniteliği

Eskiden bunu yapmak için bir JavaScript kitaplığına ihtiyacınız vardı. Artık değil. Modern tarayıcılarda bu yerleşik olarak bulunur. Sadece bir öznitelik eklersiniz:

<img src="photo.jpg" loading="lazy" alt="…">

İşte bu kadar. <img> ve <iframe> üzerinde (katıştırılmış YouTube videoları, Google Haritalar, sosyal widget’lar gibi) tüm büyük tarayıcılarda, JavaScript olmadan çalışır.

Kaçınılması gereken tek hata

Sayfanın üstündeki büyük görseli — kahraman görseli, insanların ilk gördüğü şeyi — tembel yüklemeyin. Tembel yükleme tarayıcıya “bu bekleyebilir” der, bu yüzden tembel yüklenen bir üst görsel olması gerekenden daha sonra yüklenir ve sayfa daha yavaş hissettirir. Google’ın kendi rehberliği, sayfa açıldığında hemen görünen her şey için tembel yüklemeyi atlamaktır.

Kısa versiyon: ekranın altındaki şeyleri tembel yükleyin, ekranın üstündeki şeyleri normal şekilde yükleyin.

SEO’ya zarar verir mi?

Tek başına, hayır. Google, normal şekilde yapıldığında tembel yüklenen görselleri ve içeriği sorunsuz bir şekilde dizine ekleyebilir. Sorun yalnızca bir sayfa içeriği kaydırma veya tıklamanın arkasına gizlediğinde başlar — çünkü arama motorları kaydırmaz veya tıklamaz. Görselleriniz yalnızca loading="lazy" kullanıyorsa, sorun yok. Google’ın bunu gerçekte nasıl gördüğüne ve nasıl kontrol edeceğinize dair ayrıntıları ister misiniz? Gelişmiş sekmesine geçin.

TL;DR — Tembel yükleme, ekran dışındaki görselleri ve iframe’leri görünüm alanına yaklaşana kadar erteler; bu da ilk sayfa ağırlığını (LCP’ye yardımcı olur) ve başlangıç ana iş parçacığı işini (INP’ye yardımcı olur) azaltır. loading="lazy"/<img> üzerindeki yerel <iframe> özniteliği çoğu JS kitaplığının yerini almıştır; yalnızca lazy ve eager anlamlı değerlerdir (auto kullanımdan kaldırılmıştır). Zarar veren hatalar: LCP/ekran üstü görselini tembel yüklemek (peşinde olduğunuz metriği geciktirir) ve içeriği kaydırma/tıklamanın arkasına gizlemek — Googlebot bunu asla tetiklemez çünkü sayfayla etkileşime girmez. Doğrudan bir sıralama faktörü değildir; etki Core Web Vitals ve taranabilirlik üzerinden geçer. Search Console’un URL İnceleme Aracı’nda görsel URL’lerinin işlenmiş HTML’in src özniteliğinde olduğunu doğrulayın.

Tembel yükleme gerçekte ne yapar

Fikir basittir: her şeyi aynı anda yüklemek yerine, kaynakları yalnızca ihtiyacınız olduğunda yükleyin. Medya açısından yoğun bir sayfada, her görseli ve gömmeyi baştan indirmek, tarayıcıyı ziyaretçinin asla kaydırmayabileceği şeyleri getirmekle meşgul eder — boşuna bant genişliği, bellek ve pil harcar. Ekran dışındakileri ertelemek, ekran üstü içeriğin daha erken boyanmasını sağlar. Martin Splitt, Google’ın Search Off the Record bölümü “Lazy loading demystified” bölümünde tam olarak bu noktaya değindi: amaç, hiçbir şey getirmeyen işten kaçınmaktır, çünkü sayfanın onsuz da iyi olacağı kritik olmayan görseller tarayıcıyı meşgul eder.

Bu, çoğu kişinin peşinde olduğu Core Web Vitals ile bağlantılıdır. Ağ için başlangıçta rekabet eden daha az bayt, Largest Contentful Paint öğesinin daha erken işlenebileceği anlamına gelir. Iframe’ler için — reklamlar, sosyal widget’lar, yorum bölümleri, haritalar — bunları ertelemek, başlangıç sırasında ana iş parçacığı iş yükünü de azaltır; bu yalnızca LCP değil, aynı zamanda Interaction to Next Paint kazancıdır. Google’ın kendi web.dev rehberi, yavaş yüklenen iframe’leri sayfa yükleme sırasında bir INP iyileştirmesi olarak çerçeveler.

Yerel ve JavaScript tabanlı yavaş yükleme

Birkaç yıl önce tarayıcılar, görüntüler ve iframe’ler için yerel bir loading özniteliği kazandı; böylece bir JavaScript API’si bağlamak yerine tüm işi tarayıcıya devredebilirsiniz. Ahrefs’teki JavaScript SEO rehberimde aynı gözlemi yapıyorum: bu yazıyı ilk yazdığımdan beri, yavaş yükleme çoğunlukla JavaScript tabanlı olmaktan tarayıcılar tarafından işlenmeye geçti. Yine de JS tabanlı kurulumlarla karşılaşacaksınız ve görüntüler için bunlar genellikle sorun değildir — kontrol ettiğim şey, gerçek içeriğin (yalnızca görüntüler değil) yavaş yüklenip yüklenmediğidir, çünkü bu kurulumlar içeriğin doğru şekilde alınmamasına neden olanlardır.

Yerel sürüm:

<!-- Below-the-fold image: defer it -->
<img src="gallery-07.jpg" loading="lazy" width="800" height="600" alt="…">

<!-- Off-screen embed: defer it -->
<iframe src="https://www.youtube.com/embed/…" loading="lazy" title="…"></iframe>

Yavaş yüklenen görüntülerde her zaman açık width/height (veya bir en-boy oranı) belirleyin, böylece tarayıcı görüntü yüklenmeden önce alanı ayırır — bu, ertelenen görüntülerle ilgili en büyük düzen kayması riskidir. Ayrılmış boyutlar mutlak bir CLS garantisi değildir: çevreleyen düzen veya duyarlı bir kırpma, görüntü yüklendikten sonra hâlâ değişirse, yine de bir kayma görebilirsiniz; bu nedenle, sabit boyutların tek başına bunu çözdüğünü varsaymak yerine gerçek bir düzen kayması iziyle doğrulayın.

Yavaş yükleme ve iframe’ler bir ayrım daha gerektirir: bir loading="lazy" üzerindeki <iframe> yalnızca yerleştirmenin getirilmesinin ve oluşturulmasının ne zaman gerçekleşeceğini erteler. title’ını, odak davranışını, sandbox’ını, allow/izin politikasını, referrerpolicy’sini, onay işlemesini veya boyutlarını sizin için ayarlamaz — bunlar yine de kendi ilgilerini gerektirir ve bir yerleştirme, yüklenmeye uygun hale geldikten sonra çalışmaya devam edebilir (komut dosyaları, izleme pikselleri, düzen). Ve “kat altı”nın her yerde aynı davrandığını varsaymayın: display: none içeriği, ekran dışı carousel slaytları, dönüştürülmüş öğeler ve iç içe kaydırma kapları, görünüm alanıyla düz bir kat altı öğeden farklı şekilde kesişebilir; bu nedenle eşdeğerlik varsaymak yerine gerçek düzeni ve gezinme kontrollerini test edin.

loading özniteliğinin değerleri

Bugün yalnızca iki değer önemlidir:

• loading="lazy" — kaynağı görünüm alanına yaklaşana kadar ertele.
• loading="eager" — hemen yükle, varsayılan davranış. Kat üstü görüntüler hakkında açık olmak için kullan.

Eski makalelerde loading="auto" görebilirsiniz — Chrome’da kullanımdan kaldırıldı, bu yüzden ona başvurmayın. Buna gerek yok; özniteliği atlamak size zaten varsayılan (eager) davranışı verir.

“Yakın” ne kadar yakın? loading="lazy" bir ipucudur, yazar tarafından kontrol edilen bir garanti değildir — spesifikasyon, gerçek görünüm alanına yakın kararı tarayıcıya bırakır. Chromium, yavaş bir kaynağı, ona kaydırdığınızda hazır olacak kadar erken getirmeye çalışır ve tetikleme mesafesi tarayıcıya, bağlantı hızına ve kaynak türüne göre değişir; tarayıcılar veya sürümler arasında güvenebileceğiniz veya yeniden üretebileceğiniz sabit bir piksel değeri değildir. Belirli bir “görünüm alanından N piksel önce yükler” sayısını yayınlamayın — veya güvenmeyin; görünüm alanına yakın pencereyi uygulama tanımlı olarak ele alın ve bir sabit varsaymak yerine önemsediğiniz tarayıcı/bağlantı üzerinde bir Ağ iziyle gerçek davranışı doğrulayın.

Yerel yavaş yükleme, duyarlı görsellerle de sorunsuz çalışır: sıradan src ve srcset/sizes seçimine uygulanır, bu nedenle loading="lazy" ekleyerek duyarlı görsel davranışını kaybetmezsiniz. Gerçek URL’yi yalnızca bir data-* özniteliğinde gizleyip daha sonra bir betiğin değiştirmesini bekliyorsanız, yükleme artık o betiğe bağlıdır — işlenmiş HTML’i ve betik başarısız olursa ne olacağını test edin (bununla ilgili daha fazlası Scripts ve Troubleshooting sekmelerinde).

1 numaralı hata: LCP / ekranın üstündeki görseli yavaş yüklemek

This is the failure I see most, and every source agrees on it. If you lazy-load the hero image — or any image likely to be the LCP element — you’ve told the browser to wait on the single most important pixel for perceived load speed. The browser also can’t lazy-load an image until it knows where the image will sit on the page, so lazy above-the-fold images tend to load more slowly than eager ones. That directly delays Largest Contentful Paint, the metric Google says should resolve within the first 2,5 seconds of load.

Splitt, SOTR bölümünde diğer tarafı açıkça ifade etti: olması gereken yerlerde yavaş yükleme kullanmıyorsanız, bu muhtemelen Core Web Vitals’ın bazı yönlerine zarar verir — büyük olasılıkla LCP’ye. Yani bu iki ucu keskin bir kılıçtır. Kural şudur:

• Olası veya gözlemlenen LCP adayı → hızlı yükleyin (loading="lazy" özniteliğini atlayın veya eager olarak ayarlayın). LCP görselinde fetchpriority="high" kullanmayı düşünün.
• Ekranın altında → loading="lazy".

Ekranın üstündeki her görsel LCP adayı değildir — gerçek olanı belirleyin (bir Performance izlemesi veya PageSpeed Insights bunu adlandıracaktır) ve her ilk ekran görseline aynı şekilde davranmak yerine istek zamanlamasını doğrulayın. Bunlar ayrı ipuçlarıdır, tek bir ayar değildir: loading="eager" (veya loading özniteliğini atlamak) yalnızca tarayıcının kaynağın keşfini ertelemediği anlamına gelir — bu tek başına getiri önceliğini yükseltmez. fetchpriority, bunun üzerine ayrı, danışma niteliğinde bir ipucudur. Aynı kaynağa <link rel="preload"> ile loading="lazy" eklemek tarayıcıya çelişkili bir niyet gönderir, bu nedenle kombinasyonun beklediğinizi yaptığını varsaymak yerine gerçek ağ şelalesini kontrol edin.

Yaygın anti-desen, sitenin tamamındaki her görsel için yavaş yüklemeyi açmaktır — yaygın bir CMS varsayılanı. Splitt’in belirttiği gibi, her görsel yavaş yüklenirse, hemen görünür olan (veya olması gereken) görseller de yavaş yüklenir; bu da tam olarak kaçınmak istediğiniz durumdur.

Googlebot yavaş yüklenen içeriği nasıl işler

İşte insanları şaşırtan tarama gerçeği: Googlebot kaydırmaz ve tıklamaz. Sayfanızı başsız bir tarayıcıyla işler, ancak onunla etkileşime giren bir kullanıcıyı simüle etmez. Google bunu doğrudan belirtir — önerdiği yavaş yükleme yöntemleri, kaydırma veya tıklama gibi kullanıcı eylemlerine kasıtlı olarak dayanmaz, çünkü Google Arama sayfanızla etkileşime girmez.

Bu nedenle uygulamanızın nasıl yapıldığı önemlidir. Google’ın belgeleri güvenli kabul ettiği üç uygulamayı listeler: görseller ve iframe’ler için tarayıcının yerleşik yavaş yüklemesi, IntersectionObserver API’si (bir polyfill ile) veya verileri görünüm alanına girdikçe yükleyen bir JavaScript kitaplığı. Üçü de görünüm alanı kesişimine dayanır — Googlebot’un asla tetiklemeyeceği bir kaydırma veya tıklama olayına değil.

Yüksek riskli desen, özel veya üçüncü taraf bir JS tembel yükleme kütüphanesidir. Kütüphane hatalı davranırsa ve görsel URL’si src özniteliğine asla ulaşmazsa, Google o görseli basitçe almaz — Splitt, SOTR bölümünde tam olarak bu hata modunu tanımladı. URL orada değilse dizine eklenecek bir şey yoktur. Bu, JavaScript SEO rehberimde belirttiğim şeyle aynıdır: görsel tembel yükleme genellikle sorunsuzdur, ancak tembel yüklenen içerik, dizine ekleme sorunlarının ortaya çıktığı yerdir ve çözüm, Google’ın gerçekte neyi işlediğini kontrol etmektir.

Sonsuz kaydırma farklı bir sorundur

Temel görsel/iframe tembel yüklemeyi sonsuz kaydırma veya sayfalanmış yüklemeyle karıştırmayın. Görselleri ertelemek bir şeydir; kullanıcı kaydırdıkça yeni içerik parçaları yüklemek başka bir şeydir ve kendi mimarisini gerektirir. Google’ın yönergesi: her parçaya kalıcı, benzersiz bir URL verin, içeriği URL başına sabit tutun (?page=12 gibi göreli değerler değil, ?date=yesterday gibi mutlak sayfa numaraları kullanın) ve her parça birincil görünür içerik haline geldikçe görüntülenen URL’yi History API ile güncelleyin, böylece yenilenebilir, paylaşılabilir ve bağlantı verilebilir. Bunu atlarsanız, sonsuz kaydırmanın arkasındaki daha derin içerik asla güvenilir bir şekilde taranamayabilir veya dizine eklenemeyebilir.

Nasıl test edilir

The verification path is the same in Google’s doc and in my own methodology: use Search Console’s URL Inspection Tool and look at the rendered HTML. If your image (or video) URLs appear in the src attribute on the <img>/<video> elements in that rendered HTML, your setup works. Google says this outright — check the rendered HTML to make sure your content is in it. If the URL is missing from src, that’s your problem, and it usually points back to a scroll/click trigger or a broken library.

Tembel yüklenen bir ürün ızgarası için bu varlık kontrolünün ötesine geçin. Sonsuz Kaydırma SEO test matrisini standart ve uzun görünüm alanları, yeni gezinme ve yükleme sonrası yeniden boyutlandırma, eylemsiz ve kademeli kaydırma çalıştırmaları, benzersiz ürün bağlantısı sayıları ve erişilebilirlik ağacı incelemesiyle çalıştırın. Başlatılmış bir sayfayı yeniden boyutlandırmak, son görünüm alanı boyutunda gezinmeye eşdeğer değildir çünkü gözlemciler ve toplu hesaplamalar yalnızca başlangıç sırasında kaydedilmiş olabilir. Evidence for this claim Google Search does not scroll or click to trigger lazy-loaded content, so implementations should not depend on user interaction and should expose resource URLs in rendered HTML. Scope: Google Search guidance for JavaScript-driven lazy loading. Confidence: high · Verified: 2026-07-14 Google Search Central: Lazy-load content

Ayrıca web performans araçlarınıza da güvenebilirsiniz: PageSpeed Insights, ertelemeniz gereken ekran dışı görselleri işaretler. Ahrefs’teki PageSpeed Insights rehberimde “ekran dışı öğeleri ertele” denetiminin size görselleri tembel yüklemeyi söylediğini belirtiyorum — halihazırda çalıştırdığınız tanılamayı çözüme bağlamanın kullanışlı bir yolu.

Sıralama sinyali dürüstlüğü

Tembel yüklemenin ne olduğu ve ne olmadığı konusunda net olun. Bunu kullanmak doğrudan bir sıralama faktörü değildir ve kullanmamak da bir ceza değildir. Sıralamayla bağlantı dolaylıdır: Core Web Vitals (çoğunlukla LCP, bazen iframe’ler için INP) ve tarama yapılabilirliği üzerinden akar; kötü bir uygulama içeriği gizlerse. Splitt, Core Web Vitals aracılığıyla sıralama etkisini çoğu durumda küçük, dakika düzeyinde bir faktör olarak nitelendirdi. Bu nedenle tembel yüklemeyi kullanıcılarınızın yükleme deneyimi ve temiz dizine ekleme için optimize edin — özniteliğin kendisinden bir sıralama artışı beklediğiniz için değil.

Bu nereye uyuyor

Tembel yükleme, daha geniş web performansı araç setindeki kaldıraçlardan biridir. Kaynak ipuçlarıyla (erken istediğiniz kaynaklar için ön yükleme/ön bağlantı), yazı tipi yükleme stratejisi, önbelleğe alma ve bir CDN ile eşleşir — ve nihayetinde Core Web Vitals aracılığıyla değerlendirilir. İlk görünüm/alt görünüm ayrımını doğru yapın ve mevcut en ucuz kazanımlardan biri olur.

AI özeti

Gelişmiş sürümün yoğunlaştırılmış bir değerlendirmesi:

• Yavaş yükleme (lazy loading), ekran dışındaki görselleri ve iframe’leri görünüm alanına yaklaşana kadar erteler — ilk sayfa ağırlığını ve başlangıç iş yükünü azaltır. JS gerektirmeyen yerel yöntem, loading="lazy" ve <img> üzerinde <iframe> kullanmaktır; bu, JS kütüphanelerinin yerini büyük ölçüde almıştır. Bu bir tarayıcı ipucudur, garanti edilen bir mesafe veya zamanlama değildir — tetikleme noktası tarayıcıya, bağlantıya ve kaynak türüne göre değişir, bu yüzden sabit bir piksel sayısına güvenmeyin.
• Değerler: yalnızca lazy ve eager önemlidir. auto, Chrome’da kullanımdan kaldırılmıştır.
• Core Web Vitals bağlantısı: daha az başlangıç baytı LCP’ye yardımcı olur; iframe’leri ertelemek, başlangıçtaki ana iş parçacığı iş yükünü azaltarak INP’ye yardımcı olur. Ertelenen görsellerin CLS’ye neden olmaması için width/height ayarlayın — ancak ayrılan boyutlar tek başına, çevredeki düzen hâlâ değişiyorsa sıfır kayma garantisi vermez.
• #1 hata: yalnızca herhangi bir ekran üstü görseli değil, olası/gözlemlenen LCP görselini yavaş yüklemek. Bu, Google’ın 2,5 saniye içinde çözülmesi gerektiğini söylediği Largest Contentful Paint’i geciktirir. eager veya loading özniteliğinin atlanması yalnızca keşfi etkiler — bu tek başına getirme önceliğini artırmaz; fetchpriority ayrı bir ipucudur ve aynı kaynakta preload ile loading="lazy" kullanmak çakışır. Site genelinde körlemesine yavaş yükleme, yaygın CMS anti-desenidir.
• Iframe’lerin kendi sözleşmeleri vardır: loading="lazy" yalnızca getirme/oluşturma zamanlamasını erteler — title, sandbox, permissions policy, referrer policy, onay ve boyutların yine de bağımsız olarak ayarlanması gerekir ve gizli/karusel/dönüştürülmüş düzenler, görünüm alanıyla düz bir ekran altı öğeden farklı şekilde kesişebilir.
• Googlebot kaydırmaz veya tıklamaz. Kaydırma/tıklama olaylarının arkasına gizlenen herhangi bir içerik görünmeyebilir. Google’ın güvenli yöntemleri — yerel yavaş yükleme, IntersectionObserver veya iyi davranan bir JS kütüphanesi — tümü görünüm alanı kesişimine dayanır.
• En yüksek risk: özel/üçüncü taraf JS yavaş yükleme kütüphaneleri. URL src içinde asla yer almazsa, Google görseli dizine eklemez (Martin Splitt’e göre).
• Sonsuz kaydırma farklıdır: benzersiz sayfalanmış URL’ler + History API gerektirir.
• Doğrulayın: Search Console URL İnceleme → işlenmiş HTML → görsel URL’lerinin src özniteliğinde bulunması.
• Doğrudan bir sıralama faktörü değildir. Etki, Core Web Vitals ve taranabilirlik yoluyla dolaylıdır ve Splitt, Core Web Vitals sıralama etkisini küçük olarak nitelendirmiştir.

Resmi dokümantasyon

Arama motorlarından ve Google’ın web.dev sitesinden birincil kaynak rehberliği.

Google — Search Central

• Yavaş Yüklenen Web Sitesi İçeriğini Düzeltme — kesin doküman: güvenli uygulama yöntemleri, “Google sayfanızla etkileşime girmez” kuralı, sonsuz kaydırma/sayfalanmış yükleme gereksinimleri ve işlenmiş HTML’de nasıl doğrulanacağı.
• JavaScript SEO Temellerini Anlama — görselleri yavaş yüklemeyi bant genişliği/performans için en iyi uygulama olarak önerir ve özel rehbere bağlantı verir.
• Core Web Vitals — LCP öğesini yavaş yüklemenin neden kendi kendini baltaladığı (LCP hedefi 2,5 saniyedir).

Google — web.dev (Performansı Öğrenin)

• Görselleri ve <iframe> öğelerini yavaş yükleme — ne zaman ertelemeli ve yavaş iframe’lerin INP faydası.
• Web için tarayıcı düzeyinde görsel yavaş yükleme — yerel öznitelik ve görünüm alanındaki/LCP görsellerini neden yavaş yüklememek gerektiği.
• Ekran dışı iframe’leri yavaş yüklemenin zamanı geldi! — iframe’e özel durum (reklamlar, widget’lar, haritalar).
• CMS’ler için tarayıcı düzeyinde yavaş yükleme — CMS platformları için rehberlik.

Google — podcast

• Search Off the Record — Ep. 98, “Lazy loading demystified” (21 Ağu 2025) — John Mueller ve Martin Splitt, yavaş yükleme, oluşturma, dizine ekleme ve Core Web Vitals hakkında. Ayrıca Google’ın Search Off the Record sayfasında dizinlenmiştir.

Geliştirici referansı (SEO’ya özel değil, ancak API hakkında yetkili)

• MDN — Lazy loading (Performans rehberi)
• MDN — HTMLImageElement: loading özelliği
• caniuse — Görseller ve iframe’ler için öznitelik aracılığıyla yavaş yükleme

Bing / Microsoft

• Bing, yavaş yüklemeye özel bir belge yayınlamaz. Genel Webmaster Yönergeleri taramayı ve JS oluşturmayı geniş kapsamda ele alır. Bingbot, Chromium tabanlı bir headless tarayıcıyla oluşturur ve Googlebot gibi kaydırma veya tıklama yapmaz — bu nedenle Google’ı tatmin eden aynı yerel loading="lazy" / IntersectionObserver yaklaşımı Bing’i de tatmin etmelidir. Bu son nokta, Bingbot’un genel oluşturma davranışından yapılan bir çıkarımdır; yavaş yükleme hakkında kaynaklı bir Bing açıklaması değildir — buna göre değerlendirin.

Kaynaktan alıntılar

Google’ın resmi belgelerinden kayıtlı açıklamalar. Her bağlantı, kaynak sayfadaki alıntılanan pasaja atlayan derin bir bağlantıdır.

Google — Search Central, “Yavaş Yüklenen Web Sitesi İçeriğini Düzeltme”

• “Deferring loading of non-critical or non-visible content, also commonly known as ‘lazy-loading’, is a common performance and UX best practice.” (çeviri) «Kritik olmayan veya görünmeyen içeriğin yüklenmesini ertelemek, yaygın olarak ‘yavaş yükleme’ olarak da bilinir, yaygın bir performans ve kullanıcı deneyimi en iyi uygulamasıdır.» Alıntıya git
• “However, if not implemented correctly, this technique can inadvertently hide content from Google. This document explains how to make sure Google can crawl and index lazy-loaded content.” (çeviri) «Ancak doğru uygulanmazsa bu teknik, içeriği istemeden Google’dan gizleyebilir. Bu belge, Google’ın yavaş yüklenen içeriği tarayıp dizine ekleyebildiğinden nasıl emin olunacağını açıklar.» Alıntıya git
• “The methods mentioned don’t rely on user actions, such as scrolling or clicking, to load content, which is important as Google Search does not interact with your page.” (çeviri) «Bahsedilen yöntemler, içeriği yüklemek için kaydırma veya tıklama gibi kullanıcı eylemlerine dayanmaz; bu önemlidir çünkü Google Arama sayfanızla etkileşime girmez.» Alıntıya git
• “Don’t add lazy-loading to content that is likely to be immediately visible when a user opens a page. That might cause content to take longer to load and show up in the browser, which will be very noticeable to the user.” (çeviri) «Kullanıcı bir sayfayı açtığında hemen görünme olasılığı yüksek olan içeriğe yavaş yükleme eklemeyin. Bu, içeriğin tarayıcıda yüklenmesinin ve görünmesinin daha uzun sürmesine neden olabilir ve bu, kullanıcı tarafından çok fark edilir.» Alıntıya git
• “Give each chunk its own persistent, unique URL.” — sonsuz kaydırma / sayfalı yükleme hakkında. (çeviri) «Her parçaya kendi kalıcı, benzersiz URL’sini verin.» Alıntıya git

Yavaş yükleme kontrol listesi

Yavaş yükleme değişikliği yayınlamadan önce bunu çalıştırın:

• Kahraman / LCP görseli TEMBEL YÜKLENMEMİŞTİR — hemen yüklenir (loading="lazy" atlanır), ideal olarak fetchpriority="high" ile.
• loading="lazy", ekranın altında kalan görsellere ve iframe’lere uygulanır.
• Tembel yüklenen görsellerin belirgin width/height (veya aspect-ratio) değerleri vardır, böylece yüklendiklerinde düzen kaymasına (CLS) neden olmazlar.
• Hiçbir içerik kaydırma veya tıklama olayının arkasına gizlenmemiştir — Googlebot bunları tetiklemez. Bunun yerine yerel tembel yükleme veya IntersectionObserver kullanın.
• Kullanımdan kaldırılan loading="auto" değerini kullanmıyorsunuz — yalnızca lazy/eager.
• Ekran dışı iframe’ler (gömülü içerikler, reklamlar, haritalar, widget’lar) başlangıçtaki ana iş parçacığı iş yükünü azaltmak için loading="lazy" kullanır.
• Tembel yüklenen iframe’lerin yine de kendi title, sandbox, allow/izin politikası, referrerpolicy ve belirgin boyutları vardır — loading="lazy" yalnızca getirme zamanlamasını erteler, bu öznitelikleri değil.
• Search Console URL İnceleme → işlenmiş HTML içinde görsel/video URL’lerinin src özniteliğinde göründüğü doğrulandı.
• Bir üçüncü taraf JS tembel yükleme kitaplığı kullanılıyorsa, src’nin işlenmiş HTML’de hâlâ doldurulduğu doğrulandı.
• Sonsuz kaydırma için her parçanın benzersiz, kalıcı, sayfalanmış bir URL’si vardır ve History API görüntülenen URL’yi günceller.
• PageSpeed Insights’ın “ekran dışı görselleri ertele” uyarıları ele alınmıştır.

Tembel yükleme anti-desenleri (mitler ve hatalar)

Bunların her biri yaygın bir inanç veya alışkanlık, neden yanlış olduğu ve bunun yerine ne yapılması gerektiğidir.

“Tembel yükleme her zaman iyidir, bu yüzden her görsele uygulayın.” Neden yanlış: site genelinde körlemesine tembel yükleme, kahraman/LCP görselinizi de yakalar ve bu da En Büyük İçerikli Boyamayı geciktirir — istediğiniz hız kazancının tam tersi. Bunun yerine: yalnızca ekranın altındakileri tembel yükleyin; ekranın üstündeki görselleri hemen yükleyin.

“Google, tembel yüklenen içeriği hiç dizine eklemez.” Neden yanlış: Google, yerel tembel yükleme, IntersectionObserver veya iyi davranan bir kitaplıkla yapıldığında tembel yüklenen içeriği sorunsuz bir şekilde tarar ve dizine ekler. Risk, kaydırma/tıklama ile kısıtlanmış veya bozuk kurulumlara özgüdür — Google’ın kendi ifadesine göre, sorun “doğru şekilde uygulanmadığında” ortaya çıkar. Bunun yerine: bir görünüm alanı kesişim yöntemi kullanın ve işlenmiş HTML’de doğrulayın.

“loading='auto' iyi bir varsayılandır.” Neden yanlış: auto, Chrome’da kullanımdan kaldırılmıştır; bunu önermek bayat bir tavsiyedir. Bunun yerine: ekran dışı kaynaklar için lazy, geri kalanı için eager (veya hiçbir şey) kullanın.

“Tembel yükleme ve sonsuz kaydırma aynı çözümdür.” Neden yanlış: bunlar farklıdır. Sonsuz kaydırma ayrıca benzersiz sayfalanmış URL’ler ve History API güncellemeleri gerektirir, aksi takdirde daha derin içerik güvenilir bir şekilde taranamayabilir. Bunun yerine: sayfalanmış/sonsuz yüklemeyi, parça başına URL’leri olan kendi mimarisi olarak ele alın.

“loading='lazy' her öğede çalışır.” Neden yanlış: <img> ve <iframe> için belirtilmiştir. Diğer öğeler için destek, çekirdek spesifikasyonun aynı şekilde bir parçası değildir. Bunun yerine: özniteliği görsellerde ve iframe’lerde kullanın; diğer medyayı uygun bir teknikle ele alın (video için, görünüm alanına girişte videoyu yükleyen bir poster görseli).

“Tembel yükleme SEO’ya zarar verir.” Neden yanlış: tembel yüklemenin kendisi bir ceza değildir. Sıralamayla ilgili etki, Core Web Vitals üzerinden geçer ve küçüktür; zarar veren kötü uygulamadır, teknik değil. Bunun yerine: doğru şekilde uygulayın, LCP görselini hariç tutun ve neyin işlendiğini doğrulayın.

Tembel yükleme hızlı başvuru

loading özniteliği

Hangi öğeler bunu destekler

• <img> — evet
• <iframe> — evet
• Diğer öğeler (video/audio) — çekirdek spesifikasyonun aynı şekilde bir parçası değildir; video için poster görseli + görünümde yükleme deseni kullanın.

Üst katın üstü vs. altı

• Üst katın üstü / olası LCP → eager (asla lazy). LCP görseline fetchpriority="high" ekleyin.
• Üst katın altı → lazy.

Core Web Vitals etkisi

• Ekran dışı görselleri ertelemek → LCP’ye yardımcı olur (başlangıçta daha az bayt rekabet eder).
• Ekran dışı iframe’leri ertelemek → INP’ye yardımcı olur (daha az başlangıç ana iş parçacığı işi).
• Lazy görsellerde width/height eksikliği → CLS’ye zarar verebilir (yükleme sırasında yerleşim kayması).

Googlebot’un önemsediği kurallar

• Googlebot kaydırmaz veya tıklamaz — kaydırma/tıklama ile açılan içerik yok.
• Güvenli yöntemler: yerel loading="lazy", IntersectionObserver, iyi davranan JS kütüphanesi.
• Doğrulayın: URL İnceleme → işlenmiş HTML → src özniteliğindeki görsel URL’si.
• Sonsuz kaydırma ≠ görsel lazy loading — benzersiz sayfalanmış URL’ler + History API gerektirir.

Öncesi / sonrası

Somut düzeltmeler, bir denetimde karşılaşacağınız şekilde çerçevelenmiştir.

1. Hero görseli lazy yükleniyor (LCP gecikti)

Öncesi:

<img src="hero.jpg" loading="lazy" alt="Product hero">

Sonrası:

<img src="hero.jpg" fetchpriority="high" alt="Product hero">

Neden: hero, LCP öğesidir. Onu eager yüklemek (ve getirmeye öncelik vermek) daha erken boyanmasını sağlar. Lazy yüklemek tam tersini yapar.

2. Bir CMS varsayılanından site genelinde toplu lazy loading

Öncesi: şablondaki her <img> etiketi loading="lazy" taşır; buna başlık logosu ve sayfanın üst kısmındaki öne çıkan görsel de dahildir. Sonrası: şablon, üst katın üstündeki görselleri eager yükler ve loading="lazy" yalnızca başlangıçtaki görünüm alanının altında işlenen görsellere uygular. Neden: toplu lazy loading, hemen görünen görselleri yakalar ve kullanıcının (ve LCP’nin) ilk gördüğünü geciktirir.

3. Sayfa yüklenirken ekran dışı yerleştirme yükleniyor

Öncesi:

<iframe src="https://maps.google.com/…" title="Store map"></iframe>

Sonrası:

<iframe src="https://maps.google.com/…" loading="lazy" title="Store map"></iframe>

Neden: harita üst katın altındadır. Onu ertelemek başlangıç maliyetini kaldırır ve INP’ye yardımcı olur; çünkü yerleştirmeler sayfa yüklenirken ana iş parçacığı işi yapar.

4. Özel JS lazy load, Googlebot için src’yi boş bırakıyor

Öncesi: bir kütüphane gerçek URL’yi data-src içinde saklar ve bir kaydırma eyleminde onu src’ye takas eder — Googlebot bunu asla tetiklemez, bu nedenle işlenmiş HTML boş/yer tutucu bir src gösterir. Sonrası: yerel loading="lazy" (gerçek URL baştan src içinde) veya IntersectionObserver tabanlı bir kütüphane kullanın, ardından URL İnceleme’de URL’nin işlenmiş src içinde mevcut olduğunu doğrulayın. Neden: URL, işlenmiş HTML’de src içinde değilse Google görseli alamaz.

Lazy yüklenmesi gereken (veya gerekmeyen) görselleri bulun

Herhangi bir sayfaya yapıştırabileceğiniz, loading özniteliğini denetleyen bir DevTools Console snippet’i. Görselleri loading değerleriyle ve şu anda görünüm alanında olup olmadıklarıyla listeler — böylece lazy olarak işaretlenmiş üst katın üstünde bir görseli veya lazy olmayan üst katın altında bir görseli tespit edebilirsiniz.

Chrome DevTools Console

// Audit loading attributes vs. viewport position
[...document.images].forEach(img => {
  const r = img.getBoundingClientRect();
  const inView = r.top < innerHeight && r.bottom > 0;
  const loading = img.getAttribute('loading') || '(none/eager)';
  // Flag the two mistakes: in-view + lazy, or off-view + not lazy
  const flag =
    (inView && loading === 'lazy') ? '⚠ above-the-fold but LAZY' :
    (!inView && loading !== 'lazy') ? '· off-screen, not lazy' : '';
  console.log(loading.padEnd(14), inView ? 'in-view ' : 'off-view', flag, img.currentSrc || img.src);
});

Kaynağınızı riskli lazy-load desenleri için grep yapın

Kullanımdan kaldırılan auto değeri ve data-src tarzı JS lazy loading (Googlebot için src’yi boş bırakabilir) için şablonlarınızı/derleme çıktınızı kontrol edin.

macOS / Linux (bash)

# Deprecated loading="auto"
grep -rn 'loading="auto"' ./src

# JS-driven lazy load leaving real URL in data-src (verify these render into src)
grep -rn 'data-src=' ./src

Windows (PowerShell)

# Deprecated loading="auto"
Get-ChildItem -Recurse .\src | Select-String -Pattern 'loading="auto"'

# JS-driven lazy load using data-src
Get-ChildItem -Recurse .\src | Select-String -Pattern 'data-src='

Unutmayın: data-src otomatik olarak bir sorun değildir — gerçek URL’nin işlenmiş src içinde sona erdiğini doğrulamak için bir ipucudur; bunu Search Console URL İnceleme’de doğrularsınız.

Lazy loading etkinleştirildikten sonra hero görseli daha geç başlıyor

Belirti: LCP yavaşlar ve hero isteği su şelalesinde geç başlar.

Olası neden: Genel bir CMS kuralı, üst katın üstünde veya LCP görseline loading="lazy" ekledi.

Düzeltme ve doğrulama: Bu görselden lazy özniteliğini kaldırın, isteğe bağlı olarak fetchpriority="high" ekleyin ve eşleşen bir izlemede isteğinin daha erken başladığını doğrulayın.

Lazy görsel görünüyor ancak sayfayı kaydırıyor

Belirti: Ertelenen bir görsel görünüm alanına girdiğinde içerik sıçrar.

Olası neden: Görselin açık boyutları veya ayrılmış bir en-boy oranı yok.

Düzeltme ve doğrulama: width ve height özniteliklerini ekleyin veya CSS’de aynı en-boy oranını ayırın. Yerleşim kayması bölgeleri etkinleştirilmiş şekilde yeniden yükleyin ve görselin çevresindeki içeriği artık hareket ettirmediğini doğrulayın.

Google ertelenen içeriği görmüyor

Belirti: İşlenmiş bir inceleme, bir insan kaydırdıktan sonra görünen görsel URL’sini veya içeriği eksik gösteriyor.

Olası neden: Googlebot için bir kaydırma/tıklama işleyicisi hiç çalışmıyor veya bir lazy-load kütüphanesi gerçek URL’yi işlenmiş data-src yerine src içinde bırakıyor.

Düzeltme ve doğrulama: Yerel lazy loading veya IntersectionObserver tabanlı bir uygulama kullanın, ardından işlenmiş HTML’i inceleyin ve etkileşim olmadan son URL’nin ve içeriğin mevcut olduğunu doğrulayın.

Ekran dışı yerleştirme yine de hemen yükleniyor

Belirti: Lazy-loading değişikliğine rağmen, katlanma çizgisinin altındaki bir iframe ilk su şelalesinde görünüyor.

Olası neden: Öznitelik dağıtılan iframe’de yok, bir sarmalayıcı iframe’i istekli olarak oluşturuyor veya yerleştirme, tarayıcının yükleme eşiğine yeterince yakın duruyor.

Düzeltme ve doğrulama: Canlı DOM’u ve istek başlatıcısını inceleyin, soğuk önbellekle uzun bir sayfada test edin ve isteğin tarayıcının görünüm alanına yakın eşiğine kadar ertelendiğini doğrulayın.

Uygulama ve kanıt için araçlar

• Chrome DevTools Elements ve Network panelleri: dağıtılan loading özniteliğini doğrulayın, bir iframe’i hangi komut dosyasının oluşturduğunu belirleyin ve bir değişiklikten önce ve sonra istek başlangıç zamanlarını karşılaştırın.
• Chrome DevTools Performance paneli: bir yükleme kaydedin ve bir yerleştirmeyi ertelemenin LCP görselini geciktirmeden başlangıç ana iş parçacığı işini azalttığını doğrulayın.
• PageSpeed Insights: ekran dışı görsel tanılamasını başlangıç listesi olarak kullanın, ardından gerçek katlanma çizgisi altı adayları kahraman veya diğer anlık içerikten ayırın.
• Search Console URL Inspection: işlenmiş HTML’i inceleyin ve ertelenen görsel URL’lerinin src içinde olduğunu ve lazy yüklenen içeriğin kaydırma veya tıklama olmadan var olduğunu doğrulayın.
• Tarayıcı görünüm alanı ve film şeridi: birden fazla görünüm alanı boyutunu test edin. Masaüstünde katlanma çizgisinin altındaki bir görsel, daha küçük veya farklı şekilli bir cihazda katlanma çizgisinin üzerinde olabilir.

Katlanma çizgisi altı görsel erteleme

Çalıştırılacak test: İlk görünüm alanının oldukça altındaki bir görsele yerel lazy loading eklemeden önce ve sonra soğuk yükleme Network izlemesi kaydedin.

Beklenen sonuç: Görsel isteği ilk kritik su şelalesinde yoktur ve görünüm alanı ona yaklaştıkça başlar.

Hata yorumu: Dağıtılan işaretleme öznitelikten yoksun, JavaScript görseli istekli olarak oluşturuyor veya getiriyor ya da test görseli tarayıcının görünüm alanına yakın eşiği içinde.

İzleme penceresi: Dağıtımdan hemen sonra temsili mobil ve masaüstü görünüm alanı boyutlarında kontrol edin.

Geri alma tetikleyicisi: İlk yüklemede görünen bir görsel ertelenirse veya görsel kullanıcı ona ulaşmadan önce rutin olarak görünmezse geri alın.

LCP görsel hariç tutma

Çalıştırılacak test: Kapsamlı lazy loading kaldırıldıktan sonra sayfanın LCP görseli için eşleşen performans izlemelerini ve istek su şelalelerini karşılaştırın.

Beklenen sonuç: LCP görseli istekli olarak yüklenir, isteği daha erken başlar ve LCP geriye gitmez.

Hata yorumu: Başka bir şablon veya optimizasyon katmanı özniteliği yeniden ekliyor veya keşif hâlâ CSS, JavaScript veya işaretleme tarafından geciktiriliyor.

İzleme penceresi: Tekrarlanan laboratuvar çalışmalarını hemen kontrol edin, ardından sonraki raporlama penceresinde saha LCP’sini izleyin.

Geri alma tetikleyicisi: Değişiklik diğer kritik kaynakları tekrarlanabilir bir LCP gerilemesine neden olacak kadar geciktirirse çevreleyen dağıtımı geri alın.

İşlenmiş içerik görünürlüğü

Çalıştırılacak test: Sayfayla etkileşime girmeden işlenmiş HTML’i görüntülemek için URL İnceleme’yi kullanın ve ertelenen görsel URL’sini ve ilişkili içeriği arayın.

Beklenen sonuç: Son URL src içinde görünür ve önemli içerik işlenmiş HTML’de mevcuttur.

Hata yorumu: Uygulama bir kaydırma/tıklama olayına bağlıdır veya yavaş yükleme betiği işleme sırasında başarısız olmuştur.

İzleme penceresi: Yayından sonra ve yavaş yükleme kitaplığını veya CMS görsel işlem hattını değiştirdikten sonra etkilenen her şablonu test edin.

Geri alma tetikleyicisi: Dizine eklenebilir içerik veya görsel URL’leri işlenmiş çıktıdan kaybolursa geri alın.

Kendinizi test edin: Yavaş Yükleme

Görselleri ve iframe’leri ertelemeyle ilgili, Core Web Vitals veya dizine eklemeye zarar vermeden beş hızlı soru. Her biri için bir yanıt seçin, ardından kontrol edin.

Zaman ayırmaya değer kaynaklar

İlgili yazılarım

• JavaScript SEO Sorunları ve En İyi Uygulamalar — JS odaklı yavaş yüklemelerden tarayıcı yerel yavaş yüklemeye geçişi ve yavaş yüklenen içeriğin (yalnızca görseller değil) dizine ekleme riski olduğunu ele aldığım yer.
• SEO’lar ve Geliştiriciler için Google PageSpeed Insights — “ekran dışı görselleri ertele” denetimini yavaş yüklemeye ve PSI raporunun geri kalanına bağlar.
• Teknik SEO Başlangıç Rehberi — performans ve işlemenin büyük resimde nereye oturduğu.

Sektörden

• Yavaş Yüklenen Web Sitesi İçeriğini Düzeltme (Google Search Central) — kesin uygulama ve test belgesi.
• Web için tarayıcı düzeyinde görsel yavaş yükleme (web.dev) — yerel öznitelik ve LCP uyarısı, doğrudan Google’ın performans ekibinden.
• Ekran dışı iframe’leri yavaş yüklemenin zamanı geldi! (web.dev) — iframe durumu ve başlangıç/INP faydası.
• Yavaş yükleme gizemi çözüldü — Search Off the Record, Bölüm 98 (Google) — Mueller ve Splitt’in yavaş yükleme, işleme, dizine ekleme ve Core Web Vitals hakkındaki tam bölümü.
• Yavaş yükleme açıklandı: Sitenizi ve UX’inizi hızlandırın (Search Engine Land) — CMS’ye özel notlarla kapsamlı bir sektör rehberi.
• Yavaş yükleme (Performans rehberi) (MDN) — API’nin geliştirici referans görünümü.
• Tarama ve dizine ekleme başarısı için yavaş yükleme başlangıç rehberi (Oncrawl) — tarama/dizin açısını derinlemesine ele alır.

Değişiklik günlüğü