Navigation API: руководство по роутингу SPA (2026)

Что изменилось в 2026 году и что означает статус Baseline Newly Available

Baseline Newly available означает, что Navigation API теперь работает во всех основных браузерах текущих стабильных версий - Chrome 102+, Firefox 147+, Safari 26.2+ и Edge 102+ - охватывая примерно 83,66% глобальных пользователей по данным Can I Use. Это порог, при котором веб-API переходит из категории "экспериментальный" в "готовый к продакшену для современных проектов" без необходимости полифиллов.

Термин "Baseline" введён WebDX Community Group, которая отслеживает, когда функции достигают стабильной кросс-браузерной поддержки. Существует два уровня. Newly available означает, что функция работает в последней версии каждого основного браузера (Chrome, Edge, Firefox, Safari). Widely available означает, что поддержка существует не менее 30 месяцев, что делает функцию безопасной для проектов, которым необходимо поддерживать старые версии браузеров. Navigation API находится на стадии Newly available, что означает прогрессивное улучшение как рекомендуемый паттерн внедрения.

Хронология поддержки по браузерам демонстрирует постепенную конвергенцию:

• Chrome и Edge выпустили Navigation API в версии 102 (апрель 2022), обеспечив ранний доступ для браузеров на базе Chromium
• Firefox 147 (январь 2026) добавил полную поддержку, как подтверждено в примечаниях к выпуску Firefox 147.0
• Safari 26.2 (январь 2026) привнёс Navigation API в WebKit, а Safari 26.3 добавил AbortSignal для NavigateEvent - критически важную функцию для отмены выполняющихся операций при прерывании навигации

Navigation API также включён в приоритетные области Interop 2026, что означает активное тестирование кросс-браузерной совместимости со стороны производителей браузеров. Для команд, создающих корпоративные SPA, это означает меньше браузерно-специфичных особенностей по сравнению с более ранними веб-платформенными функциями.

На практике статус Baseline Newly available меняет матрицу принятия решений для корпоративных проектов. Вы можете строить навигацию на Navigation API как основном слое роутинга SPA для современных браузеров, сохраняя существующий роутер (React Router, Vue Router или кастомное решение) как запасной вариант для оставшихся 16% пользователей на старых версиях. Определение поддержки выполняется просто: typeof window.navigation !== 'undefined'.

Почему History API стал техническим долгом для роутеров SPA

History API предоставляет ровно два инструмента для роутинга SPA: popstate для реакции на навигацию "назад"/"вперёд" и pushState/replaceState для изменения URL без перезагрузки страницы. Всё остальное - перехват кликов по ссылкам, обработка отправки форм, управление фокусом после переходов, восстановление позиции скролла - полностью лежит на коде приложения. В небольшом проекте это управляемо. В корпоративных SPA с десятками маршрутов, вложенными лейаутами и несколькими командами, вносящими изменения в код, этот минимальный интерфейс становится источником нарастающей сложности.

Фундаментальная проблема - фрагментированная обработка навигации. Типичное SPA, построенное на History API, требует отдельных механизмов для каждого триггера навигации:

• Клики по ссылкам требуют глобального перехватчика кликов, который проверяет, является ли цель внутренней ссылкой, предотвращает поведение по умолчанию и вызывает pushState
• Назад/вперёд требует слушателя popstate, который парсит URL и запускает ре-рендеринг
• Программная навигация требует прямого вызова pushState плюс ручной диспатчинг пользовательских событий, которые использует ваш роутер
• Отправка форм требует выделенных обработчиков onsubmit, которые предотвращают POST по умолчанию и перенаправляют на нужное представление

Каждый из этих путей может расходиться. В больших кодовых базах разные команды реализуют навигацию по-разному - один модуль использует API роутера, другой вызывает pushState напрямую, третий полагается на window.location для "жёсткой" навигации. Результат - несогласованное поведение: двойные рендеры, маршруты, которые работают при клике, но ломаются при нажатии "назад"/"вперёд", формы, теряющие состояние при навигации. Это типичная проблема при профессиональной разработке сайтов в России, где несколько команд работают над одной кодовой базой.

