Скорость загрузки сайта: как проверить и когда её чинить

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

Я открыл двенадцать страниц, которые отвечают на запрос «скорость загрузки сайта», и сверил каждую со справкой Яндекса, документацией Core Web Vitals и справкой Метрики. Семь из двенадцати устроены одинаково: подзаголовки — это названия сервисов подряд, от PageSpeed до Pingdom. Ни одна из двенадцати не приводит дословной формулировки Яндекса о скорости. И это самое интересное место в теме, потому что формулировка эта — не та, которую весь топ пересказывает.

01Чего Яндекс про скорость не говорит

Расхожее «Яндекс понижает медленные сайты» в документации Яндекса не подтверждается. Я прошёл по страницам справки Вебмастера, где такое утверждение должно было бы стоять. На странице «Как улучшить позиции сайта в поиске» скорость не упоминается вообще. Страница «Как сделать сайт быстрее» говорит осторожнее:

«Скорость загрузки страниц сайта это один из важных показателей его качества. Из-за низкой скорости пользователь может не дождаться открытия страницы и перейти на другой ресурс. Это снижает уровень доверия к сайту, его посещаемость и влияет на другие статистические показатели».

Показатель качества и влияние на посещаемость — это не то же самое, что фактор ранжирования. Зато у Яндекса есть жёсткий порог, о котором в топе почти не пишут. Он в диагностике Вебмастера, в описании ошибки «Долгий ответ сервера»:

«Во время обхода сайта поисковый робот фиксирует среднее время ответа сервера на загрузку страниц. Если некоторые страницы загружаются больше 3 секунд, робот фиксирует это как ошибку».

Второй числовой ориентир лежит в справке Метрики, в описании метрики «Время до отрисовки»: «Именно это значение субъективно воспринимается посетителем как скорость загрузки сайта. Обычно оно занимает не более двух секунд».

Отдельно стоит знать, чего в справке Яндекса нет совсем: слов Core Web Vitals, LCP, INP и CLS. Это метрики Google, и половина текста «про Яндекс» в статьях конкурентов к Яндексу отношения не имеет. У Google формулировка как раз прямая: «Core Web Vitals are used by our ranking systems», но там же оговорка — «There is no single signal» и «Google Search always seeks to show the most relevant content, even if the page experience is sub-par».

02Что закрывают двенадцать статей из топа, а что нет

Живую выдачу Яндекса снять автоматически не удалось — поиск отдаёт капчу роботам, поэтому позиции я не выдумываю и не привожу. Состав страниц собран по обоим запросам и представляет те же двенадцать доменов, которые держат эту тему годами.

Из таблицы видно три вещи. Первая: треть топа старше пяти лет — Skillbox, Ашманов и Completo написаны до того, как Core Web Vitals вообще появились, и до сих пор учат ориентироваться на «85 баллов». Вторая: ни одна страница не объясняет разницу между данными реальных пользователей и симуляцией, хотя именно из-за этой разницы человек видит то 90 баллов, то 55. Третья: денег не считает никто — проценты вроде «каждая секунда стоит 7 % выручки» кочуют из статьи в статью без формулы, по которой владелец мог бы перевести их в заявки.

Есть и проверяемый брак. В списках «ТОП-10 сервисов» у двух агентств стоит loading.express — на момент проверки домен не открывается, у него просрочен сертификат. Там же рекомендуют Ping-Admin, который по тексту собственной страницы является «системой мониторинга доступности и надёжности сервера», а не измерителем скорости загрузки. Списки сервисов копируются годами, и никто их не открывает.

03Шаг 1. Посмотрите на реальных пользователей, а не на симулятор

Откройте pagespeed.web.dev и введите адрес страницы. Наверху, если данные есть, будет блок с результатами живых посетителей Chrome. Документация PageSpeed описывает его так: «The field data is a historical report about how a particular URL has performed, and represents anonymized performance data from users in the real-world on a variety of devices and network conditions». Период фиксированный — «over the previous 28-day collection period».

Второй бесплатный источник тех же данных, которого нет ни в одном списке «ТОП-10 сервисов», — treo.sh/sitespeed: «Instant report. No sign-up required», показывает историю за годы и фильтрацию по странам.

