Скорость WordPress: кэш, база и что на самом деле тормозит сайт

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

Ниже — порядок, по которому я разбираю медленный сайт на WordPress: что измерить до того, как что-то трогать, где искать узкое место, что реально даёт кэш, как безопасно почистить базу и почему у половины сайтов главный тормоз висит в подвале страницы и называется «виджет обратного звонка». Если разбираться самому некогда, есть техническая поддержка сайта — скорость там первая по списку задача, потому что дешевле всего чинится.

Из чего складывается время ответа

Время загрузки складывается из нескольких независимых слагаемых, и чинятся они разными способами. Первое — время до первого байта. Браузер отправил запрос, сервер должен его принять, запустить PHP, собрать страницу, сходить в базу данных два-три десятка раз и отдать готовый HTML. Всё это происходит до того, как посетитель увидит хоть что-то. Если сюда уходит секунда и больше, никакие картинки и шрифты уже ситуацию не спасут.

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

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

Порядок действий: измерить, найти узкое место, чинить по одному

Главная ошибка — начинать с действий. Человек читает статью «10 способов ускорить WordPress», за вечер применяет все десять, сайт после этого ломается, и непонятно, что именно помогло, а что сломало. Правильный порядок скучнее и надёжнее.

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

Отдельно смотрите на время ответа сервера. Это первый разделитель: если сервер отдаёт страницу за 200 миллисекунд, а общее время загрузки три секунды — проблема во фронтенде, в файлах и скриптах. Если сервер думает полторы секунды — дальше можно не смотреть, копать нужно на стороне хостинга, PHP и базы.

Дальше чините строго по одному изменению за раз и перезамеряйте. Да, это дольше. Зато вы получаете знание: «отключение виджета чата дало минус 0,8 секунды», а не «я что-то поделал, и вроде стало быстрее». И когда через полгода сайт снова начнёт тормозить, вы будете знать, куда смотреть.

Хостинг и версия PHP

На виртуальном хостинге ваш сайт делит процессор и диск с десятками чужих. Признак того, что упёрлись именно в это: время ответа сервера скачет в разы в течение дня без всякой связи с тем, что вы делаете с сайтом. Утром 300 миллисекунд, вечером две секунды. Никакая оптимизация кода такое не лечит — только переезд на тариф или сервер с гарантированными ресурсами.

Версия PHP — редкий случай, когда одно переключение в панели хостинга даёт заметный прирост бесплатно. Старые ветки PHP медленнее новых на одинаковом коде, и за годы разрыв накопился приличный. Ловушка в том, что старая тема или давно заброшенный плагин могут на новой версии выдать фатальную ошибку. Поэтому порядок такой: делаете полную резервную копию, переключаете версию, обходите основные страницы сайта и админку, смотрите лог ошибок. Не завелось — возвращаете обратно одним кликом и разбираетесь, какой именно плагин виноват.

Что кэш решает, а чего не решает

Кэш — это сохранённый результат работы, который отдают в следующий раз без повторных вычислений. В WordPress встречаются несколько разных кэшей, и путаница между ними порождает половину неудачных «ускорений».

Страничный кэш сохраняет готовый HTML целиком. Документация WordPress описывает это прямо: плагины кэширования сохраняют записи и страницы как статические файлы. Первый посетитель запускает PHP и базу, остальные получают готовый файл. Это самый большой эффект из возможных — и самый опасный, если на сайте есть корзина, личный кабинет или формы с защитой от повторной отправки: посетитель может увидеть чужую или устаревшую версию страницы.

Объектный кэш хранит результаты запросов к базе между обращениями. В разделе документации WordPress об оптимизации его смысл описан как экономия обращений к базе данных. Он не заменяет страничный, а дополняет его и помогает там, где страницу целиком закэшировать нельзя.

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

Отдельная неприятность, с которой сталкивается каждый: правка в админке внесена, а на сайте старая версия. Это не поломка, а ровно то поведение, ради которого кэш и ставили. Как с этим жить и почему робот при этом может видеть уже новую страницу, я подробно разбирал в материале про кэш в WordPress и старую страницу после правок — повторяться не буду.

