Lazy Load Nedir? Tembel Yüklemenin SEO ve Hıza Etkisi

Lazy load, sayfadaki görsellerin ve gömülü içeriklerin kullanıcı onlara yaklaşana kadar indirilmemesini sağlayan bir yükleme tekniğidir. 2012'den beri müşteri sitelerinde hız ve SEO sorunlarıyla uğraşıyorum; tembel yükleme de bu işin en çok yanlış kurulan parçalarından biri. Bu yazıda doğru kullanımı, en sık hatayı ve Google'ın beklentisini anlatıyorum.

Genel hız ve sıralama ilişkisini site hızı SEO'yu nasıl etkiler yazısında ele aldım. Burada odak yalnızca tembel yükleme: hangi öğeye uygularsınız, hangisine asla uygulamazsınız ve arama motoru bunu nasıl okur.

Lazy load nedir ve nasıl çalışır?

Lazy load, yani tembel yükleme, ekranın görüş alanı dışında kalan görsel, iframe ve video gibi kaynakların sayfa açılışında değil, kullanıcı kaydırarak onlara yaklaştığında indirilmesidir. Böylece ilk açılışta daha az veri iner, tarayıcı önemli kaynaklara öncelik verir ve gereksiz trafik harcanmaz.

Mantık oldukça basit. Normalde tarayıcı HTML'i okurken bulduğu her img etiketini hemen indirmeye başlar. Sayfanın en altındaki footer logosu bile, ziyaretçi oraya hiç inmeyecek olsa da, ilk saniyelerde bant genişliği için yarışır. Tembel yükleme ise bu kaynakları bir bekleme listesine alır.

Kullanıcı sayfayı aşağı kaydırdıkça tarayıcı, bekleyen öğenin görüş alanına ne kadar yaklaştığını hesaplar. Belirli bir mesafeye girdiğinde indirmeyi başlatır. Dolayısıyla doğru kurduğunuz bir yapıda ziyaretçi görselin geç geldiğini fark etmez; görsel o alana ulaşmadan hazır olur.

Bu tekniği önemsememin nedeni şu: uzun kategori sayfaları, blog yazıları ve ürün galerileri onlarca görsel içerir. Ancak ziyaretçilerin önemli bir kısmı sayfanın yalnızca üst bölümünü görür. Yani indirilen ve kimsenin bakmadığı her görsel, hem sunucunuza hem de kullanıcının mobil paketine boşuna yük bindirir.

Tembel yükleme hangi sorunları çözer?

Tembel yüklemenin çözdüğü sorunlar, sayfanın ne kadar uzun ve ne kadar medya yüklü olduğuna göre büyür. Kısa bir hizmet sayfasında fark küçük kalır. Öte yandan yüzlerce ürün kartı olan bir kategori sayfasında etkisi belirgindir.

• İlk açılışta inen toplam veri miktarını azaltır.
• Tarayıcının bağlantılarını görüş alanındaki kaynaklara ayırmasına yardım eder.
• Mobil veri kullanan ziyaretçinin paketinden gereksiz harcama yapmaz.
• Sunucu ve CDN tarafında hiç görülmeyen görseller için trafik ödemenizi azaltır.
• Ağır üçüncü taraf gömmelerin (harita, video, sosyal medya kutuları) açılışı kilitlemesini önler.

Burada şu ayrımı net yapmak istiyorum: tembel yükleme bir kaynak önceliklendirme aracıdır, bir sıkıştırma aracı değildir. Görselin kendisini küçültmez, sadece ne zaman ineceğine karar verir. Bu yüzden tek başına bütün hız sorunlarınızı çözmesini beklemeyin.

loading="lazy" özelliğini nasıl kullanırsınız?

Bugün tembel yükleme için ilk tercihim tarayıcının kendi özelliği olan loading niteliğidir. img veya iframe etiketine loading="lazy" yazdığınızda, tarayıcı o öğeyi ekran dışında kaldığı sürece ertelemeyi kendisi yönetir. Ek bir JavaScript kütüphanesine ihtiyaç kalmaz.