Ниже в PageSpeed идёт блок с баллом — и вот он к реальным посетителям отношения не имеет: «The lab data is based on a simulated load of a page on a single device and fixed set of network conditions». Условия симуляции зафиксированы в документации Lighthouse: задержка 150 мс, канал 1,6 Мбит/с на приём, множитель нагрузки процессора ×4. Балл складывается из метрик с весами: в Lighthouse 10 это TBT 30 %, LCP 25 %, CLS 25 %, FCP и Speed Index по 10 %. Зелёная зона начинается с 90, красная кончается на 49.

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

04Шаг 2. Если поля нет — это про ваш трафик, а не про поломку

У сайта малого бизнеса верхнего блока в PageSpeed чаще всего не будет. Причина описана в документации Chrome UX Report: «There are separate eligibility criteria for origins and pages, primarily that they must be publicly discoverable and there must be a large enough number of visitors in order to create a statistically significant dataset». Порога в цифрах Google не публикует.

То же ограничение — у российских инструментов. Индекс скорости сайта, который Яндекс показывал в Вебмастере, считается не для всех: «Индекс скорости рассчитывается для тех сайтов, у которых достаточно трафика для отображения. Если данных недостаточно для расчёта, то индекс скорости не будет определён». А у Метрики порог назван прямо: «Для полноценного использования мониторинга сайта необходим достаточный объем трафика — более 100 просмотров страниц сайта в неделю».

Практический вывод для владельца небольшого сайта: три из четырёх источников данных о вашей скорости вам просто недоступны, пока трафика мало. Остаётся симуляция Lighthouse и отчёт Метрики, который при слабом трафике работает неустойчиво. Это нормально и означает ровно одно — решения придётся принимать по крупным числам, а не по сотым долям секунды.

05Шаг 3. Разложите загрузку на этапы в Метрике

Это тот замер, которого нет ни у кого в топе, хотя он есть в справке готовым списком. Путь: Отчёты → Мониторинг → Время загрузки страниц. В отчёте сразу переключите квантиль с 50 % на 90 %: «Квантиль 90% означает, что время загрузки не будет превышать указанное в 90% случаев». Медиана скрывает именно тех посетителей, которые уходят.

Читается таблица так. Большой «Ответ сервера» — разговор с хостингом, и только он. Ответ быстрый, а «Время до отрисовки» четыре секунды — виноват первый экран: тяжёлые картинки, шрифты, сторонние скрипты. Разрыв между отрисовкой и загрузкой DOM в разы — это хвост из виджетов и счётчиков, который посетитель, впрочем, часто даже не замечает.

Эта же разбивка отвечает на вопрос, который в выдаче обходят стороной: менять ли хостинг. Пока вы не видели «Ответ сервера» отдельной строкой, переезд — гадание. Рядом полезно понимать, из каких обязательных расходов складывается год владения сайтом, потому что ускорение почти всегда оказывается новой строкой в этой смете: у Timeweb услуга ускорения сайта стоит «4 рубля в день», их же CDN — «1 ₽ в месяц за CDN-ресурс + 0,6 ₽ за каждый ГБ исходящего трафика».

06Шаг 4. Сверьтесь с порогами — их всего четыре

Важная тонкость, которую не объясняет никто: пороги Core Web Vitals меряются не по среднему посетителю, а по 75-му перцентилю — «a good threshold to measure is the 75th percentile of page loads, segmented across mobile and desktop devices». При этом сами числа для мобильных и десктопа одинаковы: «The Core Web Vitals recommended thresholds are not segregated by device and the same threshold is used for both». Сегментация — про раздельное измерение, а не про разные нормы.

Насколько это вообще достижимо, видно по Web Almanac 2025: хорошие Core Web Vitals в 2025 году были у 48 % мобильных и 56 % десктопных сайтов, причём мобильная доля росла три года подряд — «increasing from 36% in 2023 to 44% in 2024, and reaching 48% in 2025». То есть половина интернета порог не проходит, и это не катастрофа, а фон.

Разберём именно
ваш сайт бесплатно

Посмотрю страницу и рекламу, найду,
где теряются заявки, и пришлю план,
что поменять.

Что входит в разбор

• 1
  Где теряются заявкипуть от объявления до формы
• 2
  Что поправить на сайтепервый экран, оффер, формы
• 3
  Что поменять в рекламезапросы, объявления, бюджет

Михаил Лапошинразберу ваш проект лично

Ваше имяТелефонСайт

TelegramWhatsAppЗвонок

Согласен на обработку данных и политику конфиденциальностиПолучить бесплатный разбор

✓ Заявка принята — отвечу в течение часа

07Шаг 5. Переведите секунды в заявки

