Chrome навчився правильно вимірювати швидкість SPA-сайтів
Уявіть, що у вас сайт на React чи Next.js із client-side переходами: людина клікає на посилання, URL у браузері змінюється, контент оновлюється — а повного перезавантаження сторінки не відбувається. Це називається "м'яка навігація" (soft navigation), і саме так влаштована більшість сучасних односторінкових застосунків (SPA).
Проблема в тому, що донедавна браузер просто не бачив ці переходи. Для нього існувало лише "перше завантаження сторінки" — і все, що відбувалося далі, випадало з поля зору стандартних інструментів вимірювання швидкості.
У чому конкретно проблема
Core Web Vitals — три метрики, за якими Google оцінює якість сайту (LCP, INP, CLS) — вимірюються двома способами: самим браузером через Chrome User Experience Report (CrUX) і сайтами самостійно через Real User Monitoring (RUM). Обидва способи спираються на подію "навігація" як точку відліку.
Для звичайного багатосторінкового сайту це логічно: кожен клік по посиланню = нова навігація = нові вимірювання з нуля. Але для SPA один-єдиний "запуск" сторінки міг тривати годинами, поки людина клікає по розділах застосунку — і всі ці внутрішні переходи, включно з повільними й незручними, просто не потрапляли в жодну статистику. Власник сайту бачив чудові показники швидкості першого завантаження й нічого не знав про те, що відбувається далі.
Що змінюється
У Chrome 147 команда розробників браузера запустила фінальний етап тестування Soft Navigations API — origin trial, який діятиме до Chrome 149. Це остання перевірка перед тим, як функціонал стане доступний усім сайтам без спеціальних прапорців.
Технічно це виглядає так: з'являються два нових типи записів у Performance API — SoftNavigationEntry і InteractionContentfulPaint. Браузер тепер розпізнає момент, коли JavaScript перехопив клік по посиланню, оновив URL і змінив вміст сторінки — і трактує це як повноцінну навігацію зі своєю точкою відліку для вимірювань.
Це особливо важливо для INP (Interaction to Next Paint) — метрики, яка показує, наскільки швидко сайт реагує на дії користувача. Раніше дані про взаємодії на різних "екранах" SPA-застосунку змішувалися в одну купу. Тепер розробники можуть "нарізати" ці дані по межах м'яких навігацій і побачити, наприклад, що перехід із каталогу товарів у кошик гальмує на секунду, навіть якщо перше завантаження сайту відбувається миттєво.
Чому це має значення для вас
Якщо ваш сайт — це класичний набір статичних сторінок (HTML + мінімум JavaScript), ця новина вас напряму не стосується: браузер і так коректно вимірює кожен перехід.
Але якщо сайт побудований як SPA — інтернет-магазин з "миттєвими" переходами між категоріями, застосунок з особистим кабінетом, будь-який складний інтерфейс на React/Vue/Next.js із клієнтським роутингом — до цього моменту ви фактично літали наосліп після першого екрана. Могли пройти місяці, поки реальна повільна взаємодія десь усередині застосунку відлякувала клієнтів, а метрики в Search Console чи PageSpeed Insights цього просто не показували.
Практична порада вже зараз: якщо у вас SPA, варто протестувати нову функціональність через прапорці Chrome або токен origin trial і подивитися дані через оновлену бібліотеку web-vitals. Панелі продуктивності в DevTools це вже підтримують, починаючи з Chrome 145. Для перевірки не обов'язково чекати повного релізу — можна вже зараз побачити, чи ховаються у вашому застосунку повільні внутрішні переходи, про які ви навіть не підозрювали.
Що це означає для бізнесу, а не лише для розробників
Якщо ви власник інтернет-магазину чи сервісу і не пишете код самостійно — все одно варто знати про цю зміну, бо вона напряму вплине на те, як Google бачитиме ваш сайт. Коли Soft Navigations API стане стандартом (а не експериментом), дані про реальну швидкість SPA почнуть враховуватися повноцінно — включно з тими "незручними" внутрішніми переходами, які раніше лишались непоміченими. Це означає, що показники в Google Search Console можуть змінитися — не тому, що сайт став повільнішим, а тому, що вимірювання стали точнішими й почали враховувати те, що реально відчувають відвідувачі. Варто заздалегідь запитати у вашого розробника чи агенції, чи готовий застосунок до коректного вимірювання внутрішніх переходів, а не лише першого екрана.