Apricode

24 Mar 2026

Реальна ціна повільного checkout

Затримка в одну секунду на checkout не втрачає 7% клієнтів — вона втрачає правильних.

Реальна ціна повільного checkout

Чому середні брешуть

Коли середній час завантаження падає на 200 мс, більшість команд святкує. Лінія конверсії майже не рухається. Це тому, що середнє ховає єдиного клієнта, що має значення: того, хто на повільному з'єднанні, старшому телефоні, з межовою терплячістю. Покращіть його досвід — і лінія рухається. Покращіть середнє — і ви змінили число, не змінивши бізнесу.

Той самий патерн з'являється всюди в роботі над продуктивністю. Клієнт на медіані — нормально. Клієнт на 75-й, 90-й та 95-й перцентилях — той, хто платить. Оптимізувати під медіану — оптимізувати під клієнта, який і так би сконвертувався.

Латенс відбирає ваших найкращих клієнтів

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

Те саме стосується трафіку з високою інтенцією. Клієнт, який годину готовий купити, найчутливіший до тертя у момент рішення. Він не буде ретраїти на хисткому з'єднанні. Він пішов за дві секунди.

Кохорти, яким повільний checkout шкодить найбільше

КохортЧому йдуть першимиРічний вплив на виручку
Мобільний, 4GНайбільша варіація латенсу30-40%
Повторні клієнтиНайменша терплячість20-25%
Високий чекВисока когнітивна навантаженість15-20%
Користувачі з paid-adsНайвища ціна acquisition втрачена10-15%
Міжнародні клієнтиEdge POP-розриви, повільні платіжні API10-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, перший день завжди однаковий:

  1. Відкриваємо живий сайт на реальному mid-tier Android на тротлованому 4G.
  2. Додаємо товар у кошик, ідемо в checkout, заповнюємо форму, сабмітимо.
  3. Весь час дивимось мережеву панель.
  4. Нотуємо кожен скрипт, що грузиться, кожен затриманий рендер, кожну лагнуту взаємодію форми.
  5. Перехресно з аналітикою для найураженіших кохортів.

Половина проблем видно за перші 5 хвилин. Інша половина — у даних. Ще не зустрічали повільний checkout, де проблема нез'ясовна — лише ті, де її незручно визнати.

Грошова логіка

Покращення LCP checkout на 1 секунду на $10M річного e-commerce-бізнесу зазвичай коштує $200,000-$500,000 додаткової виручки. Це не Lighthouse-бал. Це рядок у звіті наступного кварталу. Робота, щоб туди дійти, рідко гламурна — це нудні видалення, відкладені скрипти, аудит додатків. Команди, що ставляться серйозно, лишаються конкурентними. Команди, що ставляться до performance checkout як до Q4-проєкту, тихо губитимуть кохорт, що найбільше важить.

Маєте особливий запит?

Розкажіть про задачу — запропонуємо найкраще рішення.