Next.js prefetch zmierzony: Partial Prefetching w 16.3

Next.js 16.3 (otwiera się w nowej karcie) zmienia to, czym jest Next.js prefetch. Z włączonym partialPrefetching (otwiera się w nowej karcie) App Router nie pobiera już payloadu dla każdego linku na ekranie: pobiera jeden wspólny szkielet na trasę, a treść zależną od adresu zostawia na po kliknięciu. Zbudowaliśmy jedną aplikację na sześć sposobów i przeklikaliśmy ją 3744 razy, żeby sprawdzić, co ta zamiana daje i ile kosztuje.

Na stronie dokumentacji ze 100 linkami w bocznym menu prefetch zmalał o 93%. Ceną jest czas: treść, która wcześniej była na ekranie niemal od razu, przychodzi teraz kilkaset milisekund po kliknięciu, za szkieletem strony. Która strona tej zamiany jest lepsza, zależy od strony i od jednego szczegółu Reacta, który łatwo przeoczyć.

mniej bajtów prefetchu w dokumentacji

93%

mniej bajtów na całą nawigację w dokumentacji

11×

widoczny szkielet, przypięty przez Reacta

298 ms

treść na ekranie z prefetch={true}

43 ms

Co zmienia Partial Prefetching

Do wersji 16.3 App Router (otwiera się w nowej karcie) robił prefetch dla każdego linku: gdy na ekran wjeżdżało N linków, pobierał mniej więcej N payloadów. Z partialPrefetching (wymaga cacheComponents (otwiera się w nowej karcie)) pobiera jeden App Shell (otwiera się w nowej karcie) na trasę: wszystko, co strona renderuje niezależnie od adresu. Linki do tej samej trasy dzielą ten jeden prefetch. Treść, która czyta params albo searchParams, rozwiązuje się po kliknięciu, chyba że link poprosi o więcej przez prefetch={true}.

Porównaliśmy sześć buildów tej samej aplikacji:

• L0, bez Cache Components: klasyczny App Router.
• C0, samo Cache Components.
• P0, Cache Components z Partial Prefetching i domyślnym inliningiem prefetchu.
• P1–P3, to samo z wyłączonym inliningiem, z małymi progami i z dużymi.

Każdy przeklikaliśmy w trzech nawigacjach: z katalogu 48 produktów na stronę produktu, ze strony dokumentacji ze 100 linkami w menu na inną stronę dokumentacji i z wyników wyszukiwania na inne wyszukiwanie przez jeden z ośmiu linków z prefetch={true}.

Bajty prefetchu: nawet o 93% mniej

W dokumentacji samo Cache Components pobierało z wyprzedzeniem każdy widoczny link z menu. Partial Prefetching zmienił to z 402 kB → 29 kB−93%lepiej, w 8,5 żądaniach zamiast 49. W katalogu oszczędność wyniosła 78%. Wyszukiwanie prawie się nie zmieniło, bo jego osiem linków z prefetch={true} nadal pobiera własne wyniki.

Pozycja	Katalog → produkt	Dokumentacja → dokumentacja	Wyszukiwanie → wyszukiwanie
L0 · Klasyczny router	30 kB	408 kB	98 kB
C0 · Cache Components	160 kB	402 kB	163 kB
P0 · Partial Prefetching	34 kB	29 kB	107 kB
P1 · Bez inliningu	33 kB	32 kB	105 kB
P2 · Mały inlining	32 kB	28 kB	103 kB
P3 · Duży inlining	34 kB	33 kB	105 kB

Źródło: Benchmark Outofplace, Next.js 16.3.6Pobierz CSVPobierz PNG

Pokaż jako obraz

Wykres jako obraz. Możesz go użyć na licencji CC BY 4.0, podając Outofplace jako źródło i link do tej strony.

Jeden wiersz zasługuje na drugie spojrzenie. Włączenie Cache Components bez Partial Prefetching sprawiło, że katalog pobierał pięć razy więcej niż klasyczny router, 30 kB → 160 kB+426%gorzej: prerenderowane szkielety produktów da się wtedy pobrać osobno dla każdego linku. Jeśli włączasz Cache Components na stronach z wieloma linkami, od razu zdecyduj o Partial Prefetching.

Czy nawigacja jest naprawdę natychmiastowa?

Szkielet tak. Przy Partial Prefetching pojawiał się 43 ms–45 ms po kliknięciu na zwolnionym telefonie. Z tym, po co ktoś kliknął, czyli produktem albo artykułem, jest inaczej: potrzebuje żądania po kliknięciu.

• L0 · Klasyczny router
• C0 · Cache Components
• P0 · Partial Prefetching

Katalog → produkt375 ms · 60 ms · 262 ms

Dokumentacja → dokumentacja47 ms · 52 ms · 345 ms

Wyszukiwanie → wyszukiwanie40 ms · 41 ms · 43 ms

0 ms100 ms200 ms300 ms400 ms

Źródło: Benchmark Outofplace, Next.js 16.3.6Pobierz CSVPobierz PNG

Pokaż dane

