Ускорение timur.website началось с ресурсов первого экрана: шрифтов, изображений и сторонних скриптов. Я изменил загрузку этих ресурсов в собственной теме WordPress. По рабочим записям от 7 октября 2026 года мобильная оценка PageSpeed выросла с 65 до 95.
Это результат замеров конкретной главной страницы. Исходные отчёты PageSpeed в материалах кейса не сохранились, поэтому цифры ниже — историческая запись, а не воспроизводимый эксперимент с одинаковыми условиями. Я не могу приписать каждому изменению точный прирост баллов. Сам набор правок сохранён в истории проекта.
Что было до оптимизации
Главная состоит из первого экрана с фотографией, карточек проектов, услуг и описания процесса работы. Она не требует сложного приложения в браузере, но загружает изображения, несколько шрифтов и аналитику. Для такой страницы полезнее сначала разобрать состав загрузки, чем устанавливать ещё один универсальный плагин ускорения.
В рабочих записях зафиксированы FCP 4,5 → 1,5 секунды и LCP 6,7 → 2,1 секунды. FCP показывает появление первого содержимого, LCP — отрисовку крупнейшего видимого элемента. Эти показатели помогают понять ожидание посетителя, но не заменяют проверку форм, навигации и всего пути до заявки.
Перевёл шрифты в WOFF2 и оставил нужные символы
В теме использовались файлы Geist и JetBrains Mono в TTF. Я заменил их на WOFF2 с подмножеством символов для используемых языков. Обычное начертание Geist сократилось со 168 804 до 41 344 байт, JetBrains Mono — со 189 028 до 47 476 байт. Эти размеры можно проверить по файлам до и после изменения.
Разница возникла не только из-за формата: я также сократил набор символов. Такой файл нельзя без проверки переносить на многоязычный сайт. После обработки нужно посмотреть кириллицу, латиницу, знаки валют, кавычки и те начертания, которые действительно встречаются на страницах.
Roboto для заголовков разместил на своём сервере. Неиспользуемые подключения Inter и Ubuntu Mono убрал. Так стало проще контролировать, какие шрифты загружает тема и какие файлы нужны странице. Само по себе локальное размещение не гарантирует ускорения: важны размер, кеширование и количество запросов.
Добавил предварительную загрузку основных шрифтов
Основным шрифтам добавил preload, чтобы браузер мог обнаружить их раньше. Предварительная загрузка полезна для действительно нужного ресурса первого экрана. Если назначить её всем начертаниям сразу, они начнут конкурировать с изображением и стилями за сеть.
После такой правки я проверяю не только наличие строки preload в коде, но и фактические запросы в браузере. Если адрес, тип ресурса или параметры загрузки не совпадают, браузер может не использовать подготовленный файл так, как ожидалось. Для текста также важна стратегия показа запасного шрифта до загрузки основного.
Подготовил изображения под размер экрана
Для фотографии на первом экране добавил вариант шириной 600 пикселей, для превью проектов — 720 пикселей. В разметке использованы srcset и sizes: браузер выбирает подходящий файл с учётом ширины изображения и плотности пикселей устройства. Большой исходник при этом остаётся для экранов, которым он нужен.
Фото первого экрана получает приоритет загрузки и не откладывается через lazy loading. Превью ниже страницы можно загружать лениво. У изображений указаны размеры, чтобы браузер заранее выделял место. Подробнее о размерах и выводе картинок я писал в статье о миниатюрах WordPress.
Важно проверять не только внешний вид. В инструментах разработчика видно, какой файл выбран на конкретном устройстве. Если мобильный браузер всё равно скачивает крупнейший вариант, стоит проверить sizes и фактическую ширину блока, прежде чем ещё сильнее сжимать картинку.
Отложил аналитику и учёл компромисс
GTM и Метрика запускаются после первого действия пользователя либо через три секунды после события load. Это освобождает начальную загрузку от части сторонней работы. Но здесь есть цена: короткий визит может закончиться до запуска счётчика, а раннее действие — произойти до установки обработчика аналитики.
Для сайта, где важно точно учитывать первые клики, такую схему нельзя копировать без проверки. Нужно отдельно пройти отправку заявки, переходы и события, убедиться в отсутствии повторной загрузки счётчиков. Улучшение лабораторного балла не должно скрывать потерю значимых данных.
Как оценивать результат такого ускорения
Для следующего сравнения я бы сохранял отчёты до и после, фиксировал устройство и режим проверки и делал несколько запусков каждой версии. Единичный результат зависит от условий теста. Данные реальных посетителей и лабораторный запуск отвечают на разные вопросы: первое показывает накопленный опыт пользователей, второе помогает искать конкретные задержки.
- Сравнивать одну и ту же страницу и одинаковый режим измерения.
- Проверять несколько типовых страниц, а не только главную.
- После правок пройти меню, формы, админку и мобильную версию.
- Сохранять отчёты и список изменений, чтобы результат можно было объяснить.
Что осталось и что можно повторить
В плане проекта осталась работа с блокирующим CSS. Её в этот кейс как выполненную не включаю. Самый полезный порядок для похожего сайта: найти тяжёлые ресурсы, убрать лишнее, подготовить подходящие размеры, а затем измерить результат. Перенос на другой сервер и установка кеша не заменяют эту проверку.
На сайте с готовой темой те же задачи могут решаться через её настройки или отдельный плагин. Начинать стоит с копии и одного изменения за раз. Если нужен разбор конкретной страницы, можно прислать её адрес и описать, где заметна задержка.