Почему сайт медленно грузится и как найти причину за 15 минут

Чаще всего сайт тормозит из-за одного из пяти мест: медленный ответ сервера, тяжёлые картинки, лишние сторонние скрипты, отсутствие кеша или устаревшие CMS и PHP. Откройте PageSpeed Insights и вкладку Network в браузере — за 15 минут видно, какое из пяти ваше. Если причина не снимается своими силами, дальше нужна оптимизация скорости живого сайта.

Короткий ответ: 5 причин и диагностика за 15 минут

Ниже — восемь шагов проверки. Каждый занимает одну-две минуты, инструмент — бесплатный, результат виден сразу.

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

Причина 1: сервер отвечает медленно (TTFB)

TTFB (time to first byte) — время от запроса страницы до первого байта ответа сервера. Если TTFB больше 0,6 секунды на всех страницах подряд, включая самые лёгкие, дело не в контенте страницы, а в сервере. Причины типичные: слабая конфигурация хостинга, нет кеша на уровне PHP, тяжёлые запросы к базе данных без индексов. Отличить эту причину от «тяжёлой страницы» просто. Откройте пустую страницу с минимумом контента — например, страницу входа в админку. Сравните её TTFB с TTFB обычной страницы каталога. Разница в разы указывает на сложность самой страницы, а не на сервер. Одинаково высокий TTFB везде — это сервер.

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

Причина 2: тяжёлые картинки, шрифты и сторонние скрипты

Картинка весом 2–3 МБ, загруженная прямо с телефона без сжатия. Самая частая находка при разборе медленной главной страницы. Современные форматы WebP и AVIF при том же визуальном качестве весят на 30–50 % меньше JPEG. Конвертация занимает минуты через плагин CMS или онлайн-конвертер. Шрифты тоже добавляют задержку, если подключены синхронно и блокируют отрисовку текста. Решение — одна строка кода: font-display: swap в CSS.

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

Core Web Vitals простыми словами: LCP, INP, CLS

Core Web Vitals — три метрики Google, по которым оценивают удобство загрузки страницы для живого посетителя, а не только скорость по секундомеру. Largest Contentful Paint (LCP) — время до отрисовки самого крупного видимого блока, хорошим считается результат до 2,5 секунды. Interaction to Next Paint (INP) — задержка отклика интерфейса на клик или тап, порог — 200 миллисекунд. Cumulative Layout Shift (CLS) — насколько сильно «прыгает» вёрстка во время загрузки, порог — 0,1 (источник: web.dev/articles/vitals, проверено 29.09.2026).

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

Причина 5: устаревшие CMS и PHP

Старая версия CMS и PHP замедляет сайт сразу по нескольким направлениям. Новые версии PHP быстрее старых на одних и тех же задачах. Необновлённые плагины и модули добавляют лишние запросы к базе. Есть и другой риск: снятая с поддержки версия не получает патчей безопасности. Это уже не только про скорость.

Плановое обновление CMS, плагинов и PHP закрывает проблему до того, как она проявится как «сайт тормозит». Какой календарь обновлений сайта держать в течение года — с частотой по CMS, модулям и PHP — расписано в отдельной статье о поддержке и обновлениях сайта после запуска.

Если сайт на 1С-Битрикс

У 1С-Битрикс своя специфика замедления. Общие советы про кеш и картинки закрывают только часть проблемы. Сильные и слабые стороны 1С-Битрикс как платформы разобраны в отдельном материале. Здесь — что проверить именно по скорости; если разбираться самостоятельно нет времени, узкие места находит сопровождение сайта на 1С-Битрикс.

Первым делом откройте «Монитор производительности» в панели администратора: инструмент оценивает сайт по числу страниц в секунду, которое способен обработать сервер при текущей конфигурации, и подсвечивает узкие места (источник: курс «Монитор производительности» на dev.1c-bitrix.ru, проверено 29.09.2026). Дальше — композитный режим: он отдаёт посетителю статический HTML из кеша, а динамические блоки подгружает поверх, и для каталога с редко меняющимся контентом это самый быстрый вариант из всех режимов кеширования платформы. Включать его нужно не на всех сайтах. Если на странице много персонального контента (корзина, личный кабинет в каждом блоке), композит потребует точной настройки исключений. Иначе он покажет чужие данные одному посетителю вместо другого.

