Скорость загрузки напрямую влияет на конверсию и позиции в поиске: посетитель, столкнувшийся с долгим ожиданием, закрывает вкладку раньше, чем видит предложение. Механика этого влияния на продажи и ранжирование разобрана в статье о том, почему быстрая загрузка важна для SEO и продаж. Причины низкой скорости различаются, и одинаковый симптом у двух сайтов редко указывает на одинаковую техническую проблему.
Ниже разобрано, какие значения считаются нормой, как отличить медленный хостинг от тяжёлого контента и блокирующего кода, чем проверить сайт и в каком порядке устранять найденное. Порядок диагностики важнее полноты работ: при времени ответа сервера в полторы секунды минификация не даст измеримого эффекта.
Как понять, что сайт действительно загружается медленно
Субъективные оценки скорости расходятся: одному и тому же сайту один наблюдатель приписывает заметное замедление, другой — мгновенный отклик, и разрешают спор только измерения. Открытие до 1–2 секунд воспринимается как быстрое, 2–4 секунды остаются в пределах допустимого, после 3–5 секунд часть аудитории уходит. В справке регистратора Руцентр о долгой загрузке приемлемым ожиданием названы те же 1–2 секунды, а ожидание дольше 3 секунд связано с потерей трафика и позиций.
По исследованию Google, 53% пользователей покидают мобильный сайт, если он загружается дольше 3 секунд, а рост времени загрузки с 1 до 3 секунд повышает вероятность отказа на 32%. С 2021 года Google использует Core Web Vitals как фактор ранжирования. Прямого аналога у Яндекса нет: он судит о быстроте через поведенческие факторы, то есть отказы, возврат в поиск и глубину просмотра.
Метрика FID устарела, и в марте 2024 года её место в Core Web Vitals заняла INP. Пороги Google для мобильной версии по TTFB:
- LCP до 2,5 секунды;
- INP до 200 миллисекунд;
- CLS не выше 0,1;
- FCP до 1,8 секунды;
- TTFB до 0,6–0,8 секунды.
| Метрика | Что показывает | Норма | Рычаг исправления |
|---|---|---|---|
| TTFB | Время до начального байта ответа | 0,6–0,8 с | Тарифный план хостинга, кэширование на стороне CMS, длительные запросы к базе данных |
| FCP | Первое содержимое на экране | 1,8 с | Критический CSS, шрифты |
| LCP | Отрисовка крупнейшего видимого элемента | 2,5 с | Главное изображение, блокирующие ресурсы |
| INP | Задержка отклика на действие | 200 мс | Объём и тяжесть клиентского JavaScript |
| CLS | Сдвиги вёрстки при загрузке | 0,1 | Размеры картинок, баннеры, шрифты |
Почему сайт загружается медленно: основные причины
Загрузка страницы складывается из последовательных этапов: DNS-запрос, установка соединения, ответ с HTML, приём стилей, шрифтов, скриптов и изображений, отрисовка и выполнение JavaScript. Задержка способна возникнуть на любом из них, поэтому вопрос «почему сайт долго грузится» без указания конкретного этапа не позволяет локализовать источник задержки.
В справке регистратора Руцентр о долгой загрузке названы четыре фактора: работа CMS и скриптов, производительность сервера, соединение пользователя и генерация страницы в браузере. Это же деление применяется при диагностике: оно позволяет определить, на каком этапе снижается скорость загрузки и почему задержка проявляется лишь у части аудитории.
Сервер долго отвечает: хостинг, CMS и база данных
TTFB выше 0,6–0,8 секунды указывает на проблему у хостинга, движка или СУБД. Дешёвый виртуальный тариф делит ресурсы с десятками других сайтов, и в часы нагрузки падает скорость сайта. Движок выполняет сотни обращений без индексов, а вызовы сторонних сервисов задерживают ответ, и ответа от недоступного сервиса сервер ждёт до таймаута.
Тяжёлые изображения и медиафайлы
По открытым данным рынка, тяжёлые неоптимизированные изображения считаются самым частым и самым легко устранимым фактором. Фотография шириной в тысячи пикселей выводится в блоке в несколько сотен, и браузер скачивает файл целиком, и уже затем масштабирует его средствами браузера. Сюда же идут фоновые видео и слайдеры.
Стили, скрипты и шрифты блокируют отрисовку
Браузер не покажет содержимое, пока не разберёт таблицы стилей, а синхронный код в начале документа останавливает разбор HTML. Отсюда характерная картина: отклик приходит за 200 миллисекунд, а человек видит белый экран. Тяжёлый JavaScript бьёт по INP: сайт виден, но поток занят, и нажатия идут с задержкой.
Слишком много запросов, сторонних сервисов и нет кэширования
Плагины и темы с конструкторами подключают свои стили и код по всему сайту, даже там, где их функции не нужны. Сторонние виджеты (чаты, пиксели, аналитика) живут годами после отказа от сервиса. Без кэширования движок собирает одну и ту же страницу заново каждому посетителю.
Проблемы на стороне пользователя: соединение, устройство, география
Слабый Wi-Fi, старый роутер, перегруженный провайдер, медленный DNS и расширения браузера замедляют открытие документа. Если медленно открываются все сайты, а не один, проблема в подключении, и скорость загрузки сайта на разных скоростях связи различается в разы.
С апреля 2025 года мобильная версия лишилась дополнительной подстраховки: Яндекс отключил Турбо-страницы, и трафик из мобильного поиска приходит на оригинальный сайт со всем его весом.
Что проверить по каждой причине:
- у сервера смотрят TTFB, выбранный тариф, версию PHP и лог медленных запросов;
- у картинок сверяют вес и размеры с блоком, формат, width и height;
- в коде ищут стили и скрипты, которые грузятся в начале документа без нужды;
- по обращениям считают их число, сторонние домены и настройку кэша;
- у пользователя проверяют соединение и браузер без расширений.
Платформа добавляет особенности. На WordPress тормозят модули и конструкторы со своими стилями, магазины на 1С-Битрикс тяжелеют от запросов к каталогу, а в конструкторах шаблон закрыт от правок.
Как проверить скорость сайта и найти причину
Проверить скорость загрузки сайта на публичном сервисе можно за минуту, но результат нужно читать правильно. Лабораторные данные (Lighthouse, PageSpeed) моделируют условия: заданный смартфон и канал. Полевые данные (CrUX) показывают опыт реальных посетителей, и поисковые системы смотрят на них. Оценка по одному сводному баллу некорректна: высокий показатель нередко соседствует с реальными жалобами на медленную загрузку.
Инструменты для проверки
Базовый набор бесплатных инструментов для диагностики:
- PageSpeed Insights даёт лабораторные и полевые метрики в одном отчёте;
- Lighthouse запускает тот же анализатор в браузере после каждой правки;
- Chrome DevTools во вкладках Network и Performance показывает тайминги файла;
- WebPageTest и GTmetrix мерят из разных точек и на разных профилях связи;
- Google Search Console собирает Core Web Vitals по группам адресов;
- Яндекс Метрика и Google Analytics дают время загрузки у посетителей.
Построчный разбор отчёта приведён в разборе отчёта PageSpeed Insights, а часть сервисов детально рассмотрена в полном руководстве по замерам. Одного сервиса недостаточно: каскадная диаграмма загрузки запросов показывает, какой файл задерживает отрисовку, а счётчики аналитики оценивают, скольких посетителей эта задержка коснулась.
Как правильно проводить тестирование
Замер без единой методики даёт числа, которым нельзя доверять: два соседних прогона расходятся вдвое, и реальный прирост теряется в разбросе. В справке провайдера Рег.ру о медленной работе сайта отмечено, что стадии Queueing, Stalled, DNS Lookup и Initial connection суммарно укладываются менее чем в 0,1 секунды, а проблемным этапом чаще прочих оказывается Waiting — ожидание ответа сервера. Именно эта стадия показывает, где возникает задержка: на стороне хостинга или уже в браузере пользователя. Корректная методика замеров строится на следующих правилах:
- брать несколько типовых адресов: главную, каталог, карточку, статью;
- мерить мобильную и настольную версии врозь;
- делать несколько замеров подряд: начальный обычно выбивается;
- фиксировать показатели до изменений, иначе не с чем сравнивать;
- на изменение один замер.
Симптом → где искать причину
Метрики скорости сами указывают на источник замедления. Высокий TTFB свидетельствует о проблемах на стороне хостинга, слабый LCP — о содержимом видимой части экрана и блокирующих ресурсах, высокий INP — о тяжёлом JavaScript, слабый CLS — об изображениях без заданных размеров, баннерах и шрифтах, а большое число запросов — о сторонних подключениях.
По внешним признакам источник задержки читается так же. Долгий белый экран, после которого всё появляется сразу, выдаёт серверную часть, а пустое полотно при быстром отклике оставляют стили и шрифты. Изображение, приходящее позже текста, указывает на графику. Страница видна, но кнопки не реагируют — причина в JavaScript. Прыгающее содержимое выдаёт сдвиги вёрстки, а вялость на телефоне идёт от веса ресурсов и слабого процессора.
Как ускорить сайт: решения по каждой причине
Порядок ускорения загрузки сайта определяется результатами диагностики. Общий список «сделайте всё сразу» здесь неуместен: половина пунктов не даст эффекта. Сначала прорабатывается направление, названное виновником, затем следует контрольный замер, затем — переход к следующему. Сами группы факторов разобраны в статье о том, что влияет на быстроту сайта.
Серверная часть: хостинг, CMS и база данных
Смена тарифа рассматривается в последнюю очередь: более мощная машина не отменяет необходимости оптимизировать код. Если движок формирует документ секундами из-за сотен запросов, дополнительные ресурсы лишь маскируют проблему, и низкая скорость загрузки вернётся с ростом трафика. Сначала выполняются анализ скриптов, настройка кэширования и обновление окружения, и только затем — перенос на VPS или выделенный сервер.
С базой данных работают так. Сначала найти тяжёлые запросы через лог slow query и настроить индексы, затем удалить старые ревизии, спам-комментарии и просроченные сессии, а повторяющиеся закэшировать. Обновите окружение: PHP 7.x и новее производительнее линейки 5.x, а свежие версии CMS работают быстрее старых.
В диагностику включите проверку на вирусы, ведь опасные скрипты запускают ресурсоёмкие процессы и перегружают машину. Неиспользуемые плагины и темы удаляйте полностью, оставшиеся проверяйте по одному на тестовой копии.
Изображения и медиафайлы
Правка картинок окупается быстрее прочего, ведь из-за них низкая скорость загрузки страниц сайта держится и на мощном сервере. Порядок такой:
- привести размеры файлов к месту на странице, а не выводить фото в тысячи пикселей в блоке шириной 300;
- подключить srcset, чтобы телефон получал свою версию, а десктоп свою;
- проставить width и height, без которых содержимое прыгает и портит CLS;
- перевести графику в WebP или AVIF, которые при том же качестве весят на 25–50% меньше JPEG;
- сжать остальное.
Отложенную загрузку (lazy load) включают для картинок ниже первого экрана. Главную иллюстрацию, которая обычно и служит LCP-элементом, откладывать нельзя, её грузят заранее через preload. Частая ошибка: плагин включает lazy load везде, и LCP становится хуже.
CSS, JavaScript и шрифты
Задача в том, чтобы освободить видимую часть от лишнего. Выделите критический CSS, остальное грузите асинхронно. Шрифтов достаточно 1–2 семейств в формате WOFF2 с font-display: swap, лишние начертания убираются.
Некритичные скрипты (счётчики, чаты, виджеты) подключайте с атрибутами defer или async. На слабых смартфонах громоздкий JavaScript «замораживает» интерфейс и загоняет INP в красную зону. Вклад виджетов проверяют опытом: выключите самый тяжёлый на тестовой копии и сравните. По оценкам участников рынка, это нередко даёт прирост больше, чем минификация.
Сам код минифицируйте и чистите от неиспользуемых правил. При HTTP/2 и HTTP/3 мелкие файлы грузятся параллельно, поэтому сборка всего в один бандл нередко вредит, а полезнее разделение по разделам.
Кэширование, сжатие и отложенная загрузка
Кэширование настраивается на двух уровнях. У себя это готовая вёрстка и кэш движка, в браузере заголовки Cache-Control и Expires. Кэширующие модули есть во всех популярных CMS. Сжатие gzip или Brotli уменьшает объём передаваемых данных одной настройкой.
В той же справке Рег.ру о медленной работе сайта предложено разделять статические файлы (css, js, html, графику) и динамические (php-скрипты, обращения к базе данных). Для первых работают сжатие, размер и кэш, для вторых ускорение скриптов и отказ от внешних вызовов.
CDN и смена хостинга
CDN хранит копии статики ближе к пользователю и снижает задержки для аудитории по всей стране. Чем дальше узел раздачи, тем выше задержка, поэтому российской аудитории выгоднее дата-центр в России.
Переезд обоснованно выносится на завершающий этап. Если отклик остаётся высоким после чистки таблиц, кэширования и обновления PHP, смена хостинга оправдана.
В каком порядке исправлять: пошаговый план
В цепочке загрузки определяющей оказывается самая ранняя помеха: пока ответ сервера идёт секунду, эффект остальных улучшений остаётся незаметным. Этим и задан порядок работ: ответ сервера, ресурсы, блокирующие первый экран, основное изображение на нём, избыточный JavaScript, сдвиги вёрстки, прочие оптимизации.
Чек-лист, по которому ведутся работы:
- Зафиксировать исходные показатели на 3–4 страницах, мобильные и десктоп отдельно.
- Посмотреть TTFB. Выше 0,6–0,8 секунды разбираются с сервером: кэш CMS, тяжёлые SQL-запросы, версия PHP, лишние плагины, вирусы.
- Убрать с первого экрана блокирующие стили и скрипты, оставить критический CSS.
- Заняться LCP-элементом: размер под место, современный формат, preload вместо lazy load.
- Сократить JavaScript, повесив defer или async на счётчики.
- Закрыть CLS размерами картинок и местом под баннеры.
- Включить кэширование и сжатие, и лишь затем обсуждать CDN или переезд.
- Повторить замер после каждого шага.
Если после всех работ скорость сайта очень медленно приближается к норме, узкое место найдено неверно, и диагностику повторяют сначала.
Частые ошибки при оптимизации скорости
Неудачная оптимизация обходится дороже простоя. Время потрачено, бюджет израсходован, а скорость загрузки сайта осталась прежней. На практике повторяются пять ошибок.
- Смена хостинга вслепую. Переезд устраняет лишь один класс проблем, и если цепочку загрузки никто не смотрел, новый тариф даст доли секунды. Начинать нужно с разбора цепочки загрузки: какой запрос тормозит и сколько времени съедает.
- Несколько плагинов оптимизации сразу. Они конфликтуют и дублируют функции. Один минифицирует стили, другой их же склеивает, третий включает отложенную загрузку поверх первых двух. Какой помог, а какой сломал вёрстку, потом не разобрать. Подключать их следует по одному.
- Погоня за зелёной зоной PageSpeed. Балл 100 в лабораторном тесте при плохих полевых данных не улучшит ни поведение посетителей, ни позиции: поисковые системы читают опыт живых людей.
- Оптимизация одной главной. Заявки приходят с карточек, статей и лендингов, а они тяжелее главной: там галереи, отзывы и формы. Норму требуется держать на всех типах страниц.
- Тестирование в тепличных условиях. Производительный офисный компьютер на проводном соединении покажет результат, недостижимый для реальной аудитории. Замеры корректно проводить на мобильном профиле устройства и ограниченном канале связи.
Отдельная ошибка – считать ускорение разовой акцией. Новый виджет или обновление темы незаметно тянут показатели назад, поэтому сайт проверяют после каждой правки.
