Obrázky pro Web: WebP vs AVIF, Lazy Loading a Responzivní Techniky

Minulý měsíc jsem auditovala e-shop s nábytkem. Homepage měla 14 MB. Čtrnáct megabajtů dat, která si každý návštěvník musel stáhnout, než viděl první produktovou fotku.

Na rychlém optickém připojení to trvalo 8 sekund. Na mobilních datech? Zákazníci odcházeli dřív, než se stránka načetla.

Po optimalizaci obrázků: 1.8 MB, načítání 1.9 sekundy, konverze +12 %.

Jeden jediný problém — neoptimalizované obrázky — stál klienta stovky tisíc korun ročně.

V tomto článku vám ukážu vše, co za roky v SEO vím o optimalizaci obrázků. Od výběru správného formátu přes líné načítání (lazy loading) až po responzivní techniky pro všechna zařízení.

Proč Obrázky Brzdí Většinu Webů

Statistiky - kolik obrázky skutečně zabírají

HTTP Archive sleduje miliony webů a pravidelně zveřejňuje statistiky. Čísla jsou jednoznačná:

• Průměrná webová stránka má 2.5 MB
• Obrázky tvoří 60-70 % celkové velikosti
• Medián má 900 KB jen v obrázcích

U e-shopů je situace ještě horší. Každý produkt má několik fotek. Kategorie zobrazuje desítky náhledů. A majitelé webů nahrávají fotky přímo z fotoaparátu bez jakékoliv komprese.

Dopad na LCP a celkovou rychlost

LCP (Largest Contentful Paint) je metrika, která měří, kdy se zobrazí největší viditelný prvek na stránce. V 80 % případů je tím prvkem obrázek — Hero banner, produktová fotka nebo hlavní ilustrace.

Když má váš Hero obrázek 2 MB místo optimálních 100 KB, Google vám to spočítá:

Core Web Vitals jsou ranking faktorem od roku 2021. Pomalé LCP = horší pozice ve vyhledávání.

SEO hodnota optimalizovaných obrázků

Rychlost není jediný důvod pro optimalizaci. Obrázky mají přímý SEO potenciál:

1. Google Images zpracovává 10 % všech vyhledávání
2. Google Lens roste — lidé fotí produkty a hledají, kde je koupit
3. AI přehledy v Google zobrazují obrázky jako součást odpovědí

Správně optimalizovaný obrázek s popisným názvem souboru a alt textem může přivést stovky návštěvníků měsíčně.

Porovnání Formátů: JPEG vs WebP vs AVIF

JPEG - kdy ho ještě použít

JPEG má 30 let. Je to dinosaurus mezi formáty, ale stále žije.

Kdy má JPEG smysl:

• Jako fallback pro staré prohlížeče (méně než 3 % uživatelů)
• Když potřebujete garantovanou kompatibilitu všude
• Pro archivaci původních fotografií (ne pro web)

Kdy JPEG nepoužívat:

• Jako primární formát pro web v roce 2026
• Pro grafiku s textem nebo ostrými hranami
• Když vám záleží na rychlosti

WebP - zlatý standard 2026

WebP vyvinul Google v roce 2010. Dnes ho podporuje 97 % prohlížečů včetně Safari (od verze 14).

Výhody WebP:

• 30-35 % menší než JPEG při stejné kvalitě
• Podporuje průhlednost (jako PNG)
• Podporuje animace (jako GIF, ale menší)
• Nativní podpora ve WordPressu, Shoptetu, Next.js SEO

Praktický příklad: Produktová fotka sedačky:

• JPEG (kvalita 85): 420 KB
• WebP (kvalita 85): 280 KB
• Úspora: 140 KB na jeden obrázek

Při 50 produktových fotkách na stránce: 7 MB úspora.

AVIF - budoucnost (podpora a omezení)

AVIF je nejmladší formát (2019). Vyvinul ho Netflix pro streamování videa, ale skvěle funguje i pro statické obrázky.

Výhody AVIF:

• 50 % menší než JPEG
• 20 % menší než WebP
• Lepší podání barev (HDR, wide gamut)
• Ostrější hrany bez artefaktů

Nevýhody AVIF:

• Pomalejší enkódování (problém při real-time konverzi)
• Podpora prohlížečů: 94 % (Safari od 16.0, Edge od verze 121)
• Některé CMS ho ještě nepodporují nativně

Kdy použít AVIF:

