Resource Hint Nedir?

Resource hint mantığının temeli

Tarayıcı sayfayı işlerken hangi kaynağın ne kadar önemli olduğunu kendi öncelik sistemine göre belirler. Ancak uygulama mantığını her zaman tam okuyamaz. Geliştirici olarak siz, bazı kaynaklar için tarayıcıya daha erken sinyal verirsiniz. İşte resource hint dediğimiz yapı bu sinyallerin genel adıdır.

Yani hint kullanımı, kaynağı otomatik sihirle hızlandırmak değildir. Tarayıcının sıra ve zamanlama kararını etkileyen editoryal bir yönlendirmedir. Bu yüzden faydası, doğrudan kaynak önceliğini ne kadar doğru tanımladığınıza bağlıdır.

Yanlış kaynak için erken sinyal verirseniz, gerçekten kritik olan başka bir dosyanın önünü kesebilirsiniz. Bu yüzden “ne bulursam preload edeyim” yaklaşımı genelde kötü sonuç verir.

Preload için doğru zaman

Preload, sayfanın yakın zamanda kesin ihtiyaç duyacağı bir kaynağı erkenden gündeme getirir. Üst alandaki kritik font, kahraman görseli ya da erken kullanılacak script gibi dosyalar için mantıklı olabilir.

Buradaki ana fikir, kaynağın gerçekten gerekli olacağından neredeyse emin olmaktır. Çünkü preload, “bunu sonra belki kullanırım” türü gevşek bir ipucu değildir; ciddi öncelik etkisi yaratabilir. Bu yüzden yanlış hedef seçilirse diğer kritik isteklerle yarışa girer.

Özellikle FCP ve LCP tarafında üst alanda belirgin rolü olan dosyalar için doğru preload kararı faydalı olabilir. Ama ekranın dışında kalan ya da belirsiz kullanımlı kaynakları preload etmek çoğu zaman gereksiz baskı yaratır.

Prefetch'in farklı rolü

Prefetch, mevcut anın değil, bir sonraki olası adımın ipucudur. Kullanıcı birazdan başka sayfaya geçebilir, ikinci sekmeyi açabilir ya da sonraki ekranı isteyebilir; tarayıcıyı bu olasılığa hazırlarsınız.

Bu yüzden prefetch ile preload aynı iş için kullanılmaz. Biri “yakında kesin lazım”, diğeri “sonraki adımda muhtemelen lazım” düşüncesine daha yakındır. Eğer bu fark karıştırılırsa mevcut sayfanın kritik akışı gereksiz yere yük altında kalabilir.

Prefetch özellikle sayfalar arası geçişin yoğun olduğu yapılarda anlamlıdır. Ama ilk ekran daha kurulmadan çok sayıda prefetch çağrısı yapmak, mevcut sayfanın işini zorlaştırabilir.

Preconnect'in ayrı rolü

Preconnect doğrudan dosya indirmez; bir origin ile bağlantı kurma maliyetini erkene çekmeye çalışır. DNS çözümü, TCP bağlantısı ve TLS el sıkışması gibi adımların bir kısmı böylece daha kullanıcı henüz o kaynağı tam istemeden hazırlanmış olur.

Özellikle üçüncü taraf font, CDN ya da harici medya origin'lerinde bu ipucu anlamlı olabilir. Ama her dış kaynağa preconnect eklemek doğru değildir. Fazla bağlantı hazırlığı, kullanılmayacak origin'ler için gereksiz iş yükü ve bağlantı bütçesi tüketebilir.

Preconnect ile DNS prefetch farkı ayrıca ayrı başlıkta ele alınıyor; burada daha geniş resource hint ailesi içindeki yerini anlamak yeterli.

Yanlış hint kullanımının ters etkisi

Çünkü tarayıcı kaynak önceliği konusunda zaten kendi mantığıyla çalışır. Siz yanlış anda yanlış dosyayı öne çekerseniz, gerçekten kritik olan başka bir kaynağın şeridini işgal etmiş olursunuz. Sonuçta toplam iş daha hızlı değil, daha da dağınık hale gelebilir.