Niteliğin üç değeri vardır:

1. lazy: Öğe görüş alanına yaklaşana kadar indirmeyi erteler.
2. eager: Öğeyi konumundan bağımsız olarak hemen indirir.
3. auto: Kararı tarayıcıya bırakır; pratikte eager ile aynı sonucu verir.

Hiç yazmadığınızda tarayıcı varsayılan olarak eager modunu seçer. MDN dokümantasyonu bu davranışı ayrıntılı anlatıyor. Ayrıca tarayıcı desteği bugün Chrome, Edge, Firefox ve Safari'nin güncel sürümlerinde mevcut.

Uygulamada dikkat ettiğim iki kural var. İlk olarak lazy verdiğiniz her görsele width ve height değerlerini yazın. İkinci olarak bu niteliği şablonun tamamına körlemesine eklemeyin; sayfanın üst bölümündeki görselleri ayrı ele alın. Bu iki kuralı bir sonraki bölümlerde açıyorum.

Tarayıcı lazy load görselini ne zaman indirmeye başlar?

Tarayıcı, lazy işaretli bir görseli tam görüş alanına girdiğinde değil, biraz önce indirmeye başlar. Chrome ekibinin web.dev üzerindeki rehberine göre bu mesafe bağlantı hızına göre değişir: tarayıcı hızlı bağlantıda mesafeyi kısa, yavaş bağlantıda uzun tutar.

Aynı rehber, Chrome'un bu eşiği zamanla güncellediğini ve hızlı bağlantılarda yaklaşık 1250 piksel, yavaş bağlantılarda yaklaşık 2500 piksel mesafe kullandığını belirtiyor. Bu değerler tarayıcı sürümüne göre değişebilir; bu yüzden sabit bir kural gibi kodunuza gömmeyin.

Peki bu sizin için ne anlama geliyor? Normal hızda kaydıran bir kullanıcı çoğu zaman boş bir kutu görmez. Ancak kullanıcı çok hızlı kaydırırsa ya da bağlantı zayıfsa, görsel bir an geç gelebilir. İşte bu nedenle width ve height değerleri kritik: tarayıcı görsel gelmeden alanı önceden ayırır ve sayfa zıplamaz.

Sahada gördüğüm pratik sonuç şu: native tembel yükleme, eski JavaScript kütüphanelerinin çoğundan daha dengeli çalışıyor. Çünkü tarayıcı ağ koşullarını sizden daha iyi biliyor ve eşiği buna göre ayarlıyor.

Lazy load LCP görselinde neden kullanmamalısınız?

En sık gördüğüm ve en pahalı hata bu. LCP, sayfanın görüş alanındaki en büyük öğenin ekrana çizildiği andır ve çoğu sitede bu öğe hero görselidir. Bu görsele loading="lazy" verdiğinizde tarayıcı onu hemen istemez; önce sayfa düzenini hesaplar, görselin ekranda olduğunu anlar, ancak ondan sonra indirmeye başlar.

Sonuç olarak en önemli görsel, en geç keşfedilen görsellerden biri olur. web.dev'in bu konudaki analizi, WordPress'in tüm görselleri varsayılan olarak tembel yüklediği dönemde, lazy işaretli LCP görseline sahip sayfaların LCP değerlerinin daha kötü çıktığını gösteriyor. WordPress ekibi de ardından ilk görselleri bu davranışın dışında tutacak bir güncelleme yayınladı.

Benim kuralım net: sayfa açıldığında ilk ekranda yer alacak hiçbir görsele lazy vermem. Özellikle hero görseline şunları uygularım:

• loading niteliğini tamamen kaldırırım ya da eager yazarım.
• fetchpriority="high" ekleyerek tarayıcıya önceliğini söylerim.
• Görseli JavaScript ile değil, doğrudan HTML içinde veririm.
• CSS arka planı yerine img etiketi kullanırım ki tarayıcı erken keşfetsin.

Kısacası lazy load, sayfanın aşağısı için bir hız aracıdır; yukarısı için ise bir fren.