• Pro Hero obrázky (málo souborů, velký vizuální dopad)
• Když používáte Image CDN s automatickou konverzí
• Pro fotograficky náročné weby (portfolia, e-shopy s módou)

Srovnávací tabulka kvality vs velikosti

Testovala jsem stejnou produktovou fotografii (původně 4000x3000 px JPEG, 4.2 MB):

Doporučení: AVIF jako primární, WebP jako fallback, JPEG pro extrémní případy.

Implementace Picture Element

Základní syntax s fallbackem

Element <picture> umožňuje servírovat různé formáty různým prohlížečům. Prohlížeč si vybere první formát, který podporuje.

<picture>
  <source srcset="produkt.avif" type="image/avif">
  <source srcset="produkt.webp" type="image/webp">
  <img src="produkt.jpg" alt="Kožená sedačka Chester v hnědé barvě"
       width="800" height="600">
</picture>

Prohlížeč Chrome 2026 stáhne AVIF. Safari 15 (starší iPhone) stáhne WebP. Internet Explorer (ano, někde ještě běží) stáhne JPEG.

Art direction pro různá zařízení

Art direction znamená zobrazit jiný obrázek na různých zařízeních. Ne jen zmenšený, ale jinak oříznutý.

Příklad: Hero banner má na desktopu široký záběr na celou sedačku. Na mobilu chcete detail na texturu kůže.

<picture>
  <source media="(max-width: 768px)"
          srcset="hero-mobile.avif" type="image/avif">
  <source media="(max-width: 768px)"
          srcset="hero-mobile.webp" type="image/webp">

  <source srcset="hero-desktop.avif" type="image/avif">
  <source srcset="hero-desktop.webp" type="image/webp">

  <img src="hero-desktop.jpg" alt="Showroom s koženými sedačkami"
       width="1920" height="800">
</picture>

Srcset a sizes - správné hodnoty

Atribut srcset říká prohlížeči: "Tady máš různé velikosti stejného obrázku, vyber si podle displeje."

<img src="sedacka-800.jpg"
     srcset="sedacka-400.jpg 400w,
             sedacka-800.jpg 800w,
             sedacka-1200.jpg 1200w,
             sedacka-1600.jpg 1600w"
     sizes="(max-width: 600px) 100vw,
            (max-width: 1200px) 50vw,
            800px"
     alt="Rohová sedačka v obývacím pokoji">

Co to znamená:

• 400w = obrázek má 400 px šířky
• sizes říká prohlížeči, jak velký bude obrázek na stránce
• Na mobilu (do 600px) zabírá celou šířku (100vw)
• Na tabletu (do 1200px) zabírá polovinu (50vw)
• Na desktopu má fixních 800px

Prohlížeč pak počítá: "Na Retina displeji mobilu (2x DPR) s šířkou 390px potřebuji obrázek 780px. Stáhnu tedy sedacka-800.jpg."

Líné načítání (lazy loading) - správná implementace

Nativní líné načítání (loading="lazy")

Všechny moderní prohlížeče podporují nativní líné načítání. Stačí přidat jeden atribut:

<img src="produkt.webp"
     loading="lazy"
     width="400" height="300"
     alt="Jídelní stůl z dubového masivu">

Prohlížeč automaticky odloží načítání obrázků, které jsou mimo viewport (viditelnou oblast). Když uživatel scrolluje dolů, obrázky se začnou načítat těsně před tím, než je uvidí.

Důležité: Vždy uvádějte width a height. Bez rozměrů prohlížeč neví, kolik místa obrázek zabere, a dochází k CLS (posouvání obsahu).

Kdy NEPOUŽÍT líné načítání (above the fold)

Líné načítání na obrázcích "above the fold" (viditelných bez scrollování) zpomaluje LCP.

Proč? Prohlížeč nejdřív vykreslí stránku, pak teprve začne řešit lazy obrázky. Hero banner se načte až sekundu po zbytku stránky.

Pravidlo: První 1-3 obrázky na stránce (Hero, logo, hlavní produktová fotka) nikdy s líným načítáním.

Loading="eager" a fetchpriority="high"

Pro kritické obrázky použijte opačný přístup — řekněte prohlížeči, ať je načte přednostně:

<img src="hero.avif"
     loading="eager"
     fetchpriority="high"
     width="1920" height="800"
     alt="Hlavní banner e-shopu">

Co to dělá:

• loading="eager" — načti okamžitě, nečekej
• fetchpriority="high" — dej tomuto obrázku přednost před ostatními resources

