Оптимизация изображений для мобильных: руководство по ускорению страниц

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

Мобильная оптимизация изображений начинается с одного ограничения: телефон не должен загружать пиксели, которые он не может отобразить. Измените размер исходника, предоставляйте адаптивные варианты, исключите самое большое изображение в области "above-the-fold" из ленивой загрузки и публикуйте сканируемые файлы WebP или AVIF через CDN.

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

Используйте такой порядок: сначала изменение размера, затем кодирование, потом доставка и в конце измерение. Профессиональная фотография продукта размером 4000 px, отображаемая шириной 390 px, является пустой тратой ресурсов даже при сжатии. Браузер все равно должен загрузить, декодировать и масштабировать ее, прежде чем страница будет готова.

Для большинства мобильных страниц используйте набор источников WebP или AVIF с шириной около 400, 800 и 1200 px. Сохраните запасной вариант JPEG, если ваша аудитория включает старые браузеры, почтовые клиенты или ленты партнеров. Для более глубокого выбора формата используйте сравнение AVIF vs WebP.

Рекомендации Google по LCP гласят, что страницы должны стремиться к Largest Contentful Paint на уровне 2.5 секунд или менее на 75-м процентиле, с разделением для мобильных и настольных устройств. Изображения часто являются элементом LCP, поэтому главное изображение заслуживает особого внимания: предварительно загрузите его или присвойте ему приоритет, установите реальные размеры и не используйте lazy-load.

Что на самом деле меняется на телефоне?

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

Я сгенерировал одну исходную графику размером 1600 x 1000 и закодировал её как WebP q82 при трёх ширинах. Результат показывает, почему изменение размера превосходит настройку качества:

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

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

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

Используйте дескрипторы ширины, когда меняется ширина макета:

<img
  src="/images/hero-800.webp"
  srcset="/images/hero-400.webp 400w, /images/hero-800.webp 800w, /images/hero-1200.webp 1200w"
  sizes="(max-width: 640px) 100vw, 720px"
  width="800"
  height="500"
  alt="Reusable water bottle on a kitchen counter"
>

В руководстве MDN по responsive images объясняется модель выбора srcset и sizes. Проще говоря: srcset перечисляет кандидатов, а sizes сообщает браузеру, какой ширины будет отображаемый слот до завершения макета.

Для пакетного рабочего процесса генерируйте ширины из одного и того же мастер-файла. В руководстве по batch resize описан шаблон командной строки, а в статье по image compression deep dive объясняется, почему изменение размера должно происходить до финального сжатия.

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

Используйте <picture>, когда мобильное изображение требует не просто меньшего файла, а другую обрезку. Широкий десктопный "геройский" баннер может стать бесполезным на телефоне, если объект расположен далеко слева или текстовая область закрывает продукт.

<picture>
  <source
    media="(max-width: 640px)"
    srcset="/images/shoe-mobile.webp 720w"
    sizes="100vw"
    type="image/webp"
  >
  <source
    srcset="/images/shoe-desktop.webp 1440w"
    sizes="min(100vw, 1440px)"
    type="image/webp"
  >
  <img
    src="/images/shoe-desktop.jpg"
    width="1440"
    height="700"
    alt="Trail running shoe with the sole tread visible"
  >
</picture>

Используйте арт-дирекшн для:

1. Изображений продуктов в стиле "герой", где продукт становится крошечным на мобильном устройстве.
2. Редакционных баннеров, где лицо или объект должны оставаться по центру.
3. Объявлений на маркетплейсах, которым нужны квадратные миниатюры и широкие детализированные изображения.
4. Изображений "до/после", где обе стороны должны оставаться читаемыми.
5. Скриншоты с мелким текстом, требующие более плотной обрезки.

Не используйте <picture> в качестве замены обычным адаптивным ширинам. Если композиция одинакова, проще использовать srcset плюс sizes.

Как WebP, AVIF и JPEG влияют на производительность мобильных устройств?

Используйте WebP в качестве базового мобильного формата, если вам нужен один современный файл, который работает широко. Используйте AVIF, когда ваш конвейер может его генерировать, и вы можете сохранить запасные варианты (fallback) WebP или JPEG. Сохраняйте JPEG для электронной почты, старых партнерских систем и исходных архивов, которые должны открывать другие инструменты.

Полный список проверки оптимизации изображений ([complete image optimization checklist]) охватывает более широкий процесс публикации. Если вам нужно сравнить инструменты, которые выводят WebP и AVIF, см. [TinyPNG alternatives].

Используйте стек <picture>, когда это возможно:

<picture>
  <source srcset="/images/card-480.avif 480w, /images/card-800.avif 800w" type="image/avif">
  <source srcset="/images/card-480.webp 480w, /images/card-800.webp 800w" type="image/webp">
  <img src="/images/card-800.jpg" width="800" height="600" alt="Blue ceramic mug beside a notebook">
</picture>

Как должна работать ленивая загрузка на мобильных устройствах?

Используйте ленивую загрузку для изображений, которые начинаются ниже первого видимого экрана. Не используйте ленивую загрузку для изображения LCP. Ленивая загрузка на уровне браузера полезна, но сама по себе она не является планом повышения производительности.

В руководстве Google по ленивой загрузке на уровне браузера рекомендуется использовать нативную директиву loading="lazy" для изображений вне области просмотра. Это же руководство предупреждает о том, что ленивая загрузка немедленно видимых изображений может задерживать контент, который ждет пользователь.

Используйте этот контрольный список:

1. Установите для героического изображения loading="eager" или опустите атрибут loading.
2. Добавьте fetchpriority="high" к наиболее вероятному изображению LCP.
3. Добавьте loading="lazy" к изображениям после первого экрана.
4. Укажите width и height для каждого изображения.
5. Используйте CSS aspect-ratio, когда изменяется соотношение сторон при изменении брейкпоинта.
6. Избегайте внедрения изображений только с помощью JavaScript для героического баннера.
7. Проверьте, что URL-адреса изображений CDN включают длинные заголовки кэша.
8. Тестируйте в профиле мобильного устройства с ограничением скорости, а не только на Wi-Fi рабочего стола.
9. Отслеживайте элемент LCP в PageSpeed Insights.
10. Повторите проверку после изменений дизайна, потому что элемент LCP может измениться.

В документации Google по LCP перечислены элементы изображений, постеры видео и фоновые изображения среди возможных кандидатов на LCP. Вот почему фоновый героический баннер может навредить LCP, даже если он не является <img>.

Что должен делать CDN для изображений на мобильных устройствах?

CDN для изображений должен устранять рутинную работу: изменять размер на периферии, согласовывать форматы, кэшировать варианты и поддерживать стабильность публичных URL. CDN не заменяет правильную подготовку исходных материалов. Загрузка размытой фотографии продукта размером 900 px в image CDN не создаст реальных деталей размером 1600 px.

Обратите внимание на следующие элементы управления:

• Трансформации ширины для распространенных мобильных и настольных слотов.
• Вывод в форматах WebP и AVIF с правильным Content-Type.
• Ключи кэша, включающие ширину, качество и формат.
• Способ сохранения оригинальных загрузок отдельно от публичных производных копий.
• Стабильные публичные URL, которые могут сканировать Google Images.
• Мониторинг ошибок 404 после развертывания и миграций.

Для поисковой оптимизации Google image SEO best practices делают акцент на полезных, видимых изображениях рядом с соответствующим текстом, описательными именами файлов и alt text, а также сканируемых URL изображений. CDN URL подойдет, если он индексируем, стабилен и ссылается со страницы.

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

Тестируйте страницу так, как ее получает мобильный посетитель. Один чистый запуск Lighthouse полезен, но он может скрыть пропуски CDN, слишком большие адаптивные кандидаты и смещения макета (layout shifts), которые проявляются только в реальных шаблонах.

Одна практическая команда для локальной проверки:

curl -I https://cdn.example.com/images/product-card-480.webp

Затем проверьте рендерированную страницу в узком видоискателе. Если таблица или изображение выходит за пределы экрана, исправьте макет, прежде чем праздновать экономию байтов.

Чеклист по SEO и GEO для изображений на мобильных устройствах

Поисковые системы и поисковики ответов нуждаются в том же, что и человек: в прямом контексте. Не прячьте изображения в карусели без объяснения поблизости и не ожидайте, что сам актив будет нести смысл.

Перед публикацией убедитесь:

1. Страница содержит один четкий ответ в верхней части.
2. Каждое важное изображение имеет описательный alt text.
3. Имена файлов описывают видимый объект, а не IMG_9021.
4. URL изображения доступен для сканирования без использования cookies.
5. Окружающий параграф объясняет, почему изображение присутствует.
6. Мобильный "герой" не больше, чем требуется для отображаемого слота.
7. Изображения в теле используют loading="lazy" только когда они находятся ниже первого области просмотра (viewport).
8. Таблицы обобщают решения, которые читатель может повторно использовать.
9. Внешние утверждения ссылаются на авторитетные источники.
10. Внутренние ссылки ведут к следующему реальному рабочему процессу, а не к случайной кластерной странице.

Для этапа оптимизации по SEO после сжатия используйте image SEO optimization checklist. Для одноразовой работы с файлами Image Compressor, Image Converter и Image Resizer охватывают общие ручные шаги.

Кредиты изображений

• Обложка (Cover), график адаптивной ширины (responsive width chart), кадрирование для арт-дирекции (art-direction crop) и график приоритета загрузки (loading-priority chart) были сгенерированы для этой статьи с помощью ImageMagick и экспортированы как WebP. График адаптивной ширины использует измеренный вывод WebP q82 из той же исходной графики размером 1600 x 1000.