На примере Adventure Guide показываем десять этапов оптимизации: аудит, изображения, стабильная раскладка, CSS, JavaScript, фильтр и SVG. Разбираем, почему высокая оценка PageSpeed полезна только вместе с работающими пользовательскими сценариями.
Содержание 10
Оценка помогает найти проблему
Красный или оранжевый отчёт PageSpeed часто становится поводом для спора между заказчиком и командой. Его полезнее использовать как начало диагностики: какие элементы задерживают загрузку, почему смещается интерфейс и что чувствует пользователь.
Высокий балл не заменяет удобство сайта и не является самостоятельной гарантией позиции в поисковой выдаче. Нужно смотреть на измеряемые показатели, условия проверки и реальное поведение страниц. Цель оптимизации — быстрее и надёжнее довести человека до нужного действия.
Почему бизнес обращает внимание на скорость
Если страница долго открывается или кнопка появляется с задержкой, посетитель может уйти до покупки. В исходной статье автор иллюстрирует этот риск историями Walmart, Amazon, Яндекса и Т-Банка.
Ниже сохранены эти примеры с атрибуцией. Ссылок на первичные замеры и методики в статье нет; переносить указанные значения на другой сайт или обещать такой же рост продаж нельзя.
- По данным автора: Walmart связывал одну секунду задержки со снижением конверсии на 2%; после оптимизации отмечался рост продаж. Первичный отчёт в статье не указан.
- По данным автора: для Amazon приводится оценка потери 1% выручки на 100 мс задержки и её пересчёт почти в 5 млрд долларов для 2023 года. Методика и первоисточник в статье не указаны.
- По данным автора: в Яндексе эксперименты с замедлением поиска на 200 мс отправляли на доработку. Ссылка на внутреннее правило или исследование не приведена.
- По данным автора: в Т-Банке сокращение LCP на 0,3–0,5 секунды связывалось с ростом конверсии на 1,5–2% за месяц. В числе доработок названы WebP, lazy-load и сторонние скрипты; исходные измерения в статье отсутствуют.
Пять ошибок в работе со скоростью
1. Считать 90+ баллов признаком идеального сайта. Ради оценки можно случайно сломать навигацию, убрать нужную графику или функции. Пользовательские сценарии должны оставаться рабочими.
2. Ограничиться сжатием изображений. Причиной задержки могут быть сторонние скрипты и тяжёлые стили. Вырезать крупный фреймворк из зрелого проекта сложно, поэтому сначала нужно измерить его вклад и зависимости.
3. Оптимизировать один раз. Новый виджет, баннер или обновление способны изменить результат. Проверки нужны после релизов.
4. Ускорять любой ценой. Дополнительные баллы не стоят сломанных интеграций и бизнес-логики.
5. Смотреть только на PageSpeed Insights. Отчёт нужно дополнять проверкой старых устройств, медленных сетей и реальных сценариев.
Оптимизация должна сохранять удобство и функции сайта, а не только улучшать число в отчёте.
Инструменты для поиска узких мест
В исходной статье собран набор инструментов для лабораторных проверок, анализа загрузки и наблюдения за пользовательскими сценариями. Их полезно сочетать с ручной проверкой сайта на разных устройствах и сетях:
- PageSpeed Insights — легендарный инструмент от Google, который первым бросит в вас оранжевой оценкой и даст чек-лист для ускорения. Удобно, что вы сразу видите разницу между мобильной и десктопной версией, а ещё здесь встроены метрики Core Web Vitals.
- Google Lighthouse — ваш личный детектив по производительности, SEO, доступности и PWA. Можно запускать прямо из Chrome DevTools (вкладка Lighthouse) или через командную строку. Показывает даже то, о чём вы и не догадывались — иногда слишком честно.
- WebPageTest — “рентген” вашего сайта. Здесь можно тестировать загрузку по разным странам, скоростям интернета и сравнивать с конкурентами покадрово. Анимированные waterfall charts прилагаются.
- GTMetrix — альтернатива PSI, которую любят за понятные отчёты и наглядные графики. Подходит для быстрого аудита и демонстрации клиенту, почему «этот баннер лучше заменить».
- Chrome DevTools — must-have для любого разработчика: вкладки Network, Performance, Coverage, а ещё возможность симулировать 3G-интернет и старые устройства, чтобы посмотреть, кто первым заплачет — ваш сайт или пользователь.
- Яндекс.Метрика: Вебвизор, Инспектор страниц (RU) — кроме привычной аналитики, Вебвизор помогает увидеть «живой» сценарий загрузки страницы для реального пользователя, а Инспектор подскажет ошибки и советы по оптимизации (работает с российскими доменами быстрее, чем зарубежные сервисы).
- PR-CY (RU) — универсальный российский аудит сайта: скорость, мобильность, мета-теги, технические ошибки и даже анализ скорости загрузки на популярных CMS в России.
- И не забываем про старую добрую консоль разработчика и “интуицию” . Иногда найти узкое место можно только ручным тестом: открыв сайт на телефоне где-нибудь за городом, подключив Wi-Fi с устаревшим роутером или попросив маму попробовать открыть ваш лендинг с её старого ноутбука.
- Секрет успеха — комбинировать инструменты: смотреть на баллы, разбирать waterfall, отслеживать реальные сессии пользователей и не стесняться задавать себе главный вопрос: «А я бы сам стал ждать эту загрузку, если бы не был разработчиком?»
Adventure Guide: от аудита к доработкам
В проекте Adventure Guide нужно было сохранить дизайн, понятную навигацию и быстрый фильтр туров, одновременно улучшив загрузку и стабильность интерфейса. Для этого команда проверила ключевые страницы и последовательно доработала изображения, раскладку, стили и скрипты.
Ниже — этапы, описанные в исходной статье, и фрагменты использованного кода. Результаты относятся к версии проекта на момент публикации.
Аудит и загрузка изображений
1. Аудит и сбор метрик. Проверили ключевые страницы в PageSpeed Insights и Lighthouse на разных устройствах. Среди проблем обнаружили сдвиги раскладки, изображения и скрытые элементы.
2. Lazy-load, кроме первого изображения. В галереях и каталоге изображения загружаются отложенно; первое оставили с обычной загрузкой, чтобы не задерживать LCP. Ниже — пример PHP и HTML из проекта.
<?php foreach ($gallery as $i => $img): ?>
<img
src="<?= $img['src'] ?>"
<?= $i > 0 ? 'loading="lazy"' : 'loading="eager"' ?>
alt="Фото тура №<?= $i+1 ?>"
width="350" height="250"
>
<?php endforeach; ?>Формат изображений и стабильность страницы
3. WebP и сжатие. Перевели изображения в WebP и настроили автоматический ресайз.
4. Уменьшение CLS. Задали пропорции и размеры ключевых блоков, фиксированную высоту и min-height слайдеров, чтобы содержимое меньше смещалось при загрузке.
5. Загрузка стилей и скриптов. Критичные стили подключили сразу; остальное — асинхронно или через preload. Ниже сохранён пример отложенного подключения CSS.
<link rel="preload" href="/style/main.css" as="style" onload="this.onload=null;this.rel='stylesheet'">
<noscript><link rel="stylesheet" href="/style/main.css"></noscript>
<!-- Файл main.css сначала preloaded, а затем включается как обычный стиль -->Стили, фильтр и SVG
6. Ревизия CSS. Удалили дубли, сгруппировали медиазапросы и убрали лишние классы.
7. Универсальный фильтр туров. Фильтр стал поддерживать несколько блоков, перестал зависеть от конкретного id и получил обработку сложных сценариев выбора дат.
8. Размеры карточек и баннеров. Задали высоту и aspect-ratio, чтобы стабилизировать раскладку на разных экранах.
9. Скрытые блоки. Для неотображаемых элементов использовали display: none и доработали анимацию. Этот CSS-приём исключает элемент из раскладки, но не удаляет его из DOM — формулировка исходной статьи здесь уточнена.
10. SVG-иконки. Разместили часть иконок инлайн, часть объединили в спрайты, чтобы сократить число запросов.
По данным автора, эти изменения улучшили загрузку и стабильность интерфейса. Оценка на иллюстрации относится к проверке описанной версии проекта, а не к гарантированному постоянному результату.
Как сохранять результат после релиза
После оптимизации проект продолжает меняться: новые баннеры, виджеты, плагины и интеграции способны снова замедлить страницу. Поэтому контроль производительности включён в поддержку.
В исходной статье команда описывает Lighthouse CI в процессе разработки и сборки, регрессионные проверки после релизов и наблюдение за пользовательскими данными в Яндекс.Метрике и Google Analytics.
В регулярные проверки входят сторонние скрипты, обновления плагинов, скорость на старых устройствах и медленных сетях, а также загрузка из разных регионов. Небольшие плановые доработки помогают сохранять результат и не доводить проблемы до аварийной переделки.
Скорость — часть поддержки продукта
Работа со скоростью продолжается после получения хорошего отчёта. Мы сохраняем достигнутый результат через проверки и доработки, чтобы новые функции не мешали людям пользоваться сайтом.
Загружаем комментарии…