Pozycja	L0 · Klasyczny router	C0 · Cache Components	P0 · Partial Prefetching
Katalog → produkt	375 ms	60 ms	262 ms
Dokumentacja → dokumentacja	47 ms	52 ms	345 ms
Wyszukiwanie → wyszukiwanie	40 ms	41 ms	43 ms

Wykres jako obraz. Możesz go użyć na licencji CC BY 4.0, podając Outofplace jako źródło i link do tej strony.

W dokumentacji samo Cache Components pokazało nowy artykuł po 52 ms, Partial Prefetching po 345 ms. Na stronie produktu różnica była mniejsza, 60 ms → 262 ms+337%gorzej, a najwolniejszy był klasyczny router, bo dla dynamicznej trasy nie miał nic wyrenderowanego z góry. Wyszukiwanie, gdzie każdy link ma prefetch={true}, pokazywało treść po 40 ms–43 ms w każdej konfiguracji.

Szkielet, który zobaczysz: 300 ms

Na stronie produktu trzy etapy przychodzą po kolei: szkielet, produkt, a potem część renderowana w chwili żądania.

• Szkielet
• Treść
• Część z serwera

L0 · Klasyczny router375 ms · 375 ms · 375 ms

C0 · Cache Components60 ms · 60 ms · 342 ms

P0 · Partial Prefetching47 ms · 262 ms · 562 ms

0 ms200 ms400 ms600 ms

Źródło: Benchmark Outofplace, Next.js 16.3.6Pobierz CSVPobierz PNG

Pokaż dane

Pozycja	Szkielet	Treść	Część z serwera
L0 · Klasyczny router	375 ms	375 ms	375 ms
C0 · Cache Components	60 ms	60 ms	342 ms
P0 · Partial Prefetching	47 ms	262 ms	562 ms

Wykres jako obraz. Możesz go użyć na licencji CC BY 4.0, podając Outofplace jako źródło i link do tej strony.

W dokumentacji szkielet był widoczny przez 298 ms w każdym buildzie z Partial Prefetching. To nie jest czas sieci: odpowiedź dochodziła po 250 ms.

Wczesne kliknięcie

Kliknięcie 50 ms po hydratacji, zanim skończy się jakikolwiek prefetch, zabiera przewagę wszystkim, którzy pobierają z wyprzedzeniem. Samo Cache Components jest wtedy mniej więcej tak samo wolne jak Partial Prefetching, bo obie konfiguracje najpierw pokazują fallback, a potem odczekują 300 ms.

• L0 · Klasyczny router
• C0 · Cache Components
• P0 · Partial Prefetching

Katalog → produkt367 ms · 374 ms · 389 ms

Dokumentacja → dokumentacja262 ms · 528 ms · 529 ms

Wyszukiwanie → wyszukiwanie234 ms · 404 ms · 339 ms

0 ms200 ms400 ms600 ms

Źródło: Benchmark Outofplace, Next.js 16.3.6Pobierz CSVPobierz PNG

Pokaż dane

Pozycja	L0 · Klasyczny router	C0 · Cache Components	P0 · Partial Prefetching
Katalog → produkt	367 ms	374 ms	389 ms
Dokumentacja → dokumentacja	262 ms	528 ms	529 ms
Wyszukiwanie → wyszukiwanie	234 ms	404 ms	339 ms

Wykres jako obraz. Możesz go użyć na licencji CC BY 4.0, podając Outofplace jako źródło i link do tej strony.

Ostatni etap, czyli część z serwera, dzieli te kliknięcia na dwie grupy. Przy Partial Prefetching w 6 z 12 wczesnych kliknięć na stronie produktu cała strona była na ekranie po 375 ms–400 ms. W pozostałych 6 dopiero po 650 ms–700 ms, a pomiędzy nie trafił żaden przebieg. Ta przerwa to mniej więcej 300 ms, które React odczekuje między dwoma odsłonięciami: ostatni etap pojawia się razem z produktem albo jedno odczekanie później.

375 ms500 ms600 ms700 ms

Źródło: Benchmark Outofplace, Next.js 16.3.6Pobierz CSVPobierz PNG

Pokaż dane

Zakres	przebiegi
375 ms–400 ms	6
400 ms–425 ms	0
425 ms–450 ms	0
450 ms–475 ms	0
475 ms–500 ms	0
500 ms–525 ms	0
525 ms–550 ms	0
550 ms–575 ms	0
575 ms–600 ms	0
600 ms–625 ms	0
625 ms–650 ms	0
650 ms–675 ms	3
675 ms–700 ms	3

Wykres jako obraz. Możesz go użyć na licencji CC BY 4.0, podając Outofplace jako źródło i link do tej strony.

Cały rachunek

Partial Prefetching przenosi bajty sprzed kliknięcia na po kliknięciu, a na stronie produktu dodatkowo je podwaja: odpowiedź nawigacji niosła dwie pełne kopie payloadu produktu, 13 kB → 26 kB+99%gorzej po kompresji. Licząc wszystko, co pobiera nawigacja, razem z prefetchem, w dokumentacji i tak wychodzi daleko do przodu.

