LCP Görseli: fetchpriority, Preload ve Lazy Load Hataları

Sayfanın en büyük görseli geç geliyorsa, kullanıcı boş bir kapak alanına bakar ve LCP (Largest Contentful Paint) değeriniz bozulur. Çoğu zaman sebep görselin kendisi değil, tarayıcının onu geç keşfetmesi, düşük öncelikle indirmesi ya da kodun yanlışlıkla tembel yüklemeye bırakmasıdır. Kısa cevap: LCP görselini ilk HTML'de bulunur kılın, tembel yüklemeyin, gerekiyorsa fetchpriority="high" ile işaretleyin ve görsel indiğinde ekrana basılmasını engelleyen bir şey olmadığından emin olun.

Bu rehber, kapak ya da ürün görseli yüzünden LCP'si yavaş kalan sayfalarla uğraşan geliştirici, SEO uzmanı ve içerik editörü için hazırlandı. Önce LCP'nin hangi parçalardan oluştuğunu, sonra LCP öğesinin nasıl bulunacağını anlatır. Ardından fetchpriority ve preload'ın ne zaman işe yaradığını, ilk ekranda lazy load kullanmanın neden zarar verdiğini ve yaptığınız değişikliği nasıl doğrulayacağınızı gösterir. Hiçbir ayar belirli bir sıralama sonucu vaat etmez; amaç gerçek ziyaretçilerde daha erken görünen ana içeriktir.

LCP'nin Dört Parçası

LCP tek bir sayı olsa da dört ardışık parçanın toplamıdır. Hangi parçanın şiştiğini görmeden yapılan düzeltme çoğu zaman yanlış yere vurur. web.dev'in LCP optimizasyon rehberi (yeni sekmede açılır) bu ayrımı ve parça başına önerileri verir.

LCP neyi ve hangi eşikle ölçer

web.dev'in LCP makalesine (yeni sekmede açılır) göre metrik, görünür alandaki en büyük görsel, metin bloğu ya da videonun ekrana işlenme zamanını, kullanıcının sayfaya ilk gittiği andan itibaren raporlar. İyi değer 2,5 saniye ve altıdır; 4,0 saniyenin üstü zayıf, arası iyileştirme gerekli sayılır. Değerlendirme, mobil ve masaüstü ayrı olacak şekilde sayfa yüklemelerinin 75. yüzdeliğinde yapılır.

Hangi öğelerin aday olduğunu bilmek önemlidir: img öğeleri, svg içindeki image öğeleri, video öğeleri (poster görseli ya da ilk kare, hangisi önceyse), url() ile verilen arka plan görselleri ve metin düğümü içeren blok seviyesindeki öğeler. CSS gradyanları sayılmaz. Opaklığı sıfır olan öğeler, görünür alanın tamamını kaplayan öğeler ve yer tutucu ya da düşük entropili görseller Chromium sezgilerine göre dışarıda bırakılır.

Parçalar ve ideal paylar

Rehber, toplam LCP'nin dört parçaya bölünerek izlenmesini önerir ve her parçanın yalnızca diğerlerine göre anlam taşıdığını vurgular.

İki gecikme parçasının sıfıra yakın olması hedeflenir. Rehber bu yüzdeleri sabit milisaniye bütçelerine çevirmemeyi de uyarır. Tablodaki oranlar bir tanı aracıdır; sayfanızın kendi dağılımı bu ideale ne kadar uzaksa, o parça o kadar öncelikli olur.

Parçaları birbirinden ayırmak neden önemli

Aynı "yavaş LCP" şikayeti dört farklı sebepten doğabilir ve her birinin sahibi farklıdır. İlk bayt süresi sunucu, önbellek ve yönlendirme tarafıdır. Kaynak yükleme gecikmesi işaretleme ve yükleme önceliğiyle ilgilidir, yani genellikle şablon kodunda çözülür. Kaynak yükleme süresi dosyanın boyutu, biçimi ve dağıtım ağıyla ilgilidir. Öğe işleme gecikmesi ise engelleyen CSS, senkron betikler ve istemci tarafı işlemeyle ilgilidir. Parçaları ayırmadan "görseli küçültelim" demek, iki gecikme parçasını hiç ele almadan tek parçaya yüklenmek demektir. Bu yüzden rapor dilinde de "LCP yavaş" yerine "LCP'nin kaynak yükleme gecikmesi payı yüksek" gibi parça adlı cümleler kurun.

