Známá odpověď je: záleží.
A upřímně, tady by tenhle článek klidně mohl skončit.

V praxi se ale tahle otázka velmi často zodpoví až příliš rychle - a většinou jen jedním směrem.

Hodně zjednodušený pohled na to, jak funguje HTTP

Než se rozhodnete, jestli je problém ve frontendu nebo backendu, je dobré si připomenout, jak vlastně funguje HTTP požadavek.

  1. Připojení - prohlížeč se připojí k serveru
  2. Požadavek - prohlížeč si vyžádá stránku (např. kategorii)
  3. Zpracování - server požadavek zpracuje
  4. Odpověď - server pošle HTML
  5. Spojení se zavře (nebo zůstane otevřené pomocí keep-alive)

Všechno až do doručení HTML je část request/response cyklu, kde má backend a infrastruktura největší vliv na výkon.

Kde začíná frontend

Jakmile je HTML doručeno, přebírá to prohlížeč.

Tady se:

  • parsuje HTML
  • aplikuje CSS
  • spouští JavaScript
  • načítají obrázky, fonty a další assety
  • vykreslí stránka do použitelné podoby

Tohle je frontendová část výkonu.

Ta skutečná otázka

Skutečné rozhodnutí nezní „Máme optimalizovat frontend?“
Je mnohem jednodušší:

Kde je ten web vlastně pomalý?

Na backendu? Na frontendu? Nebo na obou stranách?

Pokud si vyberete špatně, můžete klidně strávit týdny optimalizací části, která vůbec není problém.

Hádat je drahé. Data jsou levnější.

Reálná uživatelská data: CrUX

Jedním z nejužitečnějších zdrojů dat je Chrome UX Report (CrUX).

CrUX vychází z reálného chování uživatelů Chromu. Vzhledem k tomu, že Chrome má globální podíl kolem 71 % (listopad 2025), jsou tahle data naprosto použitelná pro reálná rozhodnutí. Zároveň jde o zdroj Core Web Vitals, které Google používá jako rankingový signál.

Na prohlížení CrUX dat většinou používám treo.sh.
Free verze ukáže data za celý web, placená jde až na úroveň jednotlivých URL.

Po zadání URL uvidíte několik výkonových grafů.

Příklad 1 - kdy vám frontend nepomůže

CrUX data showing poor TTFB with 1.8s response time

První metrika, na kterou se vždycky dívám, je TTFB (Time To First Byte).

  • TTFB kolem 1,8 s - červená čísla, jasně špatně
  • Rozdíl mezi TTFB a FCP je ~400 ms
  • Rozdíl mezi TTFB a LCP je ~600 ms

Všimnete si, že se tyhle metriky hýbou spolu.
Nejsou dokonale korelované, ale v reálných projektech je ten vzorec většinou hodně čitelný.

Co z toho plyne?

  • Prohlížeč vykreslí hlavní obsah cca do 600 ms od chvíle, kdy začne renderovat
  • Ale skoro 2 sekundy trvá, než vůbec dorazí HTML

V tomhle případě:

  • Frontend už je relativně rychlý
  • Úzké hrdlo je odezva backendu

Příklad 2 - backendová práce, která dává smysl

CrUX data showing improved metrics after backend optimisation

V jiném případě:

  • TTFB pořád není ideální
  • Ale FCP a LCP jsou už zelené

Klient investoval jen zlomek času do backendové optimalizace a výsledek byl hned vidět.

Žádný redesign. Žádná výměna frameworku. Prostě se opravilo to, co bylo skutečně špatně.

Z pohledu klienta je tohle často ten nejlepší možný scénář.

Příklad 3 - když je problém na obou stranách

CrUX data showing both TTFB and LCP in red

A pak jsou případy, kdy:

  • TTFB je červené
  • LCP je taky špatné

Tady je to jasné:

  • Backend je pomalý
  • Frontend tomu nijak nepomáhá

V takové situaci už frontendová optimalizace smysl dává - ale jen jako součást širší práce na výkonu, ne jako samostatné řešení.

Neexistuje jedno řešení na vše

Tohle je ta část, kterou lidi neradi slyší.

Na webový výkon neexistuje univerzální recept.

V praxi se ale výměna frontendu často prezentuje jako čisté „komplexní“ řešení. Někdy to funguje. Velmi často je to ale jen nejviditelnější - a nejsnáze prodeprodejná varianta.

Úkolem vývojáře nebo architekta je:

  • pochopit, kde je skutečný problém
  • umět ho srozumitelně vysvětlit
  • a doporučit klientovy investovat peníze tam, kde dávají smysl

Magento realita

Tento text je hodně ovlivněný mými zkušenostmi s Adobe Commerce / Magento 2 projekty:

Ve většině projektů, na kterých jsem pracoval, se jako větší brzda výkonu ukázal backend než frontend.

To neznamená, že frontend není důležitý.

U nových projektů jsem přesvědčený, že pro většinu případů je začít s Hyvä to nejlepší rozhodnutí.

Ale u existujícího webu by frontend nikdy neměl být automatickou odpovědí. Musí si to obhájit daty.

Pro tip

Pokud vám někdo řekne, že výměna frontendu je to nejlepší, co můžete udělat, aniž by předtím proběhl jakýkoliv performance audit…

Utíkejte.