
Картинки — обычно самая тяжёлая часть страницы. Пока они не оптимизированы, сайт теряет в скорости загрузки, мобильном PageSpeed, краулинговом бюджете и, как следствие, в конверсии.
Разберём на примере bobers.ru, как перевести изображения в формат WebP и ускорить сайт на 60–90% по весу картинок — без потери качества и без риска для действующего проекта.
Каждый лишний мегабайт — это секунды ожидания, особенно на мобильном интернете. Пользователь не ждёт — уходит.
Google оценивает мобильную версию отдельно и строже. Тяжёлые изображения — одна из главных причин низкого балла.
Поисковый бот тратит лимит на загрузку тяжёлых файлов вместо обхода новых и важных страниц сайта.
Скорость страницы напрямую влияет на поведенческие метрики и итоговую конверсию в заявку или покупку.
Прежде чем менять хоть один файл — снят полный бэкап. Любое действие можно откатить в исходное состояние.
Imagick, качество q80, с сохранением альфа-канала (прозрачность PNG не теряется). Оригиналы не изменяются и не удаляются.
WebP отдаётся через тег <picture> с фолбэком на оригинал для старых браузеров. Правка обратима одним переключателем.
Статика сайта, фотографии кейсов (works/), retina-галереи (srcset 1x/2x), превью «на лету» (phpThumb) — ни один тип картинок не пропущен.
Новые загрузки автоматически получают WebP-версию — оптимизация не требует ручной работы после внедрения.
Вес хранилища изображений сократился по обоим хранилищам, а на мобильных страницах экономия по картинкам достигает 93%. Полные цифры — в таблицах ниже.
| Хранилище | До | После | Изменение |
|---|---|---|---|
| Статичные изображения сайта | 283,9 МБ | 74,5 МБ | −73,8% |
| Превью phpThumb (кэш «на лету») | 679 МБ | 273 МБ | −60% |
Итого по двум хранилищам: −615 МБ (209 + 406) при полностью обратимой замене.
| Страница | До | После | Изменение |
|---|---|---|---|
| Главная страница | 3,39 МБ | 1,14 МБ | −66% |
| /o-nas | 5,42 МБ | 0,38 МБ | −93% |
| /portfolio | 21,08 МБ | 4,40 МБ | −79% |
| /uslugi | 0,472 МБ | 0,061 МБ | −87% |
Desktop-балл вырос на всех без исключения проверенных страницах. Mobile-балл вырос на большинстве страниц; на самой тяжёлой по DOM странице (/portfolio) — минус 2 балла, что находится в пределах обычной погрешности измерения PageSpeed.
| Страница | Mobile: до → после | Δ Mobile | Desktop: до → после | Δ Desktop |
|---|---|---|---|---|
| Главная | 70 → 79 | +9 | 90 → 96 | +6 |
| /portfolio/sv-life-ru | 64 → 66 | +2 | 93 → 95 | +2 |
| /portfolio/smirnov-haus | 67 → 72 | +5 | 88 → 91 | +3 |
| /portfolio | 77 → 75 | −2 | 93 → 96 | +3 |
Почему это безопасно: оригиналы не тронуты — ни один исходный файл не удалён и не перезаписан; изменение обратимо в любой момент одним переключателем; для старых браузеров без поддержки WebP автоматически отдаётся оригинал; все страницы после внедрения отвечают 200, вёрстка и раскладка сайта остались целыми.
Ни один исходный файл не удалён и не перезаписан. WebP-версии — отдельные файлы рядом с оригиналами.
Отдача WebP включается и выключается одним переключателем — без правок вёрстки и без потери данных.
Если браузер не поддерживает WebP, автоматически отдаётся оригинальное изображение — разрывов показа нет.
Все страницы отвечают 200, вёрстка и раскладка сайта остались целыми — проверено после внедрения.
Хотите такой же результат для своего сайта? Проведём аудит веса изображений, покажем прогноз экономии и сроки — без риска для действующего сайта.
Такой же подход к WebP-оптимизации мы прогоняем и по другим проектам. Ниже — реальные кейсы с цифрами до/после по каждому сайту.