Kombinace těchto atributů může zlepšit LCP o 200-500 ms.

Intersection Observer pro pokročilé

Pokud potřebujete větší kontrolu (třeba animaci při načtení), použijte JavaScript s Intersection Observer:

// Sleduj obrázky s třídou .lazy
const lazyImages = document.querySelectorAll('img.lazy');

const imageObserver = new IntersectionObserver((entries) => {
  entries.forEach(entry => {
    if (entry.isIntersecting) {
      const img = entry.target;
      img.src = img.dataset.src;
      img.classList.remove('lazy');
      imageObserver.unobserve(img);
    }
  });
}, {
  rootMargin: '200px' // Načti 200px před zobrazením
});

lazyImages.forEach(img => imageObserver.observe(img));

Pro většinu webů je ale nativní líné načítání (loading="lazy") dostatečné.

Automatizace a Nástroje

Squoosh pro ruční optimalizaci

Squoosh.app je bezplatný nástroj od Google pro ruční kompresi obrázků.

Kdy použít Squoosh:

• Optimalizace Hero obrázků (důležité, optimalizujete jednou)
• Porovnání formátů (AVIF vs WebP)
• Experimentování s kvalitou komprese

Postup:

1. Nahrajte obrázek
2. Vlevo originál, vpravo komprimovaný
3. Zvolte formát (WebP/AVIF)
4. Posuňte kvalitu (doporučuji 75-85)
5. Porovnejte vizuálně
6. Stáhněte

ShortPixel/Imagify pro WordPress

Pro WordPress existuje spousta pluginů. Po letech testování doporučuji dva:

ShortPixel:

• Automatická komprese při nahrání
• Konverze do WebP a AVIF
• 100 obrázků měsíčně zdarma
• Cena: od 4 USD/měsíc

Imagify:

• Od tvůrců WP Rocket
• Skvělá integrace s jejich cache pluginem
• Jednodušší rozhraní
• Cena: od 5 USD/měsíc

Nastavení pro oba:

1. Agresivní komprese (Lossy)
2. WebP konverze zapnutá
3. Zachovat originály (pro případ)
4. Automaticky zpracovat existující knihovnu médií

Image CDN (Cloudflare, Cloudinary)

Image CDN je služba, která automaticky optimalizuje obrázky na letu.

Cloudflare (Polish):

• Součást Cloudflare CDN
• Automatická konverze do WebP
• Lossy nebo Lossless komprese
• Zdarma na Pro plánu (20 USD/měsíc)

Cloudinary:

• Pokročilé transformace (ořez, resize, filtry)
• Automatická detekce formátu
• AI-based komprese
• Zdarma do 25 GB/měsíc

Kdy použít Image CDN:

• E-shop se stovkami produktů
• Web s mezinárodním publikem
• Když nechcete řešit optimalizaci ručně

Build-time optimalizace (next/image, Astro)

Moderní frameworky řeší optimalizaci automaticky při buildu:

Next.js (next/image):

import Image from 'next/image'

<Image
  src="/sedacka.jpg"
  alt="Kožená sedačka"
  width={800}
  height={600}
  priority // Pro LCP obrázky
/>

Next.js automaticky:

• Generuje WebP/AVIF verze
• Vytvoří srcset pro různá zařízení
• Přidá líné načítání (pokud není priority)
• Optimalizuje velikost

Astro:

---
import { Image } from 'astro:assets';
import sedacka from '../images/sedacka.jpg';
---

<Image src={sedacka} alt="Kožená sedačka" />

Podobné chování jako Next.js, navíc podporuje Sharp pro build-time optimalizaci.

Responzivní obrázky v praxi

Jak určit správné breakpointy

Breakpointy by měly odpovídat vašemu layoutu, ne náhodným číslům.

Špatný přístup: "Dám tam 320, 768, 1024, 1920 — to jsou přece standardní breakpointy."

Správný přístup:

1. Podívejte se, kdy se mění layout obrázku
2. Na mobilu zabírá 100 % šířky? Breakpoint tam
3. Od tabletu je ve dvou sloupcích (50 %)? Breakpoint tam
4. Na desktopu má fixní šířku? To je maximum

Příklad pro produktovou galerii:

<img src="produkt-800.webp"
     srcset="produkt-400.webp 400w,
             produkt-600.webp 600w,
             produkt-800.webp 800w"
     sizes="(max-width: 640px) 100vw,
            (max-width: 1024px) 50vw,
            400px"
     alt="Produktová fotografie">

