Как мы сократили время загрузки site менее чем до одной секунды
Скорость — это не просто метрика тщеславия, она влияет на позиции в поиске и доход. Вот конкретные шаги по оптимизации производительности, которые мы выполняем для каждого build, в порядке их значимости.
Большинство медленных websites работают медленно не по каким-то таинственным причинам. Они медленные из-за нескольких предсказуемых проблем, накладывающихся друг на друга, — и решаются они в предсказуемом порядке. Когда к нам приходит клиент с трехсекундным временем загрузки, нам редко требуются необычные приемы. Нам нужна дисциплина.
Мы используем этот же чек-лист при каждом проекте по оптимизации производительности, примерно в порядке приоритета. Каждый шаг относительно дешев по сравнению с его эффектом, и большинство sites работают ощутимо быстрее уже после первых трех.
Измеряйте показатели перед любыми изменениями
Нельзя улучшить то, что вы не измеряете, и уж точно нельзя доказать улучшение без исходных показателей. Мы начинаем каждый проект с полевых данных, а не только с лабораторных результатов.
- Лабораторные данные — Lighthouse и WebPageTest для контролируемого, воспроизводимого среза.
- Полевые данные — метрики реальных пользователей (CrUX / RUM) для оценки того, с чем люди сталкиваются на самом деле.
- Бюджет — жесткий лимит на каждый маршрут, чтобы ухудшения показателей отслеживались в CI, а не в production.
Оценка 100 в лабораторных тестах ничего не значит, если ваши реальные пользователи используют устройства среднего сегмента и нестабильный интернет. Оптимизируйте для полевых условий.
Устраните ресурсы, блокирующие рендеринг
Главная победа на большинстве sites — это исключение CSS и JavaScript из критического пути загрузки. Браузер не может выполнить отрисовку, пока не завершит разбор блокирующих рендеринг ресурсов. Поэтому чем их меньше, тем раньше на экране что-то появится.
// defer everything that isn't critical
const load = () => import('./analytics.js');
if ('requestIdleCallback' in window)
requestIdleCallback(load);
else setTimeout(load, 2000);Внедряйте небольшой объем CSS, необходимый для первого экрана, непосредственно в HTML, а остальную часть загружайте асинхронно. Откладывайте загрузку некритичных скриптов. Цель — выполнить первую отрисовку без ожидания ресурсов, которые не требуются сразу.
Относитесь к изображениям как к бюджету
Изображения обычно являются самым тяжелым элементом на странице, и здесь проще всего допустить ошибку. Три правила покрывают девяносто процентов случаев:
- Используйте современные форматы — AVIF или WebP — с резервным вариантом (fallback).
- Подгоняйте размеры изображений под размеры их отображения; никогда не вставляйте изображение hero размером 3000px в контейнер шириной 600px.
- Настраивайте lazy-load для всего, что находится ниже первого экрана, и резервируйте место, чтобы избежать сдвигов макета.
Кэшируйте на edge-серверах
Когда страница облегчена, следующий вопрос заключается в том, насколько быстро байты доходят до пользователя. CDN с правильно настроенными заголовками кэширования превращает 600-миллисекундный запрос к исходному серверу в 30-миллисекундный ответ от edge-сервера. Для динамического контента stale-while-revalidate дает мгновенный отклик, выполняя обновление в фоновом режиме.
Производительность — это фича. Мы планируем бюджет на нее так же, как и на любую другую часть build.
Результат
В проекте, который вдохновил на написание этой статьи, показатель Largest Contentful Paint главной страницы сократился с 3,1 до 0,9 секунды, а органическая конверсия заметно выросла в течение месяца. Никакой магии — только приведенный выше чек-лист, выполненный по порядку.
Если ваш site кажется медленным и вы не знаете, с чего начать, свяжитесь с нами — короткий аудит обычно позволяет выявить две-три доработки, которые принесут наибольшую пользу.