Скорость страницы как редакционный стандарт

Скорость загрузки страницы привыкли считать заботой разработчиков. Есть технический аудит, есть отчёт PageSpeed Insights с красными и зелёными цифрами, есть задача в бэклоге «оптимизировать изображения», которая месяцами ждёт своей очереди. Редакция при этом живёт своей жизнью: загружает фотографии по 6 мегабайт, вставляет по три видеоролика в статью, добавляет виджеты соцсетей, опросы, слайдеры и встраиваемые карты.

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

Почему скорость — это про контент

Если посмотреть, что делает типичную страницу медленной, окажется, что большая часть веса приходится не на код шаблона, а на содержимое:

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

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

Как скорость влияет на результат

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

Для поиска скорость — часть оценки качества страницы. Google учитывает показатели Core Web Vitals как один из сигналов ранжирования, хотя и не главный. Яндекс также оценивает удобство страниц, а в Вебмастере и Метрике есть свои инструменты мониторинга скорости. Но важнее прямого влияния на позиции — косвенное: пользователь, который не дождался загрузки, не прочитает, не поделится и не купит.

Метрики, которые стоит знать редакции

Редакторам не нужно разбираться в тонкостях фронтенд-оптимизации, но три показателя Core Web Vitals полезно понимать.

• LCP (Largest Contentful Paint) — время, за которое отображается самый крупный элемент первого экрана: обычно главное изображение или заголовок. Хороший результат — до 2,5 секунды. Именно на LCP сильнее всего влияет обложка статьи.
• INP (Interaction to Next Paint) — насколько быстро страница реагирует на действия пользователя. Хороший результат — до 200 миллисекунд. Страдает от тяжёлых скриптов и виджетов.
• CLS (Cumulative Layout Shift) — насколько «прыгает» вёрстка при загрузке. Хороший результат — до 0,1. Ухудшается, когда изображения, баннеры и встраиваемые блоки не имеют заданных размеров и раздвигают текст после загрузки.

Все три метрики напрямую зависят от того, как оформлен материал.

Что включить в редакционный стандарт

Изображения

• Ограничьте вес. Например: обложка — не более 200 КБ, иллюстрации в тексте — не более 150 КБ. Конкретные цифры зависят от дизайна, важно, чтобы они были записаны.
• Ограничьте размер в пикселях. Нет смысла загружать фото шириной 6000 пикселей, если колонка текста — 800. Достаточно двукратного запаса для экранов высокой плотности.
• Используйте современные форматы. WebP и AVIF при том же качестве весят заметно меньше JPEG. Если CMS конвертирует автоматически — отлично, если нет — это задача для разработки, а не повод отказаться от правила.
• Не используйте PNG для фотографий. PNG нужен для схем, скриншотов интерфейсов и графики с прозрачностью.
• Замените тяжёлые GIF на видео. Короткий ролик в MP4 или WebM обычно весит в разы меньше аналогичной анимации.
• Заполняйте alt. Это не про скорость, но про доступность и поиск по картинкам — удобно проверять одновременно.

Видео

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

Встраиваемые блоки и виджеты

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

Вёрстка

• Изображения и встроенные блоки должны иметь заданные пропорции, чтобы текст не прыгал при загрузке.
• Рекламные места резервируются заранее, а не вставляются поверх контента.
• Специальные шрифты для отдельных лонгридов — только если без них действительно нельзя.

Как внедрить стандарт без сопротивления

Сделайте правила короткими

Документ на двадцать страниц никто не прочитает. Достаточно одностраничной памятки с конкретными лимитами и примерами: «так можно, так нельзя».

Автоматизируйте всё, что можно

Лучший стандарт — тот, который не нужно соблюдать вручную. Попросите разработку настроить автоматическое сжатие и конвертацию изображений при загрузке, генерацию нескольких размеров, ленивую загрузку по умолчанию, ограничение на максимальный вес файла с понятным сообщением об ошибке. Тогда редактору останется только не обходить защиту.

Добавьте скорость в чек-лист публикации

Перед публикацией редактор уже проверяет заголовок, анонс, метаописание, ссылки и орфографию. Добавьте один пункт: проверить страницу в PageSpeed Insights или в инструментах браузера. Это занимает минуту.

Показывайте результат

Раз в месяц делитесь с редакцией простым отчётом: какие материалы были самыми быстрыми и медленными, как скорость связана с дочитываниями и конверсией. Когда люди видят, что тяжёлая статья хуже читается, мотивация появляется сама.

Назначьте ответственного

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

Как мониторить скорость

• Search Console — отчёт об основных интернет-показателях по реальным данным пользователей Chrome.
• PageSpeed Insights — точечная проверка отдельной страницы: лабораторные и полевые данные с конкретными рекомендациями.
• Яндекс Вебмастер и Метрика — показатели скорости и качества загрузки для аудитории Яндекса.
• Инструменты разработчика в браузере — вкладка Network покажет, какой элемент весит больше всего.

Полезно раз в квартал выгружать список самых посещаемых материалов и проверять их скорость: старые статьи, созданные до введения стандарта, часто оказываются главными нарушителями.

Вывод

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