У CrUX з’явилися експериментальні Core Web Vitals для переходів усередині SPA

Chrome додав до Chrome User Experience Report (CrUX) експериментальні версії всіх трьох Core Web Vitals, які враховують переходи всередині односторінкових застосунків без повного перезавантаження. Як пише Search Engine Journal, дані доступні починаючи з випуску CrUX від 13 жовтня в BigQuery, CrUX API та History API. Якщо ваш сайт використовує такі переходи, уже можна порівняти стабільні й експериментальні показники в CrUX Vis. Стабільні оцінки поки не змінилися.

Як CrUX враховує переходи всередині застосунку

Раніше CrUX вимірював перше завантаження односторінкового застосунку. Подальші взаємодії та зсуви макета зараховувалися до початкової сторінки, навіть коли людина вже перейшла до іншого вмісту. Через це було складно зрозуміти, як працюють окремі маршрути застосунку: їхні показники не відображалися окремо в даних для відповідних URL.

Тепер експериментальні версії LCP, INP і CLS охоплюють і повні завантаження, і виявлені «м’які» переходи. Chrome розпізнає такий перехід, якщо після дії користувача змінюється видимий URL і на екрані з’являється оновлений вміст. Метрики цього перегляду зараховуються до цільового URL — за умови дотримання звичайних правил включення даних до CrUX.

Для виявлення переходів використовується Soft Navigations API. Його ввімкнено за замовчуванням починаючи з Chrome 151, випущеного 28 липня. Нові показники існують поряд зі стабільними, а не замість них: у CrUX Vis з’явився перемикач Include soft navigations, який дає змогу порівняти обидва варіанти.

Де оцінки можуть помітно відрізнятися

Для більшості ресурсів різниця, імовірно, буде невеликою. Залежно від платформи у 66–75% джерел даних (origins) у CrUX — одиниць, за якими у звіті згруповано перегляди, — частка «м’яких» переходів становить менш ніж 5%. Понад половину переглядів такі переходи становлять у 7,0% origins на Android і 10,6% на комп’ютерах. Серед тисячі найбільших ресурсів ці частки вищі: 35% на Android і 42% на комп’ютерах.

Коли більшість переглядів припадає на переходи без перезавантаження, експериментальні оцінки всіх трьох метрик поліпшуються. Серед origins на Android із часткою таких переходів від 75% до 100% хорошу оцінку LCP отримують 26% за стабільною метрикою і 87% за експериментальною. Це не означає, що односторінкові застосунки загалом швидші за сайти, де кожна сторінка завантажується заново. За поясненням Chrome, наступні переходи зазвичай швидші за перше відкриття незалежно від того, як влаштований сайт.

Для INP змінюється розподіл взаємодій: швидкість відгуку оцінюється в межах окремого перегляду, а не за найповільнішою взаємодією за весь сеанс. Серед origins на Android, які переважно використовують «м’які» переходи, частка тих, що відповідають порогу INP, приблизно подвоюється. Водночас вони й далі відстають від ресурсів із повним завантаженням сторінок: інтенсивна робота JavaScript під час зміни вмісту може впливати на швидкість відгуку.

Зсуви макета в експериментальному CLS також розподіляються між переглядами, а не накопичуються за весь сеанс. На комп’ютерах це ставить ресурси з великою часткою «м’яких» переходів приблизно на один рівень із багатосторінковими сайтами; на Android невелике відставання зберігається. У вересневому наборі даних частка origins із хорошими Core Web Vitals становила 55,9% без урахування «м’яких» переходів і 59,5% з їх урахуванням.

Що робити власнику сайту й команді

Якщо сайт змінює вміст і URL без повного перезавантаження, розробникам варто ввімкнути перемикач у CrUX Vis. Порівняння покаже, наскільки відрізняються оцінки і яка метрика змінюється найбільше, коли внутрішні переходи розглядаються окремо. Якщо кожен перехід супроводжується повним завантаженням сторінки, помітної різниці очікувати не варто.

Власникам сайтів і маркетологам я б радив не сприймати поліпшення експериментальних оцінок як свідчення того, що інтерфейс став швидшим. Сайт не змінився: змінився спосіб віднесення вимірювань до переглядів і URL. Обговорюючи результати з командою, краще уточнювати, які саме показники ви порівнюєте, особливо якщо йдеться про односторінковий сервіс.

Поки ці метрики залишаються експериментальними, а Chrome попереджає про можливі зміни результатів від місяця до місяця в міру вдосконалення вимірювань. У листопадовому випуску CrUX очікуються показники FCP і типів навігації з урахуванням «м’яких» переходів. Chrome планує завершити експериментальний етап у травні 2027 року, але термін залежить від зворотного зв’язку. Коли метрики вийдуть з експериментального статусу, нові дані має почати використовувати Search Console; якого статусу вони набудуть далі, у матеріалі не уточнюється.

Моя думка: важливий не лише перший екран

Мені подобається, що вимірювання стає ближчим до того, як людина користується односторінковим інтерфейсом: вона не припиняє роботу після першого завантаження. Особливо у складному сервісі хочеться бачити не лише швидкість входу, а й те, що відбувається після вибору розділу чи наступного кроку.

Водночас я б не показував команді зростання частки хороших оцінок LCP як доказ того, що проблему вирішено. Перехід може допомагати людині рухатися далі — або змушувати її чекати наступної дії. Експериментальні дані допомагають точніше сформулювати запитання, а відповідь я б шукав у конкретному сценарії, починаючи з того, як він сприймається на мобільному екрані.

Джерела

Звідки новина. Текст — переказ своїми словами, факти — з джерела, думка — автора.

1. Google Adds Experimental Soft Navigation Metrics To CrUX via @sejournal, @MattGSouthern www.searchenginejournal.com

Про автора

Павло Воронов

UX/UI-дизайнер продуктових сервісів

Проєктую інтерфейси й допомагаю командам домовитися про те, що справді потрібно користувачеві. Люблю оцінювати швидкість не лише за Lighthouse, а й за відчуттями людини.

Усі публікації автора