Hydration Gecikmesi ve LCP Analizi

Hydration gecikmesi, sunucu tarafında render edilmiş statik HTML'in istemcide JavaScript ile etkileşimli hale getirilmesi sürecinde oluşan bekleme süresidir. 2026 verilerine göre hydration süresi 2 saniyeyi aşan sayfalarda LCP skoru ortalaması 3.8 saniyeye yükselmekte ve bu sayfaların %72'si Core Web Vitals değerlendirmesinde "kötü" kategorisine düşmektedir. Bu iki metriğin kesişim noktasını anlamak, hem kullanıcı deneyimini hem de sıralama performansını doğrudan belirler.

Hydration Kavramının Teknik Anatomisi

Hydration, SSR veya SSG ile üretilen statik HTML'in tarayıcıda JavaScript framework'ü tarafından "canlandırılması" sürecidir. Sunucu tam HTML'i gönderir, tarayıcı bu HTML'i ekrana çizer ve kullanıcı sayfayı görür. Ardından JavaScript bundle'ı indirilir, parse edilir ve çalıştırılır. Framework, DOM üzerindeki her elemana event listener'lar bağlar, state yönetimini başlatır ve bileşen ağacını yeniden oluşturur. Bu süreç tamamlanana kadar sayfa görünür ancak etkileşimsizdir.

Bu "görünür ama tıklanamaz" aralık, kullanıcı perspektifinden en rahatsız edici deneyimlerden biridir. Kullanıcı butona tıklar, form alanına yazar veya menüyü açmaya çalışır; hiçbir tepki alamaz. Bu sessiz başarısızlık, bounce rate'i doğrudan artırır. Dolayısıyla hydration gecikmesi yalnızca teknik bir metrik değil, doğrudan iş sonuçlarını etkileyen bir kullanıcı deneyimi sorunudur.

LCP Metriğinin Tanımı ve Ölçüm Mantığı

LCP (Largest Contentful Paint), sayfanın görüntü alanındaki (viewport) en büyük içerik elemanının ekrana çizilme süresini ölçer. Bu eleman genellikle hero görseli, ana başlık bloğu veya büyük bir metin paragrafıdır. Google, LCP'nin 2.5 saniye altında olmasını "iyi", 4 saniye üzerinde olmasını "kötü" olarak sınıflandırır.

LCP ölçümü, navigasyon başlangıcından itibaren en büyük elemanın render edilme anına kadar geçen süreyi kapsar. Bu süreye sunucu yanıt süresi (TTFB), kaynak indirme, HTML parse, CSS işleme ve render adımlarının tamamı dahildir. JavaScript ile render edilen içeriklerde hydration süreci de bu zincire eklenir. Dolayısıyla hydration gecikmesi, LCP süresinin doğrudan bir bileşenidir.

Hydration Gecikmesinin LCP Üzerindeki Doğrudan Etkisi

SSR ile sunulan bir sayfada LCP elemanı (örneğin hero görseli) HTML'de zaten mevcuttur ve tarayıcı bu elemanı JavaScript'ten bağımsız olarak ekrana çizer. Bu senaryoda hydration gecikmesi LCP'yi doğrudan etkilemez; çünkü LCP elemanı hydration'dan önce render edilmiştir. Ancak bu ideal senaryo, her zaman gerçekleşmez.

Hydration süreci sırasında framework DOM'u yeniden değerlendirdiğinde, belirli koşullarda LCP elemanı yeniden render edilebilir. Hydration mismatch durumunda React, sunucu HTML'ini atıp istemci tarafında DOM'u sıfırdan oluşturur. Bu yeniden oluşturma sırasında LCP elemanı ekrandan kaldırılıp tekrar eklenir ve LCP süresi hydration tamamlanana kadar uzar. Hydration mismatch, LCP süresini 2-5 saniye artırabilen sessiz bir performans katilidir. DevTools Console'da "Hydration failed" veya "Text content did not match" uyarıları bu sorunun doğrudan göstergesidir.

Hydration Mismatch Kaynaklarının Tespiti ve Çözümü

