Fotografii jste zmenšili na polovinu, ale článek se na telefonu stále otevírá pomalu. Obrázek totiž může většinu času čekat, než jej prohlížeč vůbec začne stahovat. U LCP nerozhoduje pouze velikost souboru. Nejdřív zjistěte, který prvek je při dané šířce největší a kdy se skutečně objeví.
V magazínu to bývá hlavní fotografie, ale někdy titulek nebo jiný textový blok. Automaticky tedy neoznačujte featured image za příčinu každého špatného výsledku. Tento návod pomůže připravit cílený úkol pro správce WordPressu bez plošného přepisování staré knihovny médií.
Rozdělte čekání na čtyři části
| Část LCP | Co se děje | První směr kontroly |
|---|---|---|
| TTFB | Čekání na první byte odpovědi HTML | Server, přesměrování a cache |
| Prodleva nalezení zdroje | HTML už přišlo, obrázek se ještě nestahuje | Způsob vložení a načasování požadavku |
| Přenos zdroje | Stahuje se použitý obrazový soubor | Rozměry, datový objem a doručení |
| Prodleva vykreslení | Zdroj už dorazil, ale prvek není zobrazen | CSS, skripty a skryté prvky |
LCP vyjadřuje dobu do vykreslení největšího způsobilého prvku v zobrazené části. Pro dobrou zkušenost je cílem nejvýše 2,5 sekundy u 75. percentilu návštěv. Čtyři uvedené části pomáhají hledat příčinu; nejde o čtyři oddělené výsledky, které by bylo možné libovolně sčítat z různých testů.
Pokud server dlouho neposílá HTML, samotné zmenšení fotografie tuto část čekání neodstraní. Pokud zdroj dorazí včas, ale šablona jej drží skrytý, další komprese může jen zvětšit čekání před vykreslením. Nejprve potřebujete časovou osu stejného načtení.
Najděte skutečný prvek a skutečný soubor
Otevřete konkrétní URL anonymně a ověřte ji zvlášť při mobilní a desktopové šířce. V diagnostice vyhledejte LCP prvek. U obrázku si poznamenejte použitou adresu a jeho reálné rozměry. Prohlížeč může z nabídky variant vybrat jiný soubor než ten, který správce právě prohlíží v knihovně.
Záznam by měl spojit URL článku, velikost okna, prvek a obrazový požadavek. Bez této vazby se snadno optimalizuje jiná fotografie. Při proměnlivém horním banneru zopakujte scénář i s jeho načtením; jiná skladba úvodu může změnit výsledek.
- Vyhledejte LCP prvek pro dané rozložení, nikoli jen první obrázek v HTML.
- Uložte adresu vybraného zdroje a jeho přenos, ne pouze údaj z mediální knihovny.
- Porovnejte první návštěvu a opakované načtení s využitou cache.
- Zapište, zda je obrázek viditelný hned, nebo jej doplňuje skript.
Způsob dostupného vložení a rozlišení souboru od přílohy popisuje technická kontrola obrázků ve WordPressu. Výkonový problém zde řešte na konkrétní šabloně; neměňte automaticky všechna historická média.
Hlavní obrázek potřebuje včasné načtení
Obrázek v horní viditelné části obvykle není vhodným kandidátem pro odložené načítání. Ověřte, co skutečně vytváří šablona a optimalizační plugin. Dvě souběžná řešení mohou přidat odklad i tam, kde jej správce nečekal. Neodstraňujte ale lazy loading ze všech dlouhých článků; obrázky hluboko pod úvodem mají jiný účel.
Správce může posoudit prioritu načtení a případný preload konkrétního klíčového zdroje. Nepřednačítejte automaticky každou variantu fotografie. Nejprve musí odpovídat skutečnému výběru prohlížeče. Jinak lze přidat zbytečný přenos místo jeho omezení. Výsledek ověřte na síťové časové ose.
Kdy pomůže menší WebP a kdy nepomůže
Pokud přenos samotného souboru tvoří významnou část čekání, připravte přiměřené rozměry a kompresi. Zohledněte šířku sloupce, kvalitu obrazu a existující originál. Malou fotografii nezvětšujte jen kvůli tabulkovému cíli. U fotografie s jemným textem nebo důležitým detailem navíc posuzujte čitelnost, nikoli pouze počet bajtů.
Modelově může redakce zvolit hlavní fotografii kolem 1536 pixelů a datový cíl 100–200 kB. Jde o vlastní pracovní rozpočet, ne hranici LCP stanovenou Googlem. Opravte i varianty, které se opravdu doručují na mobil. Nový malý originál nic neprokáže, jestli se do stránky dál vkládá stará velká adresa.
| Nález | Vhodný další krok | Riziko slepého zásahu |
|---|---|---|
| Velký mobilní přenos | Zkontrolovat vybranou variantu a rozměry | Zhoršení kvality bez změny doručované URL |
| Pozdní začátek stahování | Ověřit vložení a odklad | Další komprese neřeší čekání na požadavek |
| Dlouhá odpověď HTML | Prověřit serverovou cestu | Přepis médií nemění odezvu aplikace |
| Staženo, ale neviditelné | Prověřit skripty, styly a skrytí | Preload přidá práci bez nápravy vykreslení |
Modelový výpočet odhalí špatně zvolenou prioritu
Uvažujme vlastní model jednoho načtení: odpověď HTML 0,9 sekundy, prodleva obrázkového požadavku 1,2 sekundy, přenos 0,4 sekundy a čekání na vykreslení 0,5 sekundy. Celkem jde o 3,0 sekundy. Kdyby se pouze přenos zkrátil na polovinu a ostatní zůstalo stejné, výsledek by byl 2,8 sekundy.
Model ukazuje, proč lze mnoho práce věnovat kompresi s omezeným výsledkem. Nevypovídá o výkonu konkrétního webu. V reálném načtení se navíc mohou závislosti změnit a úspora jedné části nemusí přejít celá do konečného LCP. Před rozhodnutím proto uložte původní časovou osu a zvolte příčinu s doloženým podílem.
Před nasazením zkontrolujte i obsah a indexaci
Při úpravě šablony může hlavní fotografie zmizet z původního HTML nebo být dostupná až po interakci. Výkonový test proto doplňte kontrolou úplnosti článku. U obrázku zachovejte odpovídající alt a správnou vazbu na obsah. Výrazně jiný ořez posuďte na telefonu; podstatná část motivu nesmí zůstat mimo viditelnou plochu.
Samostatně projděte vztah JavaScriptu a mobilního vykreslení. Rychlejší prázdná plocha není použitelným výsledkem. Stejně tak změna URL fotografie vyžaduje ověření dostupnosti nových variant, ne předpoklad, že mediální knihovna vše opraví sama.
- Zaznamenejte výchozí LCP prvek a čtyři části čekání.
- Na kopii upravte jednu příčinu: variantu, odklad nebo vykreslení.
- Ověřte kvalitu fotografie a úplnost textu na obou šířkách.
- Po nasazení zkontrolujte veřejný soubor, HTML a původní scénář.
- Předejte výsledek s podmínkami a časem změny; neslibujte stejné sekundy pro každého návštěvníka.
Pokud první část čekání ukazuje na aplikaci, navazuje diagnostika vytížení hostingu. Pokud se naopak mění uspořádání celé stránky, posuďte současně stabilitu rozložení. Oprava jednoho obrázku nemá být důvodem přehlédnout přesunuté nadpisy nebo nefunkční menu.
Výsledek přijměte, když odpovídá původnímu problému a přežije běžné vydání dalšího článku. Test pouze jedné ručně upravené stránky neověří, zda šablona správně zpracuje také novou fotografii v příští dávce. Přidejte proto jeden čerstvý redakční příklad stejného typu.
Jak předat problém s fotografií bez zbytečného přepisování médií
Správci předejte jeden reprezentativní článek a přesnou cestu k použité variantě. Doplníte-li jen název obrázku, může najít jiné médium s podobným označením. Identita souboru musí odpovídat měřenému požadavku. U sdílené fotografie zároveň ověřte, zda by její výměna nezasáhla další články.
Rozlišujte opravu výstupu šablony a změnu obrazového originálu. Jestli šablona na telefon vybírá nesprávnou velikost, může být účelnější opravit výběr než znovu nahrát stovky médií. Pokud konkrétní originál opravdu vyžaduje menší soubor, připravte samostatnou řízenou změnu s kontrolou všech jeho aktivních variant. Historické adresy nemají mizet bez dohledání použití.
Redaktor může nápravu převzít i bez znalosti všech parametrů prohlížeče. Má dostat původní a novou veřejnou podobu, dohledatelnou fotografii a vysvětlení, která část čekání se změnila. Zkontroluje motiv, ostrost, ořez a popis. Vývojář dodá technický záznam. Tím se oddělí obrazová kvalita a technické doručování, přestože oba výsledky musí společně projít.
Při testování různých typů článků zachovejte jednu srovnatelnou fotografii nebo zapište rozdíl. Jiný motiv s jiným datovým objemem může výsledek ovlivnit. Změna čísla bez evidence vstupních souborů proto ještě neprokazuje, že pomohla právě úprava priority.
Časté otázky
Je náhledová fotografie vždy LCP?
Ne. Záleží na viditelném rozložení a jeho načtení. Na jiné šířce může být největším způsobilým prvkem titulek či jiný obsah.
Mám vypnout lazy loading všude?
Ne. Prověřte konkrétní horní prvek a jeho potřebu načíst se včas. Fotografie níže v dlouhém článku mohou z odkladu dál těžit.
Zaručí WebP zelené LCP?
Ne. Formát ovlivňuje přenos, ale nevyřeší dlouhé čekání na HTML, objevení zdroje nebo jeho vykreslení.
Pomůže preload každého obrázku?
Takový postup může soutěžit o prostředky s důležitějším obsahem. Výběr musí vycházet ze skutečného prvku a načítané varianty.
Kdy řešit hosting?
Když diagnostika ukáže významné čekání na serverovou odpověď a ověříte související aplikaci, cache a provozní podmínky.
