Понимание компонентов кэша и частичного предзагрузчика в Next.js 16.3
Объясняется, как функция мгновенного навигации в Next.js 16.3 использует общие шаблоны маршрутов и явные решения о стриминге, чтобы приложения, генерируемые на сервере, казались мгновенными в работе.
App Router уже давно имеет небольшое недостаток по сравнению с чисто клиентским SPA.
Когда всё работает в браузере, переход между маршрутами — это всего лишь обновление состояния, поэтому он происходит мгновенно по определению. Рендеринг с сервера лишает нас этого мгновенного ощущения в обмен на значительно меньший первоначальный объем данных.
Однако вы платите за этот компромисс позже: каждый последующий переход означает необходимость снова взаимодействовать с сервером.
Next.js 16.3 прямо борется с именно этой проблемой.
Эта функция называется Instant Navigations и основана на двух ключевых механизмах: Кэширование компонентов и частичное предзагрузчество.
Каждая функция навигации, которую когда-либо выпускал этот фреймворк, выглядела потрясающе на MacBook.
Так что же она на самом деле делает?
Эта идея взята почти напрямую из подходов к проектированию одностраничных приложений. В отличие от более ранних версий, которые загружали полную копию целевой страницы для каждой ссылки заранее,
Next.js теперь загружает заранее шаблон, совместный для всех маршрутов и хранит его в кэше на клиенте. Как только вы нажимаете на ссылку, этот шаблон сразу же отображается, в то время как сервер передает оставшийся контент.
Этот шаблон специально сделан простым: это лейаут, навигационные элементы, заголовки и основная структура — по сути, всё то, что выглядит одинаково независимо от того, на какую конкретную страницу этого маршрута вы попадаете. Поскольку он никогда не меняется, его можно безопасно сохранить в кэше и использовать снова для десятков ссылок, ведущих на один и тот же маршрут.
Чтобы включить эту функцию, используются два флага конфигурации:
const nextConfig: NextConfig = {
cacheComponents: true,
partialPrefetching: true,
};
Ожидается, что оба флага станут стандартными в какой-то будущей крупной версии. Включение их сегодня позволяет опередить это изменение, а не оказаться в экспериментальном тупике.
Почему это больше, чем просто «предзагрузка, но быстрее»
Настоящая суть здесь не сводится к чистой скорости. Речь идет о принудительном принятии явного решения для каждого маршрута.
В Next.js 16.3 появился новый инструмент разработки под названием Instant Insights, который автоматически отмечает в вашей среде разработки любую навигацию, которая не относится к мгновенным. Чтобы убрать такую отметку, теперь каждый маршрут должен четко указать, что произойдет, когда его данные еще не готовы. Существует ровно три допустимых варианта ответа:
Транслируйте данные потоком. Оберните медленную часть в <Suspense>, чтобы показывалось интерфейс загрузки до завершения работы сервера.
Сохраните в кэше. Отметьте его тегом 'use cache', чтобы вместо ожидания могла быть предоставлена ранее сгенерированная версия.
Умышленно заблокируйте его. Используйте export const instant = false для маршрутов, где ожидание действительно является правильным поведением, например при подтверждении оплаты, когда отображение устаревших данных будет хуже, чем небольшая задержка для пользователя.
Этот третий вариант заслуживает внимания. Он превращает фразу «этот маршрут работает медленно» из незамеченного сбоя в осознанное, задокументированное решение. Фреймворк не требует, чтобы каждый маршрут работал мгновенно. Он говорит о том, что с этого момента медленная работа должна быть намеренной, а не стандартом.
Где это действительно приносит пользу
Самым ярким примером являются страницы с длинным списком ссылок, такие как почтовый ящик поддержки с сорока строками заявок. Каждая отдельная страница заявки, скорее всего, использует один и тот же инструментарий, сетку метаданных и структуру диалога. Если загружать отдельную страницу для каждой ссылки заново, придется загружать эту идентичную общую структуру сорок раз. Частичная предзагрузка позволяет загрузить эту общую структуру один раз, использовать ее для всех ссылок, ведущих на этот маршрут, и транслировать только ту часть, которая действительно уникальна — содержимое конкретной заявки.
Это конкретное и значимое улучшение, которое полностью соответствует способу построения многих панелей управления в формате SaaS.
То, что обычно упускают из виду
Один разработчик перенес свой личный блог на превью версии 16.3 в отдельной ветке, полностью внедрив компоненты кэширования и частичное предзагрузчико, а также использовал набор из 19 тестов Playwright, направленных на подтверждение мгновенности навигации. Все тесты прошли.
После недели постоянного использования обеих версий они не смогли обнаружить никакой реальной разницы.
Объяснение оказалось почти разочаровывающе простым.
Сайт уже был полностью статическим: каждая страница предварительно генерировалась во время сборки и передавалась непосредственно из CDN. Не оставалось никаких запросов к серверу, которые можно было бы устранить, поэтому функция мгновенной навигации не имела возможности для улучшения.
То, что на самом деле делало сайт более быстрым, было совершенно другим фактором — уменьшение размера сжатого JavaScript на 341 КБ.
Это ограничение, которое необходимо учитывать перед внедрением этой функции. Instant Navigations устраняет задержку между нажатием на ссылку и отображением контента, особенно для динамических маршрутов, зависящих от сервера.
Если ваше приложение уже статическое или уже работает быстро по другим причинам, вы будете внедрять функцию для решения проблемы, которой у вас нет.
Сначала попробуйте её на тех маршрутах, где действительно заметна медленная работа, а не внедряйте её на всем сайте, и оценивайте результаты на умеренно быстром подключении Android с ограничением скорости, а не на ноутбуке с быстрым офисным Wi-Fi. Следует помнить комментарий об MacBook: практически каждая функция навигации, введённая этой фреймворк-системой, выглядела впечатляюще на MacBook.
Фреймворк не требует, чтобы каждый маршрут обрабатывался мгновенно. Он говорит о том, что с этого момента медленная работа должна быть целенаправленной, а не стандартом.
Что делать на самом деле
Если вы уже используете Next.js 16.x и навигация кажется медленной, начните с чего-то простого. Включите функцию частичного предзагрузчика только для двух-трех самых загруженных маршрутов, прежде чем распространять её на другие. Большая часть преимуществ связана с подготовительными действиями, а тестирование в узком диапазоне также поможет выяснить, были ли ваши лейауты должным образом отделены от процесса загрузки данных, что во многих реальных кодовых базах оказывается более полезным выводом.
Если вы всё ещё используете Pages Router и раздумываете над миграцией, этот функционал не должен стать решающим фактором. Настоящими причинами для перехода являются то, что Turbopack теперь стал стандартом для разработки, а также более полная стабилизация App Router. Instant Navigations — это дополнительное преимущество, которое вы получите позже, а не причина начинать миграцию с самого начала.
А если ваше приложение уже полностью статическое, просто пропустите миграцию.
Лучше найдите себе свои 341KB.
Связанные статьи
- 20 продвинутых шаблонов Next.js для приложений App Router высокого уровня — Узнайте о двадцати шаблонах Next.js высокого уровня, охватывающих подходы с серверной инициализацией, стриминг, кэширование, маршрутизацию и оптимизацию производительности для создания более быстрых и масштабируемых приложений.