Retina displeje a DPR

DPR (Device Pixel Ratio) říká, kolik fyzických pixelů tvoří jeden CSS pixel.

• iPhone 15: DPR 3 (1 CSS pixel = 3x3 fyzických pixelů)
• MacBook Pro: DPR 2
• Starší monitor: DPR 1

Proč to je důležité: Na Retina displeji s šířkou 400 CSS pixelů potřebujete obrázek 800-1200 px, aby byl ostrý.

Prohlížeč to řeší sám: Když uvedete správný srcset s w descriptory, prohlížeč automaticky vybere správnou velikost podle DPR.

<img srcset="produkt-400.webp 400w,
             produkt-800.webp 800w,
             produkt-1200.webp 1200w"
     sizes="100vw"
     src="produkt-800.webp"
     alt="Produkt">

Příklad kompletní implementace

Kompletní řešení pro produktovou fotku e-shopu:

<picture>
  <source type="image/avif"
          srcset="produkt-400.avif 400w,
                  produkt-800.avif 800w,
                  produkt-1200.avif 1200w"
          sizes="(max-width: 640px) 100vw,
                 (max-width: 1024px) 50vw,
                 400px">

  <source type="image/webp"
          srcset="produkt-400.webp 400w,
                  produkt-800.webp 800w,
                  produkt-1200.webp 1200w"
          sizes="(max-width: 640px) 100vw,
                 (max-width: 1024px) 50vw,
                 400px">

  <img src="produkt-800.jpg"
       srcset="produkt-400.jpg 400w,
               produkt-800.jpg 800w,
               produkt-1200.jpg 1200w"
       sizes="(max-width: 640px) 100vw,
              (max-width: 1024px) 50vw,
              400px"
       alt="Konferenční stolek z ořechového dřeva, rozměry 120x60 cm"
       width="800"
       height="600"
       loading="lazy"
       decoding="async">
</picture>

Placeholder Strategie

LQIP (Low Quality Image Placeholder)

LQIP znamená zobrazit extrémně malou verzi obrázku (třeba 20x15 px), dokud se nenačte plná verze.

Výhody:

• Uživatel okamžitě vidí, že tam bude obrázek
• Barvy a kompozice jsou naznačeny
• Lepší UX než prázdné místo

Implementace v CSS:

.image-container {
  background-image: url('produkt-placeholder.jpg'); /* 20px široký, 1KB */
  background-size: cover;
}

.image-container img {
  opacity: 0;
  transition: opacity 0.3s;
}

.image-container img.loaded {
  opacity: 1;
}

Blur-up technika

Blur-up kombinuje LQIP s rozmazáním. Placeholder je rozmazaný, po načtení plného obrázku se rozmaže pryč.

.placeholder {
  filter: blur(20px);
  transform: scale(1.1); /* Skryje okraje blur efektu */
}

.full-image {
  opacity: 0;
  transition: opacity 0.5s;
}

.full-image.loaded {
  opacity: 1;
}

Next.js má tuto techniku vestavěnou:

<Image
  src="/produkt.jpg"
  placeholder="blur"
  blurDataURL="data:image/jpeg;base64,..." // Base64 placeholder
/>

Dominant color placeholder

Místo malého obrázku zobrazíte pouze dominantní barvu.

Výhody:

• Žádný HTTP request navíc
• Extrémně rychlé (jen CSS)
• Vizuálně konzistentní

Implementace:

<div class="image-wrapper" style="background-color: #8B4513;">
  <img src="sedacka.webp" alt="Hnědá kožená sedačka" loading="lazy">
</div>

Nástroje jako Cloudinary nebo Sharp dokážou dominantní barvu extrahovat automaticky.

Před optimalizací (14 MB homepage)

Klient: E-shop s nábytkem, 2000+ produktů, měsíční obrat 3 mil. Kč.

Stav před optimalizací:

• Homepage: 14.2 MB
• Počet obrázků: 48
• Průměrná velikost obrázku: 295 KB
• Formát: JPEG (bez komprese)
• LCP: 6.8 sekund
• PageSpeed Insights skóre: 23/100 (mobil)

Hlavní problémy:

1. Hero banner: 2.8 MB (4000x2000 px JPEG)
2. Produktové náhledy: 200-400 KB každý
3. Žádné lazy loading
4. Žádné responzivní obrázky (stejná velikost pro mobil i desktop)

Implementace