Bir parçayı düzeltmek diğerine kayabilir

Rehberin dikkat çektiği bir tuzak şudur: Bir parçayı iyileştirmek süreyi başka parçaya kaydırabilir. Görseli sıkıştırdınız ama öğe, engelleyen bir stil dosyası yüzünden geç işleniyorsa toplam LCP neredeyse aynı kalır. Bu nedenle her değişiklikten sonra dört parçayı yeniden ölçün.

Örnek senaryo: kapak görselli blog sayfası

Örnek senaryo olarak kapak görseli sayfanın üstünde duran bir blog yazısı düşünelim. Parça dökümünde kaynak yükleme gecikmesinin payı büyük çıkıyor. Bunun anlamı, görselin geç keşfedildiğidir: Belki görsel bir betik tarafından sonradan ekleniyor, belki de yanlışlıkla tembel yükleniyor. Burada görseli küçültmek yerine keşfi öne almak gerekir. Aynı sayfada indirme süresinin payı büyük olsaydı, çözüm dosya boyutu ve biçimi olurdu. Parça adı, çözümün yönünü söyler.

LCP Öğesini Bulma

Düzeltmeden önce gerçekten hangi öğenin LCP olduğunu bilmek gerekir. Tahmin çoğu zaman yanlıştır: Kapak görseli sandığınız şey bir başlık metni, ya da mobilde farklı bir görsel olabilir.

Önce alan verisine, sonra tek sayfaya bakın

Rehber, ilk adım olarak gerçek kullanıcı verisine, yani CrUX'a (PageSpeed Insights ya da Chrome DevTools üzerinden) veya kendi RUM araçlarınıza bakmayı önerir; laboratuvar sonuçları farklı çıkabilir. Ayrıca CrUX verisinin tüm site için değil, incelediğiniz sayfa için olduğunu doğrulamanızı söyler. Yani önce hangi şablonun sorunlu olduğunu belirleyin, sonra tek bir sayfada öğeyi arayın.

Şelale grafiğinde eşleştirme

LCP öğesini belirledikten sonra, rehbere göre onun kaynağını ağ şelalesinde ilk HTML isteğiyle yan yana bulmalısınız. Burada iki şeye bakarsınız: Görsel isteği HTML'den ne kadar sonra başlıyor ve ne kadar sürede bitiyor? Lighthouse ve DevTools parça dökümünü gösterir; özel ölçüm için LCP, Navigation Timing ve Resource Timing API'leri ya da web-vitals kütüphanesinin attribution sürümü kullanılabilir.

Aday zamanla değişir

Tarayıcı, daha büyük bir öğe işlendikçe yeni bir LCP kaydı raporlar. Örneğin sayfa önce bir metin bloğuyla başlar, sonra hero görseli yüklenince aday değişir. İşlenmiş bir öğe sonradan kaldırılsa bile, daha büyüğü gelmedikçe aday olarak kalır. Kullanıcı sayfayla etkileşime girdiğinde raporlama durur. Dolayısıyla "LCP metin" gibi görünen bir sayfada görsel gecikmişse, değer aslında görselin geç gelişiyle belirleniyor olabilir.

Kaynağı HTML'den görülebilir kılmak

Bulduğunuz öğenin görseli, ilk HTML yanıtında bir img etiketiyle yer alıyorsa tarayıcının ön yükleme tarayıcısı (preload scanner) onu erken keşfeder. Rehber, yalnızca harici CSS ya da JavaScript içinde başvurulan görsellerin ve CSS arka plan görsellerinin bu tarayıcı tarafından görülmediğini söyler; bu durumda HTML içinde bir preload (link rel="preload" ya da Link başlığı) gerekir. Kritik kaynakları HTML ile aynı kökenden sunmak da bağlantı yeniden kullanımına yardımcı olur.

LCP öğesi metin olduğunda

Her sayfanın LCP öğesi görsel değildir. Sayfanın en büyük öğesi bir başlık ya da paragraf bloğuysa, görsel optimizasyonu sonucu değiştirmez. Böyle bir durumda öğe işleme gecikmesine, yani web yazı tipinin ve engelleyen CSS'in metni ne zaman gösterdiğine bakın. Rehber, font-display için auto ya da block dışındaki değerleri düşünmenizi önerir, böylece metin yazı tipi yüzünden engellenmez. Yanlış öğeyi optimize etmek, zaman kaybının yanı sıra yanıltıcı bir güven duygusu da üretir.

