PageSpeed Insights: як перевірити швидкість сторінки сайту

PageSpeed Insights допомагає перевірити завантаження й роботу сторінки на телефоні та комп'ютері. Сервіс показує лабораторні діагностики, а коли даних достатньо, також узагальнений досвід реальних відвідувачів. Важливо читати причини проблем, а не тільки кольоровий бал.

Для власника бізнесу результат має перетворитися на конкретне завдання: яку сторінку перевіряли, що саме затримується та як повторити перевірку після змін. Короткий огляд сервісу є в каталозі FBD.

Як провести першу перевірку

1. Відкрийте PageSpeed Insights і введіть публічну адресу важливої сторінки.
2. Дочекайтеся звіту і перегляньте окремо мобільний та десктопний режими.
3. Відмітьте, чи є польові дані для конкретної сторінки або лише для домену загалом. Відсутність даних не означає, що сторінка швидка або повільна.
4. Перегляньте лабораторні діагностики й конкретні ресурси, пов'язані з найбільшою затримкою.
5. Збережіть адресу, час перевірки та умови. Повторіть тест, щоб не робити висновок з одного запуску.

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

Польові й лабораторні дані: у чому різниця

Польові дані CrUX узагальнюють досвід частини реальних користувачів Chrome за попередній період. Вони показують реальні пристрої та мережі, але не завжди доступні для невеликого сайту або окремої сторінки. Лабораторний тест Lighthouse проводить окреме вимірювання в контрольованих умовах і допомагає шукати причини затримок.

Після виправлення лабораторний результат може змінитися одразу, а накопичений польовий звіт оновлюється поступово. Ці типи вимірювання не зобов'язані збігатися. Їх розрізняє й документація Google про PageSpeed Insights.

На які показники звернути увагу

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

Google рекомендує оцінювати Core Web Vitals за 75-м процентилем польових завантажень, окремо для мобільних і комп'ютерів. Орієнтири та визначення наведені в документації web.dev. Лабораторний бал продуктивності не дорівнює оцінці реального досвіду кожного відвідувача.

Які сторінки перевірити першими

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

Для кожної адреси запишіть дату, режим перевірки, наявність польових даних та головні спостереження. Відкрийте сторінку й самостійно: чи видно ключову пропозицію, чи не стрибають кнопки, чи вдається надіслати форму? Це доповнить звіт перевіркою реального шляху користувача.

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

Як читати польовий звіт

Польові дані PageSpeed використовують агрегований досвід частини користувачів Chrome за попередні 28 днів. Це не вимірювання всіх відвідувачів сайту. Якщо для конкретної адреси даних недостатньо, сервіс може показати узагальнення для ресурсу загалом або не показати польових даних взагалі. Перевіряйте підпис звіту, перш ніж робити висновок про окрему сторінку.

Оцінка Core Web Vitals використовує 75-й процентиль: значення, у межах якого перебувають 75% зафіксованих вимірювань відповідної метрики. Це допомагає оцінити типовий досвід більшості відвідувань, але не означає, що решта людей не стикається з проблемами. Мобільні та комп'ютерні результати аналізуйте окремо.

За достатніх даних орієнтири Google для хорошого досвіду такі: LCP до 2,5 секунди, INP до 200 мілісекунд, CLS до 0,1. Дивіться не лише на цифру, а й на розподіл досвіду. Опис умов і винятків наведено в довідці Google.

Що означає кожна метрика для відвідувача

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

INP описує чутливість сторінки до взаємодій протягом відвідування. Наприклад, людина натискає кнопку меню або відправлення форми й очікує видимої реакції. Високий показник може вказувати на затримки, але потрібно дослідити конкретні взаємодії та обставини. Окремий лабораторний запуск не вимірює всі реальні взаємодії користувачів.

CLS описує неочікуване зміщення елементів. Уявімо, що людина збирається натиснути кнопку, а над нею пізно з'являється блок і зміщує її. Для діагностики варто перевіряти розміри зображень, рекламні чи інші блоки, що з'являються пізніше. Причина залежить від конкретної сторінки.

Лабораторні дані: як знайти наступну дію

Лабораторне вимірювання Lighthouse запускає сторінку в заданих умовах і надає діагностику. Воно корисне для перевірки змін, хоча не відтворює всі пристрої, мережі й сценарії відвідувачів. Результат може коливатися між запусками, тому повторіть тест і порівняйте кілька результатів за однакової адреси та режиму.

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

Лабораторний бал це зручний сигнал, але він не є відсотком задоволених людей чи гарантією позиції в Google. Оцінка 100 не перевіряє зміст статті, наявність індексації та успішність відправлення заявки.

Умовний приклад пріоритетів для малого бізнесу

Уявімо, що власниця перевірила головну сторінку, сторінку послуги та статтю. На сторінці послуги головне зображення з'являється із затримкою, а форма працює. На статті частина тексту зміщується після завантаження медіа. Це вигаданий приклад, а не результати перевірки FBD.

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

Не визначайте пріоритет лише за найнижчим балом. Врахуйте важливість сторінки, кількість відвідувачів, серйозність проблеми та зусилля на виправлення. Якщо даних про відвідування немає, запишіть припущення та перевірте його пізніше.

Що передати розробнику

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

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

Чому мобільний і комп'ютерний звіти різняться

Пристрої та умови мережі відрізняються, тому сторінка, яка комфортно працює на комп'ютері, може бути повільнішою на телефоні. Мобільний звіт також використовує окремі лабораторні умови. Порівнюйте кожний режим сам із собою до та після змін, а польові результати переглядайте відповідно до типу пристрою.

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

Як діяти, якщо польових даних немає

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

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

Як перевірити результат після виправлення

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

Польові дані охоплюють попередній період, тому частина спостережень після виправлення ще певний час відображатиме стару версію. Повторно перегляньте їх після накопичення нових даних. Збережіть дату впровадження, щоб розуміти, які відвідування могли припадати на стару сторінку.

Приклад завдання для розробника

Уявімо, що на сторінці послуги довго з'являється головне зображення. Передайте розробнику адресу, дату та посилання на звіт, режим перевірки і конкретну діагностику. Попросіть з'ясувати, який елемент визначає LCP і що затримує його завантаження або відображення.

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

Для підготовки окремих зображень можна скористатися інструментом FBD. Для перевірки пошукових запитів та індексації потрібна Google Search Console: PageSpeed ці задачі не замінює.

Якщо затримка пов'язана із зображенням, перевірте розміри, формат і якість файлу. А для аналізу інших частин сторінки скористайтеся порядком перевірки SEO-матеріалу. Порівняння сайтів конкурентів у контексті пропозицій описано в повній інструкції конкурентного аналізу.

Коротка нотатка для повторної перевірки

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

Поширені запитання

Чому польових даних немає?

Для сторінки або ресурсу може бракувати достатніх даних CrUX. Скористайтеся лабораторною діагностикою та окремою перевіркою роботи сторінки, не вважаючи це польовим результатом.

Чи потрібно прагнути оцінки 100?

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

Чи покращить швидкість позиції автоматично?

Гарантії немає. Швидкість є частиною досвіду сторінки, а видимість у пошуку залежить від багатьох факторів, зокрема змісту та доступності сторінки.