---
title: "JPEG XL w Google Grafika i Discover: nadal bez wsparcia"
description: "Chrome 155 i Firefox 158 włączyły JPEG XL, a John Mueller potwierdził, że Google Grafika i Discover go nie obsługują. Jak wdrożyć .jxl bez ryzyka dla SEO."
date: 2026-10-26
category: SEO
tags: ["SEO", "Obrazy", "Google Grafika", "Discover", "JPEG XL", "Core Web Vitals"]
url: https://uper.pl/blog/jpeg-xl-google-grafika-discover/
---

# Chrome i Firefox już czytają JPEG XL, Google Grafika jeszcze nie Co powiedział John Mueller i jak wdrażać pliki .jxl bez utraty widoczności obrazów

**W październiku 2026 JPEG XL dostał w ciągu jednego tygodnia to, na co czekał od lat: 6 października Chrome 155 włączył go domyślnie, 13 października zrobił to Firefox 158. Dziewięć dni po premierze Chrome John Mueller z Google przypomniał, że Google Grafika i podglądy w Discover tego formatu nie obsługują.** Jeśli planujesz podmienić obrazy na `.jxl`, bo przeglądarki wreszcie je czytają, to właśnie teraz łatwo zrobić sobie krzywdę w SEO. Poniżej zbieram, co dokładnie napisał Mueller, co mówi dokumentacja, jak po październikowych premierach wygląda stan w przeglądarkach i jak sam wdrażałbym ten format.

## Co napisał John Mueller

15 października 2026 Mueller napisał na Bluesky, że jeśli komuś zależy na pokazywaniu obrazów w Google Grafika i jako podglądów w Discover, to JPEG XL „nie jest obecnie obsługiwany”, i podlinkował dokumentację. Barry Schwartz opisał sprawę 23 października w Search Engine Roundtable i stamtąd rozeszła się po branży.

Dokumentacja Google Search Central jest tu jednoznaczna. Wyszukiwarka obsługuje obrazy wskazane w atrybucie `src` elementu `img` w formatach **BMP, GIF, JPEG, PNG, WebP, SVG i AVIF**, a rozszerzenie pliku powinno zgadzać się z jego typem. JPEG XL na tej liście nie ma i Mueller nie zapowiedział, że się pojawi.

Sam komunikat nie wnosi więc nic nowego, bo lista formatów wygląda tak od dawna. Nowy jest kontekst: format po raz pierwszy działa domyślnie w głównych przeglądarkach, więc za chwilę ktoś zacznie go wdrażać na produkcji i dopiero wtedy zderzy się z tą listą.

## Co zmieniło się w przeglądarkach w październiku 2026

Jeszcze wiosną tego roku dekoder JPEG XL w Chrome siedział za flagą, a w Firefoksie był dostępny tylko w kompilacjach Nightly. Wiele poradników w sieci, także tych pisanych w 2026 roku, nadal opisuje ten stan. Październik go zmienił:

| Przeglądarka | Stan obsługi JPEG XL | Od kiedy |
|---|---|---|
| Chrome 155 i przeglądarki na Chromium (np. Brave 1.97) | dekodowanie włączone domyślnie, dekoder jxl-rs napisany w Ruście | 6 października 2026 |
| Firefox 158 | włączone domyślnie | 13 października 2026 |
| Safari | obsługa od Safari 17; według serwisu Core Web Vitals częściowa, bez animacji i dekodowania progresywnego | 2023 |

We wpisie na blogu Chrome for Developers Google podaje, że JPEG XL kompresuje o 30-50% lepiej niż JPEG, obsługuje kompresję bezstratną i HDR oraz pozwala bezstratnie przekodować istniejące pliki JPEG. Druga część tego wpisu jest ciekawsza. Google zaleca testowanie zarówno AVIF, jak i JPEG XL, i spodziewa się, że nowy format najbardziej przyda się przy fotografii, wysokiej wierności i kompresji bezstratnej oraz tam, gdzie liczy się dekodowanie progresywne. Google traktuje więc JPEG XL jako dodatkową opcję do porównania, a nie następcę AVIF. Cały wpis dotyczy wyłącznie dekodowania.

