Google Images і Discover поки не підтримують JPEG XL для прев’ю
Google Images і Discover поки не використовують JPEG XL для зображень і прев’ю, попри підтримку формату в Chrome і Firefox. Для пошуку варто залишити резервний файл у підтримуваному форматі.
Google Images і Discover поки не підтримують JPEG XL для показу зображень і прев’ю, повідомив представник Google Search Джон Мюллер 15 жовтня 2026 року. Як пише Search Engine Journal, роз’яснення з’явилося невдовзі після додавання підтримки формату в Chrome і Firefox. Для сайту це суттєва різниця: браузер може відкрити .jxl, але цього недостатньо, щоб розраховувати на показ файлу в пошуку зображень або рекомендаціях Google.
Браузери вже підтримують формат, пошук — поки ні
JPEG XL з’явився в Chrome 155, широке впровадження якого Google розпочав 6 жовтня після обмеженого випуску 23 вересня. Firefox додав підтримку у версії 158 від 13 жовтня, Safari — ще у версії 17 у 2023 році. Водночас webstatus.dev оцінює доступність формату як обмежену; випуск Edge з його підтримкою в цьому трекері не зазначений.
За оцінкою команди Chrome, JPEG XL забезпечує на 30–50% краще стиснення, ніж JPEG, підтримує стиснення без втрат і HDR. Розробники радять тестувати його поряд з AVIF і вважають особливо корисним для фотографій, де важливі висока точність зображення або стиснення без втрат. Але можливості формату й підтримка браузерів не означають, що Google використовує файли .jxl для прев’ю.
У документації Google Search перелічено формати, які пошук підтримує в атрибуті src елемента img: BMP, GIF, JPEG, PNG, WebP, SVG та AVIF. JPEG XL серед них немає. Ті самі сім форматів наведено у списку типів зображень, що індексуються. Станом на 20 жовтня в журналі змін документації Search Central не було повідомлення про додавання JPEG XL.
Як зберегти зображення для пошуку й Discover
Мюллер пояснив, що JPEG XL можна пропонувати браузеру через елемент picture, залишивши всередині звичайний img. Тоді .jxl буде одним із джерел зображення, а в src елемента img можна вказати файл у форматі, який підтримує Google, наприклад JPEG, WebP або AVIF. За словами Мюллера, така схема має працювати для пошукових систем: вони можуть прочитати img.
Це узгоджується з документацією Google: пошук може знайти зображення за src елемента img, навіть якщо той міститься всередині picture. Google радить залишати резервну адресу в src, оскільки деякі браузери й пошукові роботи не підтримують picture або srcset чи не можуть їх прочитати. Так можна випробовувати новий формат, не роблячи його єдиним доступним варіантом зображення.
Для великих зображень у прев’ю Discover є окремі рекомендації. Адресу можна вказати через розмітку schema.org або метатег og:image; ці дані можуть впливати на вибір прев’ю в Discover. Якщо посилання ведуть на .jxl, резервний img на сторінці сам собою їх не замінить. Для таких адрес доцільно вибирати формат зі списку, наведеного в документації пошуку.
Мюллер не назвав термінів появи підтримки JPEG XL у Google Images і Discover. Історія AVIF показує, що браузер і пошук можуть отримати підтримку з великим проміжком часу: Chrome додав AVIF у серпні 2020 року, а Google оголосив про його підтримку в Search 30 серпня 2024 року. Це не прогноз для JPEG XL, а причина стежити за документацією пошуку окремо від випусків браузерів.
Що це означає для власників сайтів
Якщо сайт розраховує на Google Images або прев’ю в Discover, переводити весь каталог лише у .jxl поки зарано. Перевірка того, як фотографії виглядають у Chrome і Firefox, не дає відповіді на запитання, яке зображення зможе використати Google. Під час впровадження нового формату важливо оцінювати і сторінку, і адреси зображень, які передаються для прев’ю.
Для магазину це не абстрактна технічна різниця. Покупець може вперше побачити фотографію товару ще до переходу на сайт, а потім порівняти його з іншими пропозиціями. Тому рішення щодо формату варто ухвалювати з огляду не лише на якість і розмір файлу, а й на канали, у яких магазин хоче показувати свої товари.
Моя думка: не варто робити ставку лише на один формат
Я переношу каталог магазину товарів для дому з таблиць до CMS, тому сприймаю цю новину як питання організації каталогу, а не лише швидкості завантаження. Мені цікаво спробувати JPEG XL для фотографій: коли покупець порівнює невеликі предмети, деталі мають значення. Але я б не хотів, щоб команда завантажила новий формат для всього асортименту, а потім виявила, що для потрібних нам прев’ю не залишилося відповідних зображень.
Я б одразу передбачив резервний формат у процесі роботи з фотографіями. Тоді можна пробувати нове, не ставлячи видимість товарів у залежність від одного технічного рішення. Пошук не зникає: змінюються способи, якими людина вперше знайомиться з товаром і отримує відповідь. Для невеликого магазину можливість спокійно тестувати формат і зберігати звичні канали важливіша за саму лише обіцянку кращого стиснення.
Джерела
Звідки новина. Текст — переказ своїми словами, факти — з джерела, думка — автора.
- Google Images & Discover Previews Don’t Support JPEG XL via @sejournal, @MattGSouthern www.searchenginejournal.com
- JPEG XL Image Format Not Supported By Google Images & Google Discover www.seroundtable.com
власник магазину товарів для дому
Розвиваю на Кіпрі магазин невеликих товарів для дому й нарешті переношу каталог із таблиць у повноцінну CMS. Хочу поєднати контент, пошук і продажі так, щоб команда могла запускати ідеї без тижнів очікування на розробника.
Усі публікації автораСхожі статті
Chrome додає підтримку JPEG XL починаючи з версії 155
Починаючи з Chrome 155 браузер зможе відкривати зображення JPEG XL. Власникам сайтів радять порівняти формат з AVIF і врахувати підтримку в браузерах, перш ніж змінювати формат файлів.
Microsoft Edge 155: підтримка декодування JPEG XL
Microsoft випустила Edge 155 для Windows, macOS і Linux. Браузер отримав підтримку декодування JPEG XL, а обробники `unload` тепер за замовчуванням не запускаються.
Google додав до настанов щодо спаму пораду про індексацію сторінок для обміну посиланнями
Google оновив настанови щодо спаму й пояснив, як керувати індексацією сторінок для обміну посиланнями, спільної роботи та онлайн-інструментів. Якщо сторінку не мають знаходити через пошук, радить використовувати noindex.
Обговорення 4
Лена Зайдель
тут важливий нюанс: резервний формат має бути доступний Googlebot, а не лише підставлятися браузеру через <picture> — пошуковик може забрати саме URL із src. тож перевірте, який файл реально віддається в HTML і чи він не закритий від сканування; магія responsive-картинок іноді закінчується на рівні браузера.
Яніс із Риги
@lena.such, правильно понимаю, что для JPEG XL надёжный вариант — оставить обычный JPEG в `src`, а JXL отдавать через `picture` для браузеров, которые его понимают? Не хочется потом выяснить, что каталог красиво ужался на 30–50%, а Google Images видит только пустое место.
Костас Марку Автор публікації
Так, для каталогу я б залишив звичайний JPEG у `src`, а JXL віддавав через `<picture>` як додатковий варіант для браузерів із підтримкою. Тоді Googlebot має доступний файл за основним URL, а ми можемо окремо поміряти економію ваги для покупців — без ризику, що прев’ю в Images стане порожнім. І ще перевірте, щоб JPEG не був закритий у robots.txt чи від авторизації: тут дешевше перестрахуватись, ніж потім переробляти весь каталог 🙂
Ніколай Петров
@janisbiz Для каталогу це найменш ризикова схема: JPEG у `src`, JXL — як альтернативу для сумісних браузерів. Перед запуском перевірте HTML саме на мобільній сторінці й доступність JPEG для Googlebot; окремо варто оцінити, чи економія на зберіганні виправдовує підтримку двох форматів.