Управление фокусом усугубляет проблему. После того как pushState меняет URL, браузер ничего не делает с фокусом клавиатуры. Скринридеры не оповещаются о смене контента страницы. Зрячие пользователи клавиатуры могут обнаружить, что их фокус застрял на уже невидимом элементе. Решение требует ручного кода управления фокусом - как правило, регион aria-live или явные вызовы focus() после каждого перехода. Большинство команд либо пропускают это (нарушая соответствие WCAG), либо реализуют непоследовательно на разных маршрутах.

Восстановление скролла - ещё одна болевая точка. Встроенное восстановление скролла History API пытается вернуть позицию прокрутки при навигации назад, но оно конкурирует с загрузкой контента. Если браузер пытается прокрутить до того, как SPA отрендерило целевой контент, позиция оказывается неверной. Обходное решение (history.scrollRestoration = 'manual' плюс кастомная логика) работает, но добавляет ещё один элемент навигационной инфраструктуры, который каждая команда должна поддерживать.

Наконец, History API не даёт доступа к стеку навигации. history.length возвращает счётчик, но не записи. history.state доступен только для текущей записи и может быть потерян. Нельзя проверить, откуда пришёл пользователь, какие записи существуют, или перейти к конкретной записи по ключу. Это делает функции вроде "вернуться к списку из детального представления" ненадёжными без поддержания параллельной структуры состояния.

Navigation API под капотом: navigate, NavigateEvent, canIntercept, intercept()

Navigation API заменяет фрагментированный интерфейс History API единой событийно-ориентированной моделью, построенной вокруг глобального объекта window.navigation. Каждая навигация - будь то клик по ссылке, отправка формы, кнопка "назад"/"вперёд" или программный вызов - генерирует одно событие navigate. Ваш код обрабатывает его в одном месте, а браузер берёт на себя обновление URL, управление историей и фокусом доступности.

Глобальный объект navigation

window.navigation - центральная точка управления. В отличие от window.history, он предоставляет полный список записей навигации в пределах одного источника через navigation.entries(), обеспечивая видимость стека навигации, которую History API никогда не предлагал. Каждая запись имеет url, постоянный key (стабильный в рамках сессии), уникальный id и состояние, доступное через getState().

Объект предоставляет методы навигации, возвращающие промисы: navigate(url), reload(), back(), forward() и traverseTo(key). Каждый возвращает объект с двумя промисами - committed (URL обновлён, запись в истории создана) и finished (обработчик завершён). Эта двухфазная модель позволяет программно отслеживать ход навигации - нечто невозможное с pushState.

Событие navigate

Событие navigate срабатывает для всех типов навигации в пределах документа: клики по якорям, отправка форм с GET или POST, кнопки браузера "назад"/"вперёд" и программные вызовы через navigation.navigate(). Это устраняет необходимость в отдельных перехватчиках кликов, слушателях popstate и обработчиках форм. Один слушатель событий обрабатывает всю навигацию в приложении.

Объект события (NavigateEvent) содержит всё необходимое для принятия решений о маршрутизации: destination.url для целевого URL, navigationType (push, replace, reload, traverse), formData для POST-отправок, canIntercept для проверки возможности перехвата и signal (AbortSignal) для отмены работы при прерывании навигации.

event.intercept() и canIntercept

Вызов event.intercept() преобразует навигацию в переход внутри документа. Браузер обновляет URL, создаёт запись в истории и управляет сбросом фокуса - ваша функция handler() выполняет специфичную для приложения работу: загрузку данных, обновление DOM, рендеринг компонентов. Это разделение ответственности - ключевое архитектурное улучшение по сравнению с History API, где приложение отвечало за всё.

canIntercept - встроенный механизм безопасности. Он возвращает false для навигаций, которые не могут или не должны быть перехвачены: кросс-доменные URL, загрузка файлов и определённые системные навигации. Целевой URL должен иметь тот же origin, что и текущий документ, и отличаться только путём, параметрами или фрагментом. Это предотвращает подмену URL и гарантирует, что ваш обработчик обрабатывает только те навигации, которые он может легитимно обслуживать.

Жизненный цикл навигации

