Когда на сайте больше 100 страниц (услуги, районы, ветки метро, блог), поддерживать идеальную скорость загрузки становится сложно. Любой лишний килобайт или «кривой» скрипт моментально тянет показатели вниз.
Я поставил цель: вывести весь проект в «зеленую зону». В итоге — 93–98 баллов в Mobile и 98–100 в Desktop. Делюсь чистым опытом и техническими нюансами, которые мы внедрили вместе с Claude.
Оптимизация LCP: Почему fetchpriority важнее preload?
На главной странице мы используем <link rel="preload">, но для 40+ страниц услуг мы выбрали более гибкое решение. Вместо того чтобы загромождать header.php сложной логикой динамической предзагрузки, мы оптимизировали сам тег изображения:
- Отказ от CSS-background: Все Hero-баннеры выведены через обычный <img>.
- fetchpriority="high": Это «киллер-фича». Мы прямо в HTML говорим браузеру, что эта картинка — приоритетная. Он начинает качать её сразу, не дожидаясь полной загрузки стилей.
- Дополнения: Атрибуты loading="eager" и decoding="async" закрепляют результат. Браузер находит LCP-элемент мгновенно.
Форматы изображений: Где нужен WebP?
Я не стал переводить абсолютно все картинки в WebP. Мы подошли точечно:
- Главная страница, разделы районов и ЛО: Здесь используется WebP для максимальной экономии веса.
- Страницы услуг: Оставили качественные .jpg. Благодаря атрибутам приоритета, даже JPG на страницах услуг не мешает получать 95+ баллов. Это разумный компромисс между качеством картинки и скоростью.
CSS, шрифты и «хитрая» аналитика
Чтобы 100+ страниц рендерились без задержек, мы внедрили:
- Critical CSS: Основные стили первого экрана инлайнятся в <head>.
- Self-hosted шрифты: Inter (woff2) лежит на нашем сервере, а font-display: swap убирает проблему «невидимого текста».
- Укрощение счетчиков: Яндекс Метрика, Google Analytics и Roistat загружаются через requestIdleCallback с таймаутом 3000ms. Они включаются только тогда, когда сайт уже готов к работе и основной поток свободен.
Технический фундамент (.htaccess и SEO)
Для всего массива страниц настроены единые правила:
- Кэширование: Статика «замораживается» в браузере на 1 год.
- Сжатие: Gzip/DEFLATE для всех текстовых данных.
- Чистота: Автоматические 301 редиректы (HTTPS, non-www, trailing slash) и полная Schema.org разметка (LocalBusiness, FAQ, Service) на каждой странице.
Итог
Главный вывод: не обязательно использовать самые сложные решения (вроде динамического preload под каждую страницу), если можно грамотно использовать современные атрибуты HTML5 (fetchpriority). Claude помог быстро переписать шаблоны и внедрить эти правки на весь сайт сразу.
Часто задаваемые вопросы (FAQ)
1. Почему я не использую WebP для всех 100+ страниц сайта?
Я использую WebP там, где это дает максимальный буст (главная страница и разделы с большим количеством фото). На 40+ страницах услуг я оставил оптимизированный JPG. При использовании fetchpriority="high" разница в скорости загрузки LCP становится ничтожной, а я сохраняю идеальное качество картинки без лишних манипуляций.
2. В чем разница между <link rel="preload"> и fetchpriority="high", и что выбрал я?
Preload заставляет браузер скачать файл как можно раньше. fetchpriority="high" на теге <img> — это более гибкий инструмент, который я применил для страниц услуг. Это указывает браузеру на важность ресурса прямо в коде страницы, что избавляет меня от необходимости динамически прописывать пути в <head> для каждой из 40+ услуг.
3. Не теряю ли я данные в Метрике из-за requestIdleCallback?
Нет. Я выставил таймаут в 3000ms. Это гарантирует, что скрипты загрузятся в любом случае, даже если процессор занят. По моим тестам, данные доходят корректно, зато PageSpeed не «ругается» на блокировку основного потока сторонним софтом.
4. Сложно ли мне было внедрить Critical CSS на таком количестве страниц?
С помощью Claude — нет. Я выделил общие стили для типовых шаблонов и инлайню их в header.php. Это решило проблему «белого экрана» сразу для всей сотни страниц моего сайта.
Подпишись на мой Телеграм канал