Soft Navigations API у Chrome 151 нарешті дозволяє односторінковим застосункам (SPA) звітувати про Core Web Vitals для кожного переходу всередині застосунка, проте набір даних Google CrUX все ще фіксує лише перше «жорстке» завантаження (hard load), що створює для розробників дві різні картини продуктивності.

Чому метрики SPA відставали

Core Web Vitals — Largest Contentful Paint (LCP), Interaction-to-Next-Paint (INP) та Cumulative Layout Shift (CLS) — були розроблені з урахуванням жорстких переходів (hard navigations). Жорсткий перехід завантажує абсолютно новий документ і скидає стан попередньої сторінки.

SPA, побудовані на React, Vue, Next.js або подібних фреймворках, рідко ініціюють жорсткі переходи. Натискання на посилання оновлює URL через History API, завантажує дані у фоновому режимі та замінює контент без повного перезавантаження сторінки. Існуючий Performance API фіксує лише початкове завантаження сторінки, тому LCP та INP не враховують затримку, яку відчувають користувачі під час переходу з одного маршруту на інший.

Ця «сліпа зона» спотворює дані на дашбордах, які отримують інформацію з Performance Timeline або Google Chrome User Experience Report (CrUX). Вони часто показують чудовий показник LCP для сторінки-оболонки (shell), ігноруючи при цьому повільніші завантаження всередині застосунка, що створює хибне враження про високу продуктивність.

Soft Navigations API у Chrome

Chrome 151 представив Soft Navigations API — набір евристик, які розглядають певні взаємодії в SPA як справжні переходи. API відстежує три сигнали:

  • Взаємодія, ініційована користувачем (клік, тап, подія клавіатури)
  • Зміна URL через History API
  • Подальші події малювання (paint events), що рендерять новий контент

Коли всі три умови виконуються, Chrome реєструє м'який перехід (soft navigation) у Performance Timeline, і Core Web Vitals розраховуються для цього переходу так само, як і для жорсткого. Open-source бібліотека web-vitals додала підтримку 21 липня, тож розробники вже можуть отримувати ці дані за допомогою того самого API, який вони вже використовують.

На практиці тепер можна побачити значення LCP для кожної зміни маршруту, INP, що відображає реальну затримку останнього введення користувача, та CLS, який фіксує зсуви макета після м'якого переходу.

Розбіжність даних: Chrome проти CrUX

Google CrUX (Chrome User Experience Report) є основою для PageSpeed Insights, Search Console і, опосередковано, для сигналів ранжування. CrUX все ще агрегує лише дані про жорсткі переходи.

Як наслідок, ви отримуєте два послідовні, але різні потоки даних:

  • Внутрішні інструменти, які зчитують Performance Timeline, тепер показують LCP, INP та CLS на рівні маршрутів, що дає реалістичне уявлення про досвід користувачів у SPA.
  • Публічні набори даних Google продовжують показувати метрики лише для першого завантаження сторінки — саме ці дані відображаються в Search Console і використовуються алгоритмами ранжування Google.

Обидва варіанти правильні; вони просто вимірюють різні моменти. Покладанняся лише на Search Console може приховати регресії продуктивності, що виникають після початкового завантаження, тоді як одні лише внутрішні дашборди не відображатимуть базовий рівень, який Google використовує для SEO.

На що варто звернути увагу розробникам

  • Підтримка браузерами — На сьогодні Soft Navigations API доступний лише у браузерах на базі Chromium. У Safari та Firefox аналога немає, тому необхідно зберігати логіку відкату (fallback) для частини вашої аудиторії.
  • Обмеження евристики — API визначає м'який перехід на основі набору ознак. Якщо ваш застосунок оновлює контент без зміни URL (наприклад, модальні вікна або нескінченний скрол), API може пропустити ці переходи, що призведе до прогалин у даних.
  • Перевірка перед використанням — Оскільки виявлення базується на евристиці, запустіть набір реальних взаємодій у вашому застосунку та порівняйте отримані метрики з ручним вимірюванням часу (наприклад, за допомогою performance.mark). Тільки після підтвердження точності варто приймати рішення щодо оптимізації на основі нових показників.

Підсумок

Chrome 151 надає розробникам SPA довгоочікувану можливість вимірювати LCP, INP та CLS для кожної зміни маршруту всередині застосунка, проте дані Google для ранжування все ще відображають лише перше жорстке завантаження. Поки CrUX не наздожене цей рівень, командам доведеться працювати з двома паралельними наборами даних: одним, що відображає реальний досвід користувачів, і іншим, що впливає на пошукове ранжування. Балансування між ними — і підготовка до ширшої підтримки браузерами — стане ключем до підтримки продуктивності SPA в конкурентному веб-середовищі.