Жизненный цикл следует чёткой последовательности: событие navigate срабатывает, ваш код вызывает intercept() с обработчиком, браузер фиксирует навигацию (обновляет URL, создаёт запись), обработчик выполняется до завершения, навигация завершается. Если промис обработчика отклоняется, навигация помечается как неуспешная. Если новая навигация начинается до завершения обработчика, AbortSignal предыдущего обработчика срабатывает, и новая навигация вступает в силу. Этот жизненный цикл детерминирован и наблюдаем - значительное улучшение по сравнению с неявным, трудно отслеживаемым поведением навигаций History API.

Ключевые возможности: формы, скролл, фокус, AbortSignal

Navigation API нативно обрабатывает четыре возможности, которые разработчики SPA традиционно реализовывали вручную с переменным успехом: перехват отправки форм, восстановление скролла после загрузки контента, управление фокусом для доступности и отмена запросов при уходе пользователя со страницы. Каждая из них теперь является полноценной частью жизненного цикла навигации, а не надстройкой, прикрученной к History API постфактум.

Отправка форм без ручного onsubmit

Когда пользователь отправляет форму через POST, событие navigate срабатывает с заполненным event.formData в виде объекта FormData. Это значит, что обработчик навигации - тот же самый, что обрабатывает все остальные навигации - также обрабатывает отправку форм. Не нужен отдельный слушатель событий onsubmit. Не нужен event.preventDefault() на элементе формы.

Для корпоративных приложений это централизует обработку форм вместе с роутингом. Вы можете добавлять CSRF-токены, trace ID и метаданные аудита в одном месте. Этот паттерн также упрощает тестирование: отправка форм следует тому же жизненному циклу навигации, что и переходы между страницами, с тем же AbortSignal, той же обработкой ошибок и теми же хуками наблюдаемости.

Восстановление скролла без сюрпризов

Классический баг скролла в SPA работает так: пользователь переходит назад на длинную страницу, браузер пытается восстановить позицию прокрутки, но контент ещё не загружен, и страница прокручивается не туда (или никуда). Свойство scrollRestoration History API предлагает бинарный выбор - автоматическое (часто неверное) или ручное (полностью ваша проблема).

Navigation API вводит scroll: 'manual' в параметрах intercept() и специальный метод event.scroll(). Вы устанавливаете scroll: 'manual' для предотвращения преждевременного восстановления, загружаете и рендерите контент, затем вызываете event.scroll(), когда DOM готов. Браузер выполняет фактическое позиционирование скролла (включая якорные ссылки и восстановление скролла для переходов), но только после того, как ваш контент на месте. Это устраняет гонку состояний, которая преследовала восстановление скролла в SPA годами.

Управление фокусом для доступности

После того как intercept() обрабатывает навигацию, браузер автоматически сбрасывает фокус - либо на тело документа, либо на первый элемент с атрибутом autofocus. Это критически важно для пользователей скринридеров: в традиционном SPA, построенном на pushState, скринридер не может узнать, что контент страницы изменился. Пользователи могут продолжать взаимодействовать с элементами, которые уже не видны или не релевантны.

Автоматический сброс фокуса сокращает количество ручных обходных решений для доступности, которые команда должна поддерживать. Вам больше не нужны кастомные ARIA live-регионы для объявления переходов между страницами, и не нужны явные вызовы focus(), разбросанные по обработчикам маршрутов. Поведение согласовано, предсказуемо и встроено в жизненный цикл навигации, а не применяется как заплатка. Команды, заказывающие SEO-аудит сайта, теперь могут проверить соответствие управления фокусом требованиям WCAG без необходимости кастомных патчей для каждого маршрута.

AbortSignal для отмены выполняющихся операций

NavigateEvent.signal - это AbortSignal, который срабатывает автоматически при прерывании текущей навигации - пользователь кликает по другой ссылке, нажимает кнопку "назад" или браузер отменяет навигацию. Передайте этот сигнал в вызовы fetch(), и выполняющиеся запросы будут отменены автоматически, когда они больше не нужны.

Safari 26.3 специально выделил AbortSignal для NavigateEvent как ключевой продакшен-сценарий. Практическое влияние значительно: в корпоративных SPA с интенсивной загрузкой данных прерванные навигации часто оставляют "осиротевшие" сетевые запросы, которые потребляют пропускную способность, серверные ресурсы и могут привести к рендерингу устаревших данных после того, как пользователь уже перешёл на другое представление. С event.signal очистка происходит автоматически и надёжно.

