Коротка відповідь
Оптимізуйте зображення за роллю: hero потребує раннього виявлення, галерея — responsive-кандидатів, скриншот — читабельності. Резервуйте місце, описуйте фактичну ширину через sizes і перевіряйте завантажений файл на різних екранах. Зниження JPEG-якості не виправить завеликий кандидат чи пізнє виявлення hero.
Виміряйте запит і видиму якість до зміни форматів. Фото й скриншот із дрібними підписами по-різному переносять стиснення. Зберігайте оригінал для повторної генерації; повторне стиснення з втратами шкодить. Не заявляйте виміряне покращення без траси.
Практичні кроки реалізації
Узгодьте розміри з макетом
Визначте CSS-місце на mobile, tablet і desktop. Картка на половину області не має оголошувати повний viewport. Width і height дають пропорцію; fill потребує позиціонованого батька з геометрією. Свідомо вибирайте object-fit, щоб не обрізати потрібний UI.
Пріоритезуйте підтверджене критичне зображення
Знайдіть LCP маршруту до preload чи high fetch priority. Зображення галереї нижче згину зазвичай завантажуйте lazy. Preload багатьох ресурсів конкурує з hero і стилями. Next.js 16 має preload і поточне керування; звірте версію замість старих прикладів лише з priority.
Розділіть семантику й швидкість
Пишіть alt про видиму інформацію, не файл чи ключові слова. Декоративне має порожню альтернативу, коли сусідній текст дає зміст. Підпис може пояснити контекст. Оптимізація не виправдовує вилучення корисних скриншотів чи заміну читабельного тексту плямою.
Перевірте завантажений кандидат
Перевірте network і currentSrc за різних viewport та DPR. Порівняйте ширину, пікселі файлу, обсяг і кеш. Перевірте production-оптимізатор і remotePatterns зовнішніх ресурсів. Обмежте джерела потрібними host і шляхами, не довільними URL користувача.
Приклад реалізації
Приклад Next.js задає розміри для пропорції та sizes для обмеженої колонки. Замініть ресурс і розміри реальними. Галерея розширень портфоліо має подібну модель, а візуали проєктів — fill із контейнерами.
import Image from "next/image";
export function ProductScreenshot() {
return (
<Image
src="/screenshots/product-panel.png"
alt="Product panel showing saved items and export controls"
width={1280}
height={800}
sizes="(max-width: 820px) calc(100vw - 48px), 760px"
/>
);
}
Це скриншот нижче згину, тому без preload. Якщо ресурс стає hero, підтвердьте LCP і налаштуйте завантаження для контексту. Однаковий файл не означає однаковий пріоритет усіх показів.
Компроміси та альтернативи
Сучасні формати зменшують обсяг, але читабельність і прозорість можуть потребувати іншого кодування, ніж фото. Автоматична оптимізація додає шлях кешу й оптимізатора для перевірки. Статичні варіанти підходять контрольованим ресурсам. Вибирайте за байтами, якістю й експлуатацією.
Поширені помилки
- 100vw для вузької desktop-картки.
- Fill без сталого батька.
- Lazy loading підтвердженого hero LCP.
- Preload усієї галереї.
- Стиснення до нечитабельних підписів.
Контрольний список перед випуском
- Sizes відповідають CSS.
- Геометрія стала до load.
- Пріоритет відповідає трасі LCP.
- Mobile і високий DPR перевірено.
- Alt і підписи описують вміст.
- Скриншоти читабельні у своєму розмірі.
Поширені запитання
Чи width і height є розміром показу?
Вони задають внутрішні розміри й пропорцію; CSS визначає показ. Sizes має описувати це місце для вибору кандидата.
Чи всім потрібен найменший файл?
Використовуйте найменший файл, що зберігає призначення й розміри. Скриншот без видимих кнопок не виконує задачу попри малий обсяг.
Висновок
Спершу виправте розміри й виявлення, потім стиснення. Перевірте вибраний ресурс у production-подібному браузері, оцініть обсяг і читабельність. Результат — стабільне читабельне зображення потрібного розміру.
Первинні джерела
Пов’язані посібники та приклади
Потрібно реалізувати це у вашому продукті?
Перегляньте відповідні приклади продуктів або поділіться контекстом розробки вебзастосунку, розширення Chrome, API чи SaaS.