Чому середні брешуть
Коли середній час завантаження падає на 200 мс, більшість команд святкує. Лінія конверсії майже не рухається. Це тому, що середнє ховає єдиного клієнта, що має значення: того, хто на повільному з'єднанні, старшому телефоні, з межовою терплячістю. Покращіть його досвід — і лінія рухається. Покращіть середнє — і ви змінили число, не змінивши бізнесу.
Той самий патерн з'являється всюди в роботі над продуктивністю. Клієнт на медіані — нормально. Клієнт на 75-й, 90-й та 95-й перцентилях — той, хто платить. Оптимізувати під медіану — оптимізувати під клієнта, який і так би сконвертувався.
Латенс відбирає ваших найкращих клієнтів
Повторні клієнти терплять більше тертя, ніж нові. Вони також коштують більше — їх LTV у рази вищий за разового. Повільний checkout тихо відфільтровує найцінніший кохорт — той, що з найбільшою ймовірністю повернеться, порекомендує і витратить знову. У воронці ви цього не побачите, бо вони до воронки не дійшли. Вони відмовились на сторінці кошика і пішли до конкурента.
Те саме стосується трафіку з високою інтенцією. Клієнт, який годину готовий купити, найчутливіший до тертя у момент рішення. Він не буде ретраїти на хисткому з'єднанні. Він пішов за дві секунди.
Кохорти, яким повільний checkout шкодить найбільше
| Кохорт | Чому йдуть першими | Річний вплив на виручку |
|---|---|---|
| Мобільний, 4G | Найбільша варіація латенсу | 30-40% |
| Повторні клієнти | Найменша терплячість | 20-25% |
| Високий чек | Висока когнітивна навантаженість | 15-20% |
| Користувачі з paid-ads | Найвища ціна acquisition втрачена | 10-15% |
| Міжнародні клієнти | Edge POP-розриви, повільні платіжні API | 10-15% |
Кохорти перекриваються. Клієнт, що пішов за 2.5 секунди — ймовірно був у трьох одразу.
Що ми міряємо на checkout
Кошик і checkout — сторінки, що найбільше заслуговують вимірювань. Мінімум:
- p75 LCP на сторінках кошика й checkout, сегментовано за джерелом трафіку.
- TTI на кроці оплати — момент, коли клієнт хоче завершити.
- Failure rate платіжного провайдера за регіоном і методом.
- Drop-off між «додав у кошик» і «почав checkout» — це інша проблема, ніж сам checkout.
- Час між «надіслати оплату» і «success-сторінка відрендерилась» — частина, за якою клієнт оцінює досвід.
- Error rate по полях — форма теж частина checkout.
Якщо не можете витягнути кожне сегментовано по кохортах вище — аналітика, а не сторінка, є перший проєкт.
Виграші, що нічого не коштують у деплої
Більшість фіксів checkout — це видалення, а не доповнення.
Видаліть чат-віджет, що завантажується на оплатній сторінці. Видаліть аналітичний скрипт, що працює тричі. Видаліть upsell, що б'ється з основним CTA. Відкладіть маркетинговий пиксель до моменту, коли success-сторінка вже відрендерилась. Кожне видалення компаундиться — і жодне не потребує рефакторингу.
Стартовий список:
- Маркетинговий аналітик-тег, що працює на кожній сторінці, включно з checkout. Відкладіть.
- Чат-віджет. Вимикайте на кроці оплати.
- Карусель рекомендацій під кошиком. Замініть на статичний блок або приберіть зовсім.
- Exit-intent попап. Перебиває саме ту дію, яку хочемо завершити.
- Cookie-банер, що стартує через 200 мс через скрипт. Замініть на статичний.
- Будь-який third-party-скрипт із
<script>тегом безasyncчиdefer. Додайте. Або приберіть.
Цей список збереже секунду load-time на більшості checkout. Секунда load-time коштує більше, ніж наступні три маркетингові email разом.
Specifics для Shopify
Якщо ви на Shopify, обмеження інші — але принципи ті самі. Виграші, які бачимо найчастіше:
- Аудитуйте додатки. Кожен встановлений додаток впорскує якусь комбінацію JavaScript, Liquid-змін і async-запитів. Більшість не виправдовує своєї performance-ціни. Вимкніть на тиждень і дивіться конверсію.
- Користуйтесь нативним checkout. Кастомні checkout на Shopify Plus виглядають більш «брендово» й майже завжди гірше за продуктивністю, ніж нативний. Нативний — найбільш оптимізована поверхня платформи.
- Відкладайте Pixel та аналітику. Вбудовані події Shopify стріляють надійно без допомоги. Додавання третього трекера рідко покращує дані й завжди коштує латенсом.
- Налаштовуйте тему. Добре зроблена тема на стоковому Shopify швидша за середній headless-білд.
Спокуса на Shopify — додавати. Виграш майже завжди — віднімати.
Латенс, що приходить звідкись ще
Іноді checkout повільний не через фронтенд, а через апстрім:
- Платіжний провайдер має повільний API у вашому регіоні. Поміняйте провайдера або додайте регіональний fallback.
- Податковий сервіс робить real-time-lookup до зовнішнього вендора. Pre-compute або кешуйте.
- Калькулятор доставки синхронно дзвонить трьом перевізникам. Запускайте паралельно; fail-fast.
- Fraud-перевірка блокує submit. Перенесіть у post-submit async-флоу, якщо ризик-модель дозволяє.
- Order-сервіс робить резервування інвенторя, чергу email і запис аналітики синхронно. Поставте в чергу й підтверджуйте.
Якщо фронтенд видавлено, а LCP досі поганий — час іти на наступний шар вниз.
Пастка підтримки
Checkout-и деградують. Команда виводить швидкий checkout у березні, додає три пікселі, два додатки, нову fraud-перевірку, локалізаційний твік і банер до вересня. Checkout тепер на 800 мс повільніший, і ніхто не помітив, бо це сталось по 100 мс за раз.
Фікс — щомісячний огляд checkout:
- Поле LCP та INP на кошику й кроці оплати.
- Список усіх third-party-скриптів, що стріляють на цих сторінках.
- Список усіх змін, задеплоєних у checkout за 30 днів.
- 15-хвилинний аудит мережевої панелі на реальному mid-tier мобільному.
Команди, що тримають цей каденс, тримають checkout у зеленій зоні роками. Команди, які — ні, до другого року втрачають 5-10% конверсії на повзучу регресію.
Як ми аудитуємо повільний checkout
Коли клієнт просить подивитись на проблемний checkout, перший день завжди однаковий:
- Відкриваємо живий сайт на реальному mid-tier Android на тротлованому 4G.
- Додаємо товар у кошик, ідемо в checkout, заповнюємо форму, сабмітимо.
- Весь час дивимось мережеву панель.
- Нотуємо кожен скрипт, що грузиться, кожен затриманий рендер, кожну лагнуту взаємодію форми.
- Перехресно з аналітикою для найураженіших кохортів.
Половина проблем видно за перші 5 хвилин. Інша половина — у даних. Ще не зустрічали повільний checkout, де проблема нез'ясовна — лише ті, де її незручно визнати.
Грошова логіка
Покращення LCP checkout на 1 секунду на $10M річного e-commerce-бізнесу зазвичай коштує $200,000-$500,000 додаткової виручки. Це не Lighthouse-бал. Це рядок у звіті наступного кварталу. Робота, щоб туди дійти, рідко гламурна — це нудні видалення, відкладені скрипти, аудит додатків. Команди, що ставляться серйозно, лишаються конкурентними. Команди, що ставляться до performance checkout як до Q4-проєкту, тихо губитимуть кохорт, що найбільше важить.