Akış Etkisini Ölçme: FCP, TTI ve LCP

FCP, gezinmenin başlamasından ilk içerik parçasının (metin, görsel veya arka plan) ekrana boyanmasına kadar geçen süreyi ölçer. Akış, HTML kabuğunu hemen göndererek FCP'yi iyileştirir — tarayıcı, ilk parçalar gelir gelmez düzeni, gezinmeyi ve ilk görüntü alanındaki tüm metinleri boyayabilir.

Eş zamanlı SSR'de (renderToString) tarayıcı, oluşturmanın tamamı bitene kadar hiç HTML almaz. Akışta ise tarayıcı, isteğin alınmasından sonraki milisaniyeler içinde HTML kabuğunu alır — düzen ve statik içerik neredeyse hemen görünür ve FCP'yi önemli ölçüde azaltır.

LCP, görüntü alanındaki en büyük görünür öğenin boyandığı zamanı ölçer — genellikle bir öne çıkan görseli veya büyük bir başlığı. LCP öğesi kabuğun parçasıysa (bir Suspense sınırının içinde değilse) akış LCP'yi iyileştirir; çünkü kabuk, veri bağımlı bölümlerden önce akışa gönderilir.

Önemli bir iyileştirme, sayfanızı LCP öğesi olan öne çıkan bölümün, ana başlığın veya öne çıkarılan görselin herhangi bir Suspense sınırının dışında yer alacağı şekilde tasarlamaktır. LCP öğesi veri bekleyen bir Suspense sınırının içindeyse akış, bu veriler çözümlenene kadar LCP'ye yardımcı olamaz.

TTI, ana iş parçacığını engelleyen Uzun Görevler olmadan sayfanın kullanıcı girdisine güvenilir biçimde yanıt verir hâle geldiği zamanı ölçer. Akışın seçmeli hidratasyonla birleştirilmesi, tüm JavaScript indirildikten sonra tek ve büyük bir eş zamanlı hidratasyon görevi çalıştırmak yerine hidratasyon işini zamana yayarak TTI'yi azaltır.

İlk Bayta Kadar Geçen Süre (TTFB), ilk bayt gönderilmeden önceki ağ gecikmesi ve sunucu işleme süresi tarafından belirlenir. Akış TTFB'yi değiştirmez — uçta işleme bu noktada yardımcı olur. Akışın FCP'yi iyileştirmesi için önce düşük bir TTFB gerekir; aksi takdirde yalnızca yavaş bir kaynak sunucudan akış gerçekleştirirsiniz.

WebPageTest'in film şeridi görünümü, sayfa yüklenirken her 100 ms'de alınan ekran görüntülerinden oluşan bir dizi gösterir. Akışlı sayfa, önce düzenin erken görünmeye başladığını, ardından bölümlerin aşamalı olarak dolduğunu gösterir. Akışsız sayfadaysa önce boş bir ekran, sonra aniden tamamen oluşturulmuş bir sayfa görünür; bu, görsel açıdan net bir farktır.

Anlamlı bir kıyaslama, aynı sayfanın iki şekilde oluşturulmuş hâlini karşılaştırır: Next.js RSC akışı etkinleştirilmiş hâli ve geleneksel eşzamanlı SSR. WebPageTest'i sabit bir ağ koşuluyla (ör. Hızlı 3G, 4 kat CPU yavaşlatması) kullanın ve istatistiksel güvenilirlik için FCP, LCP ve TTI ölçümlerini 3 deneme boyunca karşılaştırın.

Chrome DevTools'un Network sekmesinde, Hızlı 3G ve Yavaş 4G gibi hazır ayarların bulunduğu bir "Yavaşlatma" açılır menüsü vardır. Hızlı 3G (1,6 Mbps, 150 ms RTT), akışlı ve akışsız sayfalar arasındaki farkı belirginleştirir; çünkü HTML belgesinin tamamının indirilme süresini artırarak artımlı akış kazanımlarını görünür kılar.

Etkileşimden Sonraki Boyama (INP), herhangi bir kullanıcı etkileşiminden sonraki boyamaya kadar geçen süreyi ölçer. 2024'te Temel Web Verileri kapsamında FID'nin yerini almıştır. Akış, kullanıcının önce etkileşim kurma olasılığı yüksek etkileşimli bileşenlerin hidrasyonuna öncelik vererek INP'yi azaltır; böylece bu bileşenler yanıt verebilir hâle gelmeden önceki engelleme süresi kısalır.

En yüksek etkiye sahip yapılandırma, uçta oluşturmayı (yakındaki bir PoP'tan düşük TTFB), akışla (aşamalı HTML iletimi) ve seçici hidrasyonla (aşamalı JS işleme) birleştirir. Bu üç teknik birlikte, yükleme yaşam döngüsünün tamamındaki tüm temel performans ölçümlerini en aza indirir.

React akışı, ekranın üst kısmındaki içerik için hangi performans ölçümünü en doğrudan iyileştirir?

Akış, HTML kabuğunu hemen ileterek en doğrudan FCP'yi iyileştirir; LCP öğesi kabukta olduğunda LCP'yi de iyileştirir. TTI, JS işinin zamana yayılmasını sağlayan seçici hidrasyon sayesinde iyileşir. TTFB değişmez; bunu uçta oluşturmayla ele alın. Akışın etkisini ölçmek için WebPageTest film şeridini ve Chrome DevTools yavaşlatmasını kullanın; Temel Web Verileri kapsamında birincil etkileşim ölçümü olarak INP'yi optimize edin.