Preconnect ve DNS Prefetch Farkı Nedir?

DNS prefetch'in öne çektiği aşama

DNS prefetch, adından da anlaşılacağı gibi en temelde alan adının IP çözümünü erkene çekmeye çalışır. Yani tarayıcı, ilgili origin için “bu alan adını biraz erken çözeyim” diye hazırlık yapar. Böylece gerçek istek geldiğinde en azından DNS tarafındaki bekleme bir miktar kısalabilir.

Bu yaklaşım görece daha hafif bir ipucudur. Tam bağlantı kurmaz, TLS hazırlığı yapmaz, yalnızca çözümleme maliyetini önden azaltmaya çalışır. Bu yüzden etkisi sınırlı ama daha düşük riskli kabul edilir.

Eğer ilgili origin kesin kullanılmayacaksa, DNS prefetch'in gereksiz maliyeti genelde preconnect kadar agresif olmaz. Ama yine de her dış kaynağa eklemek doğru değildir.

Preconnect'i daha güçlü yapan fark

Çünkü yalnızca alan adını çözmekle kalmaz; bağlantı kurulumu için daha fazla adımı öne çeker. DNS çözümünün yanında TCP bağlantısı ve çoğu durumda TLS el sıkışması da erken hazırlanır. Yani gerçek istek geldiğinde tarayıcı o origin ile konuşmaya daha hazırdır.

Bu yüzden preconnect, özellikle kesin kullanılacak üçüncü taraf origin'lerde belirgin fayda sağlayabilir. Font sağlayıcısı, kritik CDN kaynağı ya da sayfanın hemen başında çağrılan harici medya origin'i gibi örneklerde etkisi daha görünür hale gelir.

Ama güçlü olduğu kadar daha risklidir. Kullanılmayacak ya da geç kullanılacak bir origin için fazla erken preconnect yapmak, bağlantı bütçesini gereksiz yere meşgul edebilir.

İki yaklaşım arasındaki temel fark

DNS prefetch daha hafif bir ön hazırlık sinyalidir; preconnect ise daha derin bağlantı hazırlığı yapar. İlki adresi erkenden çözer, ikincisi bağlantıyı ciddi biçimde kurmaya yaklaşır.

Bu yüzden aynı işi yaptıkları düşünülmemelidir. Evet, ikisi de gelecekteki isteği kolaylaştırmaya çalışır. Ama biri bağlantının ilk adımına, diğeri daha büyük bölümüne dokunur. Kullanım kararı da bu fark üzerinden verilmelidir.

Hangi durumda hangisi daha mantıklıdır

Eğer üçüncü taraf origin'in kesin kullanılacağı çok net değilse ya da etkisini yalnızca hafifçe önden hissettirmek istiyorsanız DNS prefetch daha temkinli bir seçenek olabilir. Ama sayfanın ilk akışında kesin rol oynayan bir dış origin varsa, preconnect daha anlamlı sonuç verebilir.

Buradaki kararın ana ölçütü “kaynak kesin kullanılacak mı” ve “o kaynağın gecikmesi ilk görünür deneyimi etkiliyor mu” sorularıdır. Bu yüzden konu doğrudan resource hint mantığı ile ilişkilidir. Hint ailesi içindeki aracın hangisi olduğu, kaynağın belirliliğine ve zamanlamasına göre seçilmelidir.

Çok erken ve çok kesin bir ihtiyaç varsa preconnect, daha belirsiz ya da daha gevşek hazırlık gerekiyorsa DNS prefetch daha uygun olabilir.

Yanlış kullanımın ters etkileri

En sık hata, çok sayıda dış origin için aynı anda preconnect tanımlamaktır. Teoride “ne kadar erken hazırlık, o kadar iyi” gibi görünür. Pratikte ise bağlantı bütçesini gereksiz yere tüketebilir ve gerçekten kritik origin'in avantajını azaltabilir.

Benzer şekilde, sırf güvenli hissettirdiği için her üçüncü taraf alan adına DNS prefetch eklemek de gürültü üretir. Etki küçük görünse de, hangi kararın gerçekten faydalı olduğunu okumayı zorlaştırır. Çok sayıda küçük sinyal biriktiğinde öncelik stratejisi belirsizleşir.

