--- title: "Hydration nedir?" author: Androverse author_url: https://androverse.com.tr/yazar/androverse publisher: Androverse updated_at: 2026-10-15 url: https://androverse.com.tr/sozluk/hydration language: tr --- # Hydration nedir? Hydration, önceden oluşturulmuş HTML üzerine tarayıcıda uygulamanın etkileşimli davranışlarının bağlanması sürecidir. Diğer adlar: Hidratasyon. ## Nerede işine yarar? Sunucu ve istemcinin ilk çıktısı uyuşmalıdır. Büyük istemci paketleri indirme ve çalıştırma maliyetini artırabilir. Bu yüzden bütün içerik alanını istemci bileşeni yapmak yerine, gerekli etkileşimi küçük bileşenlere ayırmak değerlendirilebilir. ## Bir cümlede uygulaması Sunucudan gelen yazı listesine tarayıcıda arama ve kategori filtrelerini bağlamak. ## Neyle karıştırılmamalı? Hydration, HTML içeriğinin tamamını mutlaka tarayıcıda sıfırdan üretmek anlamına gelmez. ## Ekran göründü. Şimdi davranışı bağlanıyor. Bir ürün sayfası açılıyor. Başlık, fotoğraf ve renk seçenekleri hemen görünür; tarayıcı JavaScript’i yükledikten sonra seçimler tepki vermeye başlar. Sunucudan gelen HTML’e istemci tarafındaki bileşen davranışının bağlanması, hydration kavramının tipik kullanım alanıdır. İlk görüntü ile etkileşime hazır olma aynı an değildir. Bu aradaki süre uzarsa kullanıcı düğmeye bastığında bir şey olmadığını düşünebilir; sorun yalnız teknik konsolda yaşayan bir ayrıntı değildir. React gibi sistemlerde başlangıçtaki sunucu çıktısı ile tarayıcının beklediği ilk çıktı uyumlu olmalıdır. Sunucuda günün saati, tarayıcıda başka bir saat dilimi kullanılırsa metin değişebilir. Rastgele değer, pencere genişliği veya yalnız tarayıcıda bulunan kayıt da aynı farkı yaratabilir. Sorunu susturan bir uyarı ayarı, iki farklı ekranın neden üretildiğini açıklamaz. Önce ilk çıktının hangi veriyle oluştuğu belirlenir. Bir örnek üzerinden düşünelim: kullanıcı son seçtiği para birimini tarayıcıda saklıyor. Sunucu bu tercihi bilmiyorsa ilk sayfa varsayılan para birimiyle gelir. Tarayıcı ilk çizimde hemen başka değer üretirse uyumsuzluk oluşabilir. Tercihi sunucunun erişebileceği bir yöntemle taşımak veya istemciye özgü alanı kontrollü biçimde güncellemek farklı seçeneklerdir. Hangisinin uygun olduğu, kişiselleştirme ve ilk görünüm beklentisine bağlıdır. Hydration maliyeti, gönderilen etkileşimli kodun kapsamıyla ilişkilidir. Her paragrafın istemci bileşenine dönmesi gerekmez. Sadece ürün seçici, menü veya araç davranış istiyorsa bu sınır küçük tutulabilir. Bir sayfayı sunucuda üretip ardından aynı büyük ağacı tarayıcıda tekrar çalıştırmak, özellikle daha yavaş cihazlarda açılış deneyimini zorlaştırabilir. Önceden görünen içerik ile sonradan gereken davranışı ayırmak tasarımı ve geliştirmeyi birlikte ilgilendirir. Hidrasyon sorunları yalnız bir hata mesajından ibaret olmayabilir; kullanıcı ilk gördüğü içerikle etkileşimli hâl arasında fark yaşayabilir. Örneğin sunucu farklı bir saat, tarayıcı farklı bir yerel saat üretirse aynı alan değişebilir. İlk görüntüyü mümkün olduğunca tutarlı üretmek, tarayıcıya özgü bilgiyi uygun aşamada eklemek gerekir. Hata uyarısını susturmak gerçek farkın nedenini açıklamaz. Bir seslendirme düğmesi gibi yalnız tarayıcı özelliğine dayanan araçta başlangıçta güvenli bir durum sunulabilir, destek anlaşılınca etkileşim açılabilir. İçeriğin geri kalanı bu küçük aracı beklemek zorunda değildir. Böylece istemci yeteneği olmayan ziyaretçi de temel açıklamayı okuyabilir ve sayfanın anlamını kaybetmez. ### Aynı başlangıç Sunucu ve tarayıcı ilk anda aynı metin, yapı ve veriyle mi başlıyor? Tarih biçimi, kullanıcı tercihi ve rastgele kimlik gibi alanları incele. Uyum sorunu görünen tek kelimeden daha geniş bir veri akışını işaret edebilir. ### Küçük etkileşim alanı Hangi parçalar gerçekten tarayıcı durumuna ihtiyaç duyuyor? İçeriği göstermek ile kullanıcı seçimini yönetmek ayrı işlerdir. Yalnız gerekli bölümleri etkileşimli yapmak, gereksiz istemci bağımlılıklarını azaltmaya yardımcı olur. ### Hazır olma Bir düğme görünür olduğunda ne yapabiliyor? Kod gecikirse temel bağlantının veya formun davranışı devam ediyor mu? Kullanıcının ilk eylemi, yalnız hızlı bir ağ ve güçlü işlemci varsayımına bağlı olmamalıdır. ## HTML’in görünmesi ile uygulamanın hazır olması. ### İlk görüntü Tarayıcı sunucudan gelen başlıkları ve metni gösterebilir. Bu, kullanıcıya hızlı bir başlangıç verir. Ancak özel etkileşimler henüz bağlı değilse ekranın bütün işlevleri hazır değildir. Görsel açılış ölçümünün iyi olması, ilk düğmeye basışın da aynı derecede hızlı ve doğru çalışacağını tek başına göstermez. ### Davranışın devralması İstemci kodu mevcut HTML’i kendi bileşen yapısıyla eşleştirir ve etkileşimleri yönetmeye başlar. Bu sırada başlangıç verisinin tutarlı olması gerekir. Gereksiz yeniden üretim veya uyumsuzluk, hem maliyet hem görünür sorun yaratabilir. Hazır olma durumu bir uygulamanın tamamı için tek bir sayıdan ibaret olmayabilir; farklı parçalar farklı zamanda etkinleşebilir. ## İlk HTML ile istemciyi eşleştirmek Hydration sırasında sunucudan gelen yapı ile istemcinin ilk üretimi uyumlu olmalıdır. Rastgele değer, cihaz saatine bağlı metin veya yalnız tarayıcıda bilinen bir koşul ilk görüntüyü farklılaştırabilir. Etkileşimli alanlar tasarlanırken bu iki aşama ayrı düşünülür; başlangıç içeriği kararlı tutulur. - İlk render'da zaman ve rastgelelik kaynaklarını kontrol et. - Tarayıcıya özgü bilgileri uygun istemci aşamasında kullan. - Geliştirme konsolundaki uyuşmazlıkları gizlemek yerine nedenini düzelt. ## Hydration hatası yalnız görsel bir uyarı mı? Hayır. Uyuşmazlık beklenmeyen yeniden üretim veya yanlış davranışla sonuçlanabilir. Uyarıyı bastırmak yalnız sınırlı ve bilinçli durumlarda düşünülmeli; sunucu ile istemcinin neden farklı içerik ürettiği araştırılmalıdır. ## Bu karar, işinin neresinde? Hydration kavramının bir projede nasıl ele alındığını; yaklaşım, süreç ve teslimler üzerinden incele. [Web tasarım & yazılım](https://androverse.com.tr/hizmetler/web-tasarim-yazilim) ## Karar masası ### Hydration hatası her zaman sayfayı bozar mı? Sonuç kullanılan sistemin davranışına ve farkın niteliğine bağlıdır. Bazen küçük bir metin uyumsuzluğu görünür, bazen bileşen ağacı yeniden oluşturulur veya etkileşimler beklenmedik çalışır. Uyarıyı önemsiz saymak yerine hangi verinin farklılaştığı araştırılır. Özellikle form değerleri, kimlikler ve kullanıcıya özel içerik söz konusuysa görüntü doğru görünüyor diye sorun yok kabul edilmez. ### Tarayıcıya özel bilgiye hiç bakmamalı mıyız? Bakabiliriz; mesele hangi aşamada ve hangi başlangıçla bakıldığıdır. Pencere ölçüsü, yerel tercih veya ses desteği gibi bilgiler ilk sunucu çıktısında bilinmeyebilir. Sunucu için tutarlı bir başlangıç sunulup istemci hazır olduğunda uygun güncelleme yapılabilir. Yerleşimi yalnız JavaScript ölçümüyle değiştirmek yerine CSS’in yapabileceği işlere CSS’i bırakmak da bazı gereksiz farkları önler. ### JavaScript kapalıyken içerik kaybolmalı mı? Okunacak makale, ürün açıklaması veya normal bağlantı gibi temel içerik için buna çoğu zaman gerek yoktur. Sunucuda üretilmiş içerik erişilebilir kalabilir, özel araçlar ise destek durumunu açıklayabilir. Bir filtre gelişmiş davranışını kaybetse bile bütün listeye erişim sağlanabilir. Bu yaklaşım yalnız JavaScript kapalı kullanımına değil, kodun geç yüklendiği veya başarısız olduğu durumlara da daha dayanıklı bir deneyim sunar. ## İlk ekrandaki farklılığı bul. Saat, dil tercihi ve açılır menü içeren küçük bir sayfa düşün. Sunucunun ve tarayıcının ilk çıktısını ayrı listeler halinde tarif et. Her farklılığın nereden geldiğini ve kullanıcıya ne zaman gösterilmesi gerektiğini belirle. Amaç uyarıyı gizlemek değil, başlangıç sözleşmesini kurmak. - [ ] Sunucunun bildiği bilgileri yaz: istek adresi, erişilebilir oturum bilgisi ve içerik kaydı. Sonra yalnız tarayıcıda bulunanları ekle: pencere ölçüsü, bazı yerel tercihler ve cihaz yetenekleri. İki grubu karıştıran ilk render kararlarını işaretle. - [ ] Saat örneğinde hem dil hem saat dilimini açıkça seç. Aynı anın iki ortamda farklı yazılabileceğini düşün. Saatin sayfanın temel anlamı için gerekli olup olmadığını sorgula; dekoratif bir saat için bütün açılışı karmaşıklaştırmak gerekmeyebilir. - [ ] Menünün temel bağlantılarını JavaScript başlamadan ulaşılabilir kılacak bir yapı tarif et. Özel açılma animasyonu gecikse bile kullanıcının hedef sayfaya ulaşma yolu kalabilir. Görsel efekt ile gezinme işlevini aynı zorunluluk gibi ele alma. - [ ] Son durumda hangi bileşenlerin istemci davranışı taşıdığını yaz. Yalnız bir düğme etkileşimli olduğu için bütün makaleyi istemciye taşımak gerekip gerekmediğini değerlendir. Sınırların anlaşılır olması ileride eklenen özellikleri de daha kontrollü tutar. Hydration, hazır görünen ekranın yaşayan davranışa geçişidir. İyi bir başlangıç sözleşmesi ve dar etkileşim sınırları, bu geçişin kullanıcıya bir aksama olarak yansımamasına yardımcı olur. ## Bağlantılı kavramlar - [SSG](https://androverse.com.tr/sozluk/ssg) — SSG, sayfa içeriğinin kullanıcı isteğinden önce oluşturulup hazır HTML olarak sunulması yaklaşımıdır. - [SSR](https://androverse.com.tr/sozluk/ssr) — SSR, bir sayfanın HTML içeriğinin istek sırasında sunucuda oluşturulması yaklaşımıdır. - [INP](https://androverse.com.tr/sozluk/inp) — INP, bir sayfanın kullanıcı etkileşimlerine görsel yanıt verme gecikmesini değerlendiren etkileşim metriğidir. ## Konuyu uygulamaya taşı - [Web tasarım & yazılım](https://androverse.com.tr/hizmetler/web-tasarim-yazilim) — Hydration kavramının bir projede nasıl ele alındığını; yaklaşım, süreç ve teslimler üzerinden incele. - [Sunumda “disruptive”. Çıktıda aynı şablon.](https://androverse.com.tr/blog/sunumda-disruptive-ciktida-ayni-sablon) — Hydration ile ilgili tasarım kararını Androverse’nin uygulama örnekleri ve değerlendirme sorularıyla birlikte düşün. ## Kaynaklar - [React — hydrateRoot](https://react.dev/reference/react-dom/client/hydrateRoot) [Androverse profili](https://androverse.com.tr/yazar/androverse) · [Yayın ilkeleri](https://androverse.com.tr/yayin-ilkeleri)