Co Vercel ogłosił w Next.js 16.3 i dlaczego branża o tym mówi?
Między 25 a 29 czerwca 2026 Vercel opublikował trzyczęściową serię zapowiedzi Next.js 16.3, a jej finał — wpis o Turbopacku z 29 czerwca — dostarczył najtwardszych liczb. Cztery filary wydania to: redukcja pamięci serwera deweloperskiego do ok. 90%, trwały cache systemu plików dla next build, eksperymentalny Rust React Compiler oraz zgodne z Vite API import.meta.glob. Kontekst jest istotny: Turbopack jest domyślnym bundlerem od Next.js 16 (21 października 2025), a już na linii 15.3+ działało na nim ponad 50% sesji deweloperskich i 20% buildów produkcyjnych. Zmiany w Turbopacku dotykają więc większości ekosystemu Next.js — także projektów, które nigdy nic nie konfigurowały.
Ile realnie daje trwały cache w next build?
Cache systemu plików przyspieszał next dev od wersji 16.1 (grudzień 2025). W 16.3, po — jak pisze Vercel — miesiącach hartowania na własnych serwisach, ten sam mechanizm objął next build. Opublikowane pomiary czasu kompilacji Turbopacka:
| Serwis | Cold build | Z cache | Przyspieszenie |
|---|---|---|---|
| nextjs.org | 21 s | 9,2 s | ~2,3× |
| vercel.com (home) | 66 s | 46 s | ~1,4× |
| vercel.com/geist | 30 s | 5,5 s | ~5,5× |
Skalę potencjału pokazały wcześniej dane z 16.1 dla trybu dev: pierwsza kompilacja trasy na react.dev spadła z 3,7 s do 380 ms (~10×), a w dużej wewnętrznej aplikacji Vercela z 15 s do 1,1 s (~14×). Uwaga praktyczna: cache buildów jest opt-in — wymaga flagi experimental.turbopackFileSystemCacheForBuild, a w CI zysk pojawia się tylko wtedy, gdy pipeline przenosi katalog .next między przebiegami. Bezstanowy runner z czystym środowiskiem nie zyska nic.
Skąd wzięło się 90% mniej pamięci w trybie dev?
Turbopack od początku świadomie wymieniał pamięć na czas procesora: trzymał w RAM wyniki wszystkich kompilacji, żeby nie liczyć niczego dwa razy. Przy długich sesjach i dużych aplikacjach oznaczało to nieograniczony wzrost zużycia — obok IDE, typecheckerów i agentów AI, które same potrafią zjeść gigabajty. Nowa memory eviction (domyślnie włączona w 16.3) zrzuca nieużywane wpisy cache na dysk, korzystając z mechanizmu trwałego cache z 16.1:
| Aplikacja (50 skompilowanych tras) | Przed | Po | Redukcja |
|---|---|---|---|
| vercel.com (dashboard) | 21,5 GB | 2 GB | ~90% |
| nextjs.org | 4 600 MB | 840 MB | ~82% |
Vercel zaznacza uczciwie: nie ma jednego procentu redukcji dla każdej aplikacji — wynik zależy od wielkości grafu tras i długości sesji. Do tego dochodzi ponad 15% szybszy zimny start serwera dev na złożonych aplikacjach dzięki konsolidacji subskrypcji HMR.
Czy Rust React Compiler naprawdę przyspiesza kompilację o 20–50%?
React Compiler (automatyczna memoizacja komponentów) jest w Next.js stabilny od 16.0, ale działał wyłącznie jako transform Babela — i Vercel sam ostrzegał, że na dużych aplikacjach wydłuża buildy. Zespół Reacta opublikował natywny port kompilatora w Ruście, który Turbopack integruje jako funkcję eksperymentalną (experimental.turbopackRustReactCompiler). Wczesne testy na dużych aplikacjach, m.in. v0, pokazały 20–50% szybszą kompilację. To zmienia rachunek dla zespołów, które dotąd rezygnowały z React Compilera właśnie przez koszt Babela — ale liczby pochodzą na razie z jednej klasy aplikacji i statusu eksperymentu nie należy ignorować.
Gdzie jest haczyk w tych benchmarkach?
Cztery rzeczy, które w entuzjastycznych omówieniach umykają. Po pierwsze, wszystkie liczby to pomiary Vercela na trzech własnych serwisach — na dzień publikacji nie było niezależnej reprodukcji, więc wyniki na Twoim kodzie będą inne. Po drugie, 16.3 ma status preview (dist-tag @preview, v16.3.0-preview.7); stabilna linia to 16.2.11 i tam powinna zostać produkcja do czasu stabilnego wydania. Po trzecie, szybciej nie znaczy bezpieczniej: lipcowy pakiet bezpieczeństwa (20 lipca 2026) załatał 9 CVE — 4 o wysokiej i 5 o średniej wadze, w tym CVE-2026-64642, czyli obejście middleware/proxy w aplikacjach App Router budowanych… Turbopackiem (przy jednym wpisie i18n.locales). Po czwarte, konkurencja wyznacza tempo: Vite 8 (12 marca 2026) uczynił domyślnym bundlerem napisany w Ruście Rolldown — wyścig kompilatorów Rustowych trwa, a Turbopack wciąż działa wyłącznie z Next.js.
Co to zmienia przy budowie stron premium z animacjami 3D?
Z perspektywy naszej praktyki w AD AWARDS najciekawszy wniosek brzmi: trwały cache najbardziej opłaca się w projektach asset-heavy — a takie są strony z animacjami 3D. Sceny three.js, shadery i biblioteki animacji stanowią większość grafu modułów, ale przy dopieszczaniu designu, gdy robimy dziesiątki przebudów dziennie, te moduły się nie zmieniają. Cache trafia więc dokładnie w niezmienny „ciężar” 3D, a przeliczane jest tylko to, co faktycznie iterujemy. Druga część wniosku dotyczy architektury: nasze wdrożenia to statyczny export serwowany z LiteSpeed, więc całą nowość 16.3 konsumujemy w build-time, a runtime po stronie klienta pozostaje czystym HTML/JS. Z dziewięciu lipcowych CVE — dotyczących Server Actions, middleware/proxy, API optymalizacji obrazów i cache serwerowych fetchy — statycznego exportu bez tych komponentów nie dotyczy praktycznie żaden. Klient dostaje prędkość nowego kompilatora bez powierzchni ataku nowego runtime’u. Tak podchodzimy do budowy stron i aplikacji w Next.js — a jeśli planujesz klasyczną stronę firmową lub e-commerce, zobacz też nasze podejście do stron www i sklepów internetowych. O tym, jak szybkość ładowania przekłada się na widoczność w wyszukiwarkach, piszemy na landingu SEO.