Skeleton screen

Příklady z praxe

1. 01

   Výpis produktů v e-shopu

   Kategorie načítá 24 produktů z API, které odpovídá zhruba za 800 ms. Místo prázdné bílé plochy se okamžitě vykreslí 24 karet s šedým obdélníkem místo fotky a dvěma řádky místo názvu a ceny. Karty mají pevnou výšku, takže po dorazení dat se stránka ani nehne a filtry vlevo nezmění pozici.

   <article class="card" aria-hidden="true">
     <div class="sk sk-img"></div>
     <div class="sk sk-line" style-less></div>
   </article>
   <p role="status">Načítám produkty…</p>

2. 02

   Skeleton jako Suspense fallback v Reactu

   Detail objednávky se skládá z rychlé hlavičky a pomalého seznamu položek, který čeká na platební bránu. Hlavička se vykreslí hned, seznam obalí hranice Suspense se skeletonem. Uživatel tak vidí číslo objednávky během desítek milisekund a poskakující tabulku dostane až hotovou.

   export default function Order({ id }) {
     return (
       <>
         <OrderHeader id={id} />
         <Suspense fallback={<ItemsSkeleton rows={5} />}>
           <OrderItems id={id} />
         </Suspense>
       </>
     );
   }

Časté omyly

MýtusSkeleton screen zrychlí načítání aplikace.

Ve skutečnostiSkeleton screen nezrychlí nic: data dorazí ve stejnou chvíli jako předtím. Mění se jen vnímání čekání, protože uživatel má na co koukat a ví, jaká struktura přijde. Reálný výkon se řeší cachováním, menším payloadem a rychlejším dotazem.

MýtusSkeleton je vždycky lepší než spinner.

Ve skutečnostiSkeleton je lepší jen tam, kde je tvar výsledku předem známý. U akcí bez předvídatelného rozvržení (odeslání platby, generování PDF) je jasnější spinner s popiskem nebo progress bar s procenty.

MýtusSkeleton stačí prohodit za obsah, o přístupnost se starat nemusím.

Ve skutečnostiSkeleton je pro čtečku obrazovky prázdná změť prvků. Bez aria-hidden na dekoraci a bez živé oblasti s textovým stavem uživatel nepozná, že se něco načítá.

Časté dotazy

Jak dlouho má být skeleton screen vidět, než se zobrazí obsah?

Skeleton screen má smysl zobrazit až po krátké prodlevě, typicky 200 až 300 milisekund od začátku načítání. Pokud data dorazí dřív, skeleton jen problikne a působí jako grafická chyba. Zároveň se doporučuje minimální doba zobrazení, například 300 až 500 milisekund, aby se skeleton nezjevil a hned nezmizel. Nad zhruba třemi sekundami už skeleton přestává stačit a je vhodné doplnit textovou informaci o tom, na co se čeká, případně přejít na progress indikátor s reálným postupem.

Jak skeleton screen ovlivňuje Core Web Vitals?

Skeleton screen pomáhá hlavně metrice Cumulative Layout Shift, protože rezervuje přesné rozměry budoucího obsahu a stránka po načtení dat nepodskočí. Vliv na Largest Contentful Paint je nejednoznačný: šedé bloky se obvykle za největší obsahový prvek nepočítají, takže LCP se řídí až skutečným obrázkem nebo textem. Skeleton tedy metriky sám o sobě nevylepší, pokud je server pomalý. Nejvíc se vyplatí kombinace: skeleton pro stabilní rozvržení a skutečná optimalizace dotazů, cache a velikosti obrázků.

Čím se skeleton screen liší od placeholderu typu blur-up u obrázků?

Skeleton screen zastupuje celou strukturu rozhraní, tedy nadpisy, řádky textu i pozice karet, a nenese žádnou informaci o skutečném obsahu. Blur-up placeholder naopak ukazuje rozmazanou miniaturu konkrétního obrázku, kterou prohlížeč postupně nahradí ostrou verzí. Obě techniky se dají kombinovat: karta produktu má skeleton pro text a cenu, zatímco pro fotku použije rozmazaný náhled o velikosti pár set bajtů. Společný cíl je stejný, tedy rezervovat prostor a zabránit poskočení rozvržení.