Kontrol listesi: LCP öğesi bulunurken

• Sorunlu şablon alan verisinden belirlendi mi?
• Mobil ve masaüstü için LCP öğesi ayrı ayrı kontrol edildi mi?
• Öğe img mi, arka plan görseli mi, metin bloğu mu?
• Görsel adresi ilk HTML'de görünüyor mu?
• Görsel isteği şelalede HTML'den hemen sonra mı başlıyor?

fetchpriority ve Preload Ne Zaman İşe Yarar

İkisi sık karıştırılır; oysa farklı problemleri çözerler. Preload, kaynağı keşfedilebilir kılar. fetchpriority ise zaten bilinen bir kaynağın indirme önceliğini değiştirir.

fetchpriority nedir

web.dev'in Fetch Priority makalesi (yeni sekmede açılır) özniteliğin high, low ve auto değerlerini tanımlar; auto varsayılandır ve öncelik kararını tarayıcıya bırakır. Öznitelik link, img ve script etiketlerinde çalışır. Betikle yapılan isteklerde Fetch API'sinde priority özelliği kullanılır. Sayfa bunu bir "ipucu, emir değil" olarak tanımlar: Tarayıcı kendi öncelik tercihlerini uygulayabilir. Öncelik ayarı en çok kaynaklar bant genişliği için yarıştığında fark yaratır.

Tarayıcı desteği için sayfadaki liste Chrome 102, Edge 102, Firefox 132 ve Safari 17.2 sürümlerini gösterir. Eski sürümler özniteliği yok sayar; bu zararsızdır ama kazanç da olmaz.

Hangi görsele yüksek öncelik verilir

LCP rehberi, fetchpriority="high" değerini muhtemel LCP görseline vermeyi, ama bunu yalnızca bir ya da iki görselle sınırlamayı önerir. Her şeyi yüksek işaretlemek önceliği anlamsızlaştırır. Fetch Priority makalesindeki örneklerden biri, LCP görseline yüksek öncelik verilen Google Flights'ın LCP'sinin 2,6 saniyeden 1,9 saniyeye inmesidir. Bu, bir vaka bildirimidir; sizin sayfanızda aynı kazancı garanti etmez.

Düşük öncelik de aynı derecede kullanışlıdır. Rehber, görünmeyen içerik için, örneğin ekran dışındaki kaydırıcı slaytları için fetchpriority="low" önerir. Makale, bir döngüdeki ilk görünür görsele high, diğerlerine low vermeyi örnekler ve ekran dışı görsellerin, loading="lazy" eklenmiş olsa bile yüksek önceliğe çıkabildiğini not eder.

Preload ne zaman gerekir

Preload zorunlu bir getirmedir ve keşfi iyileştirir. Görsel ilk HTML'de bir img etiketiyle zaten görünüyorsa tarayıcı onu kendi bulur; ek preload gereksizdir. Responsive görsel preload sayfasının uyarısı da aynıdır: Görsel işaretlemede kolay bulunuyorsa, onu preload ile işaretlemek yerine ön yükleme tarayıcısının keşfetmesine bırakın.

Preload ise görsel yalnızca CSS arka planında, harici CSS içinde ya da JavaScript ile ekleniyorsa devreye girer. Fetch Priority makalesi, arka plan görseli LCP öğesi olduğunda preload'a da fetchpriority="high" eklemeyi söyler. Görsel preload'ları varsayılan olarak düşük öncelikle çalıştığı için, bu öznitelik olmadan etkisi sınırlı kalabilir.

Arka plan görselinden img etiketine geçmek

Preload, arka plan görselleri için bir kurtarma yoludur; kalıcı çözüm çoğu zaman görseli anlamlı içerik olarak bir img etiketiyle vermektir. Böylece ön yükleme tarayıcısı görseli kendiliğinden bulur, srcset ve sizes ile cihaza uygun boyut seçilir, alt metin erişilebilirlik ve görsel arama için yer bulur ve width ile height öznitelikleri düzen kaymasını önler. Arka plan görseli yalnızca gerçekten süsleyici olduğunda mantıklıdır. Kapak, ürün ve haber görselleri gibi sayfanın asıl içeriği olan görseller için img daha doğru araçtır. Bu geçiş yapılabiliyorsa fetchpriority="high" ile birlikte çoğu durumda ayrıca preload yazmaya gerek kalmaz.

