preload etiketi eklendi ama LCP skoru değişmedi; yanlış as değeri, URL uyuşmazlığı, lazy load çelişkisi, eksik crossorigin ve responsive görsel yapısıyla uyumsuzluk gibi somut hata noktalarını tanılayan rehber.

LCP Görseli Preload Edildi Ama Skor Düşmedi: Nerede Hata Var?

Preload etiketi sayfanın <head> bölümüne eklendi, tarayıcı görsel kaynağı daha erken keşfediyor; ama bir sonraki PageSpeed Insights ölçümünde LCP skoru olduğu yerde duruyor. Bu durumla karşılaşanların büyük çoğunluğu, preload satırını doğru yazdığını düşünmektedir. Sorun genellikle tek bir nitelikte, URL eşleşmesinde ya da görselin öncelik zincirinin başka bir noktasında gizlidir.

Preload mekanizması, tarayıcının HTML'i ayrıştırırken henüz keşfedemeyeceği kaynakları önceden talep etmesini sağlar. LCP görseli çoğu durumda bir <img> etiketinin içinde bulunduğu için tarayıcı onu zaten ayrıştırma sırasında görecektir; gecikme, o keşfin ne kadar geç geldiğindedir. Preload bu süreyi kısaltmak için kullanılır, ancak küçük bir yazım hatası veya yapısal bir çelişki etiketi işlevsiz bırakır. Hata mesajı gelmez, konsol sessiz kalır, görsel yine de ekrana gelir - yalnızca preload hiçbir şeyi değiştirmemiş olur.

En sık hata noktaları sırayla elenir: yanlış as değeri, URL uyuşmazlığı, lazy load çelişkisi, eksik crossorigin ve srcset uyumsuzluğu. LCP öğesi henüz kesinleşmediyse oradan başlamak bu adımları daha verimli kılar; yanlış görseli preload etmek de aynı sonucu verir: skor değişmez.

as değeri eksik ya da yanlış yazılmış

Preload etiketinin en kritik niteliği as'tır. Tarayıcı bu değeri görsel için as="image" olarak bekler; eksik bırakıldığında ya da geçersiz bir değerle yazıldığında bazı tarayıcılar preload talebini başlatmaz, bazıları ise onu düşük öncelikli arka plan isteği olarak sıraya alır. Hata mesajı üretilmez. Ağ isteği sıradan bir yükleme gibi görünür.

Yaygın hatalı yazımlar şunlardır: as="img", as="picture", as="png", as="webp". Bunların tamamı geçersizdir. Doğru form her zaman as="image" şeklindedir; dosya uzantısından bağımsız olarak geçerlidir.

<!-- Hatalı -->
<link rel="preload" href="/hero.webp" as="img">

<!-- Doğru -->
<link rel="preload" href="/hero.webp" as="image" fetchpriority="high">

Chrome DevTools'un Network sekmesinde ilgili isteği bulup Priority sütununa bakın. Görsel için bu değer High olmalıdır. Düşük öncelikli görünüyorsa büyük olasılıkla as niteliği eksik ya da hatalıdır. Kontrol kolaydır, ama gözden kaçması da o kadar kolaydır.

Preload URL'si ile sayfanın yüklediği URL uyuşmuyor

URL eşleşmemesi en sık görülen hatalardan biridir ve hiç hata üretmez. Tarayıcı hem preload URL'si için hem de <img src> için ayrı birer istek başlatır; önbelleğe alınan preload isteği kullanılmaz, LCP görseli ikinci bir tam yükleme süresiyle gelir.

Bu tutarsızlık birkaç farklı biçimde ortaya çıkar. Birincisi, görsel bir CDN aracılığıyla sunuluyor ve URL farklıdır: preload /images/hero.jpg olarak yazılmış, sayfa ise https://cdn.sitem.com/images/hero.jpg?w=800&q=85 talep ediyordur. İkincisi, sunucu tarafı yeniden yazma kuralları görsel URL'yi dönüştürüyordur. Üçüncüsü, bazı CMS eklentileri görseli kayıt sırasındaki yoldan farklı bir yola taşır ya da yeniden adlandırır; preload etiketi güncellenmeden kalır.

Doğrulama için DevTools'un Network sekmesini açın, görsel dosya adıyla filtreleyin. İki satır görünüyorsa - biri Initiator sütununda preload, biri img veya parser - URL'ler uyuşmuyordur. Preload etiketi içindeki URL'yi, tarayıcının gerçekte yüklediği URL ile birebir eşleştirin; sorgu parametreleri dahil. Tek karakterlik fark bile önbellek eşleşmesini engeller.