Корпоративные паттерны: построение продакшен-слоя роутинга

В корпоративных SPA навигация - это не просто "переключение страниц", это часть бизнес-процесса. Потоки авторизации, воркфлоу согласований, многошаговые формы, ролевой доступ и маршрутизация по тенантам - всё проходит через слой навигации. Navigation API позволяет создать единый слой роутинга, который централизует эти задачи, заменяя разрозненную логику, которая накапливается вокруг History API в больших кодовых базах.

Паттерн 1: Единый роутер с наблюдаемостью

Один слушатель события navigate заменяет комбинацию перехватчиков кликов, обработчиков popstate и ручных вызовов pushState. Эта единая точка входа делает навигацию наблюдаемой по умолчанию: вы можете отслеживать аналитические события на стадиях старта, успеха, ошибки и отмены без инструментирования множества путей в коде.

navigation.addEventListener('navigate', (event) => {
  if (!event.canIntercept || event.hashChange) return;

  const url = new URL(event.destination.url);

  event.intercept({
    scroll: 'manual',
    async handler() {
      const traceId = crypto.randomUUID();
      analytics.track('navigation_start', { to: url.pathname, traceId });

      try {
        const route = matchRoute(url);
        if (!route) {
          renderNotFound();
          event.scroll();
          return;
        }

        await route.handler({ url, signal: event.signal });
        event.scroll();
        analytics.track('navigation_ok', { to: url.pathname, traceId });
      } catch (error) {
        if (event.signal.aborted) {
          analytics.track('navigation_aborted', { to: url.pathname, traceId });
          return;
        }
        renderError(error);
        analytics.track('navigation_error', { to: url.pathname, traceId });
      }
    }
  });
});

Каждая навигация проходит через этот единственный обработчик. Trace ID коррелируют события навигации фронтенда с бэкенд-запросами в системах распределённой трассировки. Границы ошибок перехватывают сбои в одном месте. Отменённые навигации отличаются от реальных ошибок в дашбордах метрик. Такой уровень наблюдаемости критически важен для команд, инвестирующих в SEO-продвижение в Москве, где производительность переходов между страницами напрямую влияет на Core Web Vitals и поисковые позиции.

Паттерн 2: Гарды маршрутов RBAC/ABAC

Проверки контроля доступа выполняются в обработчике навигации до загрузки контента. С History API гарды обычно разбросаны по компонентам - маршрут рендерится, проверяет разрешения, а затем выполняет редирект. С Navigation API проверка происходит до начала рендеринга:

async function ensureAccess(url: URL, signal: AbortSignal): Promise<void> {
  const requiredRole = getRequiredRole(url.pathname);
  if (!requiredRole) return;

  const user = await fetchCurrentUser({ signal });
  if (!user.roles.includes(requiredRole)) {
    navigation.navigate('/unauthorized', { history: 'replace' });
    throw new Error('Access denied');
  }
}

Это централизует логику авторизации. Фича-флаги и маршрутизация по тенантам следуют тому же паттерну - проверка до рендеринга, редирект при необходимости - всё в одном месте, а не продублировано по дереву компонентов. Организации, работающие с агентством интернет-маркетинга, особенно ценят эту централизацию, поскольку рекламные кампании часто требуют быстрых изменений маршрутов и A/B-тестирования.

Паттерн 3: Отмена запросов при навигации

Привязка fetch-запросов к event.signal обеспечивает автоматическую очистку, когда пользователь уходит со страницы во время загрузки. Это предотвращает распространённый баг корпоративных SPA: рендеринг устаревших данных после того, как пользователь уже перешёл на другое представление, потому что медленный ответ API приходит с задержкой и обновляет DOM.

async function loadDashboardData(signal: AbortSignal) {
  const [metrics, alerts, reports] = await Promise.all([
    fetch('/api/metrics', { signal }).then(r => r.json()),
    fetch('/api/alerts', { signal }).then(r => r.json()),
    fetch('/api/reports', { signal }).then(r => r.json())
  ]);
  return { metrics, alerts, reports };
}

Если пользователь уходит со страницы, пока любой из этих запросов выполняется, все три отменяются автоматически. Никакой ручной очистки, никаких устаревших данных, никаких потраченных впустую серверных ресурсов на обработку запросов, результаты которых никогда не будут отображены.