En yaygın hata, çok sayıda preload ekleyerek işi garantiye aldığını düşünmektir. Oysa bu, kritik isteği netleştirmek yerine her şeyi kritik ilan etmek anlamına gelir. Böyle olunca tarayıcı öncelik avantajını kaybeder; siz de hangi hint'in gerçekten işe yaradığını ayıramazsınız.

Benzer şekilde, sonraki sayfa için mantıklı olabilecek bir prefetch'i mevcut sayfa daha toparlanmadan başlatmak da kötü sonuç verebilir. Kullanıcı henüz ilk ekrandayken, ikinci adım için fazla iş yapmış olursunuz.

Resource hint'e daha yakın kaynaklar

Üst alandaki büyük kahraman görseli, ilk font ailesi, hemen kullanılacak script parçası veya sonraki ekranda açılması çok muhtemel dosyalar aday olabilir. Burada ana ölçüt, kaynağın görünür deneyim üzerindeki rolü ile ne kadar kesin gerektiğidir.

Eğer bir kaynak sayfanın görsel tamamlanma akışında belirgin rol oynuyorsa ama geç keşfediliyorsa, ipucu verilmesi mantıklı olabilir. Eğer kaynak yalnızca ihtimal dahilindeyse, daha yumuşak yaklaşım gerekebilir.

Kaynağın büyüklüğü kadar zamanlaması da önemlidir. Küçük ama kritik bir font dosyası, büyük ama ekran dışı bir görselden daha fazla öncelik hak edebilir.

Doğru kullanımı doğrulama yolu

Resource hint ekledikten sonra sadece “etiketi yazdım” demek yetmez. Öncelik değişiminin gerçekten görünür akışa fayda sağlayıp sağlamadığına bakmak gerekir. Üst alan daha erken mi tamamlandı, kritik kaynak daha çabuk mu geldi, ağ sırası daha mı temiz görünüyor; bunlar kontrol edilmelidir.

Eğer hint ekledikten sonra başka kritik dosyalar geç gelmeye başladıysa, sorunu çözmek yerine dağıtmış olabilirsiniz. Bu yüzden her ipucunu tek tek ölçmek ve etkisini izole okumak daha sağlıklı sonuç verir.

Özellikle render blocking kaynaklar ve kritik görünür öğeler üzerinden düşünmek, doğru öncelik kararlarını daha kolay netleştirir.

Mobil tarafta daha dikkatli olmak gerekir

Çünkü bağlantı bütçesi, cihaz işleme gücü ve ağ dalgalanması mobil tarafta daha sınırlıdır. Bu yüzden yanlış hint kullanımı masaüstünde tolere edilirken, mobilde doğrudan gecikme olarak hissedilebilir.

Özellikle çok sayıda erken bağlantı hazırlığı ya da gereksiz preload kararı, düşük hızlı ağlarda kritik isteklerin sırasını bozabilir. Bu nedenle resource hint stratejisi mobil deneyimi ayrıca hesaba katarak kurulmalıdır.

Pratikte akılda tutulacak sade prensipler

İlk prensip şudur: gerçekten kritik olmayan hiçbir şeyi kritik gibi işaretlemeyin. İkinci prensip: mevcut sayfanın işini bitirmeden bir sonraki sayfa için aşırı hazırlık yapmayın. Üçüncüsü de, her hint kararını ölçümle doğrulayın; sezgiyle değil.

• Preload: Yakında kesin gerekecek az sayıdaki kritik kaynak için.
• Prefetch: Sonraki olası adım için, mevcut akışı bozmadan.
• Preconnect: Bağlantı maliyeti gerçekten hissedilen origin'ler için.

Bu çerçeve korunduğunda resource hint kullanımı performansı sadeleştirir. Aksi halde, etiket sayısı artar ama kazanım belirsiz kalır.

Modulepreload gibi özel ipuçlarını ayrı düşünmek

Resource hint ailesi içinde bazı ipuçları daha dar senaryolara yöneliktir. Özellikle modül tabanlı JavaScript kullanan yapılarda `modulepreload`, klasik preload ile aynı mantığa benzese de kullanım bağlamı daha özeldir. Buradaki amaç sadece dosyayı erken istemek değil, modül ağacının daha düzenli hazırlanmasına yardımcı olmaktır.

