Blog details
Sayfa hızlı sanılır, ama LCP hâlâ kırmızı kalır. Sorun çoğu zaman sunucu değil, tarayıcının önemli dosyayı geç fark etmesidir.
İşte preload ve preconnect burada fark yaratır. Biri kritik kaynağı erkenden indirtir, diğeri dış kaynağın bağlantısını önceden hazırlar. Doğru yerde kullanınca ilk ekran hızlanır, yanlış yerde kullanınca ağ sırası karışır. Önce tarayıcının öncelik mantığını netleştirelim.
Tarayıcı öncelikleri ve Core Web Vitals ilişkisi
Tarayıcı HTML’yi okurken bütün istekleri aynı anda başlatmaz. Önce neyin sayfayı boyamak için gerekli olduğuna bakar. CSS genelde üst sıraya çıkar. Görseller, script’ler ve fontlar ise görünürlüğüne ve keşif zamanına göre sıralanır.
Bu yüzden aynı sunucuda duran iki dosya bile farklı anda indirilmeye başlar. Hero görseliniz CSS arka planında duruyorsa, tarayıcı onu HTML’de duran normal bir img kadar erken göremez. Font dosyası dış origin’den geliyorsa, bağlantı kurulana kadar da ek gecikme oluşur.
2026’da iyi kabul edilen eşikler değişmedi. LCP için 2.5 saniye altı, INP için 200 ms altı ve CLS için 0.1 altı hedefleniyor. Kısa bir çerçeve için 2026 Core Web Vitals eşikleri iyi bir referans olur.
Preload ve preconnect, resource hints ailesinin en işe yarayan iki üyesidir. preload, kaynağı erken keşfettirir. preconnect, DNS, TCP ve TLS adımlarını öne çeker. Mobil ağda bu fark bazen yüzlerce milisaniyeye çıkar.
Buradaki kritik ayrım şu: preload tarayıcıya “buna erken bak” der. Preconnect ise “bu origin’e bağlanmaya hazır ol” der. Tarayıcı yine kendi öncelik sistemini kullanır. Yani bu etiketler her şeyi zorla değiştirmez, sadece doğru kararı daha erken almasını sağlar.
2026 yaklaşımında fetchpriority de önemli. Preload bir görseli erken buldurur. fetchpriority="high" ise LCP adayı olan görselin diğer görseller arasında öne çıkmasına yardım eder. Bu yüzden hero görselinde ikisini birlikte görmek artık daha yaygın.
INP tarafında etki daha sınırlıdır. Preload ve preconnect doğrudan etkileşim gecikmesini çözmez. Ancak ana iş parçacığı üzerindeki baskıyı dolaylı azaltırsa katkı sağlar. Sorun büyük bundle, ağır hydration veya geç oluşan DOM ise modern CMS yapılarında performans optimizasyonu da en az ağ ipuçları kadar önemlidir.
Preload hangi durumlarda gerçek kazanç sağlar?
Preload en çok, kritik kaynak geç keşfediliyorsa işe yarar. İlk ekranı oluşturan dosya ne kadar geç görünürse LCP o kadar uzar. Bu yüzden preload her dosya için değil, ilk boyamayı kuran az sayıdaki dosya için güçlüdür.
Gerçek kullanımda en sık kazanç şu senaryolarda çıkar:
- Hero görseli geç keşfediliyorsa:
<link rel="preload" href="/img/hero.avif" as="image"> - Responsive hero kullanıyorsanız:
<link rel="preload" as="image" href="/img/hero-1280.avif" imagesrcset="/img/hero-640.avif 640w, /img/hero-1280.avif 1280w" imagesizes="100vw"> - İlk ekrandaki font gecikiyorsa:
<link rel="preload" href="/fonts/inter-var.woff2" as="font" type="font/woff2" crossorigin> - Kritik CSS ayrı dosyadaysa:
<link rel="preload" href="/css/critical.css" as="style"> - Kritik başlangıç script’i erkene alınacaksa:
<link rel="preload" href="/js/app-critical.js" as="script">
Hero görseli için tek başına preload bazen yetmez. Aynı görseli img etiketi üzerinde fetchpriority="high" ile işaretlemek iyi sonuç verir. Örnek kullanım şöyledir: <img src="/img/hero.avif" fetchpriority="high" alt="">. Eğer LCP görseli CSS arka planındaysa preload daha da değerli olur, çünkü tarayıcı o kaynağı CSS çözülmeden göremez.
Font tarafında kazanç iki yönlüdür. Metin daha erken boyanır. Ayrıca geç font değişimi azaldığı için CLS de düşebilir. Ama yanlış fontu preload etmek pahalıdır. İlk ekranda hiç görünmeyen ikinci ya da üçüncü font ailesini öne çekmek, önemli isteklerin önünü tıkar.
CSS ve JS için küçük ama önemli bir ayrıntı var. Preload dosyayı erken indirir, fakat dosyayı uygulamaz ya da çalıştırmaz. Yani critical.css için preload eklediyseniz, normal stylesheet etiketi de durmalıdır. Script tarafında da aynı mantık geçerlidir. ES module kullanan projelerde çoğu zaman modulepreload daha iyi oturur, çünkü bağımlılık zincirini de erken başlatır.
preload, doğru kaynağı erkene çeker. Yanlış kaynağı erkene çekerse LCP iyileşmez, bazen daha da kötüleşir.
Bu yüzden basit bir sınır koymak iyi çalışır. Aynı sayfada bir veya iki kritik kaynaktan fazlasını preload etmeyin. İlk aday genelde LCP görselidir. İkinci aday ise ilk ekrandaki tek font ya da kritik CSS olur. Yayına çıkmadan önce 2026 optimizasyon rehberi gibi güncel kontrol listeleriyle seçiminizi doğrulamak da iyi fikir verir.
Preconnect’i üçüncü taraf origin’lerde ölçerek kullanın
Preconnect daha dar kapsamlı ama temiz bir araçtır. Dış origin’den gelecek dosya hemen gerekiyorsa, bağlantı kurma süresini öne alır. Tarayıcı DNS çözümünü yapar, TCP bağlantısını açar ve TLS el sıkışmasını başlatır. Dosya sonra istendiğinde kapı hazır olur.
Kod kısa görünür: <link rel="preconnect" href="https://cdn.ornek.com" crossorigin>. Eğer font ya da başka cross-origin kaynak kullanıyorsanız crossorigin eklemek gerekir. Yoksa bağlantı optimizasyonu tam karşılığını vermeyebilir.
En iyi kullanım alanı, ilk ekranda kesin gereken üçüncü taraf kaynaklardır. Görsel CDN’i, font host’u veya sayfa açılır açılmaz çalışan zorunlu bir consent platformu buna örnek olabilir. Buna karşılık chat widget, heatmap aracı veya sonradan açılan yorum sistemi için preconnect çoğu zaman gereksizdir.
Burada en sık hata, her üçüncü taraf alan adına preconnect eklemektir. Analytics, reklam, A/B test ve sosyal widget alanlarının tümünü ilk anda ısıtmak ağ kuyruğunu şişirir. Tarayıcıya yardım etmek isterken ilk ekranın önünü kesmiş olursunuz.
Preconnect’in sınırını da net görmek gerekir. Bağlantıyı erkenden kurar, ama dosyayı önce indirmez. Bu yüzden CDN’deki hero görseli için sık görülen doğru kombinasyon preconnect artı uygun yerde preload olur. İlki bağlantı gecikmesini keser, ikincisi keşif gecikmesini azaltır.
Eğer bir origin belki kullanılacaksa, daha hafif bir seçenek olan dns-prefetch daha mantıklı olabilir. Çünkü preconnect daha agresiftir. Kısacası preconnect’i “hemen gereken dış origin” filtresiyle düşünün. Geri kalanı için tarayıcının doğal davranışına alan bırakın.
Lighthouse, PageSpeed Insights ve DevTools ile nasıl doğrulanır?
Preload ve preconnect kararı hisle verilmez. İstek zincirinin önce ve sonra nasıl değiştiğine bakın. En iyi sonuç, laboratuvar verisi ile saha verisini birlikte okuyunca çıkar.
- Önce PageSpeed Insights’a bakın. Saha verisinde LCP ya da CLS sorunu görünmüyorsa, tek bir lab testine bakıp sayfayı etiketle doldurmayın. Saha ve lab ayrımını daha net okumak için Core Web Vitals raporu nasıl okunur rehberi iyi bir yardımcıdır.
- Sonra Lighthouse çalıştırın. LCP kaynağının geç keşfedilip keşfedilmediğini, render-blocking CSS ve JS dosyalarını, third-party etkisini ve istek zincirini kontrol edin. Preload sonrası aynı kaynağın daha erken başladığını görmelisiniz.
- Ardından Chrome DevTools Network panelini açın. “Priority”, “Initiator”, “Timing” ve “Waterfall” sütunlarını görünür yapın. Cache’i kapatın, mobil throttling kullanın ve ilk yüklemeyi yeniden test edin.
DevTools’ta preconnect doğruysa dış origin’in DNS ve TLS adımları daha erken yaşanır. Preload doğruysa LCP kaynağının istek başlangıcı HTML parse aşamasına yaklaşır. Performance panelinde Web Vitals izlerini de açarsanız, LCP anının daha erkene gelip gelmediğini net görürsünüz.
Karar vermeyi kolaylaştıran kısa tablo aşağıda:
| Durum | Doğru tercih | En çok etki | Kısa not |
|---|---|---|---|
| CSS arka planındaki hero görseli | Preload, çoğu zaman fetchpriority ile birlikte | LCP | Kaynak geç keşfedilir |
| İlk ekrandaki tek web fontu | Preload | LCP, bazen CLS | crossorigin önemlidir |
| CDN’den gelen LCP görseli | Preconnect + preload | LCP | Biri bağlantıyı, diğeri keşfi hızlandırır |
| Ayrı dosyadaki kritik CSS | Preload + normal stylesheet | LCP | Preload tek başına stili uygulamaz |
| ESM başlangıç dosyası | Gerekirse modulepreload | LCP, bazen INP dolaylı | Büyük modül ağacında daha anlamlı |
| Sonradan açılan chat widget | Genelde hiçbir şey | Yok ya da olumsuz | İlk anda öncelik vermeyin |
Tablonun özeti net. Preload dosyayı erken buldurur. Preconnect kapıyı erkenden açar. İlk ekranla ilgisi olmayan dosyalara bu iki ipucunu dağıtmak çoğu zaman geri teper.
Yayına almadan önce bir kez de genel kontrol yapmak iyi olur. Core Web Vitals checklist’i son taramada işinize yarar. Asıl hedef skor kovalamak değil, kritik istek zincirini sadeleştirmektir.
Sonuç
En iyi sonuç, daha çok etiket eklemekten gelmez. İlk ekranı kuran az sayıdaki dosyayı doğru sıraya koymak asıl farkı yaratır.
2026’da preload ile LCP kaynağını erkenden buldurmak hâlâ en güçlü kısa yoldur. Preconnect ise gerçekten gerekli third-party origin’lerde temiz bir destek sağlar. Öncelik disiplini kurulduğunda hem kullanıcı deneyimi hem Core Web Vitals daha sağlıklı görünür.
This post may contain affiliate links. If you make a purchase through these links, I may earn a small commission at no extra cost to you.