Більшість Shopify-магазинів набирають ~70 у Lighthouse на мобільному. Більшість WooCommerce — ~55. Headless storefront на Next.js + Medusa.js стабільно дає 90–98. Це не питання тюнінгу — це питання структури. Стаття розбирає структуру і конкретні техніки, щоб ви могли віддати 90+ на власному білді.
Усі цифри нижче — з tuned Next.js + Payload baseline (стек, з якого я деплою), не staging-демо.
Чому PageSpeed важить грошима
Перед техніками — бізнес-кейс. Три цифри варто запам'ятати:
- Конверсія падає ~1% на кожні 100ms завантаження (класичний Amazon-результат, відтворений багато разів).
- Mobile bounce rate стрибає з 32% до 90% коли завантаження йде з 1s до 5s (дані самого Google).
- Core Web Vitals — ranking-фактор Google — швидші сторінки виграють у видачі при однаковому контенті.
Для магазину з €100k/рік підняти конверсію з 1.8% до 2.0% (типовий швидкісний gain) — це €11,000/рік revenue. Ось чому це не марна метрика.
Ширший бізнес-кейс — у повному порівнянні платформ →.
Чому Shopify і WooCommerce не пробивають 90
Архітектура, не конфіг:
Shopify рендерить сторінки SSR з Liquid-темплейтів плюс фіксований рантайм: theme JS, app-sandbox (кожен app колесить скрипти), власна аналітика. Можна почистити тему — платформа залишається. Стеля Lighthouse ~75–80.
WooCommerce рендерить через PHP + WordPress, з jQuery, темою і assets кожного активного плагіна. Caching-плагіни (WP Rocket, LiteSpeed) піднімають з 40 до ~60–70. Далі — треба ламати core, що вб'є адмінку.
Обидві архітектури борються з ціллю. Headless потрапляє в ціль бо архітектура з ціллю узгоджена.
П'ять механізмів headless-переваги
Next.js + Medusa.js storefront швидкий бо:
1. Статичні або ISR сторінки. Product pages — pre-rendered build-time або edge-кешовані після першого хіту. Клієнт отримує готовий HTML з CDN, не SQL+PHP/Liquid рендер.
2. Commerce engine — поза critical path. Medusa обслуговує cart, checkout, admin через API. Storefront звертається тільки коли клієнт взаємодіє — ніколи на initial load.
3. Нема рантайму теми. Жодного jQuery, Liquid-renderer, admin chrome. Storefront віддає лише React, який реально потрібен.
4. Гранулярні JS-бандли. Next.js code-split по роутах. Homepage отримує тільки homepage-JS. Продукт — тільки product-JS. Shopify-теми ж віддають JS всього сайту на кожній сторінці.
5. Image pipeline — інженерний, не bolted-on. Next/Image конвертує в AVIF/WebP, ресайзить responsive, lazy-load. Cloudflare R2 — edge. Це саме по собі 10–15 пунктів Lighthouse на image-heavy магазинах.
Вісім технік, що ставлять 90+
Конкретний чек-ліст:
1. Статика або ISR на все, що не personalised. Listing, product, category, content — все pre-rendered або edge-кешовано. Тільки cart і checkout — динамічні.
2. Жорсткий JS budget на сторінку. Page-рівневий ліміт (під 150kb gzipped JS storefront). Аудит щотижня через next build analyzer.
3. Defer або викинути third-party скрипти. Meta Pixel, GTM, чат-віджети — їм не місце в critical path. Перенесіть на server-side tracking для Pixel і GA4. Повний гайд →
4. AVIF/WebP через Next/Image з явним width/height. Нуль CLS, нуль oversized images. 1200px-product-photo віддасте ~30kb замість 300kb з CMS-upload.
5. Font subsetting + `font-display: swap`. Self-host шрифти, subset до символів які реально використовуєте, ніколи FOIT.
6. Preload тільки LCP-картинку і primary-font. Все інше у preload конкурує з ресурсом який реально рендерить.
7. Edge caching через CDN. Cloudflare/Vercel edge для статики і ISR. TTFB падає з 0.6s до 0.05s на cached responses.
8. Чистка analytics-bloat. Багато магазинів везуть 12+ analytics-тегів. Аудит, консолідація, переведення некритичних на server-side.
Як виглядає 96/100
Tuned product-page на Next.js + Medusa baseline:
З baseline-білду з реальними фото товарів, multilingual SEO, schema, активною аналітикою — не staging-демо. Порівняння: типова Shopify product-page — ~1.4MB total, 350kb JS.
Як прийти туди звідки ви зараз
Два реальні шляхи:
- Тюнінг того, що є. Кешування, оптимізація картинок, чистка apps, аудит теми. Реалістичний приріст: +15…+25 Lighthouse-пунктів. Стеля на Shopify ~75, на WooCommerce ~70.
- Перенесення сторфронта на headless. Бек-офіс лишити (або мігрувати окремо) і перебудувати customer-facing на Next.js. Реалістичний приріст: +30…+50 пунктів, без стелі. Це робить сервіс міграції →.
Опція 1 — дешевша. Опція 2 — перестає бути опцією коли ціна повільності перевищує ціну побудови як треба з першого разу.
FAQ
Чому саме 90+? 75 хіба не достатньо? 75 — достатньо щоб не отримати penalty по Core Web Vitals. Але крива конверсії продовжує рости після 75 — кожні 100ms додатково конвертують більше. Точки, в якій "швидше" перестає означати "краще", не існує.
Чи дасть зміна теми 90 на Shopify? Швидка преміум-тема дає +10–15 пунктів. Після високих 70-х ви воюєте з рантаймом платформи. Структурна стеля існує.
Скільки часу займає побудувати 90+ магазин з нуля? Baseline online-store — 3–4 тижні і запускається на 90+ як baseline, не paid add-on.
Чи headless дає 90+ на Shopify Hydrogen? Так — Hydrogen storefront теж 90+. Performance-аргумент там вирішений. Залишається cost і lock-in — розбір тут →.
Наступний крок
Хочете швидкий магазин — розробка стартує від €2,000 і запускається на Lighthouse 90+ як baseline, не paid add-on. Дивіться /services/custom-development для bespoke-білдів де швидкість критична (booking, B2B, content-heavy storefronts).