loading="lazy" ile preload arasındaki çelişki

Preload ve lazy load birbirinin tersini yapar. Preload görsel için yüksek öncelikli erken bir istek başlatır; loading="lazy" ise tarayıcıya görseli görünüm alanına yaklaşana kadar ertelemesini söyler. İkisi aynı görsele uygulandığında çoğu tarayıcı lazy davranışını önceliklendirerek preload'u işlevsiz kılar ya da gereksiz ikili istek başlatır.

Dikkat. LCP görseli her zaman loading="eager" ya da bu nitelik hiç yazılmamış olmalıdır; çünkü varsayılan değer zaten eager'dır. Sayfada genel olarak lazy loading uygulayan bir JavaScript parçacığı veya eklenti varsa, o parçacığın LCP görselini de kapsamaması gerekir.

JavaScript tabanlı lazy loader'lar özellikle risklidir: bazen görselin src niteliğini başlangıçta boş bırakıp, görünüm alanına yaklaşınca doldurur. Bu durumda preload isteği gerçek yüklemeyle hiçbir zaman eşleşmez; tarayıcı önbelleğe aldığı kaynağı atıp sıfırdan yükler. Performans sorunlarını kökerine inerken bu tür yapısal çelişkileri gözden kaçırmak kolaydır.

fetchpriority niteliği ve öncelik farkı

Preload etiketi kaynağı erken keşfettirir, ama tarayıcı birden fazla kaynağı aynı anda keşfettiğinde aralarında öncelik sıralaması yapar. 2022'den itibaren yaygınlaşan fetchpriority="high" niteliği, hem preload etiketine hem de doğrudan <img> etiketine eklenebilir; tarayıcıya bu kaynağın diğerlerinin önünde yüklenmesi gerektiğini açıkça bildirir.

Preload tek başına yeterli olmayabilir. Özellikle karmaşık sayfa yapılarında, birden fazla yüksek öncelikli kaynak aynı anda keşfedildiğinde tarayıcı kendi heuristiklerini kullanır. İkisinin birlikte çalışan hali şu şekildedir:

<link rel="preload" href="/hero.webp" as="image" fetchpriority="high">
...
<img src="/hero.webp" fetchpriority="high" alt="...">

Eski tarayıcılar bu niteliği yok sayar; yeni tarayıcılarda ise öncelik sıralamasını doğrudan etkiler. Özellikle above-the-fold alanda hero görseli, banner veya ürün fotoğrafı gibi LCP adayı öğeler için bu iki niteliği birlikte kullanmak standart pratik haline gelmiştir.

Çapraz kaynak görsel ve eksik crossorigin niteliği

Görsel farklı bir alan adından - CDN, resim sunucusu veya üçüncü taraf depolama - geliyorsa ve CORS başlıkları mevcutsa, preload etiketine crossorigin niteliği eklenmesi gerekir. Bu nitelik eksik bırakıldığında tarayıcı preload isteğini anonim modda başlatır; asıl yükleme isteği CORS modunda geldiğinde önbellek eşleşmesi sağlanamaz ve ikinci bir tam istek tetiklenir.

Görsel aynı alan adından sunuluyorsa crossorigin niteliğine gerek yoktur. Ancak CDN kullanan sitelerde, hatta bazı alt alan adı yapılandırmalarında bu sorunla karşılaşılır. Kontrol için DevTools Network sekmesinde görselin isteğini seçip Request Headers altındaki Sec-Fetch-Mode değerine bakın. CORS isteği varsa preload etiketine de crossorigin="anonymous" ekleyin.

<link rel="preload" href="https://cdn.sitem.com/hero.webp"
  as="image"
  crossorigin="anonymous"
  fetchpriority="high">

Responsive görsel ve srcset ile preload uyuşmazlığı

Sayfa bir <picture> öğesi ya da srcset niteliğiyle farklı ekran boyutlarına farklı görsel dosyaları sunuyorsa, preload etiketi yalnızca tek bir URL'yi tanımlayamaz. Masaüstünde 1200 piksel genişliğindeki görsel yüklenirken, mobil cihazda 400 piksel görseli yükleniyor olabilir. Preload sabit bir URL ile yazılmışsa yalnızca biri için çalışır, diğerinde boşa gider.