База данных: ревизии, корзина, спам и мусор от плагинов

База WordPress разрастается тихо. Сайт работает, а таблица записей год за годом набирает строки, которых на сайте никто не видит.

Главный поставщик таких строк — ревизии. WordPress сохраняет каждое сохранение черновика и каждое обновление опубликованной записи как отдельную запись в той же таблице. По документации WordPress о ревизиях, хранятся они в таблице записей со статусом «inherit» и типом «revision», а по умолчанию количество ревизий не ограничено. Ограничение ставится константой WP_POST_REVISIONS в файле wp-config.php: значение true или -1 хранит все ревизии, false или 0 отключает их (кроме одного автосохранения на запись), а положительное число хранит указанное количество, автоматически удаляя старые при следующем обновлении записи.

Второй источник мусора — корзина. Удалённые записи, страницы, вложения и комментарии лежат в базе и удаляются окончательно через тридцать дней, если не менять настройку по умолчанию; срок задаётся константой EMPTY_TRASH_DAYS. Третий — спам в комментариях: на живом блоге его набегают тысячи строк, и каждая тянет за собой записи в таблице мета-данных.

Четвёртый и самый неприятный — следы удалённых плагинов. Большинство плагинов при удалении не убирают за собой ни свои опции, ни свои таблицы. Особенно больно, когда такие опции помечены на автозагрузку: они читаются из базы при каждом запросе любой страницы. В рекомендациях WordPress по оптимизации прямо названа разумная граница объёма автозагружаемых опций, и превышение в несколько раз — обычное дело для сайта, переживших пять конструкторов и три SEO-плагина.

До любой чистки базы — полная резервная копия, и проверенная, а не «вроде плагин её делает». Чистка базы необратима: удалённая строка не восстанавливается кнопкой «отменить». Лично я делаю копию, скачиваю её к себе на диск, проверяю, что файл открывается и не нулевого размера, и только потом запускаю что-либо. Как организовать это так, чтобы копия реально спасала, разобрано в статье про резервную копию WordPress и восстановление.

Тема, плагины и внешние скрипты

Тема и конструктор

Тяжёлая многоцелевая тема с визуальным конструктором тянет за собой собственный набор стилей и скриптов на каждой странице — включая те, где ни одного блока конструктора нет. Проверяется просто: посмотрите, какие файлы грузит пустая страница «Контакты». Если там полтора десятка файлов от конструктора, вы платите за него на каждом просмотре.

Плагины

Число плагинов само по себе ничего не говорит. Двадцать лёгких плагинов могут не влиять на скорость вообще, а один-единственный — добавлять по полсекунды на каждый запрос. Значение имеет не количество, а то, что плагин делает при каждой загрузке: ходит ли во внешний сервис, пишет ли в базу, подключает ли свои стили везде. Почему счёт плагинов — плохая метрика и где искать настоящего виновника, я разбирал отдельно: WordPress тормозит не из-за плагинов.

Внешние скрипты

Виджет обратного звонка, онлайн-чат, карта, счётчики, пиксели рекламных систем, виджет отзывов, подгрузка шрифтов с чужого домена — каждый из них это запрос к постороннему серверу, скорость которого вы не контролируете. Если такой сервер отвечает медленно или недоступен, ваша страница ждёт его. Пять виджетов — пять чужих серверов в цепочке загрузки вашего сайта.

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

Что тормозит	Как проверить	Что сделать
Слабый или перегруженный хостинг	Время ответа сервера скачет в разы в разное время суток	Сменить тариф или переехать на сервер с гарантированными ресурсами
Старая версия PHP	Посмотреть версию в панели хостинга и в разделе «Здоровье сайта»	Сделать копию, переключить версию, проверить страницы и лог ошибок
Нет страничного кэша	Время ответа одинаково высокое при каждом обновлении страницы	Включить кэш, исключив из него корзину, кабинет и страницы с формами
Раздутая база: ревизии, корзина, спам	Посмотреть размер таблицы записей и число строк со статусом ревизии	Копия базы, затем чистка; ограничить ревизии в wp-config.php
Тяжёлая тема или конструктор	Пустая страница грузит десятки файлов конструктора	Отключить подключение ресурсов там, где блоков конструктора нет
Один тяжёлый плагин	Метод исключения на копии сайта, половина за половиной	Заменить на лёгкий аналог или отказаться от функции
Внешние виджеты и чаты	Отключить все, замерить, возвращать по одному	Убрать ненужные, остальные грузить отложенно

