Как ускорить сайт на WordPress: мой кейс роста PageSpeed с 64 до 95

В августе 2026 года я закончил основную сборку своего сайта и решил проверить его мобильную версию в PageSpeed Insights. Результат оказался неприятным: 64 балла из 100, First Contentful Paint — 3,8 секунды, Largest Contentful Paint — 7,5 секунды.

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

Для диагностики и подготовки технических правок я работал с ChatGPT в режиме Codex, моделью GPT-5.6 Sol. Я передавал отчёты PageSpeed, скриншоты и фрагменты HTML-кода, а Codex помогал сравнивать замеры, находить проблемы, готовить облегчённые изображения и разметку. Каждое изменение я применял и проверял вручную.

Результат: лучший повторный тест показал 95 баллов. Другой итоговый запуск дал 92 балла, FCP 1,9 секунды, LCP 3,1 секунды, Speed Index 2,2 секунды и практически нулевой CLS. Почему результат колебался и почему я не считаю это проблемой, объясню ниже.

Исходные показатели скорости сайта

Сравнение показателей до и после оптимизации:

Показатель	До оптимизации	После оптимизации
Оценка производительности	64	92–95
First Contentful Paint	3,8 сек.	1,9 сек.
Largest Contentful Paint	7,5 сек.	3,1 сек.
Speed Index	5,7 сек.	2,2 сек.
Cumulative Layout Shift	0	0,003

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

Почему я не начал с хостинга

Когда сайт работает медленно, первым подозреваемым часто становится сервер. В моём отчёте Time to First Byte составлял около 10 мс. Это означало, что сервер отдавал документ быстро, а основная задержка возникала уже в браузере.

PageSpeed выделил четыре группы проблем:

• изображения загружались в большем разрешении, чем требовалось на мобильном экране;
• таблица стилей и библиотека JavaScript блокировали первоначальную отрисовку;
• внешние шрифты создавали дополнительную цепочку запросов;
• сторонняя аналитика добавляла трафик и работу в основном потоке.

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

Шаг 1. Проверил вес и размеры изображений

Большинство фотографий на сайте уже были переведены в WebP и весили примерно 40–90 КБ. Но нашлось два исключения.

Тяжёлый логотип

Исходный логотип в PNG весил около 2,5 МБ. При этом в шапке он показывался размером примерно 100×100 пикселей. Браузер скачивал большой квадратный файл, а затем визуально уменьшал его стилями.

Сначала я подготовил версию WebP 512×512 весом около 30 КБ, а затем отдельный файл 200×200 весом около 4 КБ. При отображении 100×100 такая версия остаётся резкой и на экранах с высокой плотностью пикселей, но не расходует лишний трафик.

Главная фотография без адаптивных размеров

Фотография первого экрана имела размер 1197×1600 и весила около 117 КБ. На мобильном устройстве она отображалась в контейнере шириной около 328 пикселей. Сам формат WebP не решал проблему: браузер всё равно получал изображение, которое было значительно шире необходимого.

Я создал три дополнительные версии:

• 400 пикселей — около 14 КБ;
• 640 пикселей — около 36 КБ;
• 960 пикселей — около 76 КБ.

В HTML добавил атрибуты srcset и sizes. Теперь браузер самостоятельно выбирает файл под ширину экрана и его плотность. Такой подход соответствует механизму адаптивных изображений WordPress.

<img
  src="photo-640.webp"
  srcset="photo-400.webp 400w,
          photo-640.webp 640w,
          photo-960.webp 960w"
  sizes="(max-width: 767px) calc(100vw - 48px), 480px"
  width="1197"
  height="1600"
  alt="Описание фотографии"
  loading="eager"
  fetchpriority="high"
  decoding="async">

Для главной фотографии я сохранил loading="eager" и fetchpriority="high", потому что именно она была крупнейшим элементом первого экрана. Откладывать её загрузку было бы ошибкой. Официальная документация web.dev также рекомендует повышать приоритет LCP-изображения, когда оно важно для первого экрана.

Шаг 2. Убрал внешний запрос к шрифтам

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

Шрифт я перенёс на собственный домен, включил font-display: swap и оставил необходимые языковые наборы. После этого в критической цепочке осталось два локальных файла вместо нескольких внешних запросов.

У этой правки есть два преимущества:

• браузеру не нужно устанавливать соединение с отдельным сервером;
• текст может отображаться системным шрифтом, пока основной файл ещё загружается.

Шаг 3. Разобрал блокирующие CSS и JavaScript

После оптимизации изображений и шрифтов главными блокирующими ресурсами остались файл стилей темы размером около 43 КБ и библиотека JavaScript размером около 30 КБ. В отдельных запусках они задерживали первоначальную отрисовку примерно на 0,7–1,5 секунды.

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

Я не стал:

• удалять правила CSS только по отчёту одной страницы;
• ставить async на все скрипты без проверки зависимостей;
• объединять любые файлы ради уменьшения количества запросов;
• гнаться за 100 баллами ценой неработающего меню.

