Скорость сайта: изображения, шрифты и скрипты

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

Решение состоит из двух шагов. Сначала изображение обрезается до размера, в котором оно реально показывается; изображение шириной четыреста пикселей на телефоне не должно отправляться в размере двух тысяч пикселей. Затем выбирается формат: AVIF и WebP при сопоставимом качестве дают гораздо более лёгкие файлы, чем старый JPEG (web.dev, Optimize LCP). Такой фреймворк, как Next.js, автоматизирует это, и разработчику не нужно вручную готовить несколько версий.

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

Настройка font-display: swap убирает это ожидание: браузер сразу показывает текст системным шрифтом, а затем заменяет его собственным шрифтом, как только тот загрузится (web.dev, Best practices for fonts). Странице бронирования сети спа-салонов иногда достаточно двух начертаний, обычного и жирного, но из файла дизайна на сайт нередко переносят пять-шесть начертаний как есть; каждое лишнее начертание означает отдельную загрузку.

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

Проблема в том, что эти скрипты занимают основной поток браузера; пока этот код выполняется, браузер не может отреагировать на клик посетителя, что напрямую ухудшает INP (web.dev, INP). Раз в несколько месяцев стоит пересматривать список используемых инструментов и убирать панель аналитики, в которую никто уже не заглядывает, или виджет чата, которым никто не пользуется, десять минут на это того стоят.

Исправлять все три источника одновременно не обязательно; порядок упрощает работу.

• Измерить текущее состояние в PageSpeed Insights или Search Console
• Привести самые крупные изображения в первом экране к нужному размеру и формату
• Сократить число начертаний шрифта, добавить font-display: swap
• Убрать неиспользуемые сторонние скрипты, остальные загружать только при необходимости
• После изменений измерить скорость тем же инструментом ещё раз

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

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

Next.js 16 и React 19, уже привычные в 2026 году, ещё сильнее опираются на серверные компоненты: большая часть страницы готовится на сервере и отправляется в браузер уже в готовом виде, что снижает объём JavaScript, который браузеру нужно загрузить. Это архитектурное решение напрямую улучшает INP.

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

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

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

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