Картинка завширшки 1920 пікселів на сторінці завантажується повністю й у власників телефонів, а на екрані стискається до 390 пікселів — у п'ять разів більше трафіку й повільніше завантаження без жодної користі. srcset дає змогу браузерові обрати версію під екран, але лише за умови, що ці версії ви підготували.
Чому однієї картинки замало
Показник LCP у Core Web Vitals — це, як правило, велике зображення на першому екрані. Якщо віддати телефону файл завширшки 1920 і вагою 400 КБ, LCP рідко вкладається у 2,5 секунди; версія завширшки 480 і вагою 40 КБ тим самим каналом вантажиться на порядок швидше. Сигнал Google про якість сторінки зчитує це число напряму.
З іншого боку, картинка завширшки 768 на великому десктопному моніторі виглядає м'якою. Звідси й кілька розмірів, з яких обирає сам браузер.
Практична таблиця брейкпоінтів
Орієнтиром править ширина, з якою зображення виводиться на сторінці, а не вікно перегляду. Для двох найчастіших випадків — банерів на всю ширину та ілюстрацій у статті:
- Зображення на всю ширину (головний блок, банери): 480, 768, 1200, 1920. Телефон, планшет, ноутбук, великий монітор.
- Ілюстрації в статті (колонка контенту до 800): 400, 800, 1200; версія 1200 обслуговує екрани 1,5x–2x.
- Мініатюри та картки (виводяться завширшки близько 300): 300 і 600.
Більше щаблів — не означає краще. Кожен — це ще один експорт і ще один файл на зберігання, а браузери прощають неточне влучання, тому оптимальний крок у 1,5–2 рази. Чотири щаблі закривають понад дев'ять із десяти комбінацій пристроїв.
Чи потрібні версії 2x
Retina і більшість телефонних екранів працюють зі щільністю 2x–3x: щоб картинка завширшки 400 виглядала чітко, потрібно 800 пікселів. Великі щаблі з таблиці вже відіграють роль версій 2x для дрібніших — 768 це 2x для телефона завширшки 390, а 1200 — 2x для колонки завширшки 600.
Тож окремий набір «@2x» не потрібен. Дотримуйте між щаблями крок приблизно вдвічі, і браузер сам обере більшу версію за щільністю.
Формат: спершу WebP, JPG про запас
За однакової якості WebP на 25–35 % легший за JPG, і його підтримують усі сучасні браузери. Експортуйте WebP для кожного розміру й залиште запасний JPG через елемент picture для старих браузерів; якщо для вашої аудиторії браузери до 2020 року вже не важливі, досить самого WebP.
AVIF важить ще менше, але кодується в браузері помітно довше, а на великих пачках це відчутно. Усі компроміси докладно розібрано в матеріалі AVIF, WebP чи JPEG.
Пакетний експорт усього набору
Завантажте вихідні файли в інструмент Пакетна обробка зображень і робіть по одному запуску на кожен щабель, змінюючи ширину та суфікс:
- Розмір: ширина 480, «Збільшувати малі зображення» вимкнено, результат WebP із якістю 80 %, суфікс -480.
- Ті самі налаштування для 768 із суфіксом -768; потім 1200; потім 1920.
- Для запасного JPG переключіть результат на JPG, суфікси залиште й запустіть ще раз.
Кожен запуск займає секунди, і в ZIP уже лежать hero-480.webp, hero-768.webp і так далі — лишається покласти їх у теку із зображеннями. Не вмикайте збільшення, щоб оригінал у 1000 пікселів не розтягнувся до 1920.
Щоб побачити різницю у вазі за щаблями на одному зображенні, відкрийте один файл в інструменті Зміна розміру зображення.
Пишемо HTML
Для зображення на всю ширину:
<img src="hero-1200.jpg"
srcset="hero-480.webp 480w, hero-768.webp 768w, hero-1200.webp 1200w, hero-1920.webp 1920w"
sizes="100vw" width="1920" height="1080" alt="...">Для ілюстрацій у статті задавайте sizes за реальною шириною, наприклад sizes="(max-width: 840px) 100vw, 800px". Завжди вказуйте width і height: тоді браузер заздалегідь резервує місце, і сторінка не «стрибає».
Коли це зроблено, додайте поради щодо відкладеного завантаження та стиснення з матеріалу як пришвидшити завантаження зображень — і та частина оцінки продуктивності, що стосується картинок, практично вибрана повністю.