Стратегия миграции: внедрение Navigation API без переписывания роутера

Миграция на Navigation API не требует замены существующего роутера. Рекомендуемый подход - прогрессивное улучшение: определить поддержку, обернуть текущий роутер адаптером, который делегирует Navigation API при его доступности, и откатиться к существующей реализации на старых браузерах. Это снижает риски и позволяет внедрять новый API постепенно.

Шаг 1: Определение поддержки

Начните с простой проверки во время выполнения:

function supportsNavigationAPI(): boolean {
  return typeof (window as any).navigation !== 'undefined';
}

Эта проверка контролирует всё использование Navigation API. В браузерах без поддержки ваш существующий роутер (React Router, Vue Router или кастомное решение) продолжает работать без изменений.

Шаг 2: Слой-адаптер

Постройте тонкий адаптер, который транслирует NavigateEvent в ваш внутренний формат навигационного намерения. Этот адаптер располагается между Navigation API браузера и логикой маршрутизации приложения:

interface NavigationIntent {
  url: URL;
  type: 'push' | 'replace' | 'traverse';
  signal: AbortSignal;
  formData?: FormData;
}

function createAdapter(onNavigate: (intent: NavigationIntent) => Promise<void>) {
  if (!supportsNavigationAPI()) return;

  navigation.addEventListener('navigate', (event) => {
    if (!event.canIntercept || event.hashChange) return;

    event.intercept({
      scroll: 'manual',
      async handler() {
        await onNavigate({
          url: new URL(event.destination.url),
          type: event.navigationType === 'traverse' ? 'traverse' : event.navigationType,
          signal: event.signal,
          formData: event.formData ?? undefined
        });
        event.scroll();
      }
    });
  });
}

Ваши существующие обработчики маршрутов получают стандартизированный объект намерения. Им не нужно знать, пришла ли навигация от Navigation API или устаревшего роутера.

Шаг 3: Поэтапное развёртывание

Включите обработку Navigation API сначала для определённых разделов приложения. Фича-флаг контролирует, какие маршруты используют новый адаптер:

• Начните с read-only страниц (дашборды, отчёты), где навигация проста
• Перейдите к потокам с формами после проверки поведения скролла и фокуса
• Добавьте обработку переходов "назад"/"вперёд" после подтверждения стабильного поведения end-to-end тестами
• Отслеживайте метрики навигации: процент успеха, процент отмен, процент ошибок, time-to-interactive по маршрутам

Шаг 4: Снижение рисков

Используйте канареечные развёртывания для тестирования роутинга через Navigation API на подмножестве пользователей. Отслеживайте метрики навигации отдельно для канареечной группы. Держите план отката, который отключает фича-флаг без развёртывания кода. Для примерно 16% пользователей на браузерах без поддержки Navigation API ваш существующий роутер продолжает функционировать - для них ничего не меняется.

Navigation API и View Transitions: полированный UX как прогрессивное улучшение

Navigation API естественно интегрируется с View Transitions API через document.startViewTransition(), позволяя создавать анимированные переходы между представлениями SPA. Обработчик navigate - идеальное место для запуска визуальных переходов, поскольку он контролирует момент, когда старый контент удаляется и появляется новый.

event.intercept({
  async handler() {
    const data = await fetchPageData(event.destination.url, event.signal);

    if (document.startViewTransition) {
      const transition = document.startViewTransition(() => {
        renderPage(data);
      });
      await transition.finished;
    } else {
      renderPage(data);
    }

    event.scroll();
  }
});

В корпоративном контексте анимированные переходы следует рассматривать как визуальное улучшение, а не как обязательное требование. Учитывайте пользовательские предпочтения: медиа-запрос prefers-reduced-motion должен управлять анимациями переходов. Учитывайте производительность: на медленных устройствах или сложных лейаутах переходы могут замедлить воспринимаемую скорость навигации. Учитывайте согласованность: переходы, добавляющие визуальную ясность (список-в-деталь, переключение вкладок), стоят реализации, тогда как переходы на каждой смене маршрута создают лишний визуальный шум.

