Сервер Shopify відповів за 0,73 секунди, перший контент відмалювався за 1,8 секунди. А головний елемент сторінки з'явився аж на 19,2 секунди, і завантаження скінчилося на 27,4 секунди. Заміряно на магазині, який ми давно ведемо, інструментом WebPageTest: Chrome, мобільний профіль, холодний кеш, точка заміру Токіо, 24.06.2026.
Ці чотири числа - уся стаття. Платформа була швидкою, повільною була сторінка. Це інший діагноз, інший винуватець і головне - інше лікування. І різниця між ними вирішує, чи витратите ви гроші на міграцію, яка нічого не виправить.
Спочатку розділіть замір на два числа, інакше ремонтуєте не те
Метрики швидкості діляться на ті, що належать платформі, і ті, що належать вашій сторінці. Якщо читати їх разом, виходить «Shopify гальмує» - висновок, який не лікується нічим, крім переїзду.
| Метрика | Заміряно | Ціль | Що насправді вимірює |
|---|---|---|---|
| TTFB | 0,73 с | - | відповідь сервера платформи |
| FCP | 1,8 с | - | перший відмальований контент |
| LCP | 19,2 с | до 2,5 с | головний елемент першого екрана |
| CLS | 1,00 | до 0,1 | зсув верстки під час завантаження |
| Fully Loaded | 27,4 с | - | завершення всіх запитів |
Перші два числа хороші. Якби проблема була в інфраструктурі, повільним був би вже TTFB: сервер озвався б за дві-три секунди, і все інше зсунулося б слідом. Тут він озвався за 0,73 секунди.
Точка заміру в Токіо для європейського магазину нетипова, і TTFB із Праги вийшов би іншим. На співвідношення між 1,8 та 19,2 секунди це не впливає: обидва числа отримані в одному прогоні, на одному каналі.
Третя метрика Core Web Vitals, INP, у цьому аудиті не замірялася, бо вона рахується зі взаємодій відвідувача. Ми наводимо лише те, що вимірювали.
Різниця між 1,8 та 19,2 секунди важить 10,6 МБ
За один перегляд цієї сторінки браузер завантажив 10,6 МБ даних у 548 запитах із 57 чужих доменів (той самий прогін WebPageTest, 24.06.2026). П'ятдесят сім доменів - це п'ятдесят сім DNS-запитів, TLS-з'єднань і чужих серверів, на доступність яких ви не впливаєте.
Більше половини цієї ваги дав один елемент: відео на 5,7 МБ на першому екрані, вставлене з autoplay: true. Такий атрибут запускає завантаження негайно, незалежно від якості зв'язку, і поки не з'явиться перший кадр, LCP не зараховується. Один рядок у шаблоні перебиває всю іншу роботу.
Власний код теми важив 635 КБ. На живій сторінці їх було три мегабайти
Коли ми розібрали локальну копію тієї самої теми (27.08.2026), ми знайшли в ній 32 власних скрипти загальним обсягом 635 КБ, і жоден із них не був підключений без атрибута defer. Власний код був у порядку.
При цьому на живій сторінці інструмент заміру нарахував близько 3 МБ JavaScript у 236 файлах. Різницю між 635 КБ і 3 МБ принесла не тема. Її принесли застосунки та їхні зовнішні скрипти.
Практичний висновок для бюджету: хто платить за рефакторинг теми і не чіпає застосунки, купує меншу частину проблеми. Що лишається в темі після застосунків, розбираємо у статті про аудит застосунків.
CLS 1,00 означає, що сторінка збирається двічі
Значення зсуву верстки 1,00 при цілі 0,1 - це не погіршена метрика, це інша сторінка, ніж та, яку відвідувач бачив секундою раніше. Дві вимірювані причини, обидві з розбору теми від 27.08.2026:
- 577 тегів <img> у темі, з них 13 з атрибутом width (2 %) і 29 з loading (5 %). Браузер не знає, скільки місця залишити під зображення, тому не залишає жодного, а після завантаження зсуває все.
- 171 виклик stylesheet_tag у секціях і сніпетах. Кожен із них вставляє <link rel="stylesheet"> у тіло документа, тобто вже після початку відмальовування.
Щодо другого пункту ми обережні: зв'язок із заміряним CLS 1,00 імовірний, але ми його не підтвердили. Контрольного заміру після перенесення стилів у layout ми поки не робили, тож це лишається гіпотезою, а не знахідкою.
Фільтр image_tag сам додає розміри і srcset та закриває питання на рівні шаблону. У цій темі він був використаний у п'яти файлах з усіх.
Дванадцять чужих скриптів без defer - це дванадцять чужих відмов
У тій самій темі ми нарахували 12 зовнішніх скриптів без атрибута defer або async із семи чужих хостів. Два з них синхронні прямо в <head> - там парсер зупиняє обробку документа, доки файл не завантажиться з чужого сервера.
Це не лише питання швидкості. Це єдина точка відмови: якщо той чужий сервер не відповість, не відмалюється нічого. Один із хостів у тій темі, polyfill.io, під час нашої перевірки 27.08.2026 повертав помилку HTTP 520.
PageSpeed Insights змішує два різні заміри, і лише один - про вашу сторінку
Інструмент показує два набори чисел: лабораторну симуляцію, яка проходить зараз і на заданому пристрої, і польові дані від реальних відвідувачів за останні 28 днів. Коли значення розходяться, це не помилка інструмента.
Це означає, що у ваших відвідувачів інші пристрої та інший канал, ніж у симуляції. Для рішень діють польові дані, бо в них сидять ваші клієнти. Лабораторне число годиться на те, щоб порівняти дві версії сторінки між собою в однакових умовах.
Порядок виправлень, у якому це робиться
Порядок не довільний. Перші п'ять пунктів на цій сторінці давали більшу частину втраченого часу, решта - косметика.
- Перший екран. Відео та головне зображення: постери, розміри, loading="eager" і fetchpriority="high" на LCP-елемент.
- Інвентаризація застосунків. Які працюють, які оплачені і які просто лишилися.
- Зовнішні скрипти. Що можна відкласти, що можна захостити в себе, що має піти.
- Стилі в layout. Критичні інлайн, решта асинхронно.
- Розміри зображень по всій темі, через image_tag.
- Контрольний замір у тих самих умовах, інакше ви не знаєте, що допомогло.
Останній пункт пропускають найчастіше. Замір до виправлення і після має пройти на тому самому профілі, з того самого місця і з холодним кешем, інакше ви порівнюєте дві різні речі.
Чим платять за прискорення
Цю сторону треба проговорити вголос, бо пропозиції з прискорення її зазвичай оминають. Коли ви знімаєте застосунок, разом із ним зникає функція, за яку ви платили - програма лояльності, відгуки про товари, апсел у кошику.
Тому рішення належить не розробнику. Воно належить тому, хто знає, скільки ця функція заробляє. Наша робота - дати другу половину рівняння: скільки вона коштує в даних, у секундах і в ризику відмови.
Ми заміряємо і власний сайт, і в нас не сходиться
Власним інструментом ми 30.08.2026 заміряли цей сайт на трьох ширинах екрана, і вийшло від 5,3 до 5,6 МБ у 55-69 запитах. Для агенції, яка продає швидкість, це неприємне число, і воно стоїть у списку на виправлення.
Ми наводимо його тут навмисно. Текст про швидкість, у якому автор має гарний вигляд, ви прочитаєте будь-де; корисний той, де видно умови заміру й дату, бо лише за ними ви перевірите, чи діють ці числа й для вас.
Хочете дізнатися, які три речі гальмують саме ваш магазин
Надішліть нам адресу магазину. Повернемо поділ на те, що робить платформа, і те, що робить сторінка, із заміряними числами і з порядком виправлень за співвідношенням ефекту до ціни.
Що саме ми вимірюємо в межах аудиту та прискорення сайту, описано на сторінці послуги. Якщо швидкість для вас - частина більшого втручання в тему, почніть зі статті про те, як шаблони виходять з-під контролю.
Напишіть на info@lamapixel.com або зателефонуйте +420 775 599 009.