Bu hatayı fark etmenin en kolay yolu, mobil görünümde sayfa kaynağını açıp hero görselinin etiketine bakmaktır. Üstelik birçok tema, masaüstü ve mobil için iki ayrı hero görseli kullanıyor; bu yüzden ikisini de ayrı ayrı kontrol etmenizi öneririm.

Hangi görselleri tembel yüklemeli, hangilerini yüklememeli?

Karar vermek için ekranın ilk görünen kısmını, yani kaydırmadan görülen alanı düşünün. Ancak bu alan cihaza göre değişir: masaüstünde ilk ekranda dört ürün kartı görünürken, mobilde yalnızca bir tanesi görünebilir. Bu yüzden ben mobil ve masaüstünü ayrı kontrol ederim.

Pratik bir yöntem önereyim: şablonunuzda bir sayaç tutun ve ilk iki ya da üç görseli eager, sonrasını lazy işaretleyin. Bu kesin bir sayı değil, saha tecrübesine dayalı bir başlangıç noktası; sayfanızın düzenine göre test ederek ayarlamanız gerekir.

Google lazy load içeriği görebiliyor mu?

Evet, doğru kurulduğu sürece görebiliyor. Google, Search Central'daki tembel yükleme yönergelerinde bu konuyu açıkça anlatıyor. Önemli ayrıntı şu: Googlebot sayfayı bir insan gibi aşağı kaydırmaz, tıklamaz ve yazı yazmaz.

Bunun yerine Google, sayfayı işlerken görüş alanını çok uzun bir pencere gibi büyütür. Dolayısıyla içeriğiniz "görüş alanına girince yüklen" mantığıyla çalışıyorsa, Googlebot bu içeriği görür. Ancak içerik "kullanıcı kaydırınca" ya da "butona tıklayınca" gibi bir etkileşime bağlıysa, Googlebot o olayı tetiklemediği için içerik hiç inmez.

Google'ın önerdiği yöntemler şunlar:

• Tarayıcının kendi loading="lazy" özelliğini kullanmak.
• JavaScript gerekiyorsa IntersectionObserver API'sine dayanan bir çözüm seçmek.
• Scroll olayını dinleyen eski kütüphanelerden kaçınmak.
• Sonsuz kaydırmada her içerik parçasına ayrı ve kalıcı bir URL vermek.

Bu yüzden benim ilk sorum her zaman şu olur: içerik yüklenmek için bir kullanıcı hareketi mi bekliyor, yoksa sadece ekrana gelmeyi mi? Birincisiyse SEO açısından risk var demektir.

Lazy load SEO için hangi hatalara yol açabilir?

Tembel yükleme doğru kurulduğunda SEO dostudur. Ancak yanlış kurulduğunda sessiz hasar verir; çünkü sayfa kullanıcıya düzgün görünürken arama motoruna eksik görünebilir. Denetimlerde en sık rastladığım hatalar şunlar:

1. src alanının boş bırakılması: Gerçek adres yalnızca data-src içinde duruyor ve script çalışmazsa görsel hiç yüklenmiyor.
2. Metin içeriğin tembel yüklenmesi: Ürün açıklaması veya yorumlar kaydırma olayına bağlı olduğunda Googlebot bu metni göremeyebiliyor.
3. Noscript yedeğinin olmaması: Eski JavaScript çözümlerinde yedek eklenmediğinde görsel dizine girmiyor.
4. Sonsuz kaydırmanın URL'siz olması: İkinci ve sonraki ürün grupları hiçbir adreste yer almadığı için taranmıyor.
5. LCP görselinin lazy olması: Doğrudan hız sinyallerini bozuyor.

Öte yandan tembel yüklemenin bizzat bir sıralama cezası yoktur. Sorun tekniğin kendisinde değil, yanlış uygulamada. Kısacası "lazy load SEO'ya zarar verir mi?" sorusunun cevabı "yanlış kurarsanız evet" oluyor. Bu hataların çoğunu kapsamlı bir teknik SEO kontrolü sırasında yakalarsınız.

