Как я разогнал свой блог до 0.13 секунды: честный рассказ с цифрами

Захожу на свой сайт через браузер. Нажимаю Enter. И через 0.13 секунды страница уже на экране. Я просто сижу и улыбаюсь. Потому что помню, с чего всё начиналось.

Когда я только запустил блог, про скорость я вообще не думал. Реальность была такой: страница грузилась 1-2 секунды, картинки весили по 200-500KB, каждый запрос дергал базу данных. Я грешил на хостинг, на PHP, на Apache. Пока однажды не решил: хватит.

WP-Super-Cache

Оказалось, что плагин установлен, но кэш выключен. Конфиг говорил, что cache_enabled = false. Исправил на true — и сайт начал отдаваться статическим HTML. Первый пинг: 0.13 секунды.

Оптимизация базы данных

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

WebP Express

Картинки — самая тяжелая часть сайта. 179 изображений, около 600MB на диске. Поставил WebP Express, настроил конвертацию через Imagick. Теперь все новые картинки автоматически конвертируются в WebP. Браузер получает в 2-3 раза легче, качество — неотличимо.

Google Search Console и Yoast SEO

Добавил сайт в Search Console, отправил sitemap. Google теперь знает про все статьи и будет индексировать быстрее.

Системный cron

WordPress использует внутренний cron, который срабатывает только когда на сайт заходит посетитель. С кэшем посетители реже заходят на PHP — и cron тупо не выполнялся. Задания висели с мая. Настроил системный crontab — каждые 15 минут.

Результаты:
— Загрузка: было 1-2 сек, стало 0.13 сек
— TTFB: было ~0.3 сек, стало 0.038 сек
— Размер страницы: 95 KB (gzip)
— Картинки: JPEG/PNG теперь WebP
— Кэш: был выключен, теперь SuperCache
— Cron: висел с мая, теперь каждые 15 мин
— БД: 839 мусорных записей удалено

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

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

Начну с того, в каком состоянии был мой блог изначально. Я запустил его, не думая о скорости вообще. Заголовки, статьи, картинки — главное, чтобы контент был. Производительность казалась чем-то «потом», чем-то, что можно отложить. Реальность быстро дала о себе знать: страницы грузились по 1-2 секунды, каждая картинка весила по 200-500 килобайт, каждый запрос дергал базу данных. Я грешил на всё подряд: на хостинг, на PHP, на Apache. Но проблема, как оказалось, была не в них, а в моей лени настройки.

Самое смешное и обидное, что решение было под носом. У меня был установлен плагин WP-Super-Cache, но кэш был выключен. В конфиге стояло cache_enabled = false. Один маленький параметр — и целый год я жил с сайтом, который генерировал страницы заново на каждый запрос. Когда я переключил кэш на true, сайт начал отдавать готовые статические HTML-файлы. Первый пинг показал 0.13 секунды. Я сначала не поверил, перепроверил, потом долго улыбался. Одна настройка — и разница в десять раз.

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

Дальше была база данных. За год работы накопилось 216 ревизий записей и 623 спам-комментария. Всё это лежало в MySQL, раздувало таблицы и замедляло запросы. Я почистил базу: удалил ревизии, спам, мусорные транзиенты. База похудела, и запросы стали легче. Этот шаг кажется необязательным, но для старого блога с многолетней историей он очень важен. Мусор в базе — это как захламлённая квартира: живётся можно, но всё медленнее и тяжелее.

Теперь про картинки — самую тяжёлую часть сайта. У меня было 179 изображений, примерно 600 мегабайт на диске. Каждая картинка в JPEG или PNG весила прилично, и браузер тянул их при каждой загрузке страницы. Я поставил WebP Express и настроил конвертацию через Imagick. Теперь все новые картинки автоматически конвертируются в WebP, который весит в 2-3 раза меньше при том же качестве. Визуально разницу не заметишь, а скорость выросла ощутимо. Это, пожалуй, самая недооценённая оптимизация: картинки часто составляют больше половины веса страницы.

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

Дальше — индексация. Я добавил сайт в Google Search Console и отправил sitemap. Это не про скорость напрямую, но про то, чтобы поисковик знал о всех статьях и индексировал их быстрее. Вместе с Yoast SEO, который генерирует правильные мета-теги и структурированные данные, это дало хороший фундамент для продвижения. Сайт может быть молниеносным, но если поисковик его плохо индексирует — трафика не будет. Поэтому оптимизация скорости и SEO должны идти рука об руку.

Теперь про крон — это была самая коварная грабля. WordPress использует внутренний cron, который срабатывает только тогда, когда на сайт заходит посетитель. Но когда я включил кэш, посетители стали реже попадать на PHP — их обслуживал статический HTML. В итоге cron просто не выполнялся: задания, которые должны были отработать, висели с мая. Это обнаружилось не сразу. Решение — системный crontab, который запускает wp-cron каждые пятнадцать минут, независимо от посещаемости. После этого все фоновые задачи (бэкапы, очистки, обновления) стали работать как надо.

Стоит сказать про сам процесс замеров. Я не полагался на «ощущения» — я снимал цифры до и после каждого шага. До оптимизации загрузка была 1-2 секунды, TTFB — около 0.3 секунды. После — загрузка 0.13 секунды, TTFB 0.038 секунды. Такие цифры наглядно показывают, какой шаг дал сколько. Если ты тоже будешь оптимизировать — снимай замеры на каждом этапе, иначе не поймёшь, что работает, а что нет. Хороший инструмент — PageSpeed Insights и просто замеры времени в браузере.

Итоговая картина после всех шагов получилась такая: загрузка 0.13 секунды, TTFB 0.038, размер страницы 95 килобайт в gzip, картинки в WebP, кэш работает, крон исправен, база почищена. 839 мусорных записей удалено. Каждая цифра — это результат конкретного действия, и все они простые. Никакой магии, никаких «волшебных» плагинов. Просто последовательная работа по списку.

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

Что бы я сделал, если бы начал заново. Я бы в первый же день настроил кэш, WebP и системный крон. Это три главных шага, которые дали мне основной выигрыш. Остальное — база, SEO, сжатие — это шлифовка, тоже важная, но не критичная. Если у тебя WordPress и ты ни разу не смотрел в сторону кэша — начни прямо сегодня. Пятнадцать минут работы — и сайт станет быстрее в разы. Не откладывай то, что занимает четверть часа и даёт такой результат.

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

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

Второе — это минификация CSS и JS. После включения кэша я прошёлся по стилям и скриптам: убрал лишние пробелы и комментарии, объединил файлы. Количество запросов к серверу сократилось, и страницы стали грузиться ещё чуть быстрее. Это уже шлифовка, но она тоже даёт свой эффект, особенно на мобильном интернете, где каждый запрос имеет значение.

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