План на один вечер

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

Шаг	Действие	Готово, если
1	Сделать полную копию сайта и базы, скачать к себе	Архив открывается, размер не нулевой
2	Замерить 4 разные страницы в режиме инкогнито, записать цифры с датой	Есть исходная точка, с которой будете сравнивать
3	Отдельно записать время ответа сервера	Понятно, проблема на сервере или во фронтенде
4	Проверить версию PHP, при необходимости переключить	Сайт и админка работают, лог ошибок чистый
5	Включить или перенастроить страничный кэш с исключениями	Формы и корзина работают, кэш не отдаёт чужое
6	Отключить внешние виджеты, замерить, вернуть по одному	Известна цена каждого виджета в секундах
7	Найти тяжёлый плагин методом исключения на копии	Виновник назван по имени или исключён
8	Ограничить ревизии константой в wp-config.php	Новые ревизии перестали копиться без ограничений
9	Почистить старые ревизии, корзину и спам	Размер базы уменьшился, сайт работает как прежде
10	Повторить замеры тех же 4 страниц и сравнить с шагом 2	Видно, что именно и на сколько изменилось

Когда это не сработает и когда нужен специалист

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

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

Частые вопросы

Сколько плагинов можно держать на сайте?

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

Плагин кэша включён, а сайт всё равно медленный. Почему?

Три частые причины. Кэш не прогрет: вы открыли страницу первым, и она собиралась с нуля. Вы залогинены как администратор, а для залогиненных кэш обычно отключён. Либо узкое место вообще не в сборке страницы, а во внешних скриптах и картинках, на которые кэш не влияет.

Ускорение сайта поднимет позиции в поиске?

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

Коротко

Время загрузки складывается из ответа сервера, загрузки файлов и отрисовки в браузере. Эти три слагаемых чинятся по-разному, поэтому сначала измеряют, а потом действуют — иначе вы лечите то, что и так здорово.

Кэш даёт самый большой разовый эффект, но не лечит причину: он не помогает первому посетителю и залогиненным, не уменьшает вес картинок и не убирает внешние виджеты. Настраивать его нужно с исключениями для корзины, кабинета и форм.

База растёт от ревизий, корзины, спама и мусора удалённых плагинов. Количество ревизий ограничивается константой в wp-config.php, корзина чистится через тридцать дней по умолчанию. Перед любой чисткой — проверенная резервная копия, потому что удаление строк необратимо.

Число плагинов ничего не значит: виновником обычно оказывается один конкретный. Ищут его методом исключения на копии сайта, а не удалением наугад на боевом. Внешние виджеты и чаты проверяют отдельно — там часто лежит самая крупная потеря.

Быстрый сайт не приводит заявки сам по себе, а медленный их теряет. Скорость — гигиена, а не канал продаж: она убирает потери, но не создаёт спрос. Спрос создаёт то, что человек находит вас в поиске тогда, когда ищет услугу.

Здесь и проходит граница между двумя способами получать клиентов. Реклама — аренда трафика: платите — идут заходы, остановили — тишина в тот же день, и качество сайта на это почти не влияет. Позиции в поиске работают наоборот: их набирают месяцами, зато они остаются вашим активом и продолжают приводить людей без ежедневного платежа. Ускоренный, технически исправный сайт нужен обоим каналам, но для поиска он ещё и обязательное условие — медленную страницу робот обходит реже и ранжирует хуже.

Разумная стратегия для малого бизнеса выглядит скучно: держать оба канала и постепенно наращивать долю своего трафика, чтобы не зависеть от одного аукциона. Если хотите понять, что в вашем случае даст больше — вечер на скорость, переезд на нормальный сервер или доработка сайта целиком, напишите мне на консультацию: посмотрю сайт, назову узкое место и скажу честно, стоит ли оно потраченного времени.