Більшість вітрин гальмують не там, де показує звіт. Робота починається з Chrome UX Report по вашому origin, бо саме його оцінює Google і саме це висиділи ваші покупці, а лабораторний прогін поруч показує причину. Іноді чесна відповідь — що швидкість вам не вузьке місце, і ви почуєте це перш ніж витратите на неї бодай щось. Коли вузьке місце таки вона, лагодити треба той шар, куди йде час: відповідь сервера на Adobe Commerce, застосунки й тему на Shopify, конвеєр картинок і скрипти, за які ніхто не відповідає.
Де зазвичай лежить час
Відповідь сервера, раніше за все інше
Time to First Byte задає нижню межу для кожної метрики після себе. На Adobe Commerce це поведінка повносторінкового кешу, Varnish і запити за сторінкою категорії. Жодна робота на фронтенді не витягне повільний origin, а оцінка Lighthouse не скаже вам, що час пішов саме туди.
LCP: перший екран і конвеєр картинок
Пріоритет для головного зображення, шрифти, які не блокують відмальовку, і критичний CSS інлайном. Ціль — 75-й перцентиль ваших реальних мобільних відвідувачів, те саме число, яке оцінює Search Console, а не бал одного прогону на одній машині.
INP: скрипти, які писали не ви
Тег-менеджери, віджети чатів, застосунки відгуків і пікселі. Вони приходять через маркетинг, вони працюють у головному потоці, і на Shopify це зазвичай головна причина. Фасади й відкладене завантаження там, де скрипт себе виправдовує, і аргумент за його видалення там, де ні.
CLS, і це не дрібниця
Зарезервоване місце під усе, що підвантажується пізніше, і розміри в кожної картинки. У найкращому за дизайном комерційному експерименті мого реєстру CLS зрушив на 92,72%, тоді як LCP не зрушив узагалі, а виручка на відвідувача зросла на 53,37%. Це не доводить, що причина в CLS. Це означає, що стабільність верстки не можна лишати наостанок.
Перевіряється на ваших користувачах, а не на моїй машині
web-vitals на сторінці віддає реальні сесії, і вони звіряються з Chrome UX Report та звітом Core Web Vitals у Search Console. Польові дані — єдиний доказ, що деплой допоміг, а 28-денне вікно вирішує, чи це зарахувалося.
Як іде робота
- 1
Діагноз - польові дані по origin, лабораторний прогін заради причини і шар, у якому лежить час
- 2
Ціна - скільки коштує закрити розрив на вашому власному трафіку, за рандомізованими експериментами, а не за цифрою, якою користується ринок
- 3
Лагодимо ту частину, яка окупається, по порядку, і кожна зміна вимірна окремо
- 4
Перевірка в полі - моніторинг реальних користувачів і ті самі 28 днів, які вирішують, чи зарахувалося
Чим міряю і з чим працюю
Що у вас є, коли роботу закінчено
Це результати роботи, а не прогнози. Кожен з них можна перевірити в день здачі.
- Ваші власні польові дані з Chrome UX Report, прочитані на 75-му перцентилі, за яким вас і оцінює Google.
- Ціна розриву, порахована за опублікованими експериментами, з названими джерелами і вказаною невизначеністю.
- Список того, куди йде час, упорядкований за вартістю виправлення, включно з пунктами, які лагодити не варто.
Пов’язані матеріали
Цей маршрут допоможе оцінити глибину імплементації до старту вашого проєкту.