Hydration mismatch, sunucu tarafında üretilen HTML ile istemci tarafında React'ın ürettiği HTML arasındaki farklılıktır. Bu farklılık, tarayıcının DOM'u yeniden oluşturmasına ve tüm hydration sürecinin uzamasına neden olur. En yaygın mismatch kaynakları belirli kalıplardan beslenir.

Tarih ve saat formatlamaları, sunucu ve istemci arasında saat dilimi farkından dolayı mismatch üretir. new Date().toLocaleString() ifadesi sunucuda UTC, istemcide yerel saat döndürebilir. Rastgele sayı üreteçleri (Math.random(), uuid()) her çalıştırmada farklı sonuç verir. window.innerWidth gibi browser API'leri sunucuda mevcut olmadığından koşullu render yapıldığında mismatch oluşur. Çözüm, bu değişkenleri useEffect hook'u içinde tanımlamak ve ilk render'da sunucu çıktısıyla tutarlı bir varsayılan değer kullanmaktır:

    
function TimeDisplay() {
  const [currentTime, setCurrentTime] = useState('');
  
  useEffect(() => {
    setCurrentTime(new Date().toLocaleString('tr-TR'));
  }, []);
  
  return <span>{currentTime}</span>;
}       
    

Bu yapıda sunucu tarafında boş string render edilir, istemcide useEffect çalıştıktan sonra gerçek saat gösterilir. Mismatch oluşmaz, hydration sorunsuz tamamlanır.

Total Blocking Time ve Hydration İlişkisi

Total Blocking Time (TBT), sayfanın etkileşime kapalı olduğu toplam süreyi ölçer. Her 50 ms'yi aşan JavaScript görevi (long task), ana thread'i bloke eder ve kullanıcı girdilerini engeller. Hydration süreci, büyük bileşen ağaçlarında tek bir uzun görev olarak çalışabilir ve TBT değerini ciddi biçimde artırır.

200 bileşenlik bir sayfada hydration işlemi 800 ms sürdüğünde, bu sürenin tamamı tek bir long task olarak kaydedilir ve TBT'ye 750 ms (800 - 50 ms eşik) eklenir. Bu değer, INP metriğiyle birlikte sayfanın etkileşim performansını belirler. Chrome DevTools Performance sekmesinde "Main" thread'inde kırmızı üçgenle işaretlenen uzun görevler, hydration kaynaklı darboğazları doğrudan gösterir.

React 18 Concurrent Rendering ve Selective Hydration

React 18, concurrent rendering özelliğiyle hydration sürecini bölünebilir (interruptible) hale getirmiştir. Geleneksel hydration'da tüm bileşen ağacı senkron olarak hydrate edilir ve bu süre boyunca ana thread bloke olur. Concurrent rendering ile hydration, küçük parçalara bölünür ve her parça arasında tarayıcıya kontrol devredilir. Bu sayede kullanıcı girdileri, hydration tamamlanmadan önce de işlenebilir.

Selective hydration ise <Suspense> bileşeni ile sarmalanan alanların bağımsız olarak hydrate edilmesini sağlar. Kullanıcının etkileşimde bulunduğu bölge öncelikli olarak hydrate edilir:

    
import { Suspense } from 'react';

function ProductPage() {
  return (
    <>
      <ProductHeader />
      <ProductDescription />
      <Suspense fallback={<div style={{ minHeight: '400px' }} />}>
        <ProductReviews />
      </Suspense>
      <Suspense fallback={<div style={{ minHeight: '300px' }} />}>
        <RelatedProducts />
      </Suspense>
    </>
  );
}     
    

Bu yapıda ProductHeader ve ProductDescription öncelikli hydrate edilir. ProductReviews ve RelatedProducts ise kullanıcı o alana scroll ettiğinde veya tıkladığında hydrate edilir. Hydration yükü zamana yayılır ve ana thread'in bloke olma süresi kısalır.

Progressive Hydration ve Kademeli Canlandırma

Progressive hydration, sayfanın üst kısmından (above-the-fold) başlayarak bileşenleri aşamalı olarak hydrate etme stratejisidir. Kullanıcının ilk gördüğü alan öncelikli olarak etkileşimli hale gelir; sayfa aşağısındaki bileşenler daha sonra hydrate edilir. Bu yaklaşım, LCP elemanının bulunduğu bölgenin hızla etkileşimli olmasını garanti eder.