O yüzden burada “daha fazla etiket” değil, “daha doğru etiket” yaklaşımı önemlidir.

Mobil tarafta farkın daha görünür olması

Çünkü bağlantı hazırlık maliyetleri zayıf ağlarda daha çok hissedilir. Özellikle üçüncü taraf origin'e giden ilk temas, mobil ağ dalgalanması altında masaüstüne göre daha yavaş algılanabilir. Bu yüzden doğru seçilmiş bir preconnect ya da temkinli bir DNS prefetch farkı mobilde daha net görülebilir.

Tersi de geçerlidir: gereksiz erken bağlantı hazırlığı, sınırlı ağ kaynaklarında görünür akışı zorlayabilir. Bu yüzden mobil deneyimde sadece teorik faydaya değil, gerçek öncelik sırasına bakmak gerekir.

Kararın daha kritik hale geldiği origin tipleri

Özellikle harici font sağlayıcıları, erken çağrılan görsel CDN'leri, video önizleme sunucuları ve üst alan deneyimini etkileyen widget origin'leri bu kararın değerini artırır. Çünkü sorun yalnızca dosyanın büyük olması değil, ilgili alan adıyla ilk temasın pahalı olabilmesidir.

Eğer bir origin sadece alt bölümde devreye giriyorsa ya da kullanıcı ikinci adıma geçtiğinde kullanılacaksa, agresif hazırlık kararı gereksiz olabilir. Buna karşılık üst alandaki kritik kaynağı taşıyan bir origin geç hazırlanıyorsa, küçük bağlantı farkı bile görünür deneyime doğrudan yansıyabilir.

Bağlantı yeniden kullanımının etkisi

Bazen ekip aynı origin için her seferinde büyük hazırlık maliyeti varmış gibi düşünür. Oysa tarayıcı bazı durumlarda mevcut bağlantıyı tekrar kullanabilir ve yeni istek daha ucuz hale gelir. Böyle senaryolarda preconnect etkisi tahmin edilenden sınırlı kalabilir.

Tersi durumda, çok parçalı alan adı yapısı ya da sık değişen origin'ler connection reuse avantajını zayıflatır. Bu yüzden preconnect ve DNS prefetch kararı, yalnızca teorik protokol adımlarına göre değil, origin mimarisinin pratikte nasıl davrandığına göre değerlendirilmelidir.

Ölçüm tarafındaki yaygın yanılgılar

İlk yanılgı, ağ panelinde erken hazırlık görünce bunun otomatik olarak kullanıcı yararı sağladığını sanmaktır. Oysa bağlantı erken kurulmuş olabilir ama görünür öğeyi taşıyan gerçek kaynak hâlâ geç geliyorsa, kullanıcı hissi beklenen kadar değişmeyebilir.

İkinci yanılgı, masaüstü laboratuvar sonucunu tüm kullanıcı kitlesine yaymaktır. Mobil ağlarda bu fark daha çok hissedilebilir ya da bazen tam tersine beklenen kadar fark üretmeyebilir. Bu yüzden tek koşullu ölçümden genel kural türetmek risklidir.

Üçüncü yanılgı da, az kullanılan origin'ler için teknik olarak doğru ama pratikte önemsiz hazırlıklar yapmaktır. Eğer kullanıcı hissine dokunmayan bir kaynağı öne çekiyorsanız, güzel görünen ama düşük etkili bir optimizasyon üretmiş olabilirsiniz.

Font ve medya origin'lerinde kararın hassasiyeti

Çünkü bu kaynaklar çoğu zaman üst alan algısını doğrudan etkiler. Harici font geç hazırlanırsa metin görünümü ya gecikir ya da geç toparlanır. Kritik görsel CDN'i geç devreye girerse, üst ekranın anlamlı parçası beklenenden daha geç oturur. Bu yüzden küçük bir bağlantı hazırlığı farkı burada daha görünür hissedilebilir.

Ama aynı nedenle hata payı da büyüktür. Her font origin'ine agresif preconnect vermek ya ekran dışındaki medya alanları için erkenden ağır hazırlık başlatmak, faydadan çok gürültü üretebilir. Yani bu alanlar en çok kazanç da sunar, en çok yanlış karar riski de taşır.

Sayfa tipinin tercihi değiştirmesi

Bir blog yazısı, ürün detay sayfası ve kampanya açılış ekranı aynı dış kaynak davranışına sahip değildir. Blog yazısında font origin'i öne çıkabilir; bir video ağırlıklı sayfada medya alanı daha kritik olabilir; uygulama panelinde ise erken API ya da ayrı asset domain'i daha değerli hale gelebilir.

Bu yüzden tek bir sitenin tüm sayfalarına aynı hint kalıbını kopyalamak sağlıklı değildir. Preconnect ile DNS prefetch kararı şablon bazında da düşünülmelidir. Hangi sayfada hangi origin kullanıcı hissini erkenden etkiliyor sorusu, doğru tercihi doğrudan değiştirir.

Tekrar ziyaretlerde sonucun değişmesi

Çünkü bağlantı hazırlık maliyeti ve kaynak keşfi, ilk ziyaret ile tekrar ziyaret arasında aynı davranmayabilir. İyi çalışan bir cache yapısı varsa bazı dış kaynakların baskısı azalabilir, başka darboğazlar daha görünür hale gelebilir. Bu nedenle aynı hint kararı her kullanıcı senaryosunda aynı katkıyı üretmez.

Burada asıl ders, ilk yükte anlamlı görünen optimizasyonu kalıcı doğru sanmamaktır. İlk ziyaret, tekrar ziyaret ve farklı cihaz sınıfları bazen aynı origin hazırlığından çok farklı sonuçlar alabilir. Bu yüzden kararları ölçüm bağlamıyla birlikte korumak gerekir.

Bazen hiç hint eklememek daha doğrudur

Eğer ilgili origin kritik değilse, görünür akışa erken dokunmuyorsa ya da mevcut tarayıcı davranışı zaten yeterince iyi işliyorsa, ek etiket yazmak sadece yönetim maliyeti üretir. Her performans problemi yeni bir hint gerektirmez. Bazen sade kalan yapı, yanlış öncelik zinciri kurmaktan daha güvenlidir.

Bu yaklaşım özellikle çok kalabalık üçüncü taraf ekosistemi olan projelerde önemlidir. Önce gerçekten değerli origin'leri ayırmak, sonra yalnızca onlara dokunmak uzun vadede daha temiz ve daha okunabilir bir yapı bırakır.

Doğru etkiyi ölçme biçimi

Önce ilgili origin'in gerçekten kritik anda kullanılıp kullanılmadığını doğrulayın. Sonra ağ sırasına bakın: bağlantı hazırlığı erken geldi mi, ilk kritik istek gerçekten daha rahat aktı mı, yoksa sadece yeni bir hareket mi eklendi? Bunlar birlikte okunmalıdır.

Ardından görünür etkiye bakmak gerekir. Üst alan daha erken oturuyor mu, kritik font ya da medya daha hızlı mı geliyor, ağ beklemesi kullanıcı hissine yansıyor muydu? Eğer cevap net değilse, hint kararı sadece teknik olarak doğru görünmüş olabilir.

Bu yüzden küçük denemeler yapmak daha sağlıklıdır. Tek origin, tek ipucu ve görünür sonucu izlemek; kalabalık bir etiket setinden çok daha öğretici olur.

Farkın daha kritik hale geldiği sayfalar

Harici font, kritik CDN görseli, video host'u ya da üçüncü taraf bileşen kullanan ekranlarda bağlantı hazırlık stratejisi daha değerli hale gelir. Çünkü gecikme sadece dosya boyutundan değil, o origin ile ilk temasın kurulmasından da kaynaklanır.

Özellikle üst alan deneyimini etkileyen kaynaklar için bu fark daha görünürdür. Eğer dış origin geç kuruluyorsa, görsel tamamlanma akışı ve kritik görünür öğelerin zamanı bundan doğrudan etkilenebilir.

Akılda tutulacak en sade kural

Kesin ve kritik dış origin için preconnect düşünün. Daha belirsiz ya da daha hafif hazırlık gereken durumlarda DNS prefetch değerlendirin. İkisini aynı görüp otomatik dağıtmayın.

Bu sade kural tüm vakaları çözmez; ama yanlış önceliklendirme riskini ciddi biçimde azaltır. Özellikle çok sayıda üçüncü taraf alan adı olan projelerde bu disiplin büyük fark yaratır.