Кеш компонентов — второй уровень. Кешируйте тяжёлые блоки (каталог, меню, фильтры) отдельно от остальной страницы, чтобы не пересобирать их на каждый запрос. Агенты — фоновые задачи платформы. По умолчанию они запускаются на хитах живых посетителей. На сайте с высокой посещаемостью это добавляет случайные задержки конкретным пользователям. Перевод агентов на выполнение по расписанию (cron) вместо хитов убирает эту случайность: настройка через модуль «Агенты на кроне» или вручную, добавлением задания в планировщик хостинга (источник: инструкция по переводу агентов на cron, проверено 29.09.2026).

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

PHP на 1С-Битрикс — отдельный порог: с 1 февраля 2026 года платформа ограничивает поддержку продуктов на версиях PHP ниже 8.2, рекомендованная версия — 8.3 и выше (источник: helpdesk.bitrix24.ru, проверено 29.09.2026). Сайт на устаревшем PHP не получает обновлений с исправлениями — и скорости, и безопасности. Порядок, как проходит обновление ядра и PHP на Битриксе без падения сайта, разобран в отдельной статье про обновление 1С-Битрикс.

Чек-лист для Битрикса из восьми пунктов:

1. Открыть «Монитор производительности» и зафиксировать текущую оценку.
2. Включить композитный режим, если контент страниц в основном одинаков для всех посетителей.
3. Настроить кеш компонентов для каталога, меню и фильтров.
4. Перевести агенты на cron вместо выполнения на хитах.
5. Проверить список активных модулей Маркетплейса и отключить лишние.
6. Обновить PHP минимум до 8.2, рекомендованно — до 8.3 и выше.
7. Проверить размер таблиц статистики и логов в базе — разросшиеся b_event_log и b_search_content замедляют запросы.
8. Повторно снять оценку в «Мониторе производительности» и сравнить с шагом 1.

Лабораторные и полевые данные: почему PageSpeed «зелёный», а клиенты жалуются

PageSpeed Insights показывает два разных набора цифр одновременно, и путаница между ними — частая причина спора «у нас всё быстро» против «клиенты жалуются». Лабораторные данные (Lighthouse) — результат теста на одном устройстве при фиксированных условиях сети, они стабильны и удобны для сравнения версий сайта. Полевые данные (CrUX, Chrome UX Report) — реальные измерения у настоящих посетителей за последние 28 дней на самых разных устройствах и сетях (источник: About PageSpeed Insights, проверено 29.09.2026).

Сайт с хорошей лабораторной оценкой и плохими полевыми данными почти всегда объясняется разницей аудиторий. Тест в лаборатории идёт на стабильном канале. Часть реальных посетителей открывает сайт с медленного мобильного интернета в регионе. Яндекс Метрика даёт похожий, но свой взгляд на реальную скорость. Отчёт «Время загрузки страниц» показывает медиану по вашим посетителям без привязки к методологии Google. Проверяйте оба источника параллельно: полагаться только на один рискованно.

Что можно сделать самому, а что — к разработчику

Сжатие картинок, включение кеша браузера через плагин, отключение неиспользуемых виджетов и асинхронная загрузка скриптов — задачи для администратора сайта без навыков программирования. Час-два работы, не больше. Настройка серверного кеша, индексов в базе данных, композитного режима на Битриксе и перенос агентов на cron требуют доступа к серверу и понимания архитектуры CMS. Это зона разработчика или технической поддержки. Смешивать эти два уровня не нужно: неудачная правка на стороне сервера без бэкапа рискует уронить сайт целиком ради выигрыша в полсекунды загрузки.