Grafika na stronę WWW — dlaczego WebP i SVG to nie moda, tylko wydajność
Grafika webowa to nie JPG wrzucony na stronę. Tłumaczę dlaczego WebP i SVG bezpośrednio wpływają na Google.
Grafika na stronie internetowej to nie dekoracja. To element infrastruktury technicznej, który bezpośrednio wpływa na prędkość ładowania, pozycję w Google i doświadczenie użytkownika. Wrzucenie JPG ze zdjęciem prosto z aparatu na stronę to jeden z najprostszych sposobów na sabotowanie własnego SEO i konwersji jednocześnie.
Core Web Vitals — dlaczego grafiki decydują o LCP i CLS
LCP (Largest Contentful Paint) mierzy czas do wyświetlenia największego elementu na stronie — najczęściej jest nim zdjęcie hero sekcji. Ciężki, nieoptymalizowany obrazek to bezpośredni powód słabego LCP. CLS (Cumulative Layout Shift) mierzy czy elementy strony skaczą podczas ładowania — grafika bez podanych wymiarów powoduje przesunięcia layoutu i karze za CLS. Google włączył Core Web Vitals jako czynnik rankingowy. Oznacza to że ciężkie grafiki to nie tylko problem techniczny, to problem SEO.
PNG vs WebP vs SVG — kiedy który format
- SVG — ikony, logotypy, ilustracje, wszystko co wektorowe. Nieskończona skalowalność, minimalny rozmiar pliku, animowalny przez CSS
- WebP — zdjęcia i grafiki rastrowe. Średnio 25-35% mniejszy plik niż JPEG przy tej samej jakości wizualnej. Obsługiwany przez wszystkie nowoczesne przeglądarki
- PNG — grafiki z przezroczystością gdy WebP nie jest opcją, ikony o małej liczbie kolorów, screenshoty UI. Większy niż WebP
- JPEG/JPG — legacy, dla starszych systemów lub gdy dostawca wymaga tego formatu. W nowych projektach zastępuję WebP
- AVIF — następca WebP, jeszcze mniejszy plik, coraz lepsza obsługa przeglądarek — wchodzi do standardu
Responsive — trzy breakpointy, które musisz znać
Każda grafika webowa powinna istnieć w trzech wariantach: 375px dla mobile (standardowy iPhone), 768px dla tabletu, 1440px dla desktop. To nie oznacza trzy osobne pliki do każdego obrazka — nowoczesny HTML obsługuje atrybut srcset, który pobiera właściwy rozmiar automatycznie. Grafika zaprojektowana tylko w 1440px i skalowana na mobile to stracony czas dewelopera i wolniejsza strona na telefonach, gdzie większość ruchu się dzieje.
Alt tagi — SEO i dostępność w jednym
Atrybut alt na obrazku to tekst alternatywny dla czytników ekranu (dostępność) i sygnał dla Google co przedstawia zdjęcie (SEO). Puste alt tagi to stracona szansa na indeksację obrazów i punkty minusowe w audycie dostępności. Dobry alt to konkretny opis: nie 'zdjęcie' ale 'projekt logo dla firmy budowlanej ABCD'. Dla grafik czysto dekoracyjnych alt powinien być pusty (alt pusty cudzysłów) — to sygnał dla czytnika żeby go pominął.
Handoff z Figmy — co powinien zawierać dla dewelopera
Pliki z Figmy przekazane deweloperowi powinny zawierać: eksporty w SVG dla grafik wektorowych, WebP lub PNG dla grafik rastrowych, nazwy plików opisowe i konsekwentne (np. hero-desktop.webp, hero-mobile.webp), wymiary każdego elementu z jednostkami, i stany hover jeśli grafika jest interaktywna. Dobry handoff to takie materiały, że deweloper nie musi mnie pytać o nic.
Kompresja lossless vs lossy — gdzie jest granica
Kompresja lossless (bezstratna) zachowuje każdy piksel — rozmiar pliku jest wyższy. Lossless stosuje się do grafik UI, ikon, i grafik gdzie piksel ma znaczenie. Kompresja lossy (stratna) usuwa część danych — plik jest mniejszy, ale przy agresywnych ustawieniach widać artefakty. Dla fotografii webowej jakość 80-85% w WebP jest punkrem równowagi: niewidoczna różnica dla oka, 60-70% mniejszy plik niż oryginał JPEG. Narzędzia: Squoosh.app do manualnej optymalizacji, Sharp lub Imagemin w procesie budowania.
Najczęstszy błąd — grafika ze środowiska druku wrzucona na stronę
Dostaję pliki od klientów i regularnie widzę TIFF 300dpi wrzucony na stronę, bo 'jest najlepsza jakość'. 300 dpi to standard drukarni — monitor wyświetla 72-96dpi. Ten sam TIFF po konwersji do WebP na 72dpi i kompresji 85% zajmuje 20 razy mniej miejsca i wygląda identycznie na ekranie. Odwrotna sytuacja też się zdarza: logo wyeksportowane jako PNG 200×60px wrzucone na stronę z expectowanym wymiarem 800×240px — rozciągnięte i pikselowane. Webowe formaty i wymiary to osobna specyfika, której nie da się zastąpić plikiem z druku.
