---
title: "Hyvä vs. Luma v číslech"
description: "Proč je Luma z principu pomalá, co Hyvä mění a jak si rozdíl změřit na vlastním katalogu místo důvěry v prodejní prezentaci."
author: "Luboš Zápotočný"
published: "2026-05-21"
language: "cs"
canonical: "https://zapolu.com/cs/blog/hyva-vs-luma/"
---

# Hyvä vs. Luma v číslech

Každá debata o výkonu Magenta dřív nebo později dorazí ke stejné
otázce: je problém ve frontendu a je odpovědí Hyvä? Poctivá odpověď
zní „většinou a většinou“, ale neměli byste ji brát od nás ani od
nikoho, kdo vám prodává přestavbu. Tento článek vysvětluje, v čem se
oba frontendy strukturálně liší a jak si rozdíl změřit na vlastním
e-shopu dřív, než do něj dáte peníze.

## Proč je Luma pomalá už z návrhu

Luma, výchozí frontend Magenta, je pomalá kvůli rozhodnutím
pevně zabudovaným do platformy kolem roku 2015:

- **RequireJS načítá JavaScript jako vodopád závislostí.** Prohlížeč
  zjistí, co má stáhnout dál, teprve když vykoná to, co už stáhl. Na
  studeném mobilním připojení to znamená jeden round-trip za druhým,
  než stránka začne reagovat.
- **Na každou stránku dorazí několik těžkých JS vrstev najednou.**
  jQuery, KnockoutJS a na Knockoutu postavená vrstva UI komponent
  Magenta se načtou vždy, ať je stránka potřebuje, nebo ne.
- **Layout XML vykresluje víc, než je potřeba.** Bloky, které nikdo neuvidí, se
  stejně sestaví, a rozšíření třetích stran registrují své skripty
  globálně místo tam, kde jsou skutečně potřeba.

Nic z toho se v profileru neukáže jako jeden pomalý řádek. Ukáže se
to jako megabajty JavaScriptu a hlavní vlákno vytížené na několik
sekund na telefonech střední třídy, tedy přesně tam, kde jsou vaši
zákazníci.

## Co Hyvä skutečně mění

[Hyvä](https://hyva.io) je náhradní theme, které frontendový
stack Lumy nahrazuje celý: žádný RequireJS, žádné jQuery, žádný
Knockout. Šablony jsou serverově renderované PHP
s [Alpine.js](https://alpinejs.dev) pro interaktivitu a Tailwindem
pro styly. Podle našich vlastních měření obvykle
JavaScript klesne z něčeho přes megabajt na výrazně pod sto
kilobajtů, což si sami ověříte v síťovém panelu libovolného
prohlížeče na demo obchodě.

Jedno omezení to má: každé rozšíření, které sahá na
frontend, potřebuje modul kompatibilní s Hyvä, nebo přepsání.
Ekosystém kompatibility je u populárních rozšíření zralý a u toho
jednoho modulu na míru z roku 2019 prázdný. Skutečné náklady
projektu s Hyvä leží v auditu rozšíření, ne v licenci theme.

Pokladna je samostatné rozhodnutí: Hyvä ve výchozím stavu ponechává
pokladnu z Lumy, dokud nenasadíte Hyvä Checkout nebo headless
řešení, a přitom právě pokladna často rozhoduje o konverzích.

## Jak si to změřit sami

Neporovnávejte svůj produkční e-shop s demem Hyvä; smícháte tak
theme, katalog, hosting a skripty třetích stran. Férové srovnání
vypadá takhle:

1. **Vyjděte z terénních dat, ne jen z Lighthouse.** CrUX (přes
   PageSpeed Insights) ukazuje, co skuteční návštěvníci zažili za
   28 dní: LCP, INP, CLS. Neškrcený laboratorní běh na rychlém
   vývojářském stroji může vypadat mnohem lépe než to, co dostanou
   skuteční návštěvníci na telefonech střední třídy.
2. **Oddělte frontend od backendu.** TTFB určuje hlavně backend
   a síť (server, DNS, TLS); při TTFB 1,5 s vás žádný theme
   nezachrání. Většina toho, co se děje
   za TTFB, je prostor, který výměna frontendu dokáže ovlivnit; pomalý
   backend nebo síť si žádají vlastní opravu.
3. **Postavte srovnání poctivě.** Stejný server, stejný katalog,
   stejná zapnutá rozšíření, tagy třetích stran buď zapnuté v obou,
   nebo vypnuté v obou. Lighthouse pusťte několikrát a porovnejte
   mediány, protože jednotlivé běhy jsou šum.
4. **Sledujte vedle toho byznysovou metriku.** Konverze podle třídy
   zařízení, před a po. To je číslo, které projekt obhajuje.

## Kdy odpověď není Hyvä

Hyvä je naše výchozí doporučení pro e-shopy na Lumě s výkonnostním
problémem, ale ne pro každý. E-shop s TTFB čtyři sekundy má problém
v backendu. E-shop, který už běží na PWA Studio, naráží na jinou hranici.
A e-shop před replatformingem by neměl investovat ani do jednoho;
napřed je na místě otázka
[replatforming, nebo oprava](/cs/blog/replatforming-nebo-oprava/).

Pokud chcete měření nechat na nás, přesně tohle je náš
[audit výkonu](/cs/services/performance-audit/): rozdělení
frontend/backend, audit rozšíření a seznam oprav seřazený podle priorit. A také
tak začíná většina naší [práce na Magentu](/cs/services/magento/).