Musím si skeleton screen psát ručně, nebo existují hotová řešení?

Skeleton screen se dá napsat ručně několika řádky CSS: barevné pozadí, zaoblené rohy, pevné rozměry a volitelně animace přes keyframes. Většina komponentových knihoven ale nabízí hotový prvek, například MUI Skeleton, Chakra Skeleton nebo utility třídy v Tailwindu s animací pulse. Existují i nástroje generující skeleton automaticky ze snímku hotové komponenty. Ruční řešení je bezpečnější v tom, že rozměry odpovídají reálnému obsahu, což je u skeletonů to nejdůležitější.

Zdroje

1. Cumulative Layout Shift (CLS)(otevře se v novém okně)MDN Web Docs
2. prefers-reduced-motion(otevře se v novém okně)MDN Web Docs
3. ARIA live regions(otevře se v novém okně)MDN Web Docs
4. <Suspense>(otevře se v novém okně)React
5. Web Content Accessibility Guidelines (WCAG) 2.2(otevře se v novém okně)W3C, 2023

Související pojmy

• Core Web VitalsCore Web Vitals je sada uživatelsky orientovaných metrik, kterými Google hodnotí rychlost načtení, odezvu na interakce a vizuální stabilitu webové stránky. V praxi jde hlavně o LCP, INP a CLS, tedy signály, které pomáhají odhalit pomalý obsah, zaseknuté rozhraní nebo poskakující layout.
• Cumulative Layout ShiftCumulative Layout Shift je metrika ze sady Core Web Vitals, která měří, jak moc se viditelný obsah stránky během načítání a používání samovolně posune. Hodnota vzniká součtem jednotlivých posunů, kde každý se počítá jako podíl zasažené plochy viewportu vynásobený vzdáleností posunu. Za dobrou se považuje hodnota do 0,1.
• Lazy loadingLazy loading je technika, při níž aplikace, stránka nebo knihovna načte data, komponentu či obrázek až ve chvíli, kdy jsou skutečně potřeba. Odkládá práci mimo první vykreslení nebo inicializaci, čímž může zrychlit start, snížit přenos dat a paměť, ale přidává složitost při měření, chybách a načítání obsahu.
• Server-side renderingServer-side rendering je způsob vykreslení webové stránky, při kterém server sestaví hotové HTML ještě před odesláním do prohlížeče. Uživatel tak může vidět obsah dříve, než se stáhne a spustí celý JavaScript. Přístup pomáhá SEO a prvnímu zobrazení, ale přesouvá část práce na server.
• Splash screenSplash screen je úvodní obrazovka s logem nebo grafikou, kterou aplikace zobrazí okamžitě po spuštění a nechá běžet, dokud se nenačte hlavní rozhraní. Slouží k překlenutí startovací prodlevy a k potvrzení, že se aplikace opravdu spustila. Na Androidu i iOS ji definuje systém, na webu ji řeší manifest progresivní webové aplikace.
• 3D model3D model je digitální reprezentace objektu nebo prostoru ve třech rozměrech, složená z geometrie, materiálů a často i textur, animací či fyzikálních vlastností. Používá se v hrách, filmech, průmyslovém návrhu, architektuře, e-commerce i simulacích, kde software z modelu počítá zobrazení nebo další data.
• A/B testováníA/B testování je řízený experiment, který porovnává dvě varianty stránky, funkce, ceny nebo sdělení na podobných skupinách uživatelů. Měří předem zvolenou metriku, například konverzi nebo retenci, a pomáhá rozhodnout, zda změna skutečně zlepšuje výsledek, nebo zda pozorovaný rozdíl mohl vzniknout náhodou.
• Adaptive IconAdaptivní ikona je formát ikony aplikace na Androidu, který se místo jedné hotové bitmapy skládá z oddělených vrstev: pozadí a popředí. Systém výsledný tvar sám ořízne podle masky výrobce zařízení a může vrstvy animovat nebo přebarvit. Vývojář tak dodá jeden zdroj a launcher z něj vytvoří kruh, čtverec i squircle.