Велике зображення JPEG, PNG чи GIF без сучасної альтернативи

Чому це важливо

Посібник web.dev щодо Largest Contentful Paint серед способів скоротити час передавання ресурсів називає сучасні формати зображень і стиснення. Водночас він застерігає, що для більшості сайтів це не суттєве вузьке місце: коли рендеринг затримує інша робота, менший файл може не змінити Largest Contentful Paint.

Тому ця перевірка повідомляє про зафіксовані розмір і формат для перегляду. Вона не встановлює, що зображення є найбільшим елементом на будь-якій сторінці чи що інший формат змінив би досвід відвідувачів.

Що зробити

Відкрийте знахідку: у ній показано адресу зображення, формат, визначений за першими байтами файлу, отримані закодовані байти (точно або як нижню межу, якщо передавання було неповним), зафіксований бюджет, формат, повернутий на запит з узгодженням, і кожну прочитану сторінку, що його оголошує, зі станом кожного вбудовування.
Вирішіть, чи має це зображення бути таким великим у цьому форматі. Де доречний менший файл, опублікуйте версію WebP чи AVIF і оголосіть її для вбудовування в елементі picture, у якого source має type="image/webp" чи type="image/avif", або налаштуйте сервер повертати для цієї адреси сучасний формат, коли запит його приймає.
Або ж зменште файл до розміру бюджету чи менше, змінивши його розмір або стиснувши. Порівняйте результат на око: аудит не оцінює якості зображення.
Для GIF знахідка фіксує, скільки блоків зображення містить повний файл. Якщо ви знаєте, що зображення анімоване, варто розглянути відеофайл; сама лише кількість блоків не доводить анімації.
Виправте кожне відповідне вбудовування, а потім запустіть новий повний аудит.

Коли залишити як є: Зображення можна залишити як є, коли його розмір і формат навмисні, наприклад для детальної фотографії чи файлу, який інші системи мають отримувати у форматі JPEG чи PNG. Бюджет — це налаштування для перегляду, а не вимога.

Що ми читаємо

Ми читаємо початковий HTML кожної вибраної сторінки в тому вигляді, у якому його повернув сервер, без виконання JavaScript. Для кожного елемента img поза вмістом head, script, style, noscript і template ми беремо адреси в src і srcset разом з елементами source, що стоять перед ним як прямі дочірні елементи того самого picture. Зображення, задані в CSS чи додані скриптами, не читаються.

source з type="image/webp" чи type="image/avif", придатним srcset і без умови media вважається оголошеною сучасною альтернативою для цього одного вбудовування. Це оголошення, а не доказ доступності файлу. Для кандидатів srcset без типу формат визначається за зафіксованими байтами кожного кандидата; закінчення назви файлу ніколи не використовується.

Формат зображення визначається за першими байтами зафіксованого файлу: JPEG, PNG і GIF вважаються застарілими форматами, WebP і AVIF — сучасними. Його розмір — це закодовані байти тіла відповіді, виміряні нашим засобом зчитування; Content-Length і декодована довжина їх не замінюють. Враховується лише розмір понад бюджет, зафіксований із налаштуваннями аудиту, а аудит без зафіксованого бюджету не бере типового значення.

Для придатного зображення ми робимо ще один запит до тієї самої адреси з Accept: image/avif,image/webp і фіксуємо формат відповіді. Повна відповідь у сучасному форматі, що відповідає умовам, може показати, що це зображення для перевірки не потребує змін. Щоб повідомити про застаріле зображення, обидві відповіді мають відповідати умовам: HTTP 200, заголовки, що узгоджуються з байтами, і відсутність ознаки перевірки на бота в заголовках відповіді.

Одна знахідка охоплює одну адресу зображення разом із рядком запиту й перелічує сторінки, що його вбудовують. Сторінка вноситься до списку як уражена, лише коли її власне вбудовування підтверджено; інші сторінки, що оголошують ту саму адресу, лишаються в даних зі своїм станом.

Приклад і докази

Ілюстративний приклад — схематичні оголошення й зафіксовані лічильники, а не реальний аудит.

Дві сторінки сайту https://bakery.example/ вбудовують ту саму адресу зображення. Зафіксований бюджет — 102 400 байтів.

<!-- https://bakery.example/cakes/ -->
<img src="/img/cake.jpg" width="1600" height="900" alt="Lemon cake">

<!-- https://bakery.example/menu/ -->
<picture>
  <source type="image/webp" srcset="/img/cake.webp">
  <img src="/img/cake.jpg" width="1600" height="900" alt="Lemon cake">