L0 · Klasyczny router463 kB

C0 · Cache Components458 kB

P0 · Partial Prefetching40 kB

P1 · Bez inliningu43 kB

P2 · Mały inlining39 kB

P3 · Duży inlining44 kB

Źródło: Benchmark Outofplace, Next.js 16.3.6Pobierz CSVPobierz PNG

Pokaż dane

Pozycja	Wartość	n
L0 · Klasyczny router	463 kB	20
C0 · Cache Components	458 kB	20
P0 · Partial Prefetching	40 kB	20
P1 · Bez inliningu	43 kB	20
P2 · Mały inlining	39 kB	20
P3 · Duży inlining	44 kB	20

Wykres jako obraz. Możesz go użyć na licencji CC BY 4.0, podając Outofplace jako źródło i link do tej strony.

Mniej więcej 11 razy mniej bajtów w dokumentacji i 2,2 raza mniej w katalogu. Hydratacja i opóźnienie reakcji na stronie startowej nie zmieniły się w żadnej konfiguracji.

Kiedy prefetch={true} się opłaca

<Link prefetch={true}> (otwiera się w nowej karcie) pobiera też dane z adresu strony docelowej, więc kliknięcie jest tak samo natychmiastowe jak przy pełnym prefetchu. Płacisz za każdy widoczny link: osiem linków wyszukiwania kosztowało 107 kB, więcej niż cała strona dokumentacji przy Partial Prefetching. Używaj go tam, gdzie kliknięcie jest prawdopodobne, a dane da się cache'ować: podpowiedzi wyszukiwania, link „dalej”, kilka pierwszych wyników. Na siatkach kart rób prefetch na zamiar (najechanie albo dotknięcie), zamiast oznaczać każdą kartę.

prefetchInlining: zostaw włączony

experimental.prefetchInlining (otwiera się w nowej karcie) łączy małe odpowiedzi prefetchu w jedną. Ustawienie domyślne i nasze dwa zestawy progów różniły się najwyżej jednym żądaniem i kilkoma kilobajtami, bez mierzalnej różnicy w czasie.

Wyłączenie inliningu dodało pięć albo sześć żądań w katalogu i wyszukiwaniu, a przez HTTP/1.1 kosztowało to wczesne kliknięcie w katalogu: sześć połączeń na host się zapycha. Przez HTTP/2 (otwiera się w nowej karcie) kara znikała. Wszystkie inne konfiguracje wypadły na obu protokołach tak samo.

• HTTP/1.1
• HTTP/2

L0 · Klasyczny router365 ms · 363 ms

C0 · Cache Components375 ms · 373 ms

P0 · Partial Prefetching387 ms · 386 ms

P1 · Bez inliningu440 ms · 372 ms

P2 · Mały inlining390 ms · 383 ms

P3 · Duży inlining387 ms · 386 ms

300 ms350 ms400 ms450 ms

Źródło: Benchmark Outofplace, Next.js 16.3.6Pobierz CSVPobierz PNG

Pokaż dane

Pozycja	HTTP/1.1	HTTP/2
L0 · Klasyczny router	365 ms	363 ms
C0 · Cache Components	375 ms	373 ms
P0 · Partial Prefetching	387 ms	386 ms
P1 · Bez inliningu	440 ms	372 ms
P2 · Mały inlining	390 ms	383 ms
P3 · Duży inlining	387 ms	386 ms

Wykres jako obraz. Możesz go użyć na licencji CC BY 4.0, podając Outofplace jako źródło i link do tej strony.

Którą konfigurację wybrać

const nextConfig: NextConfig = {
  cacheComponents: true,
  // Jeden App Shell na trasę zamiast prefetchu na każdy link.
  partialPrefetching: true,
};

<Link href={`/search?q=${suggestion}`} prefetch={true}>
  {suggestion}
</Link>

1. Policz linki

   Najwięcej zyskują strony z wieloma linkami do tej samej dynamicznej trasy: dokumentacja, siatki, feedy. Strona z kilkoma linkami do różnych stron zyskuje niewiele.

2. Zdecyduj dla każdej trasy

   Tam, gdzie natychmiastowa treść jest ważniejsza niż bajty, a strony są statyczne, zostaw pełny prefetch; gdzie indziej włącz Partial Prefetching. Konfiguracja segmentu export const prefetch = 'partial' (otwiera się w nowej karcie) pozwala przechodzić trasa po trasie.

3. Oznacz prawdopodobne kliknięcia

   Dodaj prefetch={true} tam, gdzie następne kliknięcie da się przewidzieć, a dane da się cache'ować.

4. Zaprojektuj szkielet

   Na wolnym łączu będzie widoczny przez około 300 ms. Tytuł i nawigację umieść w części niezależnej od adresu: pojawia się niemal od razu.

Ta strona działa na Partial Prefetching: większość naszych stron ma mało linków, a te, które mają ich dużo (blog, case studies), są statyczne i lekkie. Nasze własne produkty, Portivo, Sprawna Matura i Levera, też stoją na Next.js.

Jak mierzyliśmy

Dalsza lektura