Когда сайт тормозит при большом потоке посетителей, причина кажется понятной: нагрузка выросла, сервер не справляется, нужно оптимизировать проект или усиливать хостинг. Но бывает другая ситуация. Посетителей немного, заявок мало, рекламных кампаний нет, а сайт всё равно открывается медленно.
Владелец смотрит статистику и не понимает, в чём дело. На сайте всего несколько человек в день. Иногда даже меньше. Но главная страница загружается тяжело, админка подвисает, форма отправляется с задержкой, а обновление страницы занимает заметное время.
Малая посещаемость не гарантирует быструю работу. Сайт может тормозить не только из-за количества людей. На скорость влияют код, база данных, плагины, изображения, внешние сервисы, настройки CMS, лимиты хостинга, фоновые задачи и даже боты, которых не видно в обычной аналитике.
Поэтому разбирать медленный сайт нужно не с вопроса «сколько у нас посетителей», а с вопроса «что происходит при открытии страницы».
Один посетитель тоже создаёт нагрузку
Кажется, что один пользователь не может заметно нагрузить сервер. Иногда это правда. Если сайт простой, страницы статичные, изображения сжаты, кэш настроен, а база не перегружена, один посетитель почти не ощущается.
Но динамический сайт работает иначе. При каждом открытии страницы сервер может запускать PHP, обращаться к базе данных, загружать настройки CMS, проверять активные плагины, формировать меню, выводить виджеты, подключать шаблон, считать корзину, проверять сессии, подгружать SEO-данные, обращаться к внешним сервисам.
Если этот процесс сам по себе тяжёлый, даже один посетитель будет ждать. Проблема не в количестве людей, а в стоимости одного запроса.
Условно можно сравнить две ситуации:
- лёгкая страница собирается за 100–200 миллисекунд;
- тяжёлая страница собирается 3–5 секунд.
Во втором случае сайту не нужен большой трафик, чтобы казаться медленным. Он уже медленный на уровне одной операции.
Тяжёлая CMS и лишние расширения
Популярные CMS удобны тем, что позволяют быстро собрать сайт без разработки с нуля. Но удобство часто оплачивается лишней нагрузкой. Система загружает ядро, тему, плагины, модули, настройки, языковые файлы, виджеты и служебные данные.
На старте всё может работать нормально. Потом владелец добавляет форму, SEO-модуль, конструктор страниц, галерею, защиту от спама, кэш, онлайн-чат, аналитику, всплывающее окно, мультиязычность, модуль отзывов. Каждый элемент кажется небольшим. Вместе они создают тяжёлую цепочку.
Особенно часто сайт замедляют:
- визуальные конструкторы страниц;
- темы с большим количеством встроенных функций;
- плагины, которые работают на каждой странице;
- модули статистики внутри CMS;
- тяжёлые фильтры и каталоги;
- несколько плагинов, которые делают похожие вещи;
- старые расширения, которые давно не обновлялись;
- плагины безопасности с постоянным сканированием.
Посетителей может быть мало, но если каждая страница проходит через десятки лишних операций, сайт будет тормозить.
Проблемы с темой или шаблоном
Иногда сайт медленно работает не из-за CMS в целом, а из-за конкретной темы. Особенно если тема универсальная и рассчитана «на всё сразу»: лендинги, магазины, портфолио, блоги, каталоги, анимации, блоки, слайдеры, разные варианты шапки и футера.
Такая тема может подключать много файлов даже на простой странице. Пользователь открывает обычный текстовый раздел, а браузер загружает слайдер, иконки, несколько библиотек JavaScript, стили для блоков, которые на этой странице вообще не используются.
Сервер при этом тоже тратит время на сборку страницы. Если тема добавляет сложные настройки, обращения к базе и дополнительные проверки, замедление видно даже при одном посетителе.
Проверить это можно простым способом: временно включить стандартную лёгкую тему на тестовой копии сайта и сравнить скорость. Если разница большая, проблема может быть именно в шаблоне.
База данных разрослась и мешает работе
База данных часто становится причиной медленной работы при небольшой посещаемости. В ней хранятся страницы, настройки, товары, заказы, пользователи, комментарии, ревизии, логи, временные записи и данные плагинов.
Даже если посетителей мало, каждый динамический запрос может обращаться к базе. Если таблицы большие, не очищались годами, содержат много мусора или выполняют тяжёлые запросы, сайт отвечает медленно.
Частые признаки проблем с базой:
- админка долго открывает список записей или товаров;
- поиск работает с задержкой;
- фильтры собирают результат слишком долго;
- резервная копия базы создаётся медленно;
- сохранение страницы занимает несколько секунд;
- после удаления плагинов в базе остаются большие таблицы;
- в логах видны медленные SQL-запросы.
Иногда достаточно очистить ревизии, временные данные, старые логи и таблицы удалённых модулей. Иногда нужна более серьёзная оптимизация запросов. Просто сменить тариф без чистки базы тоже можно, но это скорее отсрочка проблемы.
Кэш либо не настроен, либо работает неправильно
Кэширование помогает не собирать страницу заново при каждом открытии. Если готовая версия страницы уже сохранена, сервер отдаёт её быстрее и тратит меньше ресурсов.
Но на многих сайтах кэш либо не включён, либо настроен частично. Например, кэшируется только главная страница, но не статьи. Или кэш постоянно очищается после любого действия. Или разные плагины кэширования конфликтуют между собой.
Есть и обратная ситуация: кэш включён, но владелец проверяет сайт как авторизованный администратор. Для авторизованного пользователя страницы могут не кэшироваться. В результате кажется, что весь сайт тормозит, хотя обычный посетитель видит более быструю версию.
Проверять нужно разные сценарии:
- открытие сайта в режиме инкогнито;
- скорость главной страницы;
- скорость внутренних страниц;
- работу форм;
- админку;
- страницы с динамическими элементами;
- поведение после очистки кэша.
Кэш не лечит плохую архитектуру, но без него даже небольшой сайт может работать тяжелее, чем нужно.
Изображения слишком большие
Медленная загрузка не всегда связана с серверной частью. Иногда сайт быстро формирует HTML, но страница долго грузится в браузере из-за тяжёлых изображений.
Типичная ситуация: на страницу загружены фотографии прямо с телефона или камеры. Размер одного изображения — 4–8 МБ. Внешне картинка отображается маленькой, но браузер всё равно скачивает большой файл. Если таких изображений несколько, страница становится тяжёлой даже при малой посещаемости.
Проблемы создают:
- фотографии без сжатия;
- баннеры в слишком большом разрешении;
- изображения PNG там, где достаточно WebP или JPEG;
- галереи, которые грузят все фото сразу;
- фоновые изображения большого размера;
- иконки, загруженные как большие картинки.
Если сайт открывается медленно на мобильном интернете, изображения нужно проверить в первую очередь. Иногда сжатие картинок даёт больший эффект, чем смена хостинга.
Внешние скрипты тормозят страницу
Современный сайт часто подключает много внешних сервисов: аналитику, пиксели рекламы, онлайн-чат, карты, виджеты отзывов, формы, антиспам, шрифты, платежные модули, сервисы обратного звонка.
Каждый внешний скрипт добавляет запрос. Если сервис отвечает медленно, страница может ждать. Иногда пользователь видит пустое место, задержку в отрисовке или подвисание интерфейса.
Даже при одном посетителе браузер может обращаться к десяткам внешних адресов. Поэтому малая посещаемость не спасает от медленной загрузки, если страница перегружена сторонними вставками.
Полезно периодически проверять:
- какие внешние скрипты подключены;
- нужны ли они на всех страницах;
- можно ли загружать часть скриптов позже;
- не дублируются ли счетчики;
- не висит ли старый код рекламных систем;
- не подключены ли виджеты, которые уже никто не использует.
Иногда сайт ускоряется просто после удаления нескольких забытых вставок.
Боты и сканеры не попадают в обычную аналитику
Владелец может видеть в аналитике мало посетителей, но это не значит, что сервер получает мало запросов. Часть трафика создают роботы: поисковые системы, сканеры, парсеры, спам-боты, сервисы проверки уязвимостей, инструменты мониторинга.
Обычная аналитика может не показывать такие запросы, потому что боты не выполняют JavaScript или не учитываются как пользователи. Но сервер всё равно обрабатывает их обращения.
Особенно неприятны сканеры, которые быстро перебирают URL, параметры, формы, несуществующие адреса, страницы поиска или фильтры. В статистике посещений всё спокойно, а в логах — сотни или тысячи запросов.
Проверить это можно через серверные логи. Нужно посмотреть:
- какие IP делают много запросов;
- какие страницы открываются чаще всего;
- нет ли обращений к мусорным URL;
- сканируются ли технические разделы;
- как часто запрашиваются формы и поиск;
- не обходятся ли бесконечные комбинации параметров.
Иногда сайт тормозит «без посетителей» именно потому, что реальные посетители не единственные, кто обращается к серверу.
Фоновые задачи запускаются в неподходящее время
Сайт может выполнять много действий без участия посетителей. Резервное копирование, обновление CMS, импорт товаров, генерация фидов, отправка писем, очистка кэша, проверка безопасности, cron-задачи, синхронизация с внешними сервисами.
Если такая задача тяжёлая, сайт может тормозить даже при нулевой посещаемости. Например, ночью запускается бэкап, утром идёт импорт каталога, днём модуль безопасности сканирует файлы. Пользователь открывает сайт именно в этот момент и видит задержку.
Частые проблемы:
- бэкап создаётся слишком часто;
- резервные копии хранятся на том же диске и забивают место;
- импорт обрабатывает слишком большой файл за один раз;
- cron-задачи дублируются;
- сканирование безопасности запускается в рабочие часы;
- очистка кэша происходит слишком агрессивно.
Фоновые процессы нужно планировать. Иначе сайт может тормозить не от посетителей, а от собственной служебной активности.
Хостинг ограничивает ресурсы даже при малом трафике
На обычном хостинге сайт получает не весь сервер, а часть ресурсов. У тарифа могут быть лимиты по процессорному времени, оперативной памяти, количеству процессов, времени выполнения PHP, обращениям к базе, количеству файлов, отправке писем.
Если сайт тяжёлый, он может достигать лимитов даже при малом количестве посетителей. Например, один запуск импорта, одна тяжёлая страница, один большой запрос к базе или один неудачный плагин могут потреблять больше ресурсов, чем ожидается.
В панели хостинга стоит смотреть не только место на диске, но и другие показатели. Если ресурсные лимиты часто достигают верхней границы, медленная работа уже не выглядит загадкой.
Для сравнения полезно смотреть, какие параметры обычно указывают в тарифах для размещения сайтов. Например, можно открыть описание Linux-хостинга и обратить внимание не только на объём диска, но и на возможности, которые важны для реальной работы сайта.
Старые версии PHP и CMS
Сайт может тормозить из-за устаревшего окружения. Старые версии PHP обычно работают медленнее новых, а старые CMS и плагины могут содержать неэффективный код. Иногда проект годами не обновлялся, потому что «и так работает».
Потом выясняется, что сайт работает, но тяжело. Новые версии PHP могли бы дать прирост скорости, но CMS или тема несовместимы. Обновление становится отдельной задачей, которую откладывали слишком долго.
Перед обновлениями нужно делать копию и тестировать сайт на отдельной среде. Но игнорировать устаревшее окружение тоже нельзя. Оно влияет не только на безопасность, но и на производительность.
Слишком много шрифтов и декоративных элементов
Иногда сайт тормозит из-за визуальных деталей. Несколько нестандартных шрифтов, анимации, большие иконки, слайдеры, видеофоны, всплывающие блоки, эффекты при прокрутке. Всё это может выглядеть красиво, но нагружает браузер.
На мощном компьютере с быстрым интернетом проблема почти не видна. На мобильном устройстве сайт кажется тяжёлым. Посетителей может быть мало, но каждый из них получает перегруженную страницу.
Стоит проверить:
- сколько шрифтов загружается;
- сколько начертаний подключено;
- нужны ли все анимации;
- не грузятся ли слайдеры на страницах, где они не нужны;
- можно ли заменить часть эффектов обычной версткой;
- как сайт работает на телефоне.
Иногда простая страница продаёт лучше, чем эффектная, но медленная.
Медленная админка не всегда равна медленному сайту
Бывает, что публичная часть сайта открывается нормально, а админка работает тяжело. Это отдельная проблема, но она тоже важна.
Админка может тормозить из-за количества записей, товаров, заказов, плагинов, уведомлений, проверок обновлений, метабоксов, статистики и запросов к внешним сервисам. Посетитель этого не видит, но сотрудники теряют время каждый день.
Если менеджер тратит лишние минуты на обработку каждого заказа, это уже бизнес-проблема. Даже при низкой посещаемости медленная админка мешает развивать сайт.
В таких случаях нужно отдельно оптимизировать административную часть: отключать лишние блоки, чистить базу, уменьшать количество плагинов, проверять серверные лимиты и смотреть медленные запросы.
Как искать причину без хаоса
Медленный сайт лучше диагностировать по шагам. Если менять всё подряд, трудно понять, что помогло.
- Проверить скорость для обычного посетителя в режиме инкогнито.
- Сравнить главную, внутреннюю страницу, форму и админку.
- Посмотреть размер страницы и изображений.
- Проверить внешние скрипты.
- Открыть серверные логи.
- Посмотреть нагрузку от ботов.
- Проверить размер и состояние базы данных.
- Отключить лишние плагины на тестовой копии.
- Проверить кэширование.
- Посмотреть лимиты ресурсов в панели хостинга.
После такого разбора обычно становится понятно, где искать дальше. Иногда проблема на поверхности: огромные изображения или отключённый кэш. Иногда нужно глубже смотреть базу, код и серверные ограничения.
Когда проблема точно не в количестве посетителей
Есть ситуации, где посещаемость почти не играет роли. Например:
- страница долго генерируется даже при первом одиночном запросе;
- админка тормозит при любом действии;
- база выполняет медленные запросы;
- изображения слишком большие;
- внешний сервис задерживает загрузку;
- сервер достиг лимита памяти из-за фоновой задачи;
- боты активно сканируют сайт без отображения в аналитике;
- CMS загружает много лишнего кода.
В таких случаях увеличение трафика только ухудшит ситуацию. Сайт уже работает тяжело сам по себе.
Что можно исправить первым
Если нужно быстро улучшить ситуацию, начать можно с самых частых и понятных действий:
- сжать изображения;
- включить или проверить кэширование;
- удалить лишние плагины;
- отключить неиспользуемые внешние скрипты;
- очистить старые ревизии и временные данные;
- проверить размер базы;
- посмотреть логи на предмет ботов;
- перенести тяжёлые cron-задачи на менее активное время;
- обновить PHP и CMS на тестовой копии;
- оценить, хватает ли ресурсов хостинга.
Не все действия нужно выполнять сразу на рабочем сайте. Лучше делать копию, проверять изменения и сохранять резервные копии перед серьёзными правками.
Медленный сайт — это не всегда проблема трафика
Небольшая посещаемость не означает, что сайт должен автоматически работать быстро. Если одна страница собирается тяжело, база перегружена, плагины конфликтуют, изображения огромные, внешние скрипты тормозят, а фоновые задачи работают без контроля, сайт будет медленным даже при нескольких посетителях в день.
Правильный подход — смотреть на всю цепочку: сервер, CMS, базу, шаблон, файлы, кэш, ботов, внешние сервисы и ежедневные задачи. Только так можно понять, где сайт теряет скорость.
Иногда решение простое: сжать картинки, удалить лишний модуль, включить кэш. Иногда нужна чистка базы или переход на более подходящий хостинг. В любом случае причина почти всегда находится, если не ограничиваться фразой «посетителей мало, значит тормозить нечему».
Сайт должен быть быстрым не только при большом трафике. Он должен быстро отвечать уже на первом запросе. Если этого нет, значит, проблема лежит глубже, чем количество посетителей.