Скорость загрузки сайта: как проверить, какие нормы и что ускорять первым

Радик Ишкиняевоснователь one2click

Скорость загрузки сайта проверяют по времени, за которое у посетителя появляется главное содержимое страницы. Эта метрика называется LCP, и по нормам Google она должна укладываться в 2,5 секунды у 75% визитов. Ещё две нормы: отклик на нажатие (INP) до 200 миллисекунд и сдвиг вёрстки (CLS) не больше 0,1. Проверить всё это бесплатно можно в PageSpeed Insights от Google и в отчёте Метрики «Отчёты → Мониторинг → Время загрузки страниц».

По нашим данным, скорость сильнее всего влияет на заявки с телефона. Когда главный экран появлялся за 2,5 секунды или быстрее, обращение оставляли 2,11% визитов с телефона. Когда он грузился 4–6 секунд, только 1,23%, в 1,7 раза реже. На компьютерах разницы почти нет. Ускорять сайт я советую в таком порядке: ответ сервера, главная картинка первого экрана, сторонние скрипты и виджеты.

Что такое скорость загрузки сайта

Одной цифры «сайт грузится 3 секунды» не существует. Загрузка страницы состоит из этапов, и человек замечает их по-разному. Сначала браузер ждёт ответа от сервера, потом рисует первые буквы, потом появляется большая картинка или заголовок, потом страница начинает реагировать на нажатия. Если на каком-то этапе блок съезжает вниз, человек промахивается по кнопке.

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

Между «хорошо» и «плохо» лежит зона «нужно улучшить». Например, LCP от 2,5 до 4 секунд.

Почему главная метрика именно LCP

Человек считает страницу загруженной, когда видит то, ради чего пришёл: фото кухни, заголовок с ценой, карточку товара. LCP фиксирует именно этот момент. Браузер выбирает самый крупный элемент в видимой части экрана: картинку, картинку внутри SVG, видео, фон, заданный через url(), или блок текста. Как только человек нажал, прокрутил или начал печатать, замер останавливается.

TTFB в Core Web Vitals не входит. Но от него зависят все остальные цифры: пока сервер молчит, браузеру нечего рисовать. В рекомендациях web.dev на ответ сервера закладывают около 40% времени LCP.

Нормы Core Web Vitals в 2026 году

Текущий набор Core Web Vitals: LCP, INP и CLS. INP заменил прежнюю метрику FID в 2024 году. Если вам попадается статья, где норма отклика описана через FID и 100 миллисекунд, она устарела.

Страница проходит проверку, когда все три метрики «хорошие» у 75% загрузок. Это называется 75-й процентиль. Телефоны и компьютеры оцениваются отдельно.

Процентиль удобнее среднего значения. Среднее прячет хвост: несколько визитов по 10 секунд почти не сдвигают его, хотя для этих людей сайт фактически не открылся. Норма через 75% визитов заставляет смотреть на тех, у кого медленный телефон и плохая связь.

Что показывают 190 тысяч замеров

one2click замеряет скорость прямо в браузере посетителя, как это делают Chrome и PageSpeed Insights для полевых данных. Я посчитал, как быстро на самом деле открываются сайты наших клиентов: услуги, магазины, лендинги, от кухонь до стоматологий.

Выборка: 190 463 визита людей с замером LCP на сайтах клиентов one2click, декабрь 2025 — октябрь 2026 года. Хорошая скорость сайта здесь значит LCP до 2,5 с у 75% визитов и больше. Её считали по 54 сайтам, у которых не меньше 200 замеров.

Медиана в 2,2 секунды выглядит прилично. Но у четверти визитов главный экран появляется через 4,3 секунды и позже, а это уже зона «плохо» по нормам Google. Отсюда и итог по сайтам: из 54 сайтов с достаточным числом замеров только 21 проходит норму по LCP. У остальных 33 медленных визитов слишком много.

Вторая цифра, которую я бы показал каждому владельцу сайта: у 40,8% визитов сервер отвечает дольше 0,8 секунды. Почти у половины посетителей браузер больше секунды ждёт первый байт, и никакое сжатие картинок это не исправит.

Скорость и заявки: телефоны и компьютеры

Визит «с обращением» здесь значит, что человек отправил форму, нажал на телефон, мессенджер или почту. Вот как доля таких визитов меняется со скоростью загрузки.

На телефонах быстрые визиты дают обращение в 1,7 раза чаще, чем визиты с загрузкой 4–6 секунд. Уже на зоне 2,5–4 секунды доля падает с 2,11% до 1,48%. На компьютерах все четыре группы лежат между 1,14% и 1,28%, то есть скорость почти ничего не меняет. Похоже, на компьютере человек сидит на стабильном интернете и спокойно ждёт, а с телефона закрывает вкладку и нажимает следующий результат.

Телефоны дают 56,4% визитов в нашей базе, и 77% нажатий на номер телефона тоже сделаны со смартфона. Поэтому скорость на мобильном интернете влияет на ту часть трафика, которая чаще всего звонит.