Bant genişliği rekabeti ve düşük öncelik

Fetch Priority makalesi, önceliklendirmenin en çok kaynaklar bant genişliği için yarıştığında önemli olduğunu belirtir. Bu yüzden iyileştirme yalnızca LCP görseline yüksek öncelik vermekten ibaret değildir; LCP ile yarışan, ilk görünümde gerekmeyen kaynakların önceliğini düşürmek de aynı sonuca götürür. Sayfa bu amaçla, kritik olmayan bir betiği preload edip fetchpriority="low" vermeyi örnekler. Arka plan veri çağrıları için fetch() içinde priority: 'low' kullanılabilir. Async ve defer betikler zaten düşük öncelikle gelir; render için önemsiz geç betikler low alsa da ayrıştırıcıyı yine de engelleyebilir, bu yüzden low değeri bir engelleme çözümü değildir.

Responsive görseller için doğru biçim

Düz href'li bir preload, tek bir dosyayı çeker; görünüm alanı ne olursa olsun bu dosya iner. Yanlış boyutlu görselin indirilmesi, gerçek img'in başka bir kaynak seçmesi ve ikisinin birden inmesi ihtimalini doğurur. web.dev'in responsive görselleri preload etme (yeni sekmede açılır) sayfası bunun çözümünü verir: link etiketine imagesrcset ve imagesizes eklemek. Bu öznitelikler img üzerindeki srcset ve sizes ile aynı seçim mantığını çalıştırır.

Sayfanın diğer uyarıları şunlardır. picture öğesinin karşılığı yoktur; kaynaklar sırayla denetlenir ve ilk eşleşen kazanır, oysa preload'lar sırasızdır, bu yüzden kırılma noktalarını çakışmayan media aralıklarına çevirip her biri için ayrı preload gerekir. Tür için yalnızca en çok tercih edilen biçim preload edilmelidir, çünkü birden çok türe özel preload'ın hepsi iner. Responsive preload'lar HTTP Link başlığında çalışmayabilir ve 103 Early Hints'te kullanılamaz; link öğeleri tercih edilir. Geç gelen bir viewport meta etiketi yanlış görselin indirilmesine yol açabilir.

Karar kuralı

Lazy Load İlk Ekranda Neden Zarar Verir

Tembel yükleme ekran altı görseller için yararlı bir araçtır. İlk ekrandaki görselde ise tersine döner.

Neden geciktirir

loading="lazy", görseli görünür alana yaklaşana kadar ertelemek demektir. İlk ekrandaki bir görsel için bu, tarayıcının yerleşimi tamamlayıp görselin görünür alanda olduğunu anlamasını beklemesi anlamına gelir. LCP rehberi bunu açık söyler: LCP görselini asla tembel yüklemeyin; ayrıca sık yapılan hatalar bölümünde tembel yüklenen LCP görselinin LCP'yi güvenilir biçimde kötüleştirdiğini belirtir. web.dev'in tarayıcı düzeyinde görsel tembel yükleme (yeni sekmede açılır) makalesi de aynı çizgidedir: Sayfa yüklenirken görünür alanda olması muhtemel görselleri, özellikle LCP görselini tembel yüklemeyin; loading=lazy yalnızca ilk görünür alanın dışındaki görseller için kullanılmalıdır.

Eager, tarayıcının varsayılan davranışıdır ve özniteliği hiç yazmamakla aynıdır. Yani düzeltme için eager yazmak şart değildir; lazy'yi kaldırmak yeterlidir.

Hatalar nereden gelir

Tembel yükleme genellikle bilinçli bir kararla değil, bir şablon, tema ya da eklenti varsayılanı olarak gelir. "Bütün görsellere lazy ekle" kuralı olan bir bileşen, hero görselini de kapsar. Sık görülen kaynaklar şunlardır: tema ya da eklenti ayarı, görsel bileşeninin tüm img'lere lazy eklemesi, içerik editörünün kapak görselini sonradan içeriğe gömmesi ve JavaScript tabanlı tembel yükleme kütüphanelerinin src yerine data-src kullanması. Son durumda görsel adresi ilk HTML'de bile bulunmaz ve keşif tamamen betiğe bağlı kalır. Tembel yükleme ile ilişkili daha geniş sorular için lazy loading ve SEO yazısına göz atın.

Ekran altı görselde doğru kullanım