Практичный подход - включить визуальные переходы только там, где они улучшают рабочий поток - например, плавное затемнение при переходе от списка к детальному представлению помогает пользователям сохранить пространственный контекст. Сотрудничество с профессиональной командой веб-дизайна помогает определить, где переходы действительно улучшают восприятие. Избегайте добавления переходов исключительно ради эстетики. В корпоративных приложениях быстрая и предсказуемая навигация важнее красивых анимаций.

Справочник по ключевым интерфейсам Navigation API

Navigation API состоит из шести основных интерфейсов, которые вместе обеспечивают полный контроль над клиентской навигацией. Понимание их ролей и взаимосвязей необходимо для эффективной работы с этим API.

Объект Navigation в деталях

window.navigation заменяет window.history как основной интерфейс управления навигацией. Метод entries() возвращает массив объектов NavigationHistoryEntry для всех записей в пределах одного origin в текущей сессии - то, что History API никогда не предоставлял. У каждой записи есть стабильный key, сохраняющийся на протяжении сессии, что обеспечивает надёжное поведение "перейти к конкретной записи" через traverseTo(key).

Методы навигации возвращают пару промисов { committed, finished }. committed разрешается, когда URL и запись в истории обновлены. finished разрешается, когда промис обработчика завершён. Эта двухфазная модель обеспечивает точное отслеживание хода навигации - вы точно знаете, когда URL изменился и когда контент готов.

Свойства NavigateEvent

NavigateEvent - рабочая лошадка API. Свойство navigationType различает навигации push, replace, reload и traverse. Свойство destination предоставляет целевой URL, состояние и информацию о том, является ли навигация внутридокументной. Свойство formData не равно null только для POST-отправок форм. Свойство signal предоставляет AbortSignal, привязанный к жизненному циклу навигации.

Метод intercept() принимает объект параметров с handler (асинхронная функция для логики маршрутизации), scroll (автоматический или ручной) и focusReset (автоматический или ручной). Эти параметры позволяют контролировать весь навигационный опыт, пока браузер берёт на себя управление URL и историей.

Ограничения и граничные случаи: объективная оценка

Navigation API - существенное улучшение по сравнению с History API, но у него есть чёткие границы, которые влияют на архитектуру приложения. Понимание этих ограничений заранее предотвращает сюрпризы при реализации и помогает спланировать подходящие фоллбэки.

• Нет события navigate при первоначальной загрузке страницы. Событие navigate не срабатывает при первой загрузке страницы. Серверно-рендеренные приложения не затронуты, но SPA с клиентским рендерингом нуждаются в отдельном пути инициализации для первого маршрута. Это значит, что ваш код инициализации не может полагаться исключительно на обработчик navigate.
• Область действия - один фрейм. Navigation API работает в рамках одного контекста просмотра - либо окна верхнего уровня, либо одного iframe. Он не обрабатывает кросс-фреймовую навигацию. Архитектуры микро-фронтендов, использующие iframe, должны координировать навигацию через другие механизмы (postMessage, общее состояние).
• Нет модификации истории. Нельзя программно переупорядочить, удалить или изменить записи в истории навигации. navigation.entries() доступен только для чтения. Если вашему приложению нужно очищать записи истории (например, удалить запись "шаг 2" при завершении визарда), это по-прежнему невозможно.
• Ограничения canIntercept. Кросс-доменные навигации, загрузки файлов и определённые системные навигации возвращают canIntercept: false. Ваш код должен проверять это свойство перед вызовом intercept() и иметь корректный фоллбэк для неперехватываемых навигаций.
• Гонка скролла без явного управления. Если вы используете поведение скролла по умолчанию вместо scroll: 'manual', браузер всё ещё может попытаться восстановить позицию прокрутки до загрузки контента. В SPA с асинхронной загрузкой контента всегда используйте ручное управление скроллом.
• Разрыв в покрытии браузерами. Примерно 16,34% глобальных пользователей находятся на браузерах, не поддерживающих Navigation API. Это немалое число - сюда входят старые мобильные устройства, корпоративные браузеры, привязанные к определённым версиям, и специализированные среды. Стратегия фоллбэка обязательна, а не опциональна.