Lazy load CLS sorununa neden olur mu?

Olabilir, ama tembel yüklemenin kendisi yüzünden değil, eksik boyut bilgisi yüzünden. CLS, sayfa yüklenirken öğelerin beklenmedik şekilde kaymasını ölçer. Lazy bir görsel geç geldiğinde, tarayıcı onun ne kadar yer kaplayacağını bilmiyorsa, görsel geldiği anda altındaki metni aşağı iter.

Bu sorunu çözmek oldukça kolay. Her img etiketine gerçek width ve height değerlerini yazarsınız. Modern tarayıcılar bu iki değerden en-boy oranını hesaplar ve görsel gelmeden önce doğru yüksekliği ayırır. Böylece CSS ile görseli esnek genişlikte gösterseniz bile yer tutucu doğru kalır.

Alternatif olarak CSS'teki aspect-ratio özelliğini kullanabilirsiniz. Özellikle farklı oranlarda görsel içeren kart yapılarında bu yöntem işe yarar. Ayrıca iframe gömmelerinde de aynı kural geçerli: video kutusuna sabit bir oran vermezseniz, iframe yüklendiğinde sayfa zıplar.

Sahada şunu çok gördüm: ekip lazy load ekliyor, hız puanı biraz artıyor ama CLS kötüleşiyor. Sonra tembel yüklemeyi suçlayıp kaldırıyorlar. Oysa asıl eksik, şablondaki boyut bilgisiydi. Bu tür kullanıcı deneyimi dengesini SEO ve UX uyumu yazısında daha geniş ele aldım.

iframe ve video gömmelerinde tembel yüklemeyi nasıl uygularsınız?

iframe'ler çoğu zaman görsellerden çok daha ağırdır. Tek bir YouTube gömmesi, kendi scriptlerini, stil dosyalarını ve yazı tiplerini beraberinde getirir. Bu yüzden sayfanın ortasında ya da altında kalan her iframe'e loading="lazy" eklemenizi öneririm. web.dev'in iframe rehberi bu özelliğin iframe'ler için de standart olduğunu anlatıyor.

Daha ileri bir yöntem ise önizleme yaklaşımıdır. Sayfaya gerçek oynatıcı yerine videonun kapak görselini ve bir oynat düğmesi koyarsınız. Kullanıcı tıkladığında sayfa gerçek iframe'i o anda çağırır. Böylece videoyu hiç izlemeyen ziyaretçi, oynatıcının ağır kodlarını hiç indirmez.

Video etiketi için durum biraz farklı. HTML'deki video etiketi loading niteliğini desteklemez. Bunun yerine şu ayarları kullanırım:

• preload="none" veya preload="metadata" ile video dosyasının erken inmesini engellerim.
• Hafif bir poster görseli vererek ilk görünümü sağlarım.
• Otomatik oynayan arka plan videolarını ilk ekranda mümkün olduğunca kullanmam.

Önizleme yaklaşımının SEO tarafında bir bedeli olabilir: video yapısal verisi ve video sayfası sinyalleri için Google'ın videoyu görebilmesi gerekir. Dolayısıyla video sayfanızın ana içeriğiyse, önizleme kullanırken yapısal veriyi ayrıca eklemeyi unutmayın.

JavaScript ile lazy load mı, native lazy load mı?

Bugün çoğu proje için cevabım native çözüm. Tarayıcının kendi özelliği ek kod gerektirmez, ana iş parçacığını meşgul etmez ve Google'ın önerdiği yöntemle doğrudan uyumludur. Ancak bazı durumlarda JavaScript hâlâ gerekli olabilir.

JavaScript'i yalnızca şu durumlarda tercih ederim: CSS arka plan görsellerini ertelemem gerekiyorsa, bileşen tabanlı bir yapıda görünür olunca başka işlemler de tetiklenecekse ya da çok özel bir yükleme mesafesi istiyorsam. Öte yandan scroll olayını dinleyen eski kütüphaneleri artık önermiyorum; hem performansı düşürüyor hem de Googlebot uyumunu riske atıyor.

