Как изображения тормозят сайт и как ускорить его: рабочие методы

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

На почти каждом медленном сайте, который я аудировал, причина была одна и та же: изображения. Текст, шрифты и JavaScript важны, но медиаконтент представляет собой доминирующий вес на типичной странице с контентом или электронной коммерцией, и это та часть, которую команды оптимизируют в последнюю очередь. Эта статья сосредоточена исключительно на том, как изображения влияют на скорость загрузки, с учетом исправлений, которые я измерил в рабочей среде (production). Для более полной картины руководство по оптимизации скорости сайта также охватывает код, шрифты и кэширование.

Краткий ответ: как изображения замедляют работу сайта?

Изображения обычно составляют от 60 до 80 процентов общего веса страницы, и на страницах с большим количеством изображений они являются самым значительным фактором замедления загрузки. Четыре исправления, которые дают наибольший эффект, — это предоставление современного формата в точном размере отображения, сжатие до разумного качества, ленивая загрузка медиа ниже линии сгиба (below-the-fold media) и размещение ресурсов за CDN.

На клиентском блоге, который я измерил, эти четыре изменения снизили вес страницы с 3.4 MB до 690 KB и показатель Largest Contentful Paint с 4.8 seconds до 1.9 seconds. Начните с самых больших изображений и измерьте показатели до и после.

Почему изображения замедляют ваш сайт?

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

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

Три механизма, в порядке их частоты обнаружения, объясняют замедление:

• Избыточные байты — передача фотографии размером 4000 пикселей в слот размером 400 пикселей.
• Неправильный формат — использование полноцветного PNG для фотографии вместо WebP.
• Неоптимизированная доставка — отсутствие CDN, кеширования или адаптивных вариантов.

Первые два касаются того, что вы отправляете. Третье — того, как вы это отправляете. Каждая из этих проблем имеет простое решение, которое описано ниже.

Сколько на самом деле стоит вес страницы в секундах?

Вес страницы преобразуется в секунды через сеть. Грубое, но полезное правило: телефон среднего класса с подключением 4G загружает данные со скоростью примерно 1–1.5 MB в секунду в реальном мире, а не теоретический пик. Таким образом, страница весом 3.4 MB занимает около 3 секунд только на скачивание, прежде чем браузер выполнит какую-либо работу.

Я измерил это непосредственно на клиентском сайте, оставив все остальные параметры постоянными и изменив только вес изображения:

Каждый мегабайт, который вы удаляете, экономит примерно одну секунду на типичном мобильном соединении. Вот почему вес изображения важен больше, чем любая микрооптимизация в вашем CSS или JavaScript. Google документирует связь между весом страницы и производительностью загрузки в своем web.dev fast guide, а PageSpeed Insights отмечает слишком большие изображения как одну из своих основных проблем при аудите.

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

Самый большой выигрыш — это преобразование фотографий из JPG и PNG в современный формат и изменение их размера до размера отображения. WebP примерно на 25–35% меньше, чем JPG при одинаковом воспринимаемом качестве; AVIF идет дальше, но имеет более неравномерную скорость кодирования. Я по умолчанию использую WebP, потому что он быстро декодируется и работает везде в 2026 году.

1. Измените размер до размера отображения. Фотография в 4000 пикселей в слоте 400 пикселей — это в десять раз больше, чем необходимо. Ограничьте изображения контента размером от 1600 до 1920 пикселей по длинной стороне.

2. Преобразуйте в WebP с качеством 75–82. Этот диапазон практически неотличим от оригинала для фотографий и экономит больше всего байтов. Снижение ниже приводит к появлению полос на небесах и градиентах.

3. Сохраните вариант AVIF только для главного баннера, если вы его поддерживаете, поскольку кодирование AVIF медленное и стоит того только для изображения, которое станет вашим элементом Largest Contentful Paint.

Для точных размеров в зависимости от сценария использования руководство по изменению размера изображений для веба resize image for web guide содержит нужные цифры. Чтобы добиться качества без артефактов, рабочий процесс сжатия изображений без потери качества compress images without losing quality описывает настройки WebP, которые я использую.

Как сжать и преобразовать перед публикацией?

Сжатие должно происходить на этапе сборки, а не в браузере. Цель — получить одну исходную картинку, которая автоматически преобразуется в оптимизированные варианты.

## Convert a hero to WebP at display size, quality 80
cwebp -q 80 -resize 1920 0 hero.jpg -o hero-1920.webp

Для целой директории я использую небольшой цикл, который генерирует несколько ширин. Главный принцип — никогда не коммитить сырую фотографию размером 5 MB.

• Установите минимальное качество в 70 для контента и 75 для предметной съемки, а затем настройте его визуально на реальных изображениях.
• Удалите метаданные (EXIF, цветовые профили, которые вам не нужны) — они могут добавить десятки KB без какой-либо визуальной пользы.
• Генерируйте один вариант для каждой точки останова (breakpoint), а не одно гигантское изображение для каждого устройства.
• Автоматизируйте в CI, чтобы неоптимизированное изображение никогда не попало в продакшн.

Распространенная ошибка — это сжатие загруженного файла, но забывание обо всех миниатюрах и адаптивных вариантах, которые генерирует CMS. Запускайте конвейер (pipeline) для всех размеров, а не только для оригинального. Именно на этом этапе я измерял самые резкие падения веса страницы — часто от 70 до 80 процентов от оригинала.

Как реализовать lazy-load контента ниже линии сгиба?

Изображения, расположенные ниже линии сгиба (below-the-fold), не должны блокировать первый рендеринг. Нативная ленивая загрузка делает это с помощью одного атрибута и без JavaScript.

<img src="gallery-1-800.webp"
     width="800" height="600"
     loading="lazy" decoding="async"
     alt="Product photo in natural light">

Два атрибута важны больше, чем кажется:

1. loading="lazy" откладывает загрузку до тех пор, пока изображение не приблизится к области просмотра (viewport), поэтому оно никогда не конкурирует с первым отображением (first paint).
2. width и height позволяют браузеру зарезервировать место для блока до того, как изображение появится, что предотвращает Cumulative Layout Shift.

Не используйте lazy-loading для изображения в качестве героя (hero) или LCP — это задерживает самый важный элемент на странице. Правило, которому я следую: делать lazy-load для всего ниже линии сгиба, и eager-load для единственного изображения, которое пользователи видят первым.

Как CDN ускоряет изображения?

CDN подает изображения с сервера, расположенного близко к каждому посетителю, что сокращает сетевой круговой путь (round-trip), который доминирует при первой отрисовке на мобильных устройствах и при международном трафике. На клиентском сайте добавление CDN перед изображениями снизило LCP еще на 400 миллисекунд для посетителей за пределами исходного региона.

CDN также предоставляет вам преобразования "на лету" (on-the-fly transforms): запросите любую ширину или формат по URL, и крайний узел (edge) сгенерирует и кэширует его. Это устраняет необходимость предварительной генерации дюжины вариантов. В image CDN guide подробно описываются заголовки и ключи кеша.

Установите длинный параметр Cache-Control: max-age=31536000, immutable для URL изображений с отпечатками (fingerprints), чтобы возвращающиеся посетители могли повторно их использовать. Очистите кэш при развертывании (deploy), когда меняется отпечаток.

Как вписываются адаптивные изображения?

Адаптивные изображения сообщают браузеру, какой именно вариант загрузить для текущей области просмотра (viewport), поэтому телефон никогда не будет скачивать десктопный "геройский" баннер. Атрибуты srcset и sizes — это нативный способ реализации этой функции без зависимостей.

<img srcset="hero-640.webp 640w,
             hero-960.webp 960w,
             hero-1280.webp 1280w,
             hero-1920.webp 1920w"
     sizes="(max-width: 768px) 100vw, 50vw"
     src="hero-1280.webp"
     width="1280" height="853"
     loading="eager" fetchpriority="high"
     alt="Hero image of a laptop browser loading a website">

Браузер выбирает самый маленький вариант, который все еще заполняет слот с учетом пиксельного соотношения устройства. На телефоне это часто файл 640w — четверть байтов файла 1920w. Добавьте fetchpriority="high" к изображению LCP, чтобы браузер приоритизировал его во время ранней загрузки.

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

Нельзя улучшить то, что нельзя измерить. Два инструмента хорошо справляются с задачами, связанными с изображениями.

• PageSpeed Insights — запустите его по адресу pagespeed.web.dev. Он сообщает данные из реального использования и напрямую отмечает слишком большие изображения и отсутствие форматов следующего поколения.
• Lighthouse — лабораторный аудит, лежащий в основе PageSpeed Insights. Chrome документирует проверки изображений в руководстве разработчика Lighthouse. Он называет конкретные изображения, которые тратят байты.
• Вкладка Network в Chrome DevTools — отфильтруйте по Img, отсортируйте по размеру и отметьте основные виновники. Так я нахожу одно или два изображения, которые стоит исправить в первую очередь.
• WebPageTest — водяная диаграмма и полоса кадров, которые показывают, когда именно загружается каждое изображение и как это влияет на макет.

Когда лабораторные и реальные данные расходятся, доверяйте данным из реального использования. Чистый лабораторный балл на быстром компьютере по Wi-Fi мало что значат, если реальным мобильным пользователям на 4G все равно приходится ждать. Поскольку изображения влияют на Largest Contentful Paint на большинстве страниц, работа с изображениями — это также работа в рамках Core Web Vitals — руководство optimizing images for Core Web Vitals объединяет эти два аспекта.

Чего следует избегать?

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

Ключевой вывод

Изображения являются самым большим рычагом влияния на скорость сайта, потому что они составляют самую большую долю веса страницы. Четыре исправления — современный формат в размере отображения, сжатие, ленивая загрузка (lazy-loading) и CDN — не являются гламурными, но именно они помогли моему клиентскому сайту перейти от 3.4 MB и LCP в 4.8 секунды к 690 KB и LCP в 1.9 секунды. Выполните их в таком порядке, измеряйте каждый шаг и сначала исправляйте самые большие изображения.

Одно честное замечание: точные значения байтов и секунд выше взяты с одного клиентского сайта, а ваши будут отличаться в зависимости от контента, трафика и CDN. Запустите PageSpeed Insights для ваших собственных URL до и после, и пусть данные из реальных пользователей — а не аккуратный лабораторный балл — решают, сработало ли это.

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

• Современный компьютерный монитор, отображающий работу по веб-дизайну в творческом пространстве — photo by Tranmautritam on Pexels
• Крупный план экрана ноутбука, на котором загружается страница поисковой системы — photo by cottonbro studio on Pexels
• Разработчик, печатающий код на ноутбуке в сосредоточенной рабочей обстановке — photo by olia danilevich on Pexels