Здесь заканчивается чужая фактура и начинается арифметика, которой в топе нет ни у кого. Самое аккуратное исследование про сотые доли секунды — Milliseconds Make Millions: его заказал Google, подготовила Deloitte, опубликовано 24 марта 2020 года, выборка — 37 европейских и американских брендов и свыше 30 млн сессий. Улучшение скорости на 0,1 секунды дало ритейлу «conversions increased by 8.4% and average order value increased by 9.2%», сайтам сбора заявок — «bounce rate improved by 8.3%».

Подставим 8,4 % в реальные числа небольшого сайта. Конверсию берём 2 %, это консервативно.

Таблица объясняет, почему совет «доведите PageSpeed до 90» одинаково бесполезен для всех. При 400 визитах борьба за сотые доли секунды приносит меньше одной заявки в месяц — её не окупит ни день работы программиста. При 20 тысячах визитов та же десятая доля секунды стоит четырёхсот заявок в год, и ради неё есть смысл переписывать шаблон.

Но у маленького сайта своя развилка, и она про секунды, а не про сотые. Здесь работают крупные числа: по данным Google от 8 сентября 2016 года, «53% of visits are likely to be abandoned if pages take longer than 3 seconds to load» — на выборке из 3,7 тысячи мобильных сайтов. Более поздний замер Google и SOASTA, опубликованный 20 февраля 2018 года: «as page load time goes from one second to 10 seconds, the probability of a mobile site visitor bouncing increases 123%». Разница между тремя секундами и десятью — это потерянная половина посетителей, и вот её чинить надо всегда.

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

08Шаг 6. Что делать, если сайт на конструкторе

Половина советов из топа — «настройте gzip», «минифицируйте CSS», «оптимизируйте серверный код» — владельцу сайта на Тильде или другом конструкторе физически недоступна. Об этом не предупреждает почти никто, хотя это ровно та ситуация, в которой находится большинство малого бизнеса.

У Тильды есть собственный чек-лист ускорения, и он честнее многих статей. Главное там — про картинки: «Изображения — самое тяжелое, что есть на сайте, поэтому 70% успеха скорости загрузки страницы зависит от них». Все загружаемые изображения платформа сама уменьшает «до 1680 px по большей стороне», отложенная загрузка «по умолчанию включена» для всех сайтов, а замер платформы на эмуляции 3G показывает разницу: с Lazy Load страница догружается за 1,65 с и 263 КБ, без него — 10,14 с и 1,8 МБ.

Второй по весу пункт — чужие скрипты: «в 95% случаев код, добавленный на сайт, не оптимизирован». Счётчики Тильда подключает «спустя 2 секунды с момента загрузки страницы», и отключать эту задержку не стоит. Системные шрифты вместо загружаемых экономят «100-400 кб».

Там же лежит редкая для рынка позиция платформы против культа зелёных баллов: PageSpeed «имитирует» загрузку, «это условный технический инструмент, который не всегда отражает реальную скорость загрузки», и «мы не рекомендуем всецело полагаться на PSI». Заодно стоит помнить, что у любого конструктора есть предел, за которым ускорять нечего: в разборе того, где именно кончаются возможности Тильды, этот предел описан по пунктам, а в материале про то, что платформа умеет для поиска, видно, какая часть технических правок на ней вообще недоступна владельцу сайта.

09Когда пора остановиться

Ускорение — не бесконечная работа. Останавливаться можно, когда выполнены четыре условия сразу: в диагностике Вебмастера нет ошибки «Долгий ответ сервера»; «Время до отрисовки» по квантилю 90 % в Метрике укладывается в две секунды; LCP в поле PageSpeed — до 2,5 секунды, если поле вообще есть; и следующая правка по расчёту из пятого шага приносит меньше одной заявки в месяц.

Отдельно — про то, чего делать не надо. Не надо выносить решение по одному прогону PageSpeed: симуляция даёт разброс. Не надо ориентироваться на числа из статей без источника — «32 %», «106 %», «53 % за 3 секунды» гуляют по выдаче вперемешку, и у половины из них первоисточник либо десятилетней давности, либо не находится вовсе. Не надо менять хостинг, пока не увидели строку «Ответ сервера» отдельно от всего остального.

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

Михаил ЛапошинМаркетолог, руководитель Laposhin Agency

«Делаем сайты и запускаем Яндекс Директ так, чтобы
сайт приносил заявки, а не просто был»

Есть вопрос по статье?Задать вопрос в Telegram