Как я сделал WordPress-сайт с 99–100 баллами PageSpeed без магии кэш-плагинов
Есть довольно странная традиция в веб-разработке.
Сначала собрать сайт так, чтобы он еле двигался. Потом установить плагин кэширования. Потом ещё один плагин оптимизации. Потом CDN. Потом включить GZIP. Потом объединить CSS, минимизировать JavaScript, отложить загрузку половины страницы и три дня разбираться, почему после этого перестало работать мобильное меню.
И только после этого торжественно показать клиенту: «Смотрите, мы оптимизировали сайт».
У меня всегда возникал немного другой вопрос: а почему нельзя сразу разработать сайт нормально?
И сайт преподавателя китайского языка irinazdyrenkova.ru стал хорошим примером того, что WordPress сам по себе совершенно не обязан быть медленным.
Что получилось
Сайт разработан на WordPress и изначально собирался с учётом производительности, технической SEO-оптимизации, адаптивности и минимизации лишней нагрузки на браузер.
После завершения разработки я проверил главную страницу через Google PageSpeed Insights.
Результат на десктопе:
- Performance — 100/100
- Accessibility — 95/100
- Best Practices — 100/100
- SEO — 100/100
На мобильных устройствах:
- Performance — 99/100
- Accessibility — 95/100
- Best Practices — 100/100
- SEO — 100/100
Это результаты лабораторного тестирования Lighthouse, которые видны на приложенных скриншотах от 8 сентября 2026 года.
Для понимания масштаба: Google относит Lighthouse Performance от 90 до 100 баллов к хорошему результату.
То есть результат 99–100 — это уже не история про «ну вроде быстро открывается у меня на компьютере». Это измеряемый технический результат.
И самое интересное — без попытки спрятать проблемы под кэшированием
В этом проекте я сознательно делал ставку не на то, чтобы сначала создать тяжёлый сайт, а потом пытаться замаскировать его проблемы дополнительными средствами ускорения.
В используемой мной конфигурации результат был получен без кэширования и GZIP-компрессии. И именно это мне кажется наиболее показательным.
Потому что кэширование — хороший инструмент. GZIP или Brotli — тоже полезные технологии. Я совершенно не против их использования.
Но они должны быть дополнительным уровнем оптимизации, а не системой жизнеобеспечения для сайта, который без них начинает задыхаться.
Если выключение одного плагина превращает сайт из Ferrari обратно в гружёную «Газель», возможно, проблема была не в отсутствии плагина.
Почему WordPress-сайт может быть быстрым
WordPress часто обвиняют в низкой производительности.
На мой взгляд, проблема обычно не столько в самом WordPress, сколько в том, что на него устанавливают и как на нём разрабатывают.
Типичный сценарий выглядит примерно так:
- WordPress.
- Тяжёлая универсальная тема.
- Page Builder.
- Двадцать или тридцать плагинов.
- Три библиотеки слайдеров.
- Шесть шрифтов.
- Видео на первом экране.
- Картинка весом 4 МБ.
А потом начинается расследование: «Почему PageSpeed показывает 38?»
Загадка действительно сложная. Почти детектив.
В случае с irinazdyrenkova.ru логика была обратной: сначала архитектура, затем дизайн и функциональность, причём каждый новый элемент должен был оправдывать создаваемую им нагрузку.
Производительность начинается не с кнопки «Optimize»
Когда я разрабатываю сайт, скорость для меня — не отдельный этап после завершения проекта.
Она закладывается непосредственно в разработку.
Я стараюсь следить за объёмом CSS и JavaScript, количеством внешних зависимостей, структурой DOM, изображениями, загрузкой шрифтов, поведением элементов первого экрана и адаптивностью.
Другими словами, сначала стараюсь не создать проблему, а уже потом думать о способах её лечения.
Звучит революционно.
Примерно как не разбивать окно, чтобы потом не покупать очень хороший скотч.
SEO — это тоже не Yoast с зелёным кружочком
Ещё одна распространённая иллюзия — считать сайт SEO-оптимизированным только потому, что установлен очередной SEO-плагин.
SEO-плагин — это инструмент.
Он не исправит плохую архитектуру сайта, некорректную иерархию заголовков, проблемы с мобильной версией, тяжёлую загрузку или ошибки в HTML.
В этом проекте техническая SEO-основа закладывалась непосредственно при разработке.
И Lighthouse подтвердил результат категорией: SEO — 100/100.
Важно понимать, что Lighthouse проверяет определённый набор автоматизированных SEO-аудитов, поэтому 100 баллов нельзя интерпретировать как гарантию первых позиций в Google. Это именно подтверждение отсутствия проблем в проверяемой Lighthouse технической части SEO. Google описывает Lighthouse как лабораторный инструмент для анализа в том числе категорий Performance, Accessibility, Best Practices и SEO.
И это принципиальная разница.
Позиции требуют семантики, контента, ссылок, авторитетности ресурса, конкуренции и множества других факторов.
Но техническая база сайта при этом должна быть сделана нормально с самого начала.
А что с Core Web Vitals?
Здесь важно не заниматься маркетинговой акробатикой. Google PageSpeed Insights использует два разных типа данных.
Первый — лабораторные данные Lighthouse. Именно по ним сейчас сайт получает 99 баллов на мобильных устройствах и 100 на компьютере.
Второй — полевые данные CrUX, собранные у реальных пользователей Chrome за предыдущие 28 дней. Именно они используются Google для полноценной оценки реальных Core Web Vitals — LCP, INP и CLS.
На приложенных скриншотах PageSpeed для irinazdyrenkova.ru указано: «Нет данных».
Это означает не плохие показатели, а отсутствие достаточного массива CrUX-данных для оценки реальных посетителей. Google прямо пишет, что подобная ситуация возникает, например, у новых сайтов или страниц с недостаточным количеством пользовательских измерений.
Поэтому я не буду писать красивую, но технически неправильную фразу: «Сайт прошёл Core Web Vitals у реальных пользователей».
Таких данных пока просто нет.
Зато лабораторная диагностика показывает, что техническая основа для этого подготовлена очень хорошо.
99 на мобильном — для меня даже интереснее, чем 100 на компьютере
Десктопные результаты получить обычно проще.
Мобильное тестирование Lighthouse проводится в более ограниченных условиях устройства и сети, поэтому именно мобильный показатель зачастую быстрее выявляет тяжёлый JavaScript, неоптимизированные изображения и другие проблемы производительности. Google отдельно отмечает, что Lighthouse использует эмулируемую среду и что лабораторные результаты могут отличаться от опыта реальных пользователей.
Поэтому результат: 99/100 Mobile для полноценного WordPress-сайта я считаю одним из главных технических результатов этого проекта.
Почему я вообще решил показать этот кейс
Наверное, потому что мне до сих пор немного непонятна сама идея: сначала сделать медленно, а потом продавать клиенту оптимизацию как отдельное чудо.
Мне кажется логичнее наоборот.
Если сайт разрабатывается с нуля, производительность должна быть такой же частью разработки, как дизайн, мобильная версия или форма обратной связи.
Не дополнительной услугой. Не «SEO-пакетом Premium». Не шаманским ритуалом после запуска. А базовым требованием к качественному продукту.
И да, после нормальной разработки всё равно можно подключить кэширование, CDN, Brotli/GZIP и другие уровни оптимизации.
Только тогда они будут ускорять уже быстрый сайт, а не пытаться реанимировать плохо собранный.
В итоге мы имеем…
В результате получился WordPress-сайт, который одновременно остаётся визуально полноценным, адаптивным и функциональным и при этом показывает в Google PageSpeed Insights:
- Desktop Performance — 100/100
- Mobile Performance — 99/100
- SEO — 100/100
- Best Practices — 100/100
Без необходимости превращать WordPress в лабораторию из десятка плагинов ускорения.
Для меня этот проект — хороший пример одной достаточно простой идеи:
оптимизация сайта должна начинаться не после его разработки. Она должна быть частью разработки.
И, возможно, тогда индустрии понадобится немного меньше статей с заголовками: «Как ускорить WordPress с 27 до 90 за 15 шагов». Иногда достаточно просто не делать его медленным с самого начала.