Týden 1: Quick wins

• Komprese existujících obrázků (ShortPixel)
• Přidání lazy loading na vše pod ohybem
• Hero obrázek: zmenšení na 1920px, konverze do WebP

Týden 2: Systémové změny

• Nasazení Cloudflare s Polish (automatická konverze)
• Implementace <picture> pro Hero
• Přidání fetchpriority="high" na Hero

Týden 3: Responzivní obrázky

• Generování 4 velikostí pro každý produktový obrázek
• Implementace srcset na produktových kartách
• Nastavení správných sizes podle layoutu

Týden 4: Placeholder a fine-tuning

• LQIP pro produktové fotky
• Dominant color pro kategorie
• A/B testování různých kvalit komprese

Výsledky (-87 % velikost, LCP 1.9s)

Po 4 týdnech:

Finanční dopad:

• Měsíční obrat před: 3 000 000 Kč
• Měsíční obrat po: 3 360 000 Kč
• Rozdíl: +360 000 Kč/měsíc
• ROI investice do optimalizace: 1800 %

Checklist: Optimalizace obrázků

Používám tento checklist při každém auditu:

Formáty:

• Primární formát je WebP nebo AVIF
• JPEG pouze jako fallback v <picture>
• SVG pro ikony a loga
• Žádné PNG pro fotografie

Velikosti:

• Maximální šířka odpovídá zobrazení (ne 4000px pro 400px slot)
• Implementován srcset s minimálně 3 velikostmi
• Atribut sizes odpovídá skutečnému layoutu
• Komprese 75-85 % pro fotografie

Načítání:

• Hero/LCP obrázek má loading="eager" a fetchpriority="high"
• Ostatní obrázky mají loading="lazy"
• Atributy width a height jsou uvedeny
• Implementován placeholder (LQIP/blur/color)

Metadata:

• Popisné názvy souborů (ne IMG_1234.jpg)
• Alt text popisuje obsah obrázku
• Alt text obsahuje relevantní klíčová slova (bez přehánění)

Infrastruktura:

• CDN pro doručování obrázků
• Automatická komprese při nahrání (plugin/CDN)
• Browser caching nastaven (min. 1 rok)

Potřebujete pomoct s optimalizací obrázků?

Pomáhám firmám zrychlit weby a zlepšit uživatelskou zkušenost. Bez složitých smluv, jen výsledky.

Domluvte si konzultaci

Související články

• Optimalizace obrázků pro SEO: WebP, AVIF, komprese a lazy loading
• LCP: Jak zrychlit načítání webu pod 2,5 sekundy
• Core Web Vitals: LCP, INP a CLS jednoduše
• PageSpeed Insights: Jak číst metriky a zrychlit web

Často kladené otázky (FAQ)

1. Zhorší WebP konverze kvalitu fotek?

Ne, pokud použijete správné nastavení. WebP při kvalitě 80-85 % je vizuálně nerozeznatelný od JPEG při kvalitě 85-90 %. U produktových fotek, kde záleží na detailech, doporučuji kvalitu 85 %. U ilustračních obrázků můžete jít na 75 %.

2. Podporuje Safari AVIF?

Ano, od Safari 16.0 (září 2022). Na iOS to znamená iPhone 8 a novější s iOS 16+. Aktuálně AVIF podporuje 94 % uživatelů. Pro zbylých 6 % použijte WebP fallback v <picture> elementu.

3. Mám použít líné načítání na všechny obrázky?

Ne. Obrázky viditelné bez scrollování (above the fold) by měly mít loading="eager". Typicky Hero banner, logo, a první 1-2 produktové fotky. Líné načítání na těchto obrázcích zpomaluje LCP.

4. Jak automaticky konvertovat obrázky ve WordPressu?

Nainstalujte plugin ShortPixel nebo Imagify. V nastavení zapněte automatickou konverzi do WebP, nastavte agresivní (Lossy) kompresi a nechte plugin zpracovat existující knihovnu médií. Celý proces je automatický — při nahrání nového obrázku se okamžitě optimalizuje.

5. Co je lepší - lokální obrázky nebo Image CDN?

Záleží na velikosti webu. Pro web s desítkami obrázků stačí lokální hosting s pluginem na kompresi. Pro e-shop se stovkami produktů nebo mezinárodní web doporučuji Image CDN (Cloudflare, Cloudinary). CDN automaticky optimalizuje, detekuje formát a doručuje ze serveru blízko uživateli.