Zrozumienie komponentów cache oraz częściowego prefetchingu w Next.js 16.3
Wyjaśnia, w jaki sposób funkcja Instant Navigations w Next.js 16.3 wykorzystuje wspólne szkielety tras oraz wyraźne decyzje dotyczące strumieniowania, aby aplikacje renderowane na serwerze wydawały się uruchamiać natychmiastowo.
App Router od dawna ma niewielką wadę w porównaniu z czystym SPA renderowanym na stronie klienta.
Gdy wszystko działa w przeglądarce, przechodzenie między trasami to nic więcej niż aktualizacja stanu, więc z definicji dzieje się to natychmiast. Renderowanie od strony serwera poświęca to natychmiastowe odczucie w zamian za znacznie mniejszą początkową objętość danych.
Jednak później płacisz za tę kompromisową decyzję: każda kolejna nawigacja oznacza ponowne połączenie z serwerem.
Next.js 16.3 bezpośrednio adresuje właśnie ten problem.
Ta funkcja nazywa się Instant Navigations i opiera się na dwóch podstawowych mechanizmach: Komponenty w pamięci cache oraz częściowe preloading.
Każda funkcja nawigacyjna, jaką kiedykolwiek wprowadziło to framework, wyglądała doskonale na MacBooku.
A co tak naprawdę robi?
Idea ta pochodzi niemal bezpośrednio z projektowania aplikacji jednostronicowych. Zamiast wcześniej preładowywać pełną kopię strony docelowej dla każdego linku, jak to robiły wcześniejsze wersje,
Next.js teraz preładowuje szkielet współdzielony dla każdej trasy i przechowuje go w pamięci cache na stronie klienta. Gdy tylko klikniesz link, ten szkielet jest natychmiast renderowany, podczas gdy serwer przesyła pozostałą zawartość.
Ten szkielet jest celowo prosty. To układ, elementy nawigacyjne, nagłówki oraz podstawowa struktura – dosłownie wszystko to, co wygląda identycznie niezależnie od tego, na której konkretnie stronie tej trasy się znajdujesz. Ponieważ nigdy się nie zmienia, można go bezpiecznie zapisać w cache i ponownie używać przy dziesiątkach linków prowadzących do tej samej trasy.
Aby to włączyć, używa się dwóch flag konfiguracyjnych:
const nextConfig: NextConfig = {
cacheComponents: true,
partialPrefetching: true,
};
Oczekuje się, że oba te flagi staną się standardem w jakiejś przyszłej głównej wersji. Włączenie ich już teraz pozwala być na kroku z tą zmianą, a nie znaleźć się w eksperymentalnej ślepej uliczce.
Dlaczego to jest coś więcej niż „prefetching, ale szybciej”
Prawdziwa zmiana nie dotyczy głównie samej szybkości. Chodzi o przymusowe podjęcie wyraźnej decyzji na każdej trasie.
Next.js 16.3 wprowadza nowe narzędzie rozwojowe o nazwie Instant Insights, które automatycznie oznacza, bezpośrednio w środowisku deweloperskim, każdą nawigację, która nie spełnia kryteriów natychmiastowości. Aby usunąć to oznaczenie, każda trasa musi teraz jasno określić, co powinno się stać, gdy jej dane jeszcze nie są gotowe. Istnieją dokładnie trzy prawidłowe odpowiedzi:
Przesyłaj je strumieniowo. Otocz powolną część tagiem <Suspense>, aby podczas wykonywania zadań przez serwer pokazywała się ramka ładowania.
Zachowaj to w pamięci podręcznej. Oznacz to tagiem 'use cache', aby zamiast czekania można było dostarczyć wcześniej wygenerowaną wersję.
Celowo to zablokuj. Użyj export const instant = false dla tras, w których oczekiwanie jest właściwym zachowaniem, np. przy potwierdzeniu zamówienia – pokazanie przestarzałych danych byłoby gorsze niż krótkie oczekiwanie użytkownika.
Ta trzecia opcja zasługuje na uwagę. Zamienia stwierdzenie „ta trasa jest wolna” z niezauważonego incydentu na świadomą, udokumentowaną decyzję. Framework nie wymaga, aby każda trasa była natychmiastowa – mówi jedynie, że od teraz wolne działanie musi być celowe, a nie standardem.
Gdzie to naprawdę przynosi korzyści
Najbardziej oczywistym przypadkiem są strony z długim wykazem linków, takie jak skrzynka pocztowa wsparcia pokazująca czterdzieści wierszy z zgłoszeniami. Każda pojedyncza strona z takim zgłoszeniem prawdopodobnie wykorzystuje tę samą paskę narzędzi, siatkę metadanych oraz podstawową strukturę rozmowy. Jeśli załóżysz pobieranie całej oddzielnej strony dla każdego linku, ostatecznie pobierzesz tę identyczną strukturę czterdzieści razy. Częściowe pobieranie z góry polega natomiast na jednorazowym pobraniu tej wspólnej struktury, jej ponownym użyciu dla każdego linku prowadzącego do tej ścieżki oraz przesyłaniu tylko tej części, która jest rzeczywiście unikalna – mianowicie treści konkretnego zgłoszenia.
To konkretne i istotne ulepszenie, które dobrze odpowiada sposobowi budowy wielu paneli SaaS.
Problem, którego większość opracowań nie uwzględnia
Jeden z programistów przeniósł swój osobisty blog na wersję przeglądową 16.3 na oddzielnym gałęzi, w pełni wdrożając komponenty cache oraz częściowe pobieranie treści z góry, a całość zweryfikował zestawem 19 testów w Playwright, który konkretnie sprawdzał, czy nawigacje odbywają się natychmiastowo. Wszystkie testy przeszły pomyślnie.
Po tygodniowym porównywaniu obu wersji nie byli w stanie dostrzec żadnej rzeczywistej różnicy.
Wyjaśnienie okazało się niemal rozczarowująco proste.
Strona była już w pełni statyczna: każda strona została z góry wyrenderowana podczas budowania i dostarczana bezpośrednio z CDN. Nie pozostał już żaden ruch między serwerem, który należałoby usunąć, więc funkcja natychmiastowych nawigacji nie miała już żadnej luki do zamknięcia.
To, co faktycznie sprawiło, że strona wydawała się szybsza, to coś zupełnie innego: usunięcie 341 KB skompresowanego JavaScriptu.
To jest zastrzeżenie, o którym musisz pamiętać przed wdrożeniem tej funkcji. Instant Navigations eliminuje opóźnienie pomiędzy kliknięciem w link a wyświetleniem treści, szczególnie przy dynamicznych trasach zależnych od serwera.
Jeśli twoja aplikacja jest już statyczna lub szybka z innych powodów, wdrażałbyś funkcję, aby rozwiązać problem, który w twoim przypadku nie istnieje.
Najpierw spróbuj jej na trasach, które rzeczywiście wydają się powolne, zamiast wdrażać ją na całej stronie, i mierz efekty przy ograniczonej prędkości połączenia Android w średniej klasie, a nie na laptopie z szybkim Wi-Fi w biurze. Komentarz o MacBooku na początku jest wart zapamiętania: niemal każda funkcja nawigacyjna wprowadzona do tego frameworka wyglądała imponująco na MacBooku.
Framework nie wymaga, aby każda trasa była natychmiastowa. Mówi jedynie, że od teraz wolne działanie musi być celowe, a nie standardem.
Co naprawdę należy z tym zrobić
Jeśli już używasz Next.js 16.x i nawigacja wydaje się powolna, zacznij od małych kroków. Włącz Partial Prefetching tylko na dwóch lub trzech najbardziej ruchliwych trasach, zanim rozszerzysz to na inne miejsca. Większość korzyści pochodzi z przygotowawczych działań, a testowanie w wąskim zakresie pokaże również, czy układy zostały właściwie oddzielone od procesu pobierania danych – co w przypadku wielu rzeczywistych baz kodowych okazuje się bardziej przydatnym odkryciem.
Jeśli nadal używasz Pages Router i zastanawiasz się, czy przeprowadzić migrację, ta funkcja nie powinna być decydującym czynnikiem. Turbopack stający się standardem w rozwoju, w połączeniu z większą stabilnością App Routera, to prawdziwe powody do przeniesienia się. Instant Navigations to dodatek, który otrzymujesz później, a nie powód, by w ogóle rozpoczynać migrację.
A jeśli twoja aplikacja jest już w pełni statyczna, po prostu pomiń migrację.
Lepiej poszukaj własnych plików o rozmiarze 341KB.
Powiązane artykuły
- 20 zaawansowanych wzorców Next.js dla aplikacji App Router o najwyższej jakości — Poznaj dwadzieścia wzorców na poziomie eksperta z zakresu projektowania opartego na serwerze, strumieniowania danych, buforowania, routingu i optymalizacji wydajności, aby tworzyć szybsze i skalowalne aplikacje produkcyjne.