Přeskočit na obsah
iD-SIGN
Ptejte se

Rychlost a výkon webu

Web, který se načte během mrknutí oka, i portál, který obstojí před desítkami tisíc lidí denně. Rychlost měříme v prohlížeči i na serveru, ne odhadem.

Co umíme

Rychlost skládáme z dílů, které známe do detailu. U každého je popsané, jak funguje, a změřená hodnota tohoto webu.

  • První zobrazení během mrknutí oka

    Styly mají 25 kB, hlavní řez písma se přednačte a největší obrázek stránky dostane vysokou prioritu. Co je pod ohybem, načte se až cestou. Měříme LCP, okamžik, kdy se ukáže největší prvek stránky.

    Stránka úvod tohoto webu na počítači naměřeno LCP 220 ms

  • Rychle i na pomalém telefonu

    Na slabém telefonu rozhoduje, kolik toho stránka potřebuje, než se ukáže. Skripty se načítají až s potřebou a dlouhé sekce prohlížeč vykreslí, až k nim čtenář dojde.

    Stránka stránka služby, 4G, 4× pomalejší procesor naměřeno LCP 510 ms

  • Nic neposkakuje

    Obrázky mají rozměry dřív, než dorazí, a záložní písmo má stejné metriky jako webové, takže se text při výměně písma nepřesadí. Měříme CLS, souhrn posunů obsahu.

    Stránka stránka služby, první návštěva naměřeno CLS 0

  • Odpověď serveru v milisekundách

    Aplikace zůstává mezi požadavky v paměti, mezipaměť se připraví už při sestavení a statické soubory mají v prohlížeči neomezenou platnost. Měříme TTFB, čas do prvního bajtu odpovědi. Firemní web Payminatoru odpoví v 95 % případů do 25 ms, aplikace Payminator Daně do 55 ms.

    Měření odpověď serveru tohoto webu naměřeno TTFB 20 ms

  • Obrázky, které neváží

    Každý obrázek převedeme do AVIF a WebP v šířkách pro každou obrazovku a prohlížeč si vezme nejmenší, který stačí. Pod ohybem se načítá líně.

    Obrázek snímek portálu na telefonu naměřeno 291 kB JPG 25 kB AVIF

  • Data bez čekání

    Pomalé dotazy hledáme ve výkonových profilech, doplníme indexy a co se počítá často, předpočítáme nebo podržíme v mezipaměti.

    Výpočet vektor dotazu pro hledání podle významu naměřeno 13 ms, pak den v mezipaměti

  • Průběžně sledujeme a optimalizujeme

    Rychlost a výkon našich aplikací sledujeme průběžně, už během vývoje i v provozu, a optimalizujeme podle toho, co data ukážou. Každé kliknutí vidíme celou cestou z prohlížeče přes server a mezipaměť až po jednotlivé dotazy do databáze. Vývojová verze personálního portálu má výkonové skóre 98 ze 100.

    Měření nejpomalejší serverová komponenta portálu naměřeno 2,45 ms

  • Ve více jazycích

    Každá jazyková verze má vlastní adresy a stejnou kostru, takže se načte stejně rychle jako čeština.

    Stránka /en/website-creation, 4G, 4× pomalejší procesor naměřeno LCP 520 ms, česká verze 510 ms

Jak to stavíme

Rychlost se neodhaduje, měří se. Na počítači i na pomalém telefonu, v prohlížeči i na serveru, a po každé větší změně znovu.

  1. Měření, ne odhad Změříme web na počítači i na pomalém telefonu a server v provozu. Z výkonových profilů vyjde, kde se ztrácí čas.
  2. Oprava největší ztráty Začneme tím, co zdrží nejvíc, třeba obrázkem bez rozměrů, blokujícím skriptem nebo pomalým dotazem do databáze.
  3. Hlídání v provozu Po každé větší změně měříme znovu a provoz sledujeme průběžně, aby se rychlost neztratila s novými funkcemi.

Přístup

Měření v prohlížeči
Chrome DevTools, Lighthouse, Core Web Vitals (LCP, CLS, INP)
Měření v provozu
Sentry, trasy z prohlížeče až do databáze a Web Vitals skutečných uživatelů
Worker mód
FrankenPHP, aplikace zůstává v paměti mezi požadavky
Mezipaměť
Redis, mezipaměť aplikace, stránky vygenerované předem (Next.js SSG) a statické soubory s neomezenou platností v prohlížeči
Optimalizace databáze
PostgreSQL a MariaDB, indexy podle skutečných dotazů, rozbor pomalých dotazů z výkonových profilů
Přechod na další stránku
prefetch, další stránka se načítá už při stisku odkazu
Obrázky
AVIF a WebP v šířkách pro každou obrazovku
Doručení
Traefik, HTTP/3, komprese zstd

Je to výběr, technologie volíme podle potřeb projektu.

Umíme toho hodně

Rychlý web stojí na rychlém serveru a dobrém hledání. Z těchto schopností skládáme každý projekt.