Bu durumu çözmek için preload etiketinde imagesrcset ve imagesizes nitelikleri kullanılır:

<link rel="preload" as="image"
  imagesrcset="/hero-400.webp 400w, /hero-800.webp 800w, /hero-1200.webp 1200w"
  imagesizes="(max-width: 600px) 400px, (max-width: 1000px) 800px, 1200px"
  fetchpriority="high">

Bu nitelikler olmadan sabit URL preload yapıldığında tarayıcı yine de doğru görseli yükler - ancak preload başka bir dosya için yapıldığından önbellek eşleşmesi sağlanamaz. Sonuç, preload hiç yapılmamış gibidir. Sayfa mobil ağırlıklı trafik alıyorsa bu durum özellikle ciddi bir etki yaratır; masaüstü için doğru yapılandırılmış preload, mobil LCP'yi hiç iyileştirmez.

Chrome DevTools ile preload kullanımını doğrulamak

Preload eklendiğini sanmak ile tarayıcının onu gerçekten kullandığını görmek farklı şeylerdir. İşte farkı ortaya çıkaran adımlar:

Network sekmesini açın, sayfayı sıfırdan yenileyin. Sol üstteki filtre kutusuna görselin dosya adını yazın. İki ayrı satır görünüyorsa - biri Initiator sütununda preload, biri img ya da parser - preload talebi kullanılmamış, ikinci bir tam yükleme gerçekleşmiş demektir. Tek satır görünüyorsa ve başlatıcı preload ise her şey beklendiği gibi çalışmaktadır.

Lighthouse raporundaki "Preload Largest Contentful Paint image" uyarısına dikkat edin, ama ona körü körüne güvenmeyin. Bu uyarı preload yapılmamış durumu işaret eder; preload yapılmış ama yanlış uygulanmış durumu her zaman yakalamaz. Lighthouse uyarısının kalkmış olması, preload'un doğru çalıştığı anlamına gelmez. Network sekmesiyle elle doğrulama zorunludur.

Render zincirinde başka engeller de aranmalıdır. Preload doğru uygulanmış olsa bile head bölümündeki render-blocking CSS ya da script'ler, LCP görselinin ekranda belirme zamanını erteleyebilir. Bu durumda preload çalışmıyor değildir; fakat önce engeli kaldırmak gerekir.

Preload değişikliğinin etkisini izole etmek

Değişikliği test ederken karşılaştırma koşullarını tutarlı tutmak önemlidir. Aynı sayfayı aynı koşullarda önce preload olmadan, ardından preload ile test edin. Birden fazla değişikliği aynı anda yaptıysanız preload'un etkisini diğer değişikliklerden ayırt etmek güçleşir; hangi müdahalenin ne kadar katkı sağladığı görünmez hale gelir.

LCP süresinde belirgin bir iyileşme görmüyorsanız ama DevTools doğrulaması preload'un doğru çalıştığını söylüyorsa, darboğaz başka yerdedir. TTFB yüksekse preload yardım edemez; sunucu görüntüyü zaten geç gönderiyordur. Görselin kendisi büyükse indirme süresi baskın olur. Preload yalnızca keşif gecikmesini ortadan kaldırır; başka gecikme kaynaklarına dokunmaz.

Lab skoru iyileşse bile gerçek kullanıcı verisi buna paralel hareket etmesi zaman alır. Alan verisi (field data) binlerce ziyaretten derlenir; bir değişikliğin CrUX raporuna yansıması haftalarca sürebilir. Düzenli ölçüm takibi bu gecikmeli etkiyi görünür kılar ve yanıltıcı "hiç işe yaramadı" sonucunu önler.

Preload'un işe yaramamasının neredeyse her zaman somut bir teknik nedeni vardır: yanlış as değeri, URL tutarsızlığı, lazy load çelişkisi, eksik crossorigin, fetchpriority eksikliği ya da responsive görsel yapısıyla uyumsuzluk. Bu noktaların her birini sırayla eleme yöntemiyle kontrol etmek, çözümü tahmin etmeye çalışmaktan çok daha hızlı sonuç verir.

Tanılama sürecini yapılandırmak için DevTools Network sekmesi ve öncelik sütunu birincil araç olarak kullanılabilir. Hangi kaynak ne zaman yükleniyor, hangi başlatıcı nereden geliyor - bu sorular yanıtlandıktan sonra preload'un çalışıp çalışmadığı belirsizlikten çıkar ve ölçülebilir bir duruma gelir.