Ancak bu tür daha özel hint'lerde de temel kural değişmez: gerçekten yakın zamanda gerekecek olmayan bir dosyayı öne çekmek, kritik akışı sadeleştirmek yerine karmaşık hale getirebilir. Bu yüzden “kullanıyorsam mutlaka eklemeliyim” yaklaşımı yerine, görünür ve ölçülebilir faydaya bakmak gerekir.

Özellikle modern build zincirlerinde otomatik üretilen hint davranışlarını da gözden geçirmek faydalıdır. Araç zinciri sizin yerinize bir öncelik kararı veriyor olabilir; ama bu karar her sayfanın gerçek kullanıcı akışına uymayabilir.

En büyük risk: öncelik karmaşası

Çünkü resource hint'lerin tamamı bir tür “buna dikkat et” sinyali üretir. Fakat çok fazla dikkat çağrısı olduğunda hiçbirinin değeri net kalmaz. Tarayıcıyı yönlendirmek isterken, aslında gerçekten kritik kaynağın yolunu tıkamış olabilirsiniz.

Bu risk özellikle tek sayfada birden fazla büyük medya, birden çok font dosyası ve çok sayıda harici bağlantı olduğunda büyür. Her biri için ayrı erken sinyal vermek teoride güvenli görünür ama pratikte bant genişliği, bağlantı bütçesi ve işlem sırası üzerinde gereksiz yarış başlatır.

O yüzden resource hint stratejisinde en önemli beceri, bazı kaynaklara özellikle erken öncelik vermek kadar, bazı kaynaklara hiç dokunmamayı bilmektir. Performans kazanımı bazen yeni etiket eklemekten değil, gereksiz etiket eklememekten gelir.

Hint ekledikten sonra neyin düzeldiğini doğrulamak

Sağlıklı doğrulama için iki katmanlı bakış gerekir. Önce ağ sırasına bakılır: gerçekten hedeflenen kaynak daha erken mi keşfedildi, bağlantı daha erken mi kuruldu, beklenmeyen yarış oluştu mu? Sonra kullanıcı hissine yakın sonuçlar izlenir: üst alan daha erken mi oturdu, ilk görünür deneyim daha mı temiz aktı, kritik öğe daha hızlı mı geldi?

Eğer ağ panelinde değişim var ama görünür akışta anlamlı toparlanma yoksa, ipucu doğru kaynağı hedeflemiyor olabilir. Tersi durumda ise başka bir darboğaz da aynı anda çözülmüş olabilir. Bu yüzden resource hint denemelerini mümkün olduğunca küçük ve izlenebilir parçalara bölmek daha güvenlidir.

İyi doğrulama, sadece “daha erken istek atıldı” cümlesiyle bitmez. Asıl soru şudur: bu karar kullanıcı için önemli olan anı gerçekten erkene çekti mi? Eğer cevap net değilse, hint stratejisi tekrar gözden geçirilmelidir.

Cache davranışıyla ilişkiyi gözden kaçırmamak

Resource hint kararı verirken cache tarafını unutmamak gerekir. Bazı kaynaklar ilk ziyaret için kritik görünür ama tekrar ziyaretlerde zaten tarayıcı belleğinde olabilir. Böyle durumlarda aynı hint stratejisi her kullanıcı için aynı değeri üretmeyebilir.

Özellikle iyi yapılandırılmış bir browser cache stratejisi varsa, sonraki yüklemelerde asıl darboğaz başka bir kaynağa kayabilir. Bu yüzden hint kararlarını yalnızca ilk açılış mantığıyla değil, tekrar ziyaret akışıyla birlikte değerlendirmek daha doğru sonuç verir.

Doğru resource hint stratejisinin farkı

Çünkü modern web performansı artık yalnızca “dosya küçültme” işi değil; teslimat sırası yönetimidir. Aynı kaynaklar, farklı zamanlarda istendiğinde çok farklı kullanıcı hissi üretebilir.

Resource hint yaklaşımı bu sıralama problemine daha bilinçli müdahale etmenizi sağlar. Doğru kaynağa doğru anda sinyal verdiğinizde, tarayıcıyla daha uyumlu çalışırsınız. Bu da hem yüklenme hissinde hem de görünür akışta daha düzenli sonuç üretir.