Как проверить скорость загрузки сайта

Бесплатных инструментов хватает. Я пользуюсь тремя: PageSpeed Insights для норм Google, Метрикой для этапов загрузки и инструментами разработчика в браузере, когда нужно найти конкретный тяжёлый файл.

Google PageSpeed Insights

1. Откройте pagespeed.web.dev.
2. Вставьте адрес страницы. Начните со страницы, куда ведёт реклама, потом проверьте главную.
3. Нажмите «Анализировать» и дождитесь результата.
4. Переключитесь на вкладку мобильной версии, если она не открылась сама. Начинайте с неё.

Отчёт состоит из двух частей, и их часто путают.

Верхняя часть — полевые данные из CrUX, отчёта Chrome о реальных пользователях. Это LCP, INP, CLS, FCP и TTFB живых посетителей за последние 28 дней. Проверка Core Web Vitals пройдена, если у 75% загрузок все три основные метрики хорошие. Когда данных по INP мало, хватает хороших LCP и CLS. Когда мало данных по странице, PageSpeed Insights показывает данные по всему сайту. Если их нет и по сайту, полевой блок будет пустым. У небольших сайтов так бывает часто: в CrUX попадают только посетители Chrome и только при достаточном трафике.

Нижняя часть — лабораторный тест Lighthouse. Сервер Google загружает страницу один раз, имитируя телефон среднего уровня на мобильной сети, и ставит оценку от 0 до 100: 90–100 хорошо, 50–89 нужно улучшить, ниже 50 плохо. Ниже идут рекомендации: какие картинки сжать, какие скрипты мешают отрисовке.

Яндекс Метрика: отчёт «Время загрузки страниц»

В Метрике отчёт лежит по пути «Отчёты → Мониторинг → Время загрузки страниц». В этой же группе есть «Нагрузка на сайт», «Трафик по минутам» и «Роботы». Отчёт делит загрузку на этапы:

• «DNS» и «Продолжительность установки соединения»: подключение к серверу;
• «Редиректы»: время на переадресации;
• «Ответ сервера»: от запроса до получения страницы;
• «Время загрузки и парсинга HTML»: браузер разбирает страницу до начала отрисовки;
• «Время до отрисовки»: когда страница начала появляться на экране;
• «Время до загрузки DOM»: когда страница загрузилась со всеми компонентами и готова к действиям.

Метрика считает время по квантилю. По умолчанию стоит 50%: в половине случаев загрузка не дольше показанного значения. Квантиль можно поменять, например на 90%, и тогда видно медленный хвост. Я ставлю 75%, чтобы сравнивать с нормами Google.

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

Ограничения у отчёта такие. LCP, INP и CLS в нём нет, только технические этапы загрузки. «Время до загрузки DOM» показывается максимум до 30 секунд. Для группы отчётов «Мониторинг» справка просит больше 100 просмотров страниц в неделю: на сайте с меньшим трафиком отчёт может работать неполно.

Инструменты разработчика и Search Console

В Chrome и Яндекс Браузере есть инструменты разработчика (клавиша F12). На вкладке Lighthouse запускается тот же тест, что в PageSpeed Insights, только с вашего компьютера. На вкладке Performance видно, какой файл грузился дольше всего и что именно браузер посчитал главным элементом для LCP. Обычно это работа разработчика, но владельцу полезно знать, что такая проверка есть.

Если сайт добавлен в Google Search Console, там есть отчёт Core Web Vitals по всем страницам сразу, на тех же полевых данных Chrome. Небольшим сайтам он часто показывает «недостаточно данных» по той же причине, что и PageSpeed Insights.

Что видно в отчётах и что с этим делать

Как ускорить сайт: что делать первым

Время LCP складывается из четырёх частей. web.dev даёт ориентир, сколько каждая должна занимать на хорошо настроенной странице.

Из таблицы понятен порядок работ. Если сервер отвечает 1,5 секунды, уложиться в 2,5 почти невозможно, поэтому начинать надо с него.

1. Ответ сервера

Проверьте TTFB в PageSpeed Insights и «Ответ сервера» в Метрике. Если он больше 0,8 секунды, разговаривайте с разработчиком или хостингом про кэш страниц. Сайт на конструкторе или CMS часто собирает каждую страницу заново на каждый визит, хотя она не меняется неделями. Готовая сохранённая страница отдаётся в разы быстрее. Справка Вебмастера Яндекса советует то же: оптимизировать серверный код, включить кэширование и сжатие Gzip, сократить редиректы.

Отдельно проверьте редиректы. Реклама ведёт на адрес с http, тот перенаправляет на https, потом на адрес с www, потом на адрес со слешем в конце. Каждый шаг добавляет время. Ссылка в объявлении должна вести сразу на конечный адрес.

2. Главная картинка первого экрана

На сайтах услуг главный элемент LCP почти всегда большое фото первого экрана. Что с ним сделать:

1. Сохранить в формате WebP или AVIF и в размере, который реально нужен на экране. Фото шириной 4000 пикселей на экране телефона шириной 400 пикселей добавляет лишние мегабайты.
2. Убрать с неё ленивую загрузку. В web.dev прямо сказано: ленивая загрузка главной картинки всегда добавляет задержку. Ленивая загрузка нужна картинкам ниже первого экрана.
3. Добавить ей атрибут fetchpriority="high", чтобы браузер грузил её раньше остального. Только ей одной или двум картинкам максимум, иначе приоритет теряет смысл.
4. Если картинка задана фоном в CSS или подставляется скриптом, браузер находит её поздно. Её стоит подгрузить заранее через preload или сделать обычным тегом img.

Видео на первом экране работает так же: его постер становится элементом LCP. Тяжёлый ролик без лёгкого постера тормозит весь первый экран.

3. Сторонние скрипты и виджеты

Онлайн-чат, квиз, виджет отзывов, обратный звонок, несколько счётчиков, пиксели соцсетей. Каждый весит немного, вместе они занимают процессор телефона, пока тот пытается нарисовать страницу. Отсюда плохой INP: человек нажимает «Рассчитать стоимость», а кнопка оживает через секунду.

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

4. Шрифты и сдвиги вёрстки

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

5. Проверка после правок

Лабораторный тест покажет результат сразу. Полевые данные в PageSpeed Insights обновляются каждый день, но считаются за 28 дней, так что полностью новая картина появится примерно через месяц. Если вы меряете скорость в своей аналитике, сравнивайте неделю до и неделю после правки.

Сколько заявок теряет медленный сайт

Прикинуть потери можно по таблице выше. Возьмите число визитов с телефона за месяц и долю обращений при вашей текущей скорости.

Считайте эту цифру верхней границей. Как я писал выше, связь скорости и обращений в наших данных — корреляция. Ускорение даст меньше, если у сайта есть и другие проблемы: непонятное предложение или неудобная форма. Зато расчёт хорошо показывает порядок величины. Если обращение стоит вам 1 500 рублей из рекламы, 26 обращений в месяц — это 39 000 рублей, которые можно сравнить с ценой работ по ускорению. Как посчитать стоимость обращения по своим каналам, я разбираю в статье про стоимость заявки.

Компьютерный трафик в этот расчёт не включайте. По нашим данным, там скорость почти не влияет на обращения.

Мифы о скорости загрузки

«90 баллов в PageSpeed — значит, сайт быстрый»

Балл считает лабораторный тест. Он запускается один раз и не видит, что на реальных телефонах через три секунды появляется поп-ап, а чат грузит ещё мегабайт скриптов. Бывает сайт с 95 баллами и красными полевыми данными, бывает и наоборот. Ориентируйтесь на верхний блок с данными реальных пользователей, а если его нет, на свою аналитику.

«Скорость — главный фактор в поиске»

Google прямо пишет, что Core Web Vitals используются его системами ранжирования. И там же уточняет: поиск всегда старается показать самый релевантный ответ, даже если страница медленная, а хорошие оценки не гарантируют первых мест. Справка Вебмастера Яндекса называет скорость важным показателем качества сайта, но о прямом влиянии на ранжирование не говорит. Посетители уходят с медленной страницы при любых позициях, и для заявок этого достаточно.

«У меня на компьютере всё открывается мгновенно»

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

«Надо уменьшить вес страницы, и всё»

Вес важен, но LCP зависит от порядка загрузки. Страница на 5 мегабайт может показать главный экран за 1,5 секунды, если всё тяжёлое грузится ниже. Страница на 1 мегабайт может показать его за 4 секунды, если главная картинка спрятана в скрипте, а сервер думает две секунды. Поэтому смотрите на этапы загрузки и только потом на итоговый размер.

«Ускорили один раз — и хватит»

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

Как понять, что заявки теряются из-за скорости

Медленный сайт и неудачный сайт дают похожую картину: люди быстро уходят. Различить их помогают три проверки.

1. Сравните отказы с телефона и с компьютера в Метрике. Если с телефона отказов заметно больше, проверьте мобильную скорость. Как Метрика считает отказы, я подробно описал в статье про показатель отказов.
2. Посмотрите несколько записей коротких визитов с телефона в Вебвизоре. Если человек видит белый экран или прыгающие блоки и уходит, дело в скорости. Если первый экран загрузился, а человек ушёл через 10 секунд, дело в содержании. Как искать такие записи, есть в статье про Вебвизор.
3. Проверьте, куда кликают на первом экране. Клики по фото, которое не открывается, и по номеру, который не набирается, относятся к удобству. Об этом статья про карту кликов.

Если скорость в норме, а заявок мало, ищите причину в оффере, форме и целях. С этим поможет разбор почему нет заявок с сайта.

Частые вопросы

Радик Ишкиняевоснователь one2click

С командой делаю сайты для бизнеса. one2click сделал, чтобы видеть, почему посетители уходят без заявки, и не пересматривать сотни записей руками.