Эти ограничения управляемы при правильной архитектуре. Navigation API спроектирован как слой навигации внутри одного документа и одного origin - не как универсальный контроллер навигации. Рассматривайте его как основу для клиентского роутинга и обрабатывайте граничные случаи (первоначальная загрузка, кросс-доменные переходы, старые браузеры) через явные пути в коде. Командам, работающим над GEO-продвижением и AI SEO в России, стоит особенно внимательно учитывать эти границы, поскольку AI-краулеры и LLM-агенты по-разному интерпретируют навигацию SPA по сравнению с традиционными поисковыми ботами.

Как Navigation API соотносится с популярными роутерами SPA

Navigation API работает на уровне браузерной платформы, обрабатывая задачи, которые фреймворковые роутеры исторически реализовывали на JavaScript: управление URL, отслеживание истории, сброс фокуса и поведение скролла. Фреймворковые роутеры (React Router, Vue Router, Angular Router) обрабатывают задачи уровня приложения: рендеринг дерева компонентов, загрузку данных, code splitting по маршрутам и вложенность лейаутов. Это дополняющие друг друга слои, а не конкуренты.

Navigation API - не замена React Router или Vue Router "один в один". Он заменяет нижележащий платформенный примитив, на котором построены эти роутеры. Считайте это заменой фундамента, а не дома. Фреймворковые роутеры, вероятно, со временем примут Navigation API в качестве внутреннего движка, предлагая тот же разработческий API, но с лучшей платформенной интеграцией внутри.

Для команд, создающих кастомные роутеры или решающих, стоит ли использовать фреймворковый роутер, Navigation API предоставляет достаточно функциональности на уровне платформы, чтобы построить легковесный слой маршрутизации без зависимости от сторонней библиотеки для базовых вещей. Платформа обрабатывает URL, историю, фокус, скролл и отмену - ваш код обрабатывает сопоставление маршрутов, рендеринг и управление данными. Это особенно актуально для платформ недвижимости и других нагруженных данными отраслевых приложений, где легковесный роутинг уменьшает размер бандла и улучшает производительность загрузки.

Пример кода: полноценный навигационный роутер для корпоративного SPA

Продакшен-роутер, построенный на Navigation API, требует определения поддержки, сопоставления маршрутов, гардов доступа, хуков наблюдаемости, обработки ошибок и управления скроллом - всё объединённое через один слушатель события navigate. Ниже представлена полная реализация на TypeScript, демонстрирующая каждый корпоративный аспект в контексте.

// navigation-router.ts
// Продакшен-роутер на Navigation API с корпоративными задачами

type RouteHandler = (ctx: {
  url: URL;
  params: Record<string, string>;
  signal: AbortSignal;
  formData?: FormData;
}) => Promise<void>;

interface Route {
  pattern: URLPattern;
  handler: RouteHandler;
  requiredRole?: string;
}

const routes: Route[] = [];

export function defineRoute(
  path: string,
  handler: RouteHandler,
  options?: { requiredRole?: string }
) {
  routes.push({
    pattern: new URLPattern({ pathname: path }),
    handler,
    requiredRole: options?.requiredRole
  });
}

// Определение поддержки с фоллбэком
export function bootstrapRouter(legacyRouter: () => void) {
  if (typeof (window as any).navigation === 'undefined') {
    console.info('[Router] Navigation API не поддерживается, используем устаревший роутер');
    legacyRouter();
    return;
  }

  console.info('[Router] Navigation API обнаружен, инициализируем');

  navigation.addEventListener('navigate', (event: any) => {
    if (!event.canIntercept) return;
    if (event.hashChange) return;

    const url = new URL(event.destination.url);
    const matched = routes.find(r => r.pattern.test(url));

    if (!matched) return; // Браузер обработает несопоставленные маршруты

    event.intercept({
      scroll: 'manual',
      async handler() {
        const traceId = crypto.randomUUID();
        const startTime = performance.now();

        analytics.track('nav_start', {
          to: url.pathname,
          type: event.navigationType,
          traceId
        });

        try {
          // 1. Гард доступа
          if (matched.requiredRole) {
            const user = await fetchCurrentUser({ signal: event.signal });
            if (!user.roles.includes(matched.requiredRole)) {
              navigation.navigate('/unauthorized', { history: 'replace' });
              return;
            }
          }

          // 2. Извлечение параметров маршрута
          const result = matched.pattern.exec(url);
          const params = result?.pathname?.groups ?? {};

          // 3. Выполнение обработчика маршрута
          await matched.handler({
            url,
            params,
            signal: event.signal,
            formData: event.formData ?? undefined
          });

          // 4. Скролл после рендеринга
          event.scroll();

          analytics.track('nav_ok', {
            to: url.pathname,
            traceId,
            duration: performance.now() - startTime
          });
        } catch (error) {
          if (event.signal.aborted) {
            analytics.track('nav_aborted', { to: url.pathname, traceId });
            return;
          }

          console.error('[Router] Навигация не удалась:', error);
          renderError(error);

          analytics.track('nav_error', {
            to: url.pathname,
            traceId,
            error: (error as Error).message
          });
        }
      }
    });
  });
}