Droga do tego momentu była długa. W 2022 roku Google usunął z Chrome eksperymentalne wsparcie, tłumacząc, że ekosystem nie wykazuje wystarczającego zainteresowania, a format nie daje dość korzyści względem istniejących, żeby włączać go domyślnie. W styczniu 2026 roku, jak relacjonował The Register, do kodu Chromium trafił dekoder jxl-rs, czyli implementacja w Ruście zamiast referencyjnego libjxl w C++. Dla Mozilli to był warunek: już w 2024 roku zespół Firefoksa mówił, że rozważy JPEG XL, gdy powstanie dekoder w Ruście, bo ma obawy o bezpieczeństwo około 100 tysięcy linii wielowątkowego kodu C++ w libjxl. Ten sam dekoder odblokował więc obie przeglądarki.

## Przeglądarka a wyszukiwarka to dwie różne sprawy

Najłatwiej pomylić właśnie te dwa poziomy. Przeglądarka decyduje, czy odwiedzający zobaczy obraz na Twojej stronie. Systemy indeksowania Google decydują, czy ten obraz trafi do Google Grafika, miniatur w wynikach i podglądów w Discover. Po październiku pierwszy warunek jest dla JPEG XL spełniony w trzech głównych silnikach, drugi nadal nie.

Dochodzi do tego trzeci poziom, o którym w dyskusji o Google łatwo zapomnieć: serwisy społecznościowe i komunikatory, które pobierają obraz Open Graph. Z mojego doświadczenia wymagają JPEG albo PNG i o JPEG XL nie słyszały. To moja praktyczna ocena, nie komunikat żadnej z tych firm, ale przy wdrożeniu liczy się tak samo jak lista Google.

## Jak to wpływa na SEO obrazów

Na audytach widzę, że strony tracą widoczność w grafice głównie przez jakość wdrożenia: brak tekstu alternatywnego, obrazy wstawiane skryptem po załadowaniu strony, miniatury bez podstrony, na której obraz miałby sensowny kontekst. Format rzadko bywa winowajcą, bo prawie wszyscy używają JPEG, PNG albo WebP. Przy JPEG XL stałby się nim od razu.

### Co ryzykujesz, podmieniając format

Jeśli obraz główny artykułu albo zdjęcie produktu będzie dostępne wyłącznie jako `.jxl`, Google nie daje żadnej gwarancji, że je wykorzysta. W praktyce oznacza to brak albo ograniczoną obecność w Google Grafika oraz słabszą kartę w Discover, gdzie duży obraz w dużym stopniu decyduje o klikalności. Do tego dochodzi opisany wyżej problem z Open Graph.

Osobna pułapka czeka na tych, którzy korzystają z CDN z automatyczną negocjacją formatu po nagłówku `Accept`. Taki serwer sam decyduje, co wysłać danemu klientowi, i nie wiadomo, jak zachowa się wobec robota Google, gdy do listy formatów trafi `image/jxl`. Zanim włączysz JPEG XL w takiej konfiguracji, sprawdź w logach, co dostaje Googlebot-Image.

### Bezpieczny wzorzec: element picture z fallbackiem

Jeśli chcesz testować JPEG XL już teraz, użyj elementu `picture`. Przeglądarka wybiera pierwszy `source`, który obsługuje, a `img` z formatem z listy Google jest zawsze ostatecznym wyjściem:

```html
<picture>
  <source srcset="zdjecie.jxl" type="image/jxl">
  <source srcset="zdjecie.avif" type="image/avif">
  <source srcset="zdjecie.webp" type="image/webp">
  <img src="zdjecie.jpg" alt="Opis obrazu" width="1200" height="800">
</picture>
```

Atrybut `src` w `img` powinien wskazywać format z listy Google. Dokumentacja mówi właśnie o obrazach z `src` elementu `img`, więc to tam ma stać plik, który ma trafić do indeksu. Nie traktuję tego jako potwierdzenia, że Google po prostu pominie `source` z JPEG XL, a sam wpis Google o Chrome 155 nie zawiera żadnych wskazówek o `picture` ani fallbackach. To jednak najbezpieczniejsze ułożenie, jakie znam.

### Co zamiast tego poprawi wyniki

