Зображення і швидкість: формати, розміри, lazy loading

Чому зображення визначають час завантаження

Google пише, що зображення часто становлять найбільшу частку загального розміру сторінки, через що сторінки можуть завантажуватися повільно й дорого. Два з Core Web Vitals безпосередньо залежать від зображень. Largest Contentful Paint (LCP) вимірює завантаження: Google радить, щоб найбільший елемент з’являвся протягом перших 2,5 секунди після початку завантаження сторінки. На багатьох сторінках цей елемент – зображення, наприклад велике фото вгорі. Cumulative Layout Shift (CLS) вимірює візуальну стабільність і має залишатися нижче 0,1. Зображення, які надходять без зарезервованого місця, зсувають текст униз і підвищують це значення.

Правильний формат

• Фото: JPEG працює всюди. WebP і AVIF часто помітно менші за схожої якості.
• Графіка з різкими краями чи прозорістю: PNG або WebP і AVIF, які також можуть бути прозорими.
• Логотипи й значки: SVG, бо він залишається різким за будь-якого розміру й зазвичай дуже малий.
• Google Пошук підтримує зображення в атрибуті src у форматах BMP, GIF, JPEG, PNG, WebP, SVG і AVIF.

Якщо ти пропонуєш WebP чи AVIF, можна залишити JPEG як резервний варіант в елементі picture. Браузер вибирає перше джерело, яке розуміє.

Правильний розмір

Зображення шириною 2400 пікселів, яке показується на 600 пікселів, марнує більшість своїх байтів. Експортуй зображення приблизно в тій ширині, в якій вони показуються, а для екранів із високою щільністю пікселів – приблизно вдвічі ширшими. Потім стисни їх. У багатьох графічних програмах для фото в інтернеті достатньо налаштування якості десь посередині шкали. Перевір результат у повному розмірі, перш ніж замінювати оригінал.

srcset і sizes

Один файл ніколи не пасує до кожного екрана. Через srcset ти пропонуєш кілька файлів того самого зображення й зазначаєш ширину кожного. Через sizes ти повідомляєш браузеру, якої ширини буде показане зображення. Тоді браузер вибирає найменший файл, який достатньо різкий.

<img src="/img/sofa-800.jpg"
     srcset="/img/sofa-400.jpg 400w, /img/sofa-800.jpg 800w, /img/sofa-1600.jpg 1600w"
     sizes="(max-width: 700px) 100vw, 700px"
     width="800" height="533"
     alt="…">

У цьому прикладі зображення заповнює екран на вузьких екранах і має ширину 700 пікселів на ширших. Google радить завжди залишати резервний варіант в атрибуті src. Замість трьох крапок напиши справжній альтернативний текст.

width і height проти зсувів макета

Без width і height браузер не знає, скільки місця потрібно зображенню, доки файл не надійде. Тоді текст під ним стрибає вниз. Посібник web.dev про зсуви макета радить: завжди додавай атрибути width і height до зображень і відеоелементів, із розміром файлу в пікселях або принаймні з правильним співвідношенням сторін. Сучасні браузери з цих значень задають стандартне співвідношення сторін зображення й резервують місце. У CSS width: 100% і height: auto зберігають гнучкість зображення. Якщо ти не можеш задати атрибути, посібник називає альтернативою CSS-властивість aspect-ratio.

Відкладене завантаження

З loading="lazy" браузер завантажує зображення лише тоді, коли воно наближається до видимої області. Це заощаджує дані для зображень нижче на сторінці. Google каже про відкладене завантаження (lazy loading): не додавай його до вмісту, який, імовірно, буде видно одразу, коли користувач відкриває сторінку. Вбудоване відкладене завантаження браузера доступне для зображень та iframe.

Зображення LCP

Найбільше зображення вгорі, часто головне зображення (hero) або основне фото товару, є найважливішим файлом сторінки. Посібник web.dev про LCP каже: ніколи не завантажуй зображення LCP відкладено. fetchpriority="high" – це підказка браузеру завантажити його рано. Згідно з посібником, високий пріоритет для більш ніж одного-двох зображень уже не допомагає. Зображення, адресу яких скриптова бібліотека ховає в data-src або які є лише фоном CSS, браузер знаходить пізно. Для фонового зображення посібник називає попереднє завантаження через link rel="preload" у HTML. AVIF чи WebP і менший файл також скорочують час завантаження.

Щоб побачити, як працюють твої сторінки, Google відсилає до звіту Core Web Vitals у Search Console. Для окремої сторінки інструменти продуктивності твого браузера показують, який елемент є елементом LCP і які елементи зсувають макет. Вимірюй до і після зміни, щоб знати, чи вона допомогла.

Короткий чекліст

• Найбільше зображення вгорі завантажується звичайно, а не відкладено?
• Чи має кожен img width і height або місце, зарезервоване через aspect-ratio?
• Чи кожен файл приблизно такої ширини, як показується, і чи стиснутий він?
• Чи великі фото мають кілька ширин через srcset і sizes?
• Чи є файли JPEG чи PNG, які могли б бути WebP чи AVIF?

Робота з Do4U

Перевірка зображень читає одну сторінку й кожне зображення на ній. Для кожного файлу вона повідомляє формат, розмір файлу й пікселі, а з HTML – width і height, loading, fetchpriority, srcset і sizes, джерела в picture та фонові зображення в атрибутах style. Do4U припускає ймовірне зображення LCP за HTML. Він його не вимірює, бо справжній елемент LCP визначає браузер. Ти отримуєш таблицю зображень зі знахідками, загальною вагою й коротким підсумком. Зображення, які вставляє JavaScript, і фонові зображення із зовнішніх файлів CSS не враховуються. ШІ не використовується, перевірка безкоштовна, з денним лімітом.

Do4U знаходить підказки, а ти перевіряєш і вирішуєш. Підтвердь елемент LCP інструментами продуктивності свого браузера, перш ніж змінювати сторінку.