Этот роутер обрабатывает полный жизненный цикл примерно в 80 строках кода: определение поддержки с фоллбэком на устаревший роутер, сопоставление маршрутов через встроенный URLPattern API, ролевые гарды доступа с поддержкой AbortSignal, извлечение параметров, границы ошибок, аналитику навигации с таймингами и ручное управление скроллом. Каждый аспект обрабатывается в том порядке, в котором он важен во время навигации.

Обработка форм с CSRF и трассировкой

Отправка форм проходит через тот же роутер. Свойство formData отличает навигации с формами от обычных переходов между страницами:

defineRoute('/api/submit-order', async ({ formData, signal }) => {
  if (!formData) throw new Error('Ожидалась отправка формы');

  // Добавить корпоративные метаданные
  formData.set('csrf_token', getCSRFToken());
  formData.set('trace_id', crypto.randomUUID());
  formData.set('tenant_id', getCurrentTenantId());

  const response = await fetch('/api/orders', {
    method: 'POST',
    body: formData,
    signal
  });

  if (!response.ok) {
    throw new Error(`Отправка заказа не удалась: ${response.status}`);
  }

  const order = await response.json();
  renderOrderConfirmation(order);
});

CSRF-токены, trace ID и контекст тенанта добавляются в одном месте. Если пользователь уходит со страницы до завершения отправки, AbortSignal автоматически отменяет запрос.

Заключение

Navigation API со статусом Baseline Newly available - один из тех редких случаев, когда браузерная платформа догнала то, что фронтенд-команды строили вручную годами. Унифицированный жизненный цикл навигации, встроенное управление фокусом, контролируемое восстановление скролла и автоматическая отмена запросов через AbortSignal решают системные проблемы, из-за которых History API был дорогим в поддержке для корпоративных SPA.

• Унифицированный жизненный цикл: одно событие navigate заменяет фрагментированную комбинацию перехватчиков кликов, слушателей popstate и ручных вызовов pushState
• Доступность по умолчанию: автоматическое управление фокусом после навигации устраняет наиболее распространённое нарушение WCAG в одностраничных приложениях
• Надёжный скролл: ручное управление скроллом через event.scroll() решает многолетнюю гонку состояний между загрузкой контента и восстановлением позиции прокрутки
• Очистка запросов: event.signal автоматически отменяет выполняющиеся запросы при прерывании навигации, предотвращая рендеринг устаревших данных и напрасную трату серверных ресурсов
• Безрисковое внедрение: прогрессивное улучшение через определение поддержки позволяет внедрять Navigation API без отказа от поддержки старых браузеров - ваш существующий роутер выступает фоллбэком

С глобальным покрытием 83,66% браузеров и включением в приоритетные области Interop 2026, Navigation API готов к продакшен-использованию в современных веб-проектах. Для команд, поддерживающих сложные SPA - особенно в B2B и корпоративном контексте, где надёжность навигации напрямую влияет на бизнес-процессы - этот API сокращает объём кастомной инфраструктуры, необходимой для создания стабильного, доступного и наблюдаемого слоя роутинга.

Если вы планируете корпоративное SPA или модернизируете навигационную архитектуру существующего приложения, рассмотрите стратегию прогрессивного улучшения, описанную в этой статье. Переход с History API на Navigation API может происходить постепенно, один маршрут за другим, с измеримыми улучшениями в простоте кода, соответствии стандартам доступности и удобстве разработки.