WordPress ve hazır altyapılarda lazy load ayarını nasıl yaparsınız?

WordPress, 5.5 sürümünden beri görsellere otomatik olarak loading="lazy" ekliyor. Sonraki sürümlerde ise ilk içerik görsellerini bu davranışın dışında tutacak iyileştirmeler geldi. Yani çekirdek WordPress bu işi büyük ölçüde doğru yapıyor.

Sorun genellikle eklenti ve temalarda çıkıyor. Sahada sık gördüğüm tablo şu: çekirdek native lazy load ekliyor, bir hız eklentisi kendi JavaScript tabanlı çözümünü ekliyor, tema da slider için üçüncü bir yöntem kullanıyor. Sonuç olarak aynı görseli üç farklı mantık yönetiyor ve hero görseli yanlışlıkla ertelenebiliyor.

Hazır altyapılarda şu kontrolü öneririm:

1. Sayfa kaynağını açın ve hero görselinin img etiketini bulun.
2. Etikette loading="lazy" veya data-src gibi bir erteleme izi olup olmadığına bakın.
3. Birden fazla lazy load eklentisi ya da ayarı açıksa, yalnızca birini bırakın.
4. Eklentinin "ilk X görseli hariç tut" ayarı varsa, bunu mobil düzene göre belirleyin.

Shopify, Ticimax veya IdeaSoft gibi e-ticaret altyapılarında temaya erişiminiz sınırlı olabilir. Bu durumda tema geliştiricisiyle hero ve ilk ürün kartları için ayrı bir kural konuşmanız gerekir. Bu tür altyapı kararlarında e-ticaret danışmanlığı sürecinde en çok zaman alan konulardan biri de bu oluyor.

Sonsuz kaydırma ve lazy load birlikte nasıl kurmalısınız?

Sonsuz kaydırma, tembel yüklemenin içerik düzeyindeki versiyonudur: kullanıcı aşağı indikçe sayfa yeni ürünleri veya yazıları ekler. Kullanıcı için akıcı bir deneyimdir; ancak arama motoru için ciddi bir risk taşır. Çünkü Googlebot kaydırmadığı için ilk gruptan sonrasını görmeyebilir.

Google'ın yaklaşımı net: her içerik parçasının kendi kalıcı URL'si olmalı. Pratikte bunu şöyle kurarım:

• Arka planda klasik sayfalama tutarım: kategori/sayfa-2, kategori/sayfa-3 gibi.
• Kullanıcı kaydırdıkça yeni grubu yükler ve adres çubuğunu History API ile güncellerim.
• Her sayfalama adresini doğrudan açıldığında da çalışır hale getiririm.
• Sayfalar arasında normal a etiketleriyle bağlantı bırakırım.

Böylece kullanıcı sonsuz kaydırma deneyimini yaşar, Googlebot ise her grubu ayrı bir sayfa olarak tarar. Bu yapı özellikle büyük kataloglarda önem kazanıyor. Üstelik kullanıcı bir ürüne gidip geri döndüğünde kaldığı yerden devam edebildiği için deneyim de iyileşiyor.

Lazy load sorunlarını nasıl test edersiniz?

Test için tek bir araca güvenmem; her araç farklı bir soruyu yanıtlıyor. Kullandığım sıra şu:

1. Lighthouse: LCP görselinde lazy load bulunduğunu söyleyen uyarıyı ve ekran dışındaki görselleri erteleme önerisini kontrol ederim. Ayrıntılı kullanımı Lighthouse performans testi rehberinde anlattım.
2. Search Console URL denetimi: Canlı testi çalıştırıp Google'ın gördüğü HTML'de ve ekran görüntüsünde görsellerin yer alıp almadığına bakarım.
3. Tarayıcı geliştirici araçları: Network sekmesinde sayfayı açar, kaydırmadan önce hangi görsellerin indiğini izlerim.
4. JavaScript kapalı test: Script'leri kapatıp sayfayı açar, temel görsellerin hâlâ göründüğünü doğrularım.