Tembel yükleme ekran altı için doğru araçtır. Tarayıcı ekran dışındaki görselleri erken, ama yakınlık eşiğine göre getirir. Makaleye göre Chrome, 4G için eşiği 3000 pikselden 1250 piksele, daha yavaş bağlantılar için 4000'den 2500 piksele indirmiştir ve bu değerler API üzerinden değiştirilemez. Kısacası ekran dışı görseller kaydırmaya yakın bir noktada gelir; LCP görseli ise bu mantığa sokulmamalıdır.

Tembel yüklenen görsellerde de width ve height öznitelikleri yazılmalıdır. Makale, bunun tembel yüklemeden bağımsız bir en iyi uygulama olduğunu, boyutsuz görsellerin 0x0 piksel varsayıldığında düzen kaymasına yol açabileceğini söyler. İlk ekran görselinin kapladığı yeri baştan ayırmak, içerik kaymasını da önler. Görsel dosyalarının SEO tarafı için görsel SEO yazısı ayrı bir kaynaktır.

Örnek senaryo: tema varsayılanı yüzünden gecikmiş kapak

Örnek senaryo olarak bir yayıncı sitesinin blog şablonunu ele alalım. Tema, içerikteki tüm görsellere otomatik olarak loading="lazy" ekliyor ve kapak görseli de bu kapsamda. Alan verisinde blog grubu LCP'de zayıf, parça dökümünde ise kaynak yükleme gecikmesi öne çıkıyor. Yapılacak iş, kapak görseli için lazy'yi kaldırmak ve muhtemel LCP görseline fetchpriority="high" vermek. Ekran altındaki görsellerde lazy kalır. Değişiklik şablon düzeyinde yapıldığı için tüm blog yazıları etkilenir; dolayısıyla doğrulamayı tek bir yazıyla sınırlamayın, birkaç farklı uzunlukta yazı deneyin.

Hızlı denetim listesi

• İlk ekrandaki görsellerde loading="lazy" yok.
• LCP görseli betik ile değil, HTML'de img etiketiyle veriliyor.
• Ekran altı görsellerde loading="lazy", width ve height var.
• Kaydırıcıda yalnızca ilk görünür görsel yüksek öncelikli.
• Görsel src yerine data-src ile yalnızca betikle çözülmüyor.

Doğrulama

Değişiklik tek başına bir iyileştirme değildir; sonuç ölçülerek doğrulanır. Burada yine alan verisi karar verir, laboratuvar ise nedenini gösterir.

Önce ve sonra karşılaştırması

Değişiklikten önce LCP öğesini, dört parça dökümünü ve şelaledeki görsel isteğinin başlangıç zamanını kaydedin. Sonra aynı koşullarda tekrarlayın. Beklenen işaretler şunlardır: Kaynak yükleme gecikmesi payı küçülür, görsel isteği HTML'den hemen sonra başlar. Değişmediyse sorun başka bir parçadadır. Örneğin gecikme düştü ama toplam aynı kaldıysa, süre başka parçaya kaymış demektir.

Rehbere göre LCP için TTFB de parçalardan biridir; yönlendirmeler, CDN önbelleğini engelleyen sorgu parametreleri ve sunucu yanıt süresi her sonraki parçayı geciktirir. Sunucu tarafı için TTFB, önbellek ve CDN yazısına bakabilirsiniz. Genel çerçeve içinse sayfa hızı ve Core Web Vitals rehberi uygundur.

Öğe işleme gecikmesi için ek kontroller

Görsel erken indi ama hâlâ geç görünüyorsa, öğe işleme gecikmesine bakın. Rehberin önerileri: Engelleyen CSS'i azaltın ya da küçükse satır içi verin, head içindeki eşzamanlı betiklerden kaçının, içeriğin istemci tarafı JavaScript'i beklememesi için sunucu tarafı işleme ya da ön işleme kullanın ve ana iş parçacığındaki uzun görevleri bölün. İstemci tarafı işleme genellikle FCP ile LCP arasında büyük boşluklar bırakır.

İndirme süresi için ek kontroller

İndirme süresi büyükse dosyayı küçültün: doğru boyut, modern biçimler ve sıkıştırma. Gerekirse CDN ya da görsel CDN kullanın, ama üçüncü taraf alan adlarının ek bağlantı maliyetini unutmayın. Aynı anda yüksek öncelikli başka istekler bant genişliği için yarışıyorsa, onları da azaltın.

