Как скорость сайта влияет на позиции в поиске и заявки

Скорость и ранжирование

Поисковые системы открыто говорят, что удобство страницы, включая скорость, входит в число учитываемых сигналов. Точный вес никто не публикует, и любой, кто называет вам конкретную цифру, её выдумал. Практически это означает вот что.

• Скорость не выводит слабую страницу наверх. Она не заменяет содержание и не компенсирует его отсутствие
• Но при сопоставимом содержании она работает как довод в пользу одной из страниц
• Мобильная скорость важнее настольной: индексация идёт по мобильной версии
• Данные берутся не из синтетического теста, а из поведения реальных посетителей — улучшение проявляется не сразу

Правильный вывод не «ускорим и вырастем», а «не будем терять на том, на чём терять не обязательно». Скорость — это гигиена, а не стратегия роста.

Что теряется до того, как страницу прочитали

Самая дорогая часть потерь происходит раньше любого ранжирования. Человек уже перешёл — и ушёл, не увидев ни предложения, ни цены. Для рекламного трафика это прямой убыток: за визит уже заплачено.

• Пустой экран вместо контента. Пока грузится, человек не понимает, туда ли попал
• Прыгающая вёрстка. Дочитал до середины строки, всё съехало — доверия это не добавляет
• Кнопка, которая не реагирует. Нажал, ничего не произошло, нажал ещё раз — и получил двойную заявку или ушёл
• Форма, которая думает после отправки. Самый обидный случай: человек уже согласился

Отсюда и связь с заявками: медленный сайт не отпугивает тех, кто уже решил, — он теряет тех, кто ещё выбирал. А именно они и есть основная часть трафика.

Как мы относимся к этому у себя

Проще показать, чем рассказать. На главной странице стоит блок «Инженерная проверка»: кнопка делает настоящий запрос к этой же странице мимо кеша и показывает, за сколько ответил сервер и за сколько пришёл ответ целиком. Числа берутся из замера в вашем браузере, а не с нашего стенда, и от раза к разу они разные — потому что разной бывает сеть.

Мы держим этот блок именно потому, что заявление о скорости ничего не стоит, а проверяемое число стоит. По той же причине у нас нет ни одного обещания вида «сайт за 1 секунду»: это зависит и от устройства, и от канала посетителя.

Что делать, если сайт уже медленный

Порядок важнее усердия. Большая часть выигрыша обычно лежит в двух-трёх местах, а не размазана по сотне мелочей.

• Сначала измерить на мобильном и по реальным посетителям, а не на офисном интернете
• Посмотреть на изображения: чаще всего именно они составляют основную часть веса страницы
• Пересчитать сторонние скрипты: каждый счётчик, виджет и чат — это чужой код, который вы не контролируете
• Проверить сервер: если он отвечает долго, ускорять фронтенд бессмысленно
• И только потом — точечная работа по метрикам

Проходить этот путь самостоятельно необязательно — ради того же результата существует аудит сайта. Разница только в том, что разбор делает тот, кто видел сотню похожих случаев, и заканчивается он не отчётом инструмента, а порядком действий с оценкой выигрыша по каждому. Цена такой работы зависит от размера сайта и называется после первого просмотра; стоимость разработки по форматам лежит на странице цен.

Бывает и так, что ускорять дороже, чем собрать заново: если основа тяжёлая, в неё упирается любая правка, и выигрыш каждый раз оказывается меньше затраченного. В такой момент честнее посчитать новую сборку и сравнить две суммы, чем годами гнаться за баллами. Что получается на выходе, показано в портфолио.

И главное: что именно измеряют три метрики, какие у них пороги и в каком порядке их чинят — в отдельном разборе скорость сайта и Core Web Vitals. Здесь мы их намеренно не пересказывали.