Jeśli celem jest szybsze ładowanie, a nie sam format, masz obsługiwane rozwiązania pod ręką. **AVIF** i **WebP** zwykle dają duże oszczędności względem JPEG i oba są na liście Google. Wpływ na [LCP](/blog/lcp-optimization-guide/) i na [Core Web Vitals](/blog/core-web-vitals/) w ogóle zależy bardziej od poprawnych wymiarów, priorytetu ładowania obrazu głównego i braku lazy loadingu na elemencie LCP niż od zmiany formatu. O tym, jak obrazy działają w wyszukiwaniach wizualnych, piszę szerzej w tekście o [optymalizacji treści pod kątem wyszukiwań wizualnych](/blog/optymalizacja-tresci-pod-katem-wyszukiwan-wizualnych/).

## Czego nie wiadomo

Glenn Gabe zauważył 23 października 2026 roku, że w Google Grafika widać zaindeksowane pliki `.jxl`, a zapytanie o typ pliku zwraca je razem z innymi formatami. Ciekawa obserwacja, ale słowom Muellera nie przeczy, bo obecność w indeksie nie oznacza oficjalnego wsparcia, stabilnego zachowania ani obecności w Discover. Nie wiadomo też, czy to efekt uboczny, test, czy pojedyncze przypadki.

Nie ma też żadnej informacji, czy i kiedy Google dopisze JPEG XL do dokumentacji. Skoro ta sama firma wydaje dekoder w Chrome i chwali format na własnym blogu, zgaduję, że to kwestia czasu, ale to tylko moje przypuszczenie. Planowanie wdrożenia na jego podstawie byłoby zgadywaniem za cudze pieniądze.

## Podsumowanie

JPEG XL po październiku 2026 ma wreszcie przeglądarki po swojej stronie, ale dla widoczności obrazów w Google nadal nie jest bezpieczny. Dokumentacja wymienia BMP, GIF, JPEG, PNG, WebP, SVG i AVIF, a Mueller potwierdził, że to aktualny stan. Jeśli eksperymentujesz z `.jxl`, rób to w elemencie `picture`, w `src` elementu `img` zostaw format z listy Google, a przy CDN z negocjacją formatu sprawdź, co dostaje robot. Po wdrożeniu obserwuj w Search Console raport wydajności z filtrem na typ wyszukiwania „Grafika”, bo tam najszybciej zobaczysz, czy coś się posypało.

<FaqBlog
  questions={[
    {
      question: 'Czy Google Grafika obsługuje JPEG XL?',
      answer: 'Nie. Dokumentacja Google wymienia BMP, GIF, JPEG, PNG, WebP, SVG i AVIF, a John Mueller potwierdził 15 października 2026, że JPEG XL nie jest obecnie obsługiwany.'
    },
    {
      question: 'Czy obrazy JPEG XL pojawią się w Google Discover?',
      answer: 'Mueller zaznaczył, że JPEG XL nie jest obsługiwany także dla podglądów w Discover. Jeśli zależy Ci na Discover, obraz główny trzymaj w JPEG, PNG, WebP albo AVIF.'
    },
    {
      question: 'Które przeglądarki obsługują JPEG XL?',
      answer: 'Chrome od wersji 155 (6 października 2026) i Firefox od wersji 158 (13 października 2026) dekodują JPEG XL domyślnie. Safari obsługuje format od wersji 17, według serwisu Core Web Vitals bez animacji i dekodowania progresywnego.'
    },
    {
      question: 'Czy warto przechodzić na JPEG XL dla szybszego ładowania strony?',
      answer: 'Na dziś bezpieczniej wybrać AVIF lub WebP, które Google obsługuje w wyszukiwarce. Sam Google radzi porównać AVIF i JPEG XL na własnych obrazach. JPEG XL testuj z fallbackiem w elemencie <code>picture</code> i obrazem w obsługiwanym formacie w <code>img</code>.'
    },
    {
      question: 'Skoro w Google Grafika widać pliki .jxl, to znaczy, że format działa?',
      answer: 'Nie. Glenn Gabe zauważył zaindeksowane pliki .jxl, ale oficjalna dokumentacja ich nie wymienia. Obecność w indeksie nie jest gwarancją wsparcia.'
    }
  ]}
  heading="Często zadawane pytania"
  id="faq"
/>

## Źródła