Безопасная оптимизация важнее максимальной лабораторной оценки. Отложенная загрузка JavaScript может помочь, но зависимые скрипты должны выполняться в правильном порядке. После каждой такой правки нужно проверять меню, формы, навигацию и мобильную версию.

Шаг 4. Сохранил аналитику

Система аналитики передавала около 90–96 КБ, добавляла небольшую принудительную компоновку и занимала часть времени основного потока. PageSpeed относил примерно половину её JavaScript к неиспользуемому коду.

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

Кроме того, срок хранения кеша стороннего ресурса нельзя увеличить настройкой своего сайта. Поэтому предупреждение о коротком кеше аналитики я принял как ограничение внешнего сервиса, а не как задачу, которую обязательно нужно «исправить».

Почему PageSpeed показывал то 95, то 76 баллов

После основных изменений один тест показал 95 баллов. Затем без изменений на сайте результат опускался до 76–80 и снова возвращался в зелёную зону.

Это не загадка. PageSpeed использует лабораторный запуск Lighthouse с эмуляцией мобильного устройства и ограниченной сети. В официальной документации PageSpeed Insights указано, что результаты могут меняться из-за доступности сети, вычислительных ресурсов и конкуренции за них. Лабораторный тест нужен прежде всего для диагностики, а не как постоянный сертификат качества.

Поэтому я смотрел не на единственный запуск, а на серию проверок и отдельные метрики. После оптимизации повторный тест показал:

• оценка производительности — 92;
• FCP — 1,9 секунды;
• LCP — 3,1 секунды;
• TBT — 110 мс;
• CLS — 0,003;
• Speed Index — 2,2 секунды.

По шкале PageSpeed лабораторная оценка от 90 считается хорошей. Для реальных пользователей Google оценивает полевые данные за 28 дней и ориентируется на 75-й процентиль. У нового сайта таких данных пока недостаточно, поэтому делать окончательный вывод только по зеленому кружку рано.

Что в итоге дало ускорение WordPress

Нельзя честно сказать, что одна настройка подняла PageSpeed с 64 до 95. Результат сложился из нескольких небольших изменений:

1. проверил, действительно ли проблема находится на сервере;
2. нашёл непропорционально тяжёлый логотип;
3. перевёл графику в подходящий формат и размер;
4. создал адаптивные версии главной фотографии;
5. добавил srcset, sizes, размеры и приоритет загрузки;
6. перенёс шрифт на собственный домен;
7. сократил критическую цепочку шрифтовых запросов;
8. разобрал блокирующие CSS и JavaScript, но не стал применять рискованные правки вслепую;
9. сохранил аналитику и проверил сайт серией повторных тестов.

Самое заметное изменение видно по LCP: показатель снизился с 7,5 до 3,1 секунды. Это ещё не идеальные 2,5 секунды, которые Google относит к хорошему диапазону полевых данных, но первый экран стал отрисовываться существенно быстрее.

Как я использовал ChatGPT и Codex

В этом проекте ChatGPT не заменял диагностику и не вносил изменения на сайт самовольно. Я использовал Codex с моделью GPT-5.6 Sol как технического помощника:

• передавал скриншоты отчётов и получал разбор конкретных узких мест;
• сравнивал несколько запусков, чтобы не делать вывод по одной оценке;
• проверял, какая проблема влияет на LCP, а какая только выглядит страшно в списке;
• готовил облегчённые изображения нужных размеров;
• получал готовую HTML-разметку для адаптивной загрузки;
• отделял безопасные изменения от тех, которые могли сломать тему или меню.

Главная польза оказалась не в «волшебной кнопке», а в скорости итераций. Я делал замер, передавал результат, получал гипотезу, внедрял одну правку и снова запускал тест. При этом решение о применении изменений и проверка сайта оставались на мне.

Информация о модели GPT-5.6 Sol и её доступности в Codex опубликована на официальном сайте OpenAI.

Чек-лист: как ускорить сайт на WordPress

1. Проверьте мобильную и компьютерную версии PageSpeed Insights.
2. Сохраните исходные значения FCP, LCP, TBT, CLS и Speed Index.
3. Посмотрите TTFB, прежде чем обвинять хостинг.
4. Найдите LCP-элемент первого экрана.
5. Сравните физический размер изображения с размером контейнера.
6. Используйте WebP или AVIF, но не забывайте о ширине файла.
7. Добавьте адаптивные версии через srcset и sizes.
8. Не включайте ленивую загрузку для LCP-изображения.
9. Проверьте внешние шрифты и оставьте только действительно нужные файлы.
10. Не удаляйте CSS и JavaScript без проверки всего сайта.
11. Не отключайте аналитику только ради оценки.
12. После каждой правки очищайте кеш и проводите несколько повторных запусков.

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

Что я проверяю при SEO-разборе сайта

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

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

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