В представлении пользователя переход по ссылке выглядит простым действием: нажал на объявление, открылась страница, визит записался.
В DevTools (вкладка Performance) картина иная: между нажатием на экран смартфона и моментом, когда JavaScript-счетчик отправит первый хит, проходит от 1500 до 4000 миллисекунд.
На мобильном интернете три секунды ожидания приводят к тому, что часть пользователей закрывает вкладку или возвращается в поиск до старта скрипта.
1. Семь фаз перехода по веб-ссылке
По спецификации W3C Navigation Timing API каждый переход проходит 7 последовательных этапов:
[КЛИК ПО РЕКЛАМЕ] (0 мс)
│
▼
1. DNS Lookup (30–150 мс) ────────► Разрешение доменного имени в IP-адрес
│
▼
2. TCP + TLS Handshake (50–200 мс) ─► Установление HTTPS-соединения
│
▼
3. TTFB: Ответ сервера (100–500 мс) ─► Ожидание первого байта HTML
│
▼
4. HTML Parsing & CSS (300–800 мс) ─► Построение DOM и разбор стилей
│
▼
5. Download JS Tags (500–1200 мс) ──► Скачивание библиотек аналитики
│
▼
6. DOMContentLoaded (1200–2500 мс) ─► Готовность дерева DOM к скриптам
│
▼
7. Script Execution (1500–3500 мс) ─► СЧЕТЧИК ОТПРАВЛЯЕТ ХИТ (Визит записан)
Разбор этапов:
- 0–200 мс (Сетевое рукопожатие): браузер резолвит DNS, открывает TCP-сокет и выполняет TLS-хэндшейк.
- 200–700 мс (TTFB): сервер генерирует ответ и отдает первый пакет данных.
- 700–1500 мс (Разбор разметки): браузер строит DOM. Если в
<head>подключены тяжелые шрифты или стили, отрисовка ждет их загрузки. - 1500–3500 мс (Запуск аналитики): браузер скачивает JS-файлы счетчиков, разбирает их в движке V8 и отправляет сетевой запрос
collectилиpageview.
2. Потери на ранних отказах
Что происходит, когда пользователь открывает страницу при слабом 4G-сигнале:
Время с момента клика:
0.0 сек ── Клик по рекламе. Деньги в рекламной сети списаны.
1.0 сек ── Экран телефона пустой, браузер принимает HTML.
1.8 сек ── Пользователь не стал ждать и закрыл вкладку.
-------------------------------------------------------------------------
ИТОГ:
- Рекламный кабинет: Кликов = 1, Деньги списаны.
- Счетчик аналитики: Визитов = 0, Отказов = 0.
В отчетах GA4 и Яндекс Метрики этот переход не появится даже в статистике отказов.
В результате вы не видите:
- С каких именно объявлений уходят пользователи на первой секунде.
- Был ли переход ботом или реальным клиентом с медленной связью.
- Какие лендинги теряют бюджет из-за долгого TTFB.
3. Сравнение клиентского JS и Edge-логирования
| Параметр | Браузерный счетчик | Edge Click Tracking (Sply) |
|---|---|---|
| Где фиксируется переход | В браузере после запуска JS | На пограничном шлюзе (Edge Node) |
| Время фиксации | 1500–3500 мс | 20–50 мс |
| Зависимость от мощности телефона | Высокая (слабый процессор дольше выполняет JS) | Отсутствует (серверный уровень) |
| Учет быстрых отказов | Теряет ушедших до 2-й секунды | Записывает 100% переходов |
| Блокировщики рекламы | Блокируют скрипты | Не влияют на сетевой запрос |
4. Как работает Edge Click Tracking
Логика регистрации переносится на распределенную сеть пограничных серверов (Edge).
Клик по объявлению ➔ HTTP GET /promo?yclid=12345
│
▼ (15–30 мс)
[Ближайший Edge-узел Sply]
│ │
│ ├──► Асинхронная запись лога (event.waitUntil)
│ (Метки, IP, устройство сохранены)
▼
[Генерация страницы и отдача HTML пользователю]
Механика фиксации:
- Запрос пользователя попадает на ближайший сервер CDN.
- Сервер считывает параметры URL (
yclid,gclid,utm_*) и заголовки устройства, сохраняя их в фоне через неблокирующий вызовevent.waitUntil(). - Страница начинает отдаваться пользователю без задержек.
- Если посетитель закроет сайт через 300 мс, данные о клике и кампании уже сохранены в аналитической базе.
Следующий шаг
- Калькулятор: Сколько трафика теряется до старта счетчика при вашем TTFB.
- Следующая статья: Фиксация кликов на уровне Edge: учет переходов до загрузки страницы.
Внедрите Server-Side Tracking без сложного кода
Sply восстанавливает до 30% потерянных конверсий, защищает от Safari ITP/AdBlock и ускоряет загрузку ваших лендингов.