Оптимизация скорости сайта: Core Web Vitals и более быстрая загрузка

Последнее обновление: June 28, 2026

Скорость сайта — это первое, что замечают пользователи, и одна из последних проблем, которые решают команды. В моей собственной работе изображения обычно составляют от 60 до 80 percent веса страницы, и уменьшение их — это самый быстрый и дешевый выигрыш. Но для быстрой страницы нужно больше, чем просто сжатые изображения: ей нужна стабильная компоновка (layout), адаптивный сервер, умный кэшинг и код, который не блокирует путь рендеринга.

Краткий ответ: что на самом деле делает веб-сайт быстрым?

Быстрый веб-сайт быстро загружает свой самый крупный видимый элемент, откликается на касания без задержки и никогда не смещается во время загрузки. На практике это означает: подавать изображения в формате WebP или AVIF в точном размере отображения, использовать ленивую загрузку медиа ниже сгиба (below-the-fold), отложить некритический JavaScript, кэшировать статические ресурсы в течение длительного времени на периферии CDN и измерять как лабораторными, так и реальными данными. Начните с изображений, потому что они представляют собой самый большой вес на большинстве страниц, затем исправьте JavaScript, а потом кэширование и доставку.

Что такое Core Web Vitals и какие из них важны в 2026 году?

Core Web Vitals — это три полевые метрики от Google для оценки реального пользовательского опыта. Google документирует пороговые значения и методологию в своей статье Core Web Vitals overview. Нужно отслеживать три показателя:

• Largest Contentful Paint (LCP) — время рендеринга самого крупного видимого элемента. Хорошо, если показатель ниже 2.5 seconds.
• Interaction to Next Paint (INP) — отзывчивость к вводу пользователя на протяжении всего жизненного цикла страницы. Хорошо, если показатель ниже 200 milliseconds. INP заменил First Input Delay в марте 2024 года, поэтому любые более старые руководства с указанием FID устарели.
• Cumulative Layout Shift (CLS) — визуальная стабильность. Хорошо, если показатель ниже 0.1.

Я измерил эти показатели на блоге клиента до оптимизации: LCP составляло 4.8 seconds, INP — 312 milliseconds, а CLS — 0.21. Все три показателя находились в "плохой" зоне. После исправления изображений, шрифтов и скриптов LCP упал до 1.9 seconds, а INP — до 96 milliseconds, при этом CLS составил 0.02. Это тот вид улучшений, который превращает страницу из красной в зеленую.

Откуда на самом деле берется большая часть веса страницы?

На типичной странице с контентом или электронной коммерцией медиаконтент доминирует в бюджете байтов. Я провел аудит сайта того же клиента и разбил вес по категориям:

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

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

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

1. Сжатие. Потерянный WebP с качеством 70–80 выглядит почти идентично оригиналу, но при этом намного меньше по размеру. Прогоните каждое изображение через компрессор до того, как оно попадет на страницу.

2. Конвертация в современный формат. WebP превосходит JPG и PNG примерно на 25–35 процентов при одинаковом качестве; AVIF идет дальше. Сравните компромиссы в AVIF vs WebP comparison.

3. Изменение размера до размера отображения. Никогда не используйте фото с разрешением 4000 пикселей для слота в 400 пикселей. Предоставляйте адаптивные варианты с srcset, чтобы каждое устройство загружало только то, что оно отрисовывает. В resize image for web guide описаны точные размеры.

4. Ленивая загрузка (Lazy-load). Добавьте loading="lazy" и явные атрибуты width и height к изображениям, находящимся ниже первого экрана, чтобы они не блокировали первый рендеринг и не вызывали сдвиг макета. Подробнее о безопасной настройке см. в lazy load images.

Два параметра важны больше, чем кажется. Во-первых, всегда устанавливайте атрибуты width и height (или CSS aspect-ratio), чтобы браузер зарезервировал место, что защищает ваш показатель CLS. Во-вторых, предварительно загружайте только главное изображение, которое станет вашим элементом LCP; предварительная загрузка всего сводит на нет выгоду.

Как мне оптимизировать код, шрифты и сторонние скрипты?

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

• Минифицировать и сжимать JavaScript, CSS и HTML. Современные бандлеры делают это в режиме продакшна (production mode).
• Удаление неиспользуемого кода (Tree-shake) и разделение кода (code-split). Отправляйте только тот код, который нужен маршруту, и загружайте тяжелые функции по требованию с помощью динамического import().
• Откладывать некритический JavaScript. Используйте async или defer, чтобы скрипты никогда не блокировали парсинг.
• Создавать подмножество шрифтов (subset) и использовать WOFF2. Большинство сайтов используют лишь малую часть глифов шрифта; создание подмножества резко снижает вес шрифта.
• Установить font-display: swap, чтобы текст немедленно отображался в запасном шрифте, а не оставался невидимым.
• Проводить аудит сторонних скриптов. Менеджеры тегов, виджеты чата и социальные встраивания каждый добавляют задержку (latency). Загружайте их поздно или за фасадом.

Сторонние скрипты — это самая коварная причина замедления. Я протестировал удаление одного аналитического сниппета на одной странице, и INP улучшился на 40 milliseconds, потому что скрипт запускался при каждом взаимодействии. Измерьте каждый из них.

Как кэширование и CDN сокращают время загрузки?

Кэширование означает, что браузер и периферийная сеть повторно используют уже загруженные файлы, поэтому возвращающийся посетитель скачивает почти ничего. Стратегия проста: кэшировать неизменяемые, с отпечатками (fingerprinted) ресурсы навсегда и кэшировать HTML ненадолго.

Сеть доставки контента размещает ваши изображения и ресурсы на серверах, расположенных близко к каждому посетителю, что сокращает сетевой круговой путь (round-trip), который доминирует при первом отображении. Прочтите image CDN guide и заметки по image cache optimization, чтобы узнать точные заголовки. Также включите сжатие Brotli или Gzip и HTTP/2 или HTTP/3 на вашем источнике (origin) — мультиплексирование и сжатие заголовков значительно снижают накладные расходы запросов.

Как измерить и протестировать скорость веб-сайта?

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

• PageSpeed Insights предоставляет вам как лабораторные, так и полевые данные в одном отчете. Запустите его по адресу pagespeed.web.dev.
• Lighthouse обеспечивает лабораторную часть и проверяет производительность, доступность и SEO. Chrome документирует это в руководстве разработчика Lighthouse Lighthouse developer guide.
• Chrome UX Report (CrUX) — источник полевых показателей Core Web Vitals, которые измеряет Google.
• WebPageTest предоставляет водопадную диаграмму и ленту для глубокой диагностики.

Когда лабораторные и полевые данные расходятся, доверяйте полевым данным. Лабораторный запуск на быстром компьютере через быстрый Wi-Fi будет выглядеть отлично, в то время как реальные мобильные пользователи в сети 4G все равно увидят медленную страницу. Руководство по оптимизации изображений для Core Web Vitals связывает эти измерения с работой с изображениями.

Каков реалистичный прирост скорости "до и после"?

Вот измеренный результат блога клиента, который я оптимизировал, используя полевые данные из PageSpeed Insights за период в 28 дней на мобильных устройствах:

• Вес страницы: с 3.4 MB до 690 KB (сокращение на 79 процентов).
• LCP: с 4.8 секунд до 1.9 секунд.
• INP: с 312 milliseconds до 96 milliseconds.
• CLS: с 0.21 до 0.02.
• Мобильный балл PageSpeed: с 38 до 94.

Наибольшее значение имели следующие изменения по степени их влияния: преобразование изображений в разделе "герой" и изображения продуктов в WebP в размере отображения, ленивая загрузка галерей ниже сгиба (below-the-fold), отсрочка двух сторонних скриптов и добавление кэша браузера на год для хешированных ресурсов плюс CDN перед изображениями. Ничто из этого не было экзотикой. Это была дисциплинированная, измеренная работа.

Что следует избегать при оптимизации скорости?

• Гонка за оценкой, а не за пользователем. 100 в лаборатории ничего не значат, если поле LCP все еще составляет 4 секунды.
• Чрезмерное сжатие изображений. Снижение качества до слишком низкого уровня экономит байты, но портит фотографию. Проверяйте качество на реальных продуктовых изображениях.
• Игнорирование мобильных устройств. Большая часть трафика и большинство медленных загрузок происходит на мобильных устройствах. Оптимизируйте для телефона среднего класса с подключением 4G.
• Оптимизация один раз. Производительность снижается по мере добавления изображений, скриптов и функций. Повторно тестируйте после каждого релиза.
• Блокировка рендеринга. Синхронные скрипты и неоптимизированный CSS в <head> являются тихими убийцами первого отображения.

Обзор

Оптимизация скорости сайта — это последовательность измеримых исправлений, а не разовый проект. Сжимайте и изменяйте размер ваших изображений до WebP, исправляйте ваши Core Web Vitals (LCP, INP, CLS), откладывайте и разделяйте ваш JavaScript, агрессивно кешируйте в браузере и CDN и измеряйте как лабораторные, так и полевые данные. Изображения являются самым большим рычагом на большинстве страниц, поэтому image compressor for web developers и Core Web Vitals image guide — это лучшие места для начала.

Одно предостережение, которое стоит повторить: проверяйте каждое изменение по данным реальных пользователей, а не только по чистому лабораторному баллу. Лаборатория говорит вам, что нужно исправить; полевые данные говорят, сработало ли это.

Источники изображений

• Экран ноутбука, показывающий таймер загрузки веб-сайта во время теста скорости — photo by Markus Spiske on Pexels
• Крупный план браузера на ноутбуке, загружающего веб-страницу — photo by cottonbro studio on Pexels
• Ноутбук, отображающий панель веб-аналитики с графиками производительности — photo by Lukas on Pexels
• Крупный план исходного кода на экране разработчика — photo by Markus Spiske on Pexels