Belirtiden nedene hızlı tablo

Tablo bir başlangıç noktasıdır; her satır için gerçek kanıtı şelaleden ve parça dökümünden almalısınız. Aynı sayfada birden çok belirti birlikte görülebilir ve düzeltmeleri sırayla uygulamak, hangisinin işe yaradığını görmenizi sağlar.

Raporlama ve sınırlar

Rapora hangi şablonun, hangi görselin, hangi değişiklikle ve hangi tarihte değiştiğini yazın. Alan verisi gecikmeli güncellendiği için sonucu hemen beklemeyin. Lighthouse ve CrUX uyuşmayabilir; rehber bu durumda alan verisini tercih etmeyi söyler. Bu rehberin hiçbir adımı sıralama garantisi vermez; ölçülebilir kazanç, ziyaretçinin ana görseli daha erken görmesidir.

Son olarak, bir şablonda yapılan düzeltmenin diğer şablonlara kendiliğinden yayılmadığını unutmayın. Ürün detay, kategori ve blog sayfalarının LCP öğesi farklıdır; her şablon için LCP öğesini ayrı ayrı doğrulayın.

Sık Sorulan Sorular

LCP görselini nasıl anlarım?

Önce alan verisinde sorunlu sayfa grubunu belirleyin, sonra Lighthouse ya da Chrome DevTools'ta LCP öğesini ve parça dökümünü açın. Öğeyi ağ şelalesinde ilk HTML isteğiyle birlikte inceleyin. Mobil ve masaüstü için LCP öğesi farklı olabilir, ikisini ayrı kontrol edin.

fetchpriority="high" her görsele eklenmeli mi?

Hayır. web.dev yalnızca muhtemel LCP görseline ve en çok bir ya da iki görsele vermeyi önerir. Özellik bir ipucudur; tarayıcı kendi öncelik tercihlerini uygulayabilir. Ekran dışı görseller için fetchpriority="low" daha uygundur.

Preload ile fetchpriority arasındaki fark nedir?

Preload, kaynağın erken keşfedilmesini sağlayan zorunlu bir getirmedir. fetchpriority ise zaten keşfedilen kaynağın indirme önceliğini değiştirir. Görsel ilk HTML'de img ile varsa genellikle fetchpriority yeterlidir; CSS arka planı ya da betikle eklenen görsel için preload gerekir.

Responsive görseli preload etmek için ne yapmalıyım?

link etiketine as="image" ile birlikte imagesrcset ve imagesizes ekleyin, img üzerindeki srcset ve sizes ile aynı değerleri verin ve fetchpriority="high" kullanın. Düz href tek bir dosyayı çeker ve yanlış boyutun inmesine yol açabilir. picture için kırılma noktalarını çakışmayan media aralıklarına çevirmek gerekir.

İlk ekrandaki görsele loading="lazy" vermek neden zararlı?

Tarayıcıyı görseli görünür alana yaklaşana kadar beklemeye sokar ve LCP'yi güvenilir biçimde geciktirir. web.dev ilk ekranda görünmesi muhtemel görselleri, özellikle LCP görselini tembel yüklememeyi söyler. Eager varsayılan davranıştır, lazy'yi kaldırmak yeterlidir.

Değişiklikten sonra sonucu nasıl doğrularım?

LCP öğesini, dört parçanın dökümünü ve görsel isteğinin şelaledeki başlangıcını önce ve sonra kaydedin. Laboratuvar nedeni gösterir, karar alan verisinde verilir. Alan verisi gecikmeli güncellendiği için tarihli bir değişiklik kaydı tutun.

Sonuç

LCP görseli yavaşsa önce hangi parçanın şiştiğine bakın: keşif, indirme, işleme ya da sunucu yanıtı. Görseli ilk HTML'de bulunur kılın, gerekirse fetchpriority="high" verin, CSS ya da betikle gelen görsellerde preload kullanın, ilk ekranda asla lazy kullanmayın ve değişikliği önce-sonra ölçümüyle doğrulayın. Hiçbir adım belirli bir sıralama sonucu garanti etmez; ölçülebilir kazanç ana içeriğin ziyaretçide daha erken görünmesidir.

Teknik rehberler, ürün sayfası anlatımları ya da kapak görseliyle birlikte düzenli içerik gerekiyorsa Akua Adforce'taki makale yazımı hizmetine bakabilirsiniz; kapsam ve şartlar ürün sayfasında listelenir.