Прискорення Shopify: з 4,8 с до 1,2 с і що це насправді дало

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

MioMio пройшов шлях з 4,8 с до 1,2 с. Це вчетверо швидше на мобільних. Ось що було в голові цього розподілу, приблизно за спаданням віддачі.

1. Стратегія рендерингу — найбільший окремий виграш

Стара вітрина рендерилась на клієнті. Відвідувач качав HTML-оболонку, потім JavaScript-бандл, потім чекав, поки бандл запросить каталог, потім чекав знову на зображення, які цей запит породжував. Чотири послідовні цикли до появи хоч чогось осмисленого.

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

Це не мікрооптимізація, і жодне обрізання бандлів її не замінює. У клієнтського каталогу є підлога, задана глибиною власного водоспаду запитів. Серверний рендеринг цю підлогу прибирає.

2. Зображення — найбільший виграш у байтах

У модному каталозі зображення — близько 80% переданих байтів. Три зміни, за спаданням цінності:

• →Сучасні формати. WebP проти оптимізованого JPEG — це мінус 25–35% при візуально ідентичній якості. Це зміна на етапі збірки, а не в дизайні.
• →Правильні розміри. Віддавати майстер на 2000px у слот на 400px — це викинути близько 96% пікселів. Адаптивний srcset на брейкпоінт вирішує це один раз і глобально.
• →Чесний lazy loading. Усе нижче першого екрана отримує loading="lazy". Усе вище — свідомо ні. Лінива підгрузка hero-зображення це самостійно нанесений штраф по LCP, і трапляється він часто.

Завжди супроводжуйте це явними розмірами або aspect-ratio. Зображення, що приходять без зарезервованого місця, спричиняють зсув layout, а CLS — найдешевший Core Web Vital для виправлення і найчастіше залишений зламаним.

<img
  src="/hero.webp"
  alt="Осіння кампанія"
  width="1600" height="900"
  fetchpriority="high"
/>

3. Сторонні скрипти — невидимий податок

Типова українська вітрина тягне аналітику, віджет CRM, віджет чату, пару пікселів і платформу відгуків. Кожен окремо «легкий». Разом вони регулярно блокують головний потік довше, ніж увесь застосунок.

Тут вони проходять через Partytown, який виносить сторонні скрипти у web worker. Головний потік перестає конкурувати з віджетом чату за право намалювати сторінку. Там, де скрипт не можна винести, він відкладається до першої взаємодії.

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

4. Шрифти — мало байтів, багато блокування

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

• →Preconnect до джерела шрифтів, щоб TLS-рукостискання відбулось паралельно, а не за потребою.
• →Підключати шрифти через <link> у head документа, а не @import усередині CSS.
• →font-display: swap, щоб текст малювався одразу запасним шрифтом, а не тримав рендер у заручниках.
• →Сабсетити під ті набори символів, які реально використовуються. Сайту з кирилицею й латиницею не потрібні повні грецький і в'єтнамський діапазони.

5. Кешування й доставка

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

Cache-Control: public, max-age=31536000, immutable

CDN перед цим фізично наближає байти до відвідувача. Для українського магазину з українськими покупцями це важить менше, ніж обіцяє маркетинг — але для того ж магазину з європейським трафіком це різниця між 40 мс і 300 мс на кожному ресурсі.

Вимірювати правильне

PageSpeed Insights проганяє лабораторний тест на симульованому залізі. Це інструмент діагностики, а не табло. Ранжує Google за польовими даними — Core Web Vitals, зібраними з реальних користувачів Chrome на реальних пристроях і мережах.

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

Варто стежити за трьома числами: LCP менше 2,5 с, INP менше 200 мс, CLS менше 0,1. Решта — діагностичні деталі на службі цих трьох.

Скільки насправді коштує швидкість

Ранжувальна вигода від Core Web Vitals реальна, але помірна — це радше тайбрейкер між співставними результатами, ніж важіль. Вигода в конверсії ані помірна, ані тонка. На цьому проєкті падіння завантаження з 4,8 с до 1,2 с збіглося з приростом конверсії на 25% у першому кварталі — паралельно з ребрендингом.

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