Сайт стал медленным. Первая мысль владельца обычно предсказуема: виноват хостинг.
Иногда это действительно так. Сервер перегружен, процессор постоянно занят, база отвечает медленно или соседние аккаунты на виртуальном хостинге отбирают ресурсы. Но с таким же успехом сервер может отдавать страницу быстро, а посетитель еще несколько секунд смотреть на почти пустой экран из-за огромного изображения, тяжелого JavaScript или внешнего виджета.
Поэтому совет «перейдите на VPS» способен как решить проблему за один вечер, так и совершенно ничего не изменить.
Правильная оптимизация начинается не с покупки более дорогого тарифа и не с установки очередного плагина ускорения. Сначала нужно понять, где именно теряется время.
Условно загрузку страницы можно разделить на две большие части. Сначала браузер находит сервер, устанавливает соединение и ждет от него HTML. Затем получает документ и начинает загружать стили, скрипты, изображения, шрифты и остальные ресурсы, строя страницу на экране.
Если тормозит первая часть, мы смотрим в сторону сервера, приложения, базы данных, сети и кэширования. Если HTML приходит быстро, а страница долго становится видимой и отзывчивой, причина чаще находится уже на стороне содержимого страницы и браузера.
Это простое разделение экономит огромное количество времени.
Сначала выясните, медленный весь сайт или только одна страница
Не начинайте оптимизацию со слов «сайт тормозит». Это слишком расплывчатый диагноз.
Откройте главную страницу, несколько статей, страницу категории, карточку товара и административную часть. Проверьте сайт с телефона через мобильную сеть и с компьютера через домашний интернет. Желательно повторить тест в приватном окне браузера.
Если медленно открывается абсолютно все, включая простые страницы, подозрение на серверную часть становится сильнее.
Если главная грузится пять секунд, а обычная текстовая статья появляется почти мгновенно, вероятнее всего, дело в самой главной странице. Возможно, на ней работает слайдер, видео, карта, десяток рекламных блоков и несколько сторонних счетчиков.
Бывает наоборот. Статические страницы открываются быстро, но поиск по каталогу или определенный раздел интернет-магазина заметно тормозит. Тогда стоит изучать запросы к базе, фильтрацию и код конкретного функционала.
Есть еще один показательный случай: сайт быстрый для посетителей, но административная панель WordPress медленная. Обычный страничный кэш здесь может почти не помогать, потому что персонализированные административные запросы обрабатываются динамически.
До любых изменений запишите хотя бы несколько наблюдений. Какие URL медленные? Постоянно или только иногда? Только у вас или у других пользователей? В какое время суток?
Уже на этом этапе иногда становится видно направление поиска.
Что такое TTFB и почему он помогает отделить сервер от страницы
TTFB расшифровывается как Time to First Byte, время до получения первого байта ответа.
В очень упрощенном виде браузер отправляет запрос и ждет, когда начнет приходить ответ. В это время входят сетевые задержки, установление соединения и работа сервера, поэтому TTFB нельзя считать чистым временем выполнения PHP. Но показатель хорошо помогает увидеть, что задержка возникает еще до загрузки основной массы ресурсов страницы.
Представим два сайта.
У первого HTML начинает приходить быстро, но затем браузер скачивает несколько мегабайт изображений и выполняет тяжелые скрипты. У второго страница визуально простая, однако сервер две секунды думает перед началом ответа.
Оба сайта могут субъективно казаться медленными, но лечить их одинаково бессмысленно.
В первом случае увеличение процессора сервера может почти ничего не дать. Во втором сжатие фотографии на 100 КБ не устранит двухсекундное ожидание HTML.
Проверять TTFB лучше несколько раз и из разных точек. Один замер может попасть на прогрев кэша, кратковременный скачок нагрузки или сетевую проблему.
Особенно полезно сравнить одинаковую страницу с кэшем и без него, если архитектура сайта позволяет это сделать.
Когда действительно виноват хостинг
Есть ситуации, в которых серверная площадка становится очевидным кандидатом.
Сайт раньше работал нормально, код не менялся, но в часы пик ответ резко замедляется. На VPS постоянно заканчивается оперативная память или процессор работает около предела. В логах появляются ошибки нехватки ресурсов. Панель хостинга показывает достижение лимитов CPU, процессов или ввода-вывода.
На дешевом виртуальном хостинге ресурсы физического сервера разделяются между множеством клиентов. Хороший провайдер контролирует нагрузку и изолирует аккаунты, но возможности конкретного тарифа все равно ограничены.
WordPress в официальной документации по производительности прямо относит среду хостинга и нагрузку на сервер к факторам, влияющим на скорость сайта. Там же отмечается, что без кэширования рост числа запросов способен быстро перегрузить веб-сервер и базу данных. citeturn0search2
Но фраза «хостинг медленный» должна подтверждаться измерениями.
Если сервер отвечает быстро, ресурсы не упираются в лимиты, а страница весит 12 МБ, перенос на тариф вдвое дороже вряд ли даст эффект, которого ожидает владелец.
Перед переездом полезно спросить поддержку о фактическом потреблении ресурсов и посмотреть статистику нагрузки. На VPS дополнительно проверяют CPU, память, swap, дисковые операции, процессы PHP, веб-сервер и базу.
WordPress может тормозить даже на хорошем сервере
WordPress сам по себе способен работать быстро. Проблемы обычно появляются из сочетания темы, плагинов, базы, внешних запросов и неправильной конфигурации.
Количество плагинов не является идеальным показателем. Двадцать маленьких хорошо написанных расширений могут создавать меньше нагрузки, чем один тяжелый конструктор или модуль, выполняющий дорогой запрос к базе на каждом открытии страницы.
Поэтому совет «оставьте не больше десяти плагинов» слишком примитивен.
Гораздо полезнее искать конкретного виновника.
На тестовой копии сайта можно поочередно отключать подозрительные плагины и измерять результат. Официальное руководство WordPress также рекомендует удалять ненужные расширения и выборочно отключать плагины, чтобы определить, какой из них заметно влияет на производительность. citeturn0search2
Тема тоже имеет значение. Красивый шаблон способен тащить на каждую страницу универсальный набор стилей и скриптов, даже если большая их часть там не используется.
Отдельная история связана с визуальными конструкторами. Они позволяют быстро собирать сложные страницы, но результат иногда содержит глубокую HTML-структуру, множество CSS и JavaScript. Это не означает, что любой конструктор плох. Просто удобство редактирования имеет техническую цену, которую стоит измерять.
Если WordPress медленный только без кэша, проблема может долго оставаться незаметной посетителям и внезапно проявиться после очистки кэша или при всплеске динамических запросов.
Кэширование часто дает огромный эффект, но не исправляет все
Обычная страница WordPress может собираться динамически. PHP выполняет код, обращается к базе данных, WordPress загружает настройки, тему и плагины, после чего формируется HTML.
Если результат для большинства посетителей одинаковый, выполнять всю цепочку заново на каждый запрос расточительно.
Страничный кэш сохраняет готовый результат и отдает его повторным посетителям значительно дешевле.
Официальная документация WordPress называет кэширование одним из самых быстрых способов улучшить производительность. Статические копии страниц уменьшают вычислительную нагрузку на сервер. citeturn0search8turn0search2
Но есть важное «но».
Если кэш скрывает медленный запрос к базе, проблема все равно остается для тех страниц и пользователей, где кэш неприменим. Например, личный кабинет, корзина, оформление заказа и административная панель часто требуют динамической обработки.
Поэтому после установки кэша полезно проверить как кэшированные, так и некэшированные сценарии.
Кроме страничного существует объектное кэширование. WordPress может повторно использовать результаты дорогостоящего получения данных вместо постоянных обращений к базе. В качестве постоянного объектного кэша применяются, например, Redis и Memcached. WordPress отмечает, что лишние обращения к базе увеличивают время ответа сервера, включая TTFB, особенно во время всплесков нагрузки. citeturn0search2turn0search8
Но ставить Redis на сайт-визитку из пяти страниц только потому, что это звучит профессионально, необязательно. Архитектура должна соответствовать реальной нагрузке.
База данных иногда становится тормозом, который не видно глазами
Страница выглядит простой: заголовок, текст и три картинки. Но перед ее выводом плагин может выполнить десятки или сотни запросов.
На маленькой базе это незаметно. Через несколько лет таблицы выросли, появились сотни тысяч записей, а неоптимальный запрос внезапно начал занимать секунды.
Особенно чувствительны большие каталоги, сложные фильтры, поиск, статистические плагины и функции, работающие с большим количеством метаданных.
Не стоит начинать с бездумной «очистки базы» плагином.
Сначала нужно определить медленные запросы. Для этого разработчики используют профилирование, журналы медленных запросов СУБД и инструменты диагностики WordPress.
Иногда проблема решается индексом в таблице. Иногда виноват плагин. Иногда запрос нельзя быстро исправить, но его результат можно кэшировать.
Бывает и обычный мусор: старые ревизии, временные данные, оставшиеся таблицы удаленных расширений. Их уборка полезна, но не нужно ожидать, что уменьшение базы с 300 до 250 МБ автоматически ускорит сайт в десять раз.
Размер и скорость базы связаны не линейно.
Изображения остаются одной из самых банальных причин медленной страницы
Фотограф загрузил на сайт снимок прямо с камеры. Его размер 6000×4000 пикселей, файл весит 9 МБ. На странице фотография отображается шириной 900 пикселей.
Браузеру все равно приходится скачать исходный файл, если сайт не отдает уменьшенную версию.
Несколько таких фотографий легко превращают страницу в десятки мегабайт.
Яндекс среди рекомендаций по ускорению сайта отдельно советует использовать сжатие изображений и отложенную загрузку тех картинок, которые первоначально находятся за пределами видимой области. citeturn0search0
WordPress тоже относит количество изображений и размеры файлов к факторам производительности и рекомендует оптимизировать графику для веба. citeturn0search2
Правильная оптимизация не означает превращать фотографии в квадраты из JPEG-артефактов.
Нужно подобрать реальный размер изображения под место отображения, разумно сжать файл и использовать подходящий формат. Современные форматы вроде WebP и AVIF в подходящих сценариях позволяют существенно уменьшать объем, но поддержка и конкретный выигрыш зависят от содержимого изображения и цепочки обработки.
Для адаптивного сайта важно также не отправлять смартфону без необходимости ту же огромную картинку, которая предназначена для широкого монитора.
JavaScript может сделать медленным сайт, который сервер отдал мгновенно
Вот ситуация, которая особенно хорошо показывает разницу между серверной и клиентской скоростью.
HTML приходит за доли секунды. CSS и изображения тоже относительно легкие. Но браузер получает большой объем JavaScript, который нужно скачать, разобрать и выполнить.
На мощном настольном компьютере все выглядит приемлемо. На недорогом смартфоне страница несколько секунд плохо реагирует на действия.
Сервер здесь уже почти ни при чем.
Частые источники нагрузки: рекламные системы, аналитика, чаты поддержки, карты, видеоплееры, виджеты социальных сетей, сложные меню, анимации и универсальные библиотеки.
Особенно неприятны сторонние скрипты. Владелец сайта не всегда контролирует их размер и скорость ответа.
Яндекс рекомендует устранять ресурсы, блокирующие отрисовку, уменьшать размер JavaScript, CSS и HTML, а ненужные на первом этапе скрипты загружать асинхронно или отложенно. citeturn0search0
Здесь полезен принцип бюджета.
Каждый новый виджет должен оправдывать то, что он добавляет на страницу. Если онлайн-чат используется раз в месяц, но его скрипт загружается у каждого посетителя и заметно ухудшает производительность, возможно, цена удобства слишком высокая.
CSS и шрифты тоже умеют задерживать первый экран
Посетителю неважно, что HTML уже скачан, если браузер еще не может нормально нарисовать страницу.
Большие таблицы стилей, несколько наборов иконок и множество начертаний веб-шрифтов увеличивают объем ресурсов и способны задерживать отображение.
Особенно часто сайт загружает целое семейство шрифтов, хотя реально использует два начертания.
Другой пример: огромный CSS-файл от конструктора содержит стили для десятков компонентов, которых на текущей странице вообще нет.
Минификация помогает уменьшить объем текста, но сама по себе не решает проблему избыточности. Файл на 400 КБ после минификации может стать меньше, но браузеру все равно придется обработать большой набор правил.
Поэтому оптимизация бывает двух типов: сжать то, что необходимо, и перестать загружать то, что не нужно.
CDN полезна, но не является кнопкой ускорения любого сайта
CDN размещает кэшируемые ресурсы на распределенных узлах и может отдавать их пользователю с более подходящей точки сети.
Это особенно полезно для сайтов с посетителями из разных регионов и большим объемом статического содержимого.
Яндекс рекомендует CDN как один из способов ускорить доставку изображений, JavaScript и CSS. WordPress также отмечает, что перенос статических ресурсов на CDN способен одновременно ускорить их доставку и снизить нагрузку на сервер приложения. citeturn0search0turn0search2
Но CDN не исправит медленный SQL-запрос внутри WordPress, если каждый динамический запрос все равно идет к origin-серверу.
Она также не уменьшит тяжелый JavaScript только фактом его доставки с другого узла. Скрипт может скачаться быстрее, но браузеру все равно придется его выполнить.
Поэтому CDN следует подключать к понятной архитектуре, а не использовать как универсальное лекарство.
Почему один тест скорости может обмануть
Вы запустили проверку и получили плохой результат. Через пять минут повторили, и цифры стали заметно лучше.
Какой тест правильный?
Возможно, оба.
Первый запрос мог прогревать серверный кэш. Второй получил уже готовую страницу. В момент первого теста на сервере выполнялось резервное копирование. Измерения проводились из разных регионов. Сторонний рекламный сервер один раз ответил быстро, а другой раз медленно.
Поэтому производительность лучше оценивать серией измерений, а не одним скриншотом.
Еще важнее различать лабораторный тест и реальные данные пользователей.
Лабораторный инструмент создает контролируемый сценарий и отлично подходит для поиска технических проблем. Реальные посетители приходят с разными телефонами, браузерами, скоростью интернета и географией.
Яндекс рекомендует использовать отчеты Метрики для анализа работы сайта, а Вебмастер предоставляет диагностику технического состояния и инструменты контроля индексирования. citeturn0search0turn0search3
Если инструмент показывает идеальную оценку, а реальные пользователи массово уходят до загрузки страницы, красивой цифрой проблему не закрыть.
Core Web Vitals полезны, но скорость сайта ими не исчерпывается
В разговорах о производительности часто всплывают LCP, INP и CLS.
LCP связан со скоростью появления крупного значимого элемента страницы. INP оценивает отзывчивость интерфейса при взаимодействии. CLS отражает неожиданные изменения расположения элементов.
Эти метрики помогают смотреть на загрузку глазами пользователя, а не только измерять количество секунд до события браузера.
Но не стоит превращать оптимизацию в игру ради зеленого кружка.
Страница может иметь технически неплохие показатели и все равно раздражать человека огромным рекламным окном. Или быстро показать первый экран, но очень медленно выполнять поиск по каталогу.
Цель оптимизации не оценка сама по себе, а быстрый и предсказуемый сайт.
Почему сайт медленный только у одного человека
Иногда владелец пишет хостеру: «Сайт невыносимо тормозит». Поддержка открывает его и отвечает: «У нас все быстро».
И оба могут говорить правду.
Причина бывает в домашнем провайдере, Wi-Fi, VPN, антивирусе, расширении браузера, DNS-резолвере, конкретном маршруте до дата-центра или проблемах устройства.
Первый тест в такой ситуации прост: открыть сайт с другого устройства и через другую сеть.
Например, отключить Wi-Fi на телефоне и проверить через мобильный интернет.
Если разница огромная, бессмысленно сразу переписывать WordPress.
Следующий шаг: другой браузер или приватное окно. Затем можно проверить маршрут, DNS и наличие проблем у интернет-провайдера.
Если же сайт медленный из нескольких независимых сетей и регионов, вероятность локальной проблемы резко уменьшается.
Скорость может падать только в определенное время
Сайт работает прекрасно ночью и плохо вечером.
Это очень ценное наблюдение.
Возможно, вечером приходит больше посетителей и сервер достигает предела. Возможно, в это время запускается резервное копирование, импорт товаров или тяжелое задание cron. На виртуальном хостинге может проявляться общая нагрузка площадки.
Иногда причиной становится не человеческий трафик, а роботы.
Яндекс указывает, что большое число обращений роботов может увеличивать время ответа сервера, и рекомендует при проблемах анализировать серверные логи и статистику обхода. citeturn0search1
Есть и вредоносная нагрузка: перебор страницы входа, сканирование уязвимостей, парсинг каталога, хотлинкинг изображений, DoS и другие автоматические запросы. WordPress также перечисляет подобный трафик среди факторов, способных увеличить нагрузку на сервер. citeturn0search2
Поэтому график нагрузки за сутки иногда рассказывает больше, чем десять тестов PageSpeed.
Не начинайте оптимизацию с удаления всего подряд
Есть опасный сценарий.
Владелец видит низкую скорость, устанавливает три плагина оптимизации, включает минификацию, объединение скриптов, отложенную загрузку, очистку базы и CDN одновременно.
Сайт ломается.
Теперь непонятно, какое именно изменение вызвало проблему и какое из них вообще помогало.
Гораздо надежнее менять по одному значимому параметру и повторять измерение.
До изменений сделайте резервную копию. Для сложного проекта работайте на тестовой копии.
Оптимизация должна быть экспериментом с контрольной точкой: было, изменили, измерили, сравнили.
Если результат не улучшился, изменение не нужно оставлять только потому, что оно называется «ускорением».
Практический порядок диагностики медленного сайта
Я бы действовала следующим образом.
Первое. Проверила проблему с нескольких устройств и сетей. Это сразу отсеивает часть локальных причин.
Второе. Сравнила несколько типов страниц. Если тормозит только одна, не нужно обвинять весь сервер.
Третье. Посмотрела сетевую диаграмму в инструментах разработчика браузера. Она показывает, сколько времени занимают HTML, изображения, CSS, JavaScript и сторонние запросы.
Четвертое. Проверила время начала ответа и серверные показатели. Высокий TTFB заставляет изучать приложение, базу, PHP, нагрузку и хостинг.
Пятое. Если сервер отвечает быстро, посмотрела бы на общий вес страницы, самые большие файлы, блокирующие ресурсы и JavaScript.
Шестое. Для WordPress проверила кэширование, тему и плагины. На тестовой копии попыталась бы определить расширения, которые заметно увеличивают время генерации.
Седьмое. Посмотрела базу и динамические функции, если медленными остаются корзина, поиск, фильтры или административная часть.
Восьмое. Проверила графики нагрузки во времени и серверные логи. Особенно если проблема возникает периодически.
Девятое. Только после определения узкого места решала бы, нужен ли более мощный тариф, CDN, Redis, изменение кода или просто оптимизация изображений.
Такой порядок не самый эффектный. Зато он не заставляет покупать новый сервер ради фотографии размером 12 МБ.
Когда пора менять хостинг
Если сайт оптимизирован, кэш настроен, нагрузка понятна, а тариф регулярно упирается в ограничения, переход на более мощную платформу логичен.
Другой тревожный признак: производительность нестабильна без связи с вашей нагрузкой, а поддержка не может объяснить причину.
Или проект вырос настолько, что виртуальный хостинг больше не дает нужного контроля над PHP, кэшированием, базой и системными ресурсами.
Тогда VPS, облачный сервер или более производительный управляемый тариф действительно могут стать следующим шагом.
Но переезд не должен быть первым пунктом диагностики.
Плохой запрос к базе останется плохим на новом сервере. Огромное изображение останется огромным. Тяжелый рекламный скрипт продолжит выполняться в браузере посетителя.
Более мощное железо иногда маскирует неэффективность, но не устраняет ее причину.
Быстрый сайт начинается с правильного вопроса
Когда страница открывается медленно, вопрос «как ускорить сайт» слишком широкий.
Гораздо полезнее спросить: где именно мы теряем время?
До первого байта ответа? При выполнении PHP? В базе данных? Во время загрузки изображений? На стороннем скрипте? При обработке JavaScript на смартфоне?
После этого оптимизация превращается из набора случайных советов в нормальную техническую работу.
Яндекс прямо относит скорость загрузки страниц к важным показателям качества сайта и предупреждает, что пользователь может не дождаться медленной страницы и уйти на другой ресурс. Среди рекомендуемых мер Яндекс перечисляет оптимизацию серверного кода, кэширование, сжатие, CDN, уменьшение блокирующих ресурсов и оптимизацию изображений. citeturn0search0
Но применять все эти меры одновременно не нужно.
Иногда сайт ускоряется после замены одной фотографии. Иногда после включения страничного кэша. Иногда приходится исправлять запрос к базе. А иногда действительно пора уходить с перегруженного хостинга.
Главное, чтобы решение следовало за измерением, а не наоборот.
И если после диагностики выяснилось, что сервер отвечает быстро, не спешите покупать более дорогой сервер. Возможно, хостинг в этой истории вообще ни в чем не виноват.
