Preload, prefetch ve preconnect: hangisi ne zaman gerçekten işe yarar
Resource hint’ler, gerçek tarayıcı darboğazlarıyla eşleştiğinde faydalıdır. Körlemesine kullanıldıklarında öncelik gürültüsü yaratır ve bazen sayfaları yavaşlatır.
İçindekiler
- Resource hint’ler sihirli değildir
- Tarayıcının zaten iyi yaptığı şeyler
- Preload: çok geç keşfedilen geçerli sayfa kaynakları için
- Preload ve LCP images
- Prefetch: bu sayfa için değil, sonraki sayfa için
- Preconnect: önemli origin’lere pahalı bağlantılar için
- DNS-prefetch: daha hafif kuzen
- Nasıl karar verilir: pratik bir workflow
- 1. Darboğazı belirleyin
- 2. Her seferinde bir ipucu ekleyin
- 3. Öncelik yan etkilerini kontrol edin
- 4. Header’ları ve caching’i doğrulayın
- Yaygın hatalar
- Çok fazla preload yapmak
- Gerekli kaynaklar için prefetch kullanmak
- Her üçüncü tarafa preconnect yapmak
- Mobil koşulları unutmak
- Basit bir karar tablosu
- Sakin kural
Resource hint’ler sihirli değildir
preload, prefetch ve preconnect çoğu zaman bir performans kontrol listesi gibi ele alınır. <head> içine birkaç etiket ekleyin, Lighthouse’u yeniden çalıştırın, kendinizi daha iyi hissedin. Bunlar böyle çalışmaz.
Bu ipuçları, tarayıcının yükleme hattına verilen talimatlardır. Tarayıcının yeterince erken keşfedemeyeceği bir şeyi biliyorsanız yardımcı olabilirler. Tahmin yürüttüğünüzde, kritik olmayan işleri fazla önceliklendirdiğinizde veya kullanıcıların hiç ihtiyaç duymayacağı bağlantıları önceden ısıttığınızda zarar verebilirler.
Kısa versiyon:
- Geçerli sayfa için gerekli ama çok geç keşfedilen kaynaklar için
preloadkullanın. - Geçerli sayfanın temel ihtiyaçları için değil, olası gelecekteki gezinme kaynakları için
prefetchkullanın. - Bağlantı kurulumunun gerçek bir gecikme olduğu önemli üçüncü taraf origin’ler için
preconnectkullanın.
Pratik soru “hangi ipucu en hızlı?” değildir. Soru şudur: “Tarayıcı neyi bekliyor ve bu ipucu o beklemeyi ortadan kaldırabilir mi?”
Tarayıcının zaten iyi yaptığı şeyler
Modern tarayıcılar pasif dosya indiricileri değildir. HTML’i ayrıştırır, kaynakları önceden tarar, öncelikler atar, bağlantıları yeniden kullanır, görünür olmayan işleri erteler ve ağ koşullarına uyum sağlarlar.
Bu, resource hint’lerin seçici kullanılması gerektiği anlamına gelir. Bir stylesheet, script, image veya font zaten erken keşfediliyor ve doğru önceliği alıyorsa, ipucu eklemek hiçbir şey yapmayabilir. Daha kötüsü, daha önemli kaynaklarla rekabet edebilir.
İpucu eklemeden önce DevTools’ta bir waterfall trace’e veya bir laboratuvar raporuna bakın. Lighthouse kullanıyorsanız skor yerine diagnostics ile başlayın; paniğe kapılmadan bir Lighthouse raporunu okumaya dair ayrı bir rehberimiz var — ancak doğru URL’nin büyük/küçük harfe duyarlı olduğunu unutmayın, gerekirse sitenizin navigasyonundan bağlantılı makaleyi kullanın.
Gerçek kanıt genellikle üç yerde görünür:
- Kritik bir kaynak, tarayıcı onu geç keşfettiği için geç başlar.
- Önemli bir origin’e bağlantı, ilk istekten önce fark edilir süre alır.
- Bir sonraki sayfa kaynağı yüksek olasılıkla tahmin edilebilir ve boş zamanda fetch etmek ucuzdur.
Bunların hiçbiri doğru değilse, ipucu muhtemelen süsten ibarettir.
Preload: çok geç keşfedilen geçerli sayfa kaynakları için
preload tarayıcıya şunu söyler: “Bu kaynağı şimdi fetch et, çünkü geçerli sayfanın buna ihtiyacı olacak.”
Tipik bir örnek, CSS içinde referans verilen bir web font’tur. Tarayıcı HTML’i indirmeli, CSS’i keşfetmeli, CSS’i indirmeli, ayrıştırmalı, font’u keşfetmeli ve ardından font’u istemelidir. Bu font ekranın ilk bölümündeki metin için önemliyse, keşif yeterince geç kalabilir ve layout shift’lere veya metin render’ının gecikmesine neden olabilir.
Bir preload bu isteği daha erkene çekebilir:
<link rel='preload' href='/fonts/inter-var.woff2' as='font' type='font/woff2' crossorigin>as attribute’u önemlidir. Tarayıcıya bunun ne tür bir kaynak olduğunu söyler; bu da önceliği, cache’i, content security policy’yi ve istek header’larını etkiler. Font’lar genellikle aynı siteden sunulsa bile crossorigin gerektirir, çünkü font fetch işlemi CORS mode kullanır.
İyi preload adayları şunları içerir:
- Görünür metin için kullanılan birincil web font.
- Largest Contentful Paint öğesi olan ve erken keşfedilemeyen bir hero image.
- Dolaylı olarak yüklenen kritik bir CSS dosyası.
- Çok erken gereken ama başka bir script’in arkasında gizlenen bir module veya script.
Kötü preload adayları şunları içerir:
- Design system’deki her font weight.
- Ekranın altındaki images.
- İlk render için gerekli olmayan script’ler.
- Tarayıcının ilk HTML parçasında zaten keşfettiği kaynaklar.
Preload güçlüdür, çünkü geçerli sayfa önceliğini etkiler. Bu yüzden yanlış kullanımı da kolaydır. Beş büyük asset’i preload ederseniz artık tarayıcıya yardım etmiyorsunuzdur. Onunla tartışıyorsunuzdur.
Font’lar klasik örnektir. Bir birincil font dosyasını preload etmek yardımcı olabilir. Altı weight ve italic varyantı preload etmek genellikle işleri kötüleştirir. Darboğazınız font’larsa önce font setini düzeltin; web fonts are still the easiest performance win on most sites rehberimiz bu temizliği daha ayrıntılı ele alır.
Preload ve LCP images
Bir LCP image’ı preload etmek, image başlangıç HTML’inde görünmüyorsa faydalı olabilir. Yaygın nedenler arasında CSS background images, client-rendered components veya geç ortaya çıkan responsive image mantığı bulunur.
Ancak hero image’ınız zaten HTML’de, makul srcset, sizes, boyutlar ve lazy loading olmadan bir <img> olarak yer alıyorsa, tarayıcı muhtemelen onu hızlıca bulabilir. Bu durumda, sayfaya bağlı olarak preload yerine fetchpriority='high' eklemek daha uygun olabilir.
İyi bir test: image isteği waterfall’da geç başlıyor ve LCP öğesi oluyorsa preload’u düşünün. Erken başlıyor ama yavaş indiriliyorsa sorun boyut, format, CDN davranışı veya server latency’dir — keşif değildir. Image formatı kararları için when AVIF beats WebP and when it does not yazısına bakın.
Prefetch: bu sayfa için değil, sonraki sayfa için
prefetch tarayıcıya şunu söyler: “Bu kaynağa yakında ihtiyaç duyulabilir, ama şu anda gerekli değil.”
Bu ayrım önemlidir. Prefetch kasıtlı olarak düşük önceliklidir. Tarayıcı bunu boş zamanda fetch edip daha sonra kullanmak üzere saklayabilir. Ayrıca kötü bağlantılarda, data-saving mode’larda veya bellek baskısı altında atlayabilir.
Kullanıcı niyeti, bir sonraki kaynağı olası kılacak kadar güçlüyse prefetch kullanın.
İyi prefetch adayları şunları içerir:
- Çok sayfalı bir checkout sürecindeki sonraki adım.
- Kullanıcı bir query yazmaya başladıktan sonra, sonraki route tahmin edilebiliyorsa search results.
- Kullanıcı yakındaki içeriği aktif olarak okuyorken table of contents’ten bağlantılanan documentation pages.
- Kullanıcı bir navigation item üzerine hover veya focus yaptığında single-page app içindeki route chunks.
Kötü prefetch adayları şunları içerir:
- Tüm navigation tree’niz.
- Büyük videolar veya image galleries.
- “Ne olur ne olmaz” diye üçüncü taraf script’ler.
- Kullanıcıların nadiren bir sonraki ziyaret ettiği sayfalar.
Prefetch’te ölçülülük karşılığını verir. Fetch edilip hiç kullanılmayan bir kaynak bedava değildir. Bandwidth, server capacity, enerji ve muhtemelen kullanıcı verisi tüketir. Mobil ağlarda speculative fetching aktif olarak kullanıcı dostu olmayabilir.
Birçok site için en iyi prefetch stratejisi intent-based yaklaşımdır. Home page yüklenir yüklenmez pricing page’i prefetch etmeyin. Kullanıcı pricing menüsünü açtığında, pricing link’inin üzerine geldiğinde veya navigasyonu güçlü biçimde tahmin eden bir call-to-action yakınına kaydırdığında prefetch edin.
Ayrıca tarayıcı davranışının değiştiğini unutmayın. Bazı tarayıcılar prefetch konusunda tutucudur; bazı gizlilik ayarları speculative loading’i azaltır veya devre dışı bırakır. Prefetch’i bir doğruluk mekanizması değil, fırsatçı bir iyileştirme olarak ele alın.
Preconnect: önemli origin’lere pahalı bağlantılar için
preconnect tarayıcıya şunu söyler: “Bu origin’e bağlantı kurulumunu şimdi başlat.”
Bu DNS lookup, TCP connection ve TLS negotiation içerebilir. Üçüncü taraf origin’ler için bu kurulum, özellikle yüksek latency’li ağlarda yüzlerce milisaniye sürebilir. Sayfa yakında o origin’den kritik bir isteğe ihtiyaç duyacaksa, preconnect sonraki isteği hızlandırabilir.
Örnek:
<link rel='preconnect' href='https://fonts.gstatic.com' crossorigin>İyi preconnect adayları şunları içerir:
- Render-blocking text için kullanılan bir font origin’i.
- İlk etkileşim sırasında gereken kritik bir API origin’i.
- Ekranın ilk bölümündeki asset’leri sunan bir CDN origin’i.
- Kullanıcı eyleminden hemen sonra gereken bir payments veya identity provider.
Kötü preconnect adayları şunları içerir:
- Kullanıcı açısından kritik olmayan analytics ve advertising endpoint’leri.
- Yalnızca bazı session’larda kullanılan origin’ler.
- Uzun üçüncü taraf listeleri.
- Tarayıcının zaten sahip olduğu veya yakında açacağı bağlantının bulunduğu same-origin kaynaklar.
Preconnect’in bir tutma maliyeti vardır. Açık socket’ler bellek ve ağ kaynakları tüketir. Tarayıcılar kullanılmayan bağlantıları kapatır, ancak bu gereksiz preconnect’leri zararsız yapmaz.
Faydalı bir kural: bir sayfada en fazla bir veya iki yüksek güvenli üçüncü taraf origin’e preconnect yapın. Daha fazlasını ekleme isteği duyuyorsanız, ipuçlarınızı genişletmekten çok üçüncü taraf mimarinizin gözden geçirilmesi gerekiyordur.
DNS-prefetch: daha hafif kuzen
dns-prefetch de görebilirsiniz:
<link rel='dns-prefetch' href='https://example-cdn.com'>Bu yalnızca domain name’i çözer. TCP veya TLS connection açmaz. Preconnect’ten daha ucuzdur, ama daha az yardımcıdır.
DNS-prefetch, full preconnect’in fazla agresif hissettirdiği daha düşük güvenli üçüncü taraf origin’ler için makul olabilir. Pratikte, bir origin kritikse ve yakında kesinlikle kullanılacaksa preconnect’i tercih edin. Yalnızca mümkünse ya DNS-prefetch kullanın ya da hiçbir şey yapmayın.
Nasıl karar verilir: pratik bir workflow
Etiketlerle değil, ölçümle başlayın.
1. Darboğazı belirleyin
Bir performance trace açın ve geç keşif arayın. Font, hero image veya script isteği ancak başka bir dosya indirilip ayrıştırıldıktan sonra mı başladı? Bu bir preload adayıdır.
Bir istek yalnızca üçüncü taraf origin’e uzun bir DNS/TCP/TLS kurulumundan sonra başlıyorsa, bu bir preconnect adayıdır.
Geçerli sayfa iyiyse ama sonraki navigation tahmin edilebilir biçimde yavaşsa, prefetch yardımcı olabilir.
2. Her seferinde bir ipucu ekleyin
Resource hint’ler etkileşime girer. Bir tane ekleyin, test edin ve yalnızca waterfall iyileşiyorsa ve kullanıcıya dönük metrikler gerilemiyorsa tutun.
Preload için, işaret edilen kaynağın gerçekten kısa süre içinde kullanılıp kullanılmadığını izleyin. Chrome, preloaded bir kaynak load’dan kısa süre sonra kullanılmadığında uyarı verebilir. Bu uyarıyı ciddiye alın.
3. Öncelik yan etkilerini kontrol edin
Bir preload, bandwidth’i daha önemli CSS, JavaScript veya images’tan çekebilir. Bir preconnect, bir connection slot’u işgal edebilir. Bir prefetch, arka plan trafiği ekleyebilir.
Doğru sonuç “ipucu verilen dosya daha erken başlıyor” değildir. Doğru sonuç “sayfa kullanıcılar için anlamlı biçimde daha iyi oluyor”dur. Mümkün olduğunda LCP, INP, CLS ve real-user monitoring’e bakın.
4. Header’ları ve caching’i doğrulayın
İpuçları HTML içinde veya HTTP Link headers ile gönderilebilir. Header’lar, server sayfanın neye ihtiyaç duyacağını erken biliyorsa faydalıdır; ancak gelişigüzel incelemek daha zordur. Production’da bir ipucunun gerçekten mevcut olup olmadığını debug ediyorsanız raw headers önemlidir; bu tam olarak redirects ve HTTP headers’ı production’da debug etmeye yönelik rehberimizin ele aldığı türden bir durumdur.
Caching de önemlidir. Mismatched credentials, yanlış as veya farklı URL parameters ile bir kaynağı preload etmek duplicate downloads’a yol açabilir. İyi niyetli bir preload’un performance bug’a dönüşmesinin en yaygın yollarından biri budur.
Yaygın hatalar
Çok fazla preload yapmak
Her şey kritikse, hiçbir şey kritik değildir. Preload’u ilk render veya immediate interactivity için gereken kaynaklarla sınırlayın. Tipik bir sayfada yirmi değil, sıfır ila üç preload olmalıdır.
Gerekli kaynaklar için prefetch kullanmak
Prefetch düşük öncelikli ve opsiyoneldir. Geçerli sayfanın gerektirdiği asset’ler için kullanmayın. Sayfanın buna şimdi ihtiyacı varsa preload’u veya normal HTML keşfini düşünün.
Her üçüncü tarafa preconnect yapmak
Üçüncü taraf ağırlıklı sayfalarda genellikle on veya daha fazla external origin bulunur. Hepsine preconnect yapmak gürültü yaratır. Hem kritik hem de tahmin edilebilir biçimde kullanılan bir veya ikisini seçin.
Mobil koşulları unutmak
Resource hint’ler daha yavaş bağlantılarda en değerlidir, ama orada en tehlikeli de olabilir. Hızlı bir desktop bağlantısında boşa giden prefetch yuvarlama hatasıdır. Kısıtlı bir mobil planda kötü bir takastır.
Basit bir karar tablosu
| Durum | En iyi ipucu | Neden | |---|---:|---| | CSS üzerinden keşfedilen kritik font | preload | Geçerli sayfanın ihtiyacı var, keşif geç | | CSS veya client rendering arkasında gizli hero image | preload | Image geç başlıyorsa LCP’yi iyileştirebilir | | Kullanıcı niyetinden sonra olası sonraki route | prefetch | Geçerli sayfayı bloke etmeden gelecekteki navigation’a yardımcı olur | | Kritik üçüncü taraf font/API origin’i | preconnect | Connection setup’ı critical path’ten çıkarır | | Olası ama belirsiz üçüncü taraf origin | dns-prefetch veya hiçbiri | Daha düşük maliyet, daha düşük güven | | Ekranın altındaki image | hiçbiri | Lazy loading ve tarayıcı önceliği çalışsın |
Sakin kural
Resource hint’ler sıkıcı ve spesifik olduklarında en iyi çalışır. Bir font. Bir LCP image. Bir önemli üçüncü taraf origin. Niyetten sonra olası bir sonraki route.
İyimserlik olarak kullanıldıklarında kötü çalışırlar: belki kullanıcı buna ihtiyaç duyar, belki tarayıcı şunu fetch etmelidir, belki daha fazla ipucu daha fazla hız demektir.
Tarayıcılar zaten agresif biçimde optimize eder. Göreviniz her isteği mikroyönetmek değildir. Göreviniz, tarayıcının doğru anda bilgiden yoksun kaldığı birkaç durumu düzeltmektir.
Sıkça sorulan sorular
Tüm font’larımı preload etmeli miyim?
Her internal link için prefetch kullanmak güvenli mi?
Preconnect ile dns-prefetch arasındaki fark nedir?
Resource hint’ler Core Web Vitals’ı iyileştirebilir mi?
Resource hint’ler HTML’e mi yoksa HTTP headers’a mı eklenmeli?
Kaynaklar ve ileri okuma