Search Console'daki HTML kontrolü özellikle önemli. Çünkü orada gördüğünüz, Google'ın gerçekten okuduğu içeriktir. Eğer ürün görselleri veya yorum metinleri o HTML'de yoksa, kullanıcıya ne kadar düzgün görünürse görünsün, arama motoru için eksik bir sayfanız var demektir.

Lazy load Google Görseller trafiğini etkiler mi?

Doğru kurulduğunda olumsuz etkilemez. Google, görseli dizine eklemek için onun adresini bulabilmelidir. Native loading="lazy" kullandığınızda src alanında gerçek adres durur; dolayısıyla Google görseli sorunsuz bulur.

Risk, eski JavaScript çözümlerinde ortaya çıkar. Bu çözümler src alanına küçük bir yer tutucu koyar, gerçek adresi ise data-src içinde saklar. Script düzgün çalışırsa sorun yoktur. Ancak script hata verirse veya işleme sırasında tetiklenmezse, Google yalnızca yer tutucuyu görür.

Bu yüzden görsel aramadan trafik alan siteler için şu önlemleri öneririm: src alanında her zaman gerçek adres bulunsun, önemli görselleri görsel site haritasına ekleyin ve alt metinleri açıklayıcı yazın. Ayrıca e-ticaret sitelerinde ürün görsellerinin Google'ın gördüğü HTML'de göründüğünü düzenli olarak kontrol edin. Görsel boyutu ve format tarafı ise ayrı bir konu; bu yazıda o alana girmiyorum, yalnızca doğru ölçüde dosya hazırlamak için resim küçültme aracını kullanabileceğinizi belirteyim.

Lazy load kurarken hangi adımları izlemelisiniz?

Yeni bir projede ya da mevcut bir sitede tembel yüklemeyi düzenlerken izlediğim sıra şu. Bu liste bir garanti değil, sahada tekrar tekrar işe yarayan bir çalışma düzeni:

1. Her şablon türü için (ana sayfa, kategori, ürün, blog) mobilde ilk ekranda görünen görselleri listeleyin.
2. Bu görsellerden lazy işaretini kaldırın; LCP görseline fetchpriority="high" ekleyin.
3. Kalan görsellere ve iframe'lere loading="lazy" verin.
4. Tüm img etiketlerine width ve height değerlerini ekleyin.
5. Birbiriyle çakışan eklenti veya script tabanlı çözümleri temizleyin.
6. Kaydırma veya tıklama olayına bağlı metin içeriği varsa, bunu HTML'de hazır hale getirin.
7. Sonsuz kaydırma varsa sayfalama URL'lerini kurun.
8. Search Console canlı testi ve Lighthouse ile kontrol edin, ardından saha verisini birkaç hafta izleyin.

Bu sırayı önemsiyorum, çünkü en büyük kazanç genellikle ilk iki adımdan geliyor. Öte yandan son adımı atlamayın: laboratuvar testi size yalnızca tek bir cihazdan alınmış bir fotoğraf verir, gerçek kullanıcıların deneyimini ise saha verisi gösterir.

Her adımı ayrı yayına almanızı öneririm. Böylece bir metrikte bozulma görürseniz, hangi değişikliğin neden olduğunu hemen bulursunuz.

Lazy load ile preload arasındaki fark nedir?

Bu iki teknik birbirinin tam tersidir ve sık sık karıştırılıyor. Lazy load bir kaynağı geciktirir; preload ise bir kaynağı öne çeker. Yani biri tarayıcıya "bunu şimdi isteme" derken, diğeri "bunu hemen iste, sonra lazım olacak" der.

Preload'u genellikle tarayıcının geç keşfedeceği kritik kaynaklar için kullanırım. Örneğin CSS içinde tanımlı bir arka plan görseli LCP öğesiyse, tarayıcı onu ancak stil dosyasını okuduktan sonra fark eder. Bu durumda head içine bir preload satırı eklerim. Öte yandan her şeyi preload etmek de bir hatadır; çünkü öne çektiğiniz her dosya, diğer önemli dosyalarla bant genişliği için yarışır.

Kısacası doğru kurgu şu: ilk ekrandaki kritik görseli öne çekin, ekran dışındaki görselleri ise erteleyin. Aynı görsele hem preload hem lazy vermek ise kendi içinde çelişkili bir sinyal olur; denetimlerde bunu da zaman zaman görüyorum.

Mobilde lazy load neden daha çok fark yaratır?

Mobil cihazlarda hem ekran küçük hem de bağlantı çoğu zaman değişkendir. Masaüstünde ilk ekranda dört ürün kartı görürken, telefonda aynı sayfada yalnızca bir kart görürsünüz. Dolayısıyla mobilde ertelenebilecek görsel sayısı çok daha fazladır.

Üstelik mobil ziyaretçi çoğu zaman paket veriyle geziyor. Hiç göremeyeceği bir galeriyi indirmesi, onun için gerçek bir maliyet anlamına geliyor. Bu yüzden ben tembel yükleme kararlarını her zaman önce mobil düzene göre veriyorum, ardından masaüstünü kontrol ediyorum.

Ancak mobilde bir tuzak da var: masaüstüne göre ayarladığınız "ilk üç görsel eager" kuralı, telefonda gereğinden fazla görseli öne çekebilir. Tersi de mümkün: mobilde ilk ekranda duran bir görsel, masaüstü şablonunda aşağıda kaldığı için lazy işaret alabilir. Bu nedenle iki düzeni ayrı ayrı test etmenizi öneririm.

Lazy load ne zaman gerekmez?

Her sayfada tembel yüklemeye ihtiyacınız yok. Tek ekranlık bir iletişim sayfası, birkaç görselden oluşan kısa bir hizmet sayfası ya da içeriğin neredeyse tamamı ilk ekrana sığan bir açılış sayfası düşünün. Bu sayfalarda erteleyecek anlamlı bir kaynak kalmaz; üstelik yanlış işaretleme riski artar.

Ayrıca kullanıcının neredeyse kesin olarak göreceği küçük görseller için kazanç çok düşüktür. Örneğin menüdeki küçük ikonlar ya da hemen ilk kaydırmada görünen bir güven rozeti. Bunları ertelemek, bazen kullanıcıya bir an boş alan göstermekten başka bir işe yaramaz.

Benim yaklaşımım şu: tembel yüklemeyi bir varsayılan kural olarak değil, uzun ve medya yüklü sayfalar için bir araç olarak görün. Kısacası "her yere ekle" değil, "gerektiği yere ekle" demek daha doğru.

Lazy load kararlarını kiminle birlikte vermelisiniz?

Tembel yükleme teknik bir ayar gibi görünse de kararı tek bir kişiye bırakmamanızı öneririm. Tasarımcı hangi görselin ilk ekranda olduğunu bilir, geliştirici şablonu yönetir, SEO tarafı ise Google'ın neyi gördüğünü kontrol eder. Bu üç bakış bir araya gelmediğinde, bir tarafın yaptığı iyileştirme diğer tarafın metriğini bozabiliyor.

Benim çalışma düzenimde tasarım aşamasında her şablon için "ilk ekran" tanımını birlikte yapıyoruz. Ardından geliştirme sırasında bu tanım koda yansıyor. Yayından sonra ise Search Console ve saha verisiyle kontrol ediyoruz. Yeni bir sitede bu düzeni baştan kurmak, sonradan düzeltmekten çok daha ucuz; bu yüzden web tasarım projelerinde konuyu en başta masaya koyuyorum.

Mevcut bir sitede tembel yükleme, sonsuz kaydırma ve dizine ekleme sorunları birlikte görünüyorsa, bunları tek tek değil bir bütün olarak ele almak gerekir. Bu tür durumlarda SEO danışmanlığı kapsamında şablon bazlı bir denetimle başlıyorum. Yapay zekâ destekli aramanın teknik beklentilerini ise yapay zekâ sonrası teknik SEO yazısında ayrıca anlattım.