Разбираем типичные узкие места и порядок их устранения на примере портала с 200 000 посещений в день.
На небольшой странице лишний скрипт легко не заметить. На крупном портале он загружается снова и снова, занимает время браузера и может задерживать открытие меню, поиск или отправку формы.
При этом одинаковая жалоба «сайт тормозит» может означать разные проблемы. У одного посетителя долго появляется статья, у другого зависает поиск, у третьего страница не открывается в часы пик. Покупка более дорогого сервера поможет только части из них.
Для разбора возьмём модельный портал с 200 000 посещений в сутки. Технические примеры основаны на нашей истории доработок другого сайта: обновлении оформления статей, добавлении связанных страниц и отключении ненужных модулей. Это не отчёт о фактическом ускорении портала с такой посещаемостью.
Сначала нужно понять, где теряется время
Перед исправлениями мы бы разделили проверку на три части:
- Ответ сервера. Сколько времени проходит до начала получения страницы.
- Появление основного содержимого. Когда посетитель видит статью, изображение или другой главный блок.
- Реакция на действия. Как быстро открываются меню, поиск и формы.
Измерять только главную страницу недостаточно. У портала могут быть быстрые статьи и медленный поиск, а у зарегистрированных пользователей загрузка может отличаться от гостевой.
Суточная посещаемость тоже не определяет нагрузку сама по себе. Важны просмотры страниц, запросы к серверу и распределение по времени. Портал, который получает половину трафика за час после громкой новости, отличается от сайта с равномерной посещаемостью.
1. Страница загружает слишком тяжёлые изображения
Обложка статьи может отображаться шириной в несколько сотен пикселей, а загружаться в исходном размере. Если таких изображений несколько, посетитель скачивает данные, которые на его экране не дают заметного выигрыша в качестве.
Проверять нужно размер файлов и то, когда браузер начинает их загружать. Главная обложка должна появляться вовремя, а изображения далеко внизу страницы можно загружать по мере приближения к ним. Откладывать загрузку главного изображения без разбора не стоит: это способно ухудшить время появления основного содержимого. Подробнее об этой зависимости есть в руководстве по оптимизации LCP.
В нашей истории работ оформление сначала изменили у одной статьи, затем распространили на 300 публикаций. Это пример того, почему важен общий шаблон: решение, принятое в нём, повторяется на сотнях страниц. Но само обновление оформления ещё не доказывает ускорение.
Цена проблемы. Предположим, при каждом из 200 000 посещений браузер дополнительно скачивает 1 МБ изображений. Это около 200 ГБ лишней передачи данных в день, или 6 ТБ за 30 дней. Расчёт условный: фактический объём зависит от просмотров, браузерного кэша и повторных загрузок. Счёт за передачу данных зависит от тарифа хостинга или CDN.
Что исправлять. Подготовить подходящие размеры изображений, настроить выбор версии под экран и порядок загрузки. В смету должны входить проверка шаблонов и качество картинок после обработки, а не только массовое сжатие файлов.
2. Браузер занят скриптами, которые странице не нужны
Статья уже видна, но меню открывается с задержкой. Поиск реагирует не сразу, а прокрутка становится неровной. В таком случае проблема может находиться в коде, который выполняется на устройстве посетителя.
Причиной бывают виджеты, рекламные блоки, обработчики событий и модули, подключённые на всех страницах независимо от необходимости. Диагностика должна показать, какой код задерживает конкретное действие. Для оценки отзывчивости используется метрика INP, описанная в руководстве по оптимизации взаимодействий.
В одном из наших релизов мы отключали публичный модуль. Вместе с выводом блока убрали его стили, скрипты и публичный программный маршрут. Простое скрытие блока через CSS сохранило бы часть ненужной работы.
На портале тот же вопрос стоит задать к каждому компоненту: нужен ли видеоплеер на текстовой статье, должен ли виджет загружаться до открытия пользователем, используется ли эта библиотека вообще?
Цена проблемы. Посетитель ждёт реакции интерфейса, хотя страница уже загружена. При этом более мощный сервер не устранит тяжёлый код в его браузере.
Что исправлять. Убирать неиспользуемые компоненты, подключать код только на нужных страницах и откладывать второстепенную работу. После изменений нужно проверить функции: удалённый скрипт мог обслуживать не только видимый блок, но и форму или аналитику.
3. Сервер повторяет вычисления, результат которых почти не меняется
На странице портала могут находиться подборки материалов, ссылки по теме, рейтинги и счётчики. Если при каждом открытии статьи система заново ищет связанные публикации и выполняет множество запросов к базе, нагрузка растёт вместе с просмотрами.
Проверять нужно время выполнения конкретных запросов и функций. Количество установленных плагинов само по себе не объясняет задержку: один компонент может выполнять больше работы, чем несколько остальных вместе.
В нашем проекте блок связанных страниц появился на 273 публикациях и содержал 539 ссылок. Связи подготовили заранее, а при открытии страницы сайт использовал готовое соответствие. Для этого блока не добавляли подбор по ключевым словам во время запроса и новую зависимость от JavaScript.
Для портала это применимо к подборкам, которые меняются при редактировании материала. Персональные рекомендации требуют другого подхода.
Цена проблемы. Повторные вычисления занимают процессор и базу данных. При росте нагрузки запросы могут выстраиваться в очередь, а расходы на инфраструктуру увеличиваться.
Что исправлять. Найти дорогие операции, убрать повторные запросы, подготовить неизменяемые результаты заранее. Стоимость зависит от того, достаточно ли изменить один блок или придётся перерабатывать поиск и структуру данных.
4. Кэш не используется там, где мог бы помочь
Если тысяча читателей открывает одну и ту же общедоступную статью, серверу не всегда нужно тысячу раз собирать одинаковую страницу.
Кэш позволяет повторно использовать подготовленный результат. Но сначала нужно проверить, какие запросы действительно получают готовую копию, а какие каждый раз запускают приложение. Настройки кэширования и базы входят в рекомендации по производительности WordPress.
Для портала важно также понимать, что происходит после публикации новости или очистки кэша. Быстрая работа на прогретых страницах не показывает, как система выдержит одновременные обращения к ещё не подготовленному материалу.
Персональные страницы требуют отдельных правил. Общий кэш не должен отдавать одному человеку данные другого пользователя.
Цена проблемы. Сервер повторяет работу для одинаковых запросов. Ошибка в противоположную сторону тоже обходится дорого: посетители могут видеть устаревший материал или некорректное состояние страницы.
Что исправлять. Определить, что можно кэшировать, как долго хранить результат и когда его обновлять. Проверить гостевые и авторизованные сценарии, публикацию изменений и работу после очистки. Установка плагина без этих проверок не завершает задачу.
5. Не справляется сервер или один из промежуточных сервисов
Иногда приложению действительно не хватает ресурсов. Но между посетителем и сайтом могут находиться CDN, защита от атак и другие сервисы. Их ошибки нужно отличать от проблем основного сервера.
В истории наших релизов был такой эпизод: запросы к файлу стилей временно получали 502 на промежуточном защитном узле, а повторная проверка завершилась успешно. Этот случай не доказывает хроническую медленную работу сайта, но показывает, почему нельзя проверять только приложение.
Отдельно нужно исключить постороннюю нагрузку. На исходном проекте мы находили вредоносные файлы. Их влияние на скорость не измеряли, поэтому связывать с ними торможение было бы необоснованно.
Цена проблемы. В часы пик растут задержки или появляются ошибки. Владелец может платить за дополнительные ресурсы, хотя причина находится во внешнем сервисе, фоновой задаче или конкретном запросе.
Что исправлять. Сопоставить ошибки со временем нагрузки, проверить процессор, память, диск и очереди. Затем определить, помогает ли настройка, исправление кода или увеличение мощности. При действующей аварии временно добавить ресурсы может быть оправданно ещё до завершения расследования.
Как посчитать цену медленного сайта в деньгах
Без аналитики нельзя утверждать, что каждая лишняя секунда стоит определённого процента выручки. Для рекламного портала можно начать с числа просмотров и фактического дохода на тысячу просмотров.
Условный пример:
- портал получает 200 000 посещений в день;
- средняя глубина просмотра снизилась на 0,2 страницы;
- средний доход составляет 100 рублей на тысячу просмотров страниц.
Разница составит 40 000 просмотров в день, или 1,2 млн за 30 дней. При указанном доходе это 120 000 рублей в месяц.
Это арифметический сценарий, не оценка потерь нашего проекта. Чтобы отнести снижение глубины к скорости, нужно проверить другие причины: источники трафика, устройства, содержание и сезонность. А доход на тысячу просмотров страниц нельзя подменять ставкой за тысячу рекламных показов.
В каком порядке устранять проблемы
Начинать лучше с измерений на нескольких типах страниц: главной, статье, рубрике, поиске и личном кабинете, если он есть. Мобильные и настольные устройства нужно смотреть отдельно. Лабораторный тест помогает найти причину, а данные реальных посещений показывают масштаб проблемы.
Дальше порядок зависит от результата:
- Ошибки и недоступность. Сначала восстановить работу и устранить подтверждённые угрозы.
- Медленный ответ сервера. Разобрать запросы, внешние зависимости, кэш и ограничения ресурсов.
- Медленное появление содержимого. Проверить изображения, стили и порядок загрузки.
- Задержки при действиях. Найти код, который мешает меню, поиску и формам.
- Повторная проверка. Сравнить результат при сопоставимых условиях и убедиться, что функции сохранились.
Это не список работ, который нужно выполнить целиком на любом сайте. Если задержку создаёт один внешний запрос, начинать с переработки всех изображений бессмысленно.
Что должно быть в смете на ускорение
Формулировка «ускорим сайт» слишком расплывчата для согласования бюджета. До начала работ полезно получить ответы на четыре вопроса:
- Где обнаружена задержка и чем это подтверждено?
- Какие изменения предлагаются?
- По каким показателям будут проверять результат?
- Что входит в цену: диагностика, разработка, тестирование, внедрение и откат?
Универсальную стоимость исправления каждой из пяти причин без этих данных назвать нельзя. Настроить размеры изображений в готовом шаблоне и переработать поиск крупного портала могут быть задачами совершенно разного масштаба.
Для портала с 200 000 посещений в день разумный первый результат диагностики выглядит конкретно: названы страницы и операции, которые тормозят, показана их доля в задержке и предложен порядок исправлений с отдельной оценкой каждого этапа. Такой план позволяет оплачивать работы последовательно и проверять эффект до следующего вложения.