Intersection Observer API kullanarak viewport'a giren bileşenleri hydrate eden bir wrapper oluşturulabilir. Ancak bu yöntemi sıfırdan implement etmek karmaşıktır. Astro framework'ü client:visible direktifi ile bu davranışı yerleşik olarak sunar. React ekosisteminde react-lazy-hydration kütüphanesi benzer işlevi sağlar. Bu kütüphaneler, bileşenin viewport'a girene kadar hydration'ını erteleyerek toplam hydration süresini parçalar ve her parçanın ana thread üzerindeki etkisini minimize eder.

Island Architecture ile Hydration Yükünün Ortadan Kaldırılması

Island architecture, sayfadaki statik içeriğin hiç hydrate edilmemesini, yalnızca etkileşimli "adacıkların" JavaScript ile canlandırılmasını öngören mimari modeldir. Bir blog yazısında başlık, paragraflar ve görseller statik HTML olarak kalır; yalnızca yorum formu ve paylaşım butonları hydrate edilir. Bu yaklaşım, hydration yükünü sayfanın %10-20'sine düşürebilir.

Astro bu modeli varsayılan mimari olarak uygular. Her bileşen varsayılan olarak statik HTML'dir; JavaScript yalnızca client:load, client:idle veya client:visible direktifleriyle işaretlenen bileşenlere yüklenir. Bu mimari, hydration gecikmesini kavramsal düzeyde çözer; çünkü sayfanın büyük bölümü hydration sürecine dahil bile olmaz. Dolayısıyla TBT sıfıra yaklaşır ve LCP yalnızca HTML/CSS render süresine bağlı kalır.

Server Components ve Sıfır Hydration Yaklaşımı

React Server Components (RSC), sunucu tarafında çalışan ve istemciye hiç JavaScript göndermeyen bileşen tipidir. Bu bileşenler tam HTML olarak render edilir ve istemcide hydration gerektirmez. Next.js App Router'da varsayılan bileşen tipi Server Component'tir; yalnızca "use client" direktifi ile işaretlenen bileşenler Client Component olarak hydrate edilir.

Bu ayrım, hydration gecikmesini mimari düzeyde kontrol altına almanın en güçlü aracıdır. Sayfadaki bileşenlerin %70-80'i tipik olarak etkileşim gerektirmez (başlıklar, paragraflar, görseller, listeler). Bu bileşenleri Server Component olarak bırakmak, istemciye gönderilen JavaScript miktarını ve dolayısıyla hydration süresini dramatik biçimde azaltır. Sahadaki gerçek tecrübemiz gösteriyor ki, App Router'a geçişte bileşenlerin doğru sınıflandırılması (Server vs Client), hydration süresini ortalama %60 kısaltıyor ve LCP'yi 0.8-1.2 saniye iyileştiriyor.

LCP Elemanının Doğru Tespiti ve Optimizasyon Odağı

LCP optimizasyonu, öncelikle LCP elemanının doğru tespit edilmesiyle başlar. Chrome DevTools Performance sekmesinde bir kayıt alın ve "Timings" satırında "LCP" işaretçisine tıklayın. İlgili elemanın DOM'daki konumu gösterilir. Alternatif olarak, Web Vitals Chrome uzantısı LCP elemanını doğrudan sayfa üzerinde vurgular.

LCP elemanı sayfadan sayfaya değişebilir. Ana sayfada hero görseli, blog yazısında başlık bloğu, ürün sayfasında ürün görseli LCP elemanı olabilir. Her sayfa tipi için LCP elemanını ayrı ayrı tespit etmek ve optimizasyon stratejisini o elemana göre şekillendirmek gerekir. LCP elemanı bir görsel ise görsel optimizasyonu (format, boyut, preload), metin ise font yükleme ve CSS teslim stratejisi öncelikli çalışma alanıdır.

LCP Süresini Oluşturan Bileşenlerin Ayrıştırılması

LCP süresi, birbirine eklenen dört temel bileşenden oluşur: TTFB (sunucu yanıt süresi), resource load delay (kaynak yükleme gecikmesi), resource load time (kaynak indirme süresi) ve element render delay (eleman render gecikmesi). Hydration gecikmesi, dördüncü bileşen olan "element render delay" kategorisine girer.

Bu ayrıştırmayı yapmak, doğru optimizasyon kararını vermenin ön koşuludur. TTFB 800 ms, kaynak indirme 400 ms ve render delay 300 ms olan bir sayfada toplam LCP 1.5 saniye ise, sorun tek bir katmanda değil dağınıktır. Ancak render delay 2 saniye ise, sorun net biçimde hydration kaynaklıdır ve JavaScript optimizasyonuna odaklanılmalıdır. Chrome DevTools Performance sekmesindeki "Web Vitals" lane'i bu ayrıştırmayı görsel olarak sunar.

Font Yükleme Stratejisinin LCP Üzerindeki Etkisi

Web fontları, LCP elemanı metin bazlı olduğunda doğrudan LCP süresini etkiler. Varsayılan davranışta tarayıcı, font dosyası indirilene kadar metni görünmez kılar (FOIT: Flash of Invisible Text). Bu görünmezlik süresi, LCP ölçümüne dahil olur ve LCP süresini font indirme süresine bağlar.

font-display: swap CSS kuralı, FOIT sorununu çözer. Bu kural, font indirilene kadar sistem fontunu gösterir ve metin anında görünür olur. LCP elemanı metin ise, bu kuralın uygulanması LCP'yi font indirme süresinden bağımsız hale getirir. Ek olarak, LCP elemanında kullanılan font dosyası <link rel="preload" as="font" type="font/woff2" href="/font.woff2" crossorigin> ile önceden yüklenmelidir. Bu kombinasyon, font kaynaklı LCP gecikmesini ortadan kaldırır.

Hero Görseli Optimizasyonu ve LCP İyileştirmesi

LCP elemanı bir görsel olduğunda, görsel optimizasyonu doğrudan LCP iyileştirmesidir. Üç temel adım uygulanmalıdır. Birincisi, görselin preload ile erken keşfedilmesini sağlamaktır:

    
<link rel="preload" as="image" href="/hero.webp" fetchpriority="high">   
    

İkincisi, görselin loading="lazy" yerine loading="eager" ile yüklenmesi ve fetchpriority="high" attribute'ü ile önceliklendirilmesidir. Üçüncüsü, görselin doğru format (WebP veya AVIF) ve uygun boyutta sunulmasıdır. <picture> etiketi ile responsive görsel sunumu, farklı ekran boyutlarına uygun dosyaların teslim edilmesini sağlar.

Bu üç adımın birlikte uygulanması, görsel bazlı LCP'yi ortalama 0.5-1.5 saniye iyileştirir. Hydration gecikmesi görsel yüklemeyi doğrudan etkilemez, ancak hydration mismatch görsel elemanın yeniden render edilmesine neden olursa LCP dramatik biçimde uzar.

Critical Rendering Path ve JavaScript Etkileşimi

Critical rendering path, tarayıcının HTML'i parse edip ilk piksel'i ekrana çizene kadar geçen süreçteki tüm engelleri (blocking resources) kapsar. Render-blocking JavaScript, bu sürecin en yıkıcı bileşenidir. <script> etiketi defer veya async attribute'ü olmadan HTML'de yer aldığında, tarayıcı HTML parse'ını durdurur, JavaScript'i indirir ve çalıştırır, ardından parse'a devam eder.

SSR ile üretilen sayfaların HTML'inde framework'ün bootstrap JavaScript'i genellikle defer ile yüklenir. Ancak üçüncü parti scriptler (analytics, reklam, A/B test) render-blocking olarak eklenebilir. Bu scriptleri async veya defer ile yüklemek, HTML parse süresini kısaltır ve LCP elemanının daha erken render edilmesini sağlar. Üçüncü parti scriptlerin LCP üzerindeki etkisini ölçmek için Lighthouse'un "Third-party summary" raporunu inceleyin. Bu rapor, her üçüncü parti kaynağın ana thread'i ne kadar süre bloke ettiğini gösterir.

Streaming SSR ile TTFB ve LCP İyileştirmesi

Geleneksel SSR'de sunucu, sayfanın tamamını render edene kadar istemciye hiçbir veri göndermez. Streaming SSR ise HTML'i parça parça (chunk) göndererek ilk byte'ın istemciye ulaşma süresini kısaltır. React 18'in renderToPipeableStream API'si bu mekanizmayı destekler.

Streaming ile sayfanın <head> bölümü ve above-the-fold içerik anında gönderilir. Tarayıcı, HTML'in geri kalanı gelmeden bu içeriği render etmeye başlar. LCP elemanı above-the-fold bölgesindeyse, streaming SSR ile LCP süresi veri bağımlı bileşenlerin render süresinden bağımsız hale gelir. Next.js App Router, streaming SSR'i loading.js dosyaları ve <Suspense> sınırları aracılığıyla varsayılan olarak uygular. Her <Suspense> sınırı, bir streaming noktası oluşturur ve içindeki bileşen hazır olmasa bile sayfanın geri kalanı istemciye gönderilir.

INP Metriği ve Hydration Sonrası Etkileşim Performansı

INP (Interaction to Next Paint), kullanıcının bir etkileşiminden (tıklama, dokunma, tuş basımı) sonra bir sonraki görsel güncellemenin ekrana yansıma süresini ölçer. Google, INP'nin 200 ms altında olmasını "iyi" olarak değerlendirir. Hydration tamamlanmadan yapılan etkileşimler yanıtsız kalır ve hydration tamamlandıktan sonra da JavaScript'in ağır olması INP'yi kötüleştirir.

Hydration ile INP arasındaki ilişki iki yönlüdür. Birincisi, hydration tamamlanmadan kullanıcı etkileşimi mümkün değildir ve bu süre INP olarak ölçülmez, ancak kullanıcı deneyimini bozar. İkincisi, hydration tamamlandıktan sonra büyük bileşen ağacının event handler'ları, her etkileşimde ağır re-render tetikleyebilir ve INP'yi yükseltir. Code splitting ve memoization (React.memo, useMemo) bu ikinci sorunu hafifletir.

CLS ve Hydration Kaynaklı Layout Shift Sorunları

Hydration süreci, CLS (Cumulative Layout Shift) skorunu iki mekanizmayla bozabilir. Birincisi, hydration mismatch durumunda DOM'un yeniden oluşturulması sırasında elemanların konumlarının kaymasıdır. İkincisi, hydration sonrasında JavaScript ile eklenen dinamik elemanların (banner, bildirim çubuğu, cookie consent) mevcut elemanları itmesidir.

Bu sorunların çözümü, layout shift potansiyeli taşıyan elemanlar için sabit boyut rezervasyonu yapmaktır. CSS min-height, aspect-ratio ve contain: layout kuralları, elemanın yüklenme durumundan bağımsız olarak sabit alan kaplamasını sağlar. Hydration sonrası eklenen elemanlar için position: fixed veya position: absolute kullanarak akış dışı konumlandırma yapmak, diğer elemanları itme riskini ortadan kaldırır.

Lighthouse ve Web Vitals Araçlarıyla Hydration Profiling

Hydration gecikmesini ölçmek için Chrome DevTools'un Performance sekmesi en detaylı veriyi sunar. Sayfayı profil alarak Main thread aktivitesini inceleyin. Hydration süreci, genellikle "commitRoot" veya "hydrateRoot" fonksiyon çağrısı olarak timeline'da görünür. Bu çağrının süresi, toplam hydration gecikmesini verir.

Lighthouse'un "Diagnostics" bölümündeki "Avoid long main-thread tasks" uyarısı, hydration kaynaklı long task'ları listeler. Web Vitals kütüphanesi ise gerçek kullanıcı verilerini (RUM) toplamaya olanak tanır:

    
import { onLCP, onINP, onCLS } from 'web-vitals';

onLCP(metric => console.log('LCP:', metric.value, 'Element:', metric.entries[0].element));
onINP(metric => console.log('INP:', metric.value));
onCLS(metric => console.log('CLS:', metric.value)); 
    

Bu metrikler, analytics platformunuza gönderilerek gerçek kullanıcı deneyiminin izlenmesini sağlar. Lab verisi (Lighthouse) ile field verisi (RUM) arasındaki fark, hydration gecikmesinin farklı cihaz ve ağ koşullarında nasıl değiştiğini ortaya koyar.

React Profiler ile Bileşen Bazlı Hydration Süresi Ölçümü

React Profiler DevTools uzantısı, her bileşenin render ve hydration süresini ayrı ayrı gösterir. Bu araç, hydration darboğazının hangi bileşende yoğunlaştığını tespit etmenin en doğrudan yoludur. Profiler'da "Flamegraph" görünümü, bileşen ağacının hydration süresini renkli çubuklarla gösterir; en uzun süren bileşen en geniş çubukla temsil edilir.

Profiler ile tespit edilen ağır bileşenler, üç stratejiden biriyle optimize edilir: React.memo ile gereksiz re-render'lar engellenir, useMemo ve useCallback ile pahalı hesaplamalar cache'lenir veya bileşen React.lazy ile ayrı chunk'a taşınarak hydration yükünden çıkarılır. LinkedIn üzerindeki React performans topluluklarında paylaşılan vaka analizleri gösteriyor ki, en ağır üç bileşenin optimize edilmesi, toplam hydration süresini ortalama %40-50 oranında kısaltıyor.

Üçüncü Parti Scriptlerin Hydration ve LCP Üzerindeki Kümülatif Etkisi

Google Analytics, Facebook Pixel, Hotjar, Intercom ve reklam scriptleri gibi üçüncü parti kaynaklar, ana thread'i bloke ederek hem hydration'ı geciktirir hem de LCP süresini uzatır. Bu scriptler, framework'ün hydration sürecinden bağımsız olarak kendi JavaScript kodlarını çalıştırır ve ana thread üzerinde kaynak rekabeti oluşturur.

Üçüncü parti scriptlerin etkisini izole etmek için Lighthouse'u "Block third-party" modu ile çalıştırın (DevTools Network sekmesinde üçüncü parti domain'leri engelleyerek). Üçüncü parti scriptler engellendiğinde LCP ve TBT değerlerindeki iyileşme, bu scriptlerin toplam etkisini gösterir. Çözüm, kritik olmayan üçüncü parti scriptleri requestIdleCallback ile tarayıcının boş anlarında yüklemek veya Partytown gibi web worker tabanlı kütüphanelerle ana thread'den izole etmektir.

Next.js App Router ile Hydration Optimizasyonu Pratikleri

Next.js App Router, hydration gecikmesini mimari düzeyde azaltmak için birden fazla mekanizma sunar. Server Components varsayılan olarak hydration gerektirmez. loading.js dosyaları streaming SSR ile erken içerik teslimi sağlar. <Suspense> sınırları selective hydration noktaları oluşturur.

Pratik bir optimizasyon checklist'i şöyledir: sayfa bileşenini mümkün olduğunca Server Component olarak tutun. Etkileşim gerektiren alt bileşenleri "use client" ile işaretleyin ve en küçük birim düzeyinde izole edin. Büyük veri tabloları, grafik bileşenleri ve harita widget'ları için <Suspense> ile lazy boundary tanımlayın. loading.js dosyasında LCP elemanının placeholder'ını sabit boyutlarla tanımlayarak CLS'i önleyin. Bu adımların tamamı, hydration yükünü minimum seviyeye indirir.

Performans Bütçesi ile Hydration Süresinin Kontrol Altına Alınması

Çoğu uzman aksini iddia etse de, hydration optimizasyonu tek seferlik bir düzeltme değil, sürekli izleme gerektiren bir disiplindir. Her yeni bileşen, her kütüphane güncellemesi ve her özellik eklentisi hydration süresini artırma potansiyeli taşır. Bu birikimi önlemenin yolu, performans bütçesi tanımlayıp CI/CD pipeline'ında otomatik kontrol uygulamaktır.

Lighthouse CI ile her deployment öncesinde LCP, INP ve TBT eşik değerlerini kontrol eden bir kalite kapısı kurun. LCP 2.5 saniyeyi, TBT 300 ms'yi aştığında build'i başarısız kılan bu kapı, performans regresyonlarının üretime ulaşmasını engeller. lighthouserc.js dosyasında bu eşikler tanımlanır ve CI/CD pipeline'ına lhci autorun komutuyla entegre edilir. Bu mekanizma, hydration gecikmesinin ve LCP süresinin kontrol altında kalmasını uzun vadede garanti eden tek sürdürülebilir yaklaşımdır.