</picture>

https://bakery.example/img/cake.jpg
Format from file bytes: JPEG
Encoded bytes received: 348160 (exact)
Recorded budget: 102400 bytes
Request with Accept: image/avif,image/webp returned: JPEG

Про адресу повідомляється для /cakes/, вбудовування якої не оголошує сучасної альтернативи. /menu/ оголошує джерело WebP для власного вбудовування, тож її зафіксовано як сторінку, що оголошує адресу, але не як уражену сторінку.

Можливе виправлення: оголосіть альтернативу WebP і на /cakes/ або зменште файл до розміру бюджету чи менше. Наступний повний аудит може закрити знахідку, коли повністю прочитає кожну зафіксовану сторінку, що оголошує адресу, і побачить, що кожне вбудовування чисте або видалене. Сторінка, яку він не може прочитати, залишає знахідку відкритою.

Підтвердити й перевірити знову

Перевірте самі: Відкрийте сторінку, що вбудовує зображення, з панеллю Network у браузері й зверніть увагу на переданий розмір і Content-Type відповіді із зображенням. Щоб повторити узгодження, запитайте адресу зображення клієнтом командного рядка із заголовком Accept: image/avif,image/webp, збережіть тіло й відкрийте його в редакторі зображень, щоб побачити формат. Браузер надсилає власне значення Accept, тож його результат може відрізнятися від зафіксованого запиту.

Повторна перевірка: Повний аудит — Запустіть новий повний аудит, коли зміна вже діятиме на сайті. Знахідка закривається, лише коли кожну збережену сторінку, що оголошує адресу, і кожну поточну можливу таку сторінку перевірено повністю, а початкове зображення в кожному вбудовуванні чисте або видалене. Непрочитана сторінка, неповний перелік зображень чи непевні дані про ресурс залишають знахідку відкритою. Для видалення вбудовування потрібен повний початковий HTML; зображення без типу, що лишилося, також потребує відповідних зафіксованих даних про відповідь і зафіксованого бюджету. Закрита знахідка повертається, лише коли пізніший аудит знову повідомляє про цю адресу зображення.

Обмеження та джерела

Це порівняння зафіксованих байтів із зафіксованим бюджетом. Ми не рендеримо сторінок, тож відображений розмір, джерело, яке вибрав би браузер, візуальна якість і час завантаження не вимірюються, а перевірка не визначає елемента Largest Contentful Paint.

Формат, визначений за першими байтами, не доводить, що весь файл — чинне зображення. Для GIF фіксується кількість блоків зображення в повному файлі; це не доводить анімації чи її тривалості.

Результат узгодження описує одну відповідь на один запит аудиту. Сервер, CDN чи кеш можуть відповідати іншим клієнтам інакше, а результат не показує, що сервер може робити загалом.

Читається лише початковий HTML. source з умовою media, некоректний srcset, img, який не вдається пов’язати з його picture, і HTML, обрізаний обмеженнями аудиту на читання, залишають вбудовування непідтвердженим, а не чистим.

Запити зображень і запити з узгодженням використовують спільні обмеження запитів аудиту, правила robots.txt і темп запитів. Неповне передавання чи збережений початок файлу можуть показати, що зображення перевищує бюджет, але не можуть довести, що воно менше за нього. Коли для рішення цієї перевірки потрібна відповідь, відсутній чи невдалий запит, відповідь із перевіркою на бота або заголовки, що не узгоджуються з байтами, залишають зображення непідтвердженим.

Жодної економії не обіцяється. Наскільки меншою буде версія WebP чи AVIF, залежить від зображення.

Упевненість: Висока Формат, кількість байтів і відповідь на узгодження зчитуються безпосередньо із зафіксованих відповідей, а оголошення — з початкового HTML. Чи важливе зображення для відвідувачів і чи краще обслуговував би їх інший формат — оцінка, якої аудит не робить.

Джерела

web.dev, Оптимізація Largest Contentful Paint — Пояснює скорочення розміру ресурсу LCP, зокрема через сучасні формати зображень і стиснення, як спосіб скоротити час передавання. Застерігає, що для більшості сайтів час передавання не є суттєвим вузьким місцем, і наводить приклад, де менше зображення не змінює LCP, бо рендеринг затримується. Не встановлює нашого бюджету в 100 KiB, процедури узгодження, тлумачення GIF чи будь-якої очікуваної економії. Перевірено 13 жовтня 2026.

Редакційна перевірка: 15 жовтня 2026