--- title: "Rychlost firemní aplikace: kde se reálně ztrácí čas" description: "„Je to pomalé\" bývá stížnost na jednu obrazovku, ne na celou aplikaci. Jak najít, kde se čas opravdu ztrácí, a proč to skoro nikdy není tam, kde se to hledá." canonical: "https://interfase.sk/cz/novinky/rychlost-firemni-aplikace-kde-se-realne-ztraci-cas" lang: "cz" last_updated: "2026-10-14" --- # Rychlost firemní aplikace: kde se reálně ztrácí čas > „Je to pomalé" bývá stížnost na jednu obrazovku, ne na celou aplikaci. Jak najít, kde se čas opravdu ztrácí, a proč to skoro nikdy není tam, kde se to hledá. Publikováno: 2026-10-14 - Stížnost „je to pomalé" se téměř vždy týká jedné nebo dvou obrazovek; prvním krokem je zjistit kterých, ne zrychlovat všechno. - Nejčastější příčinou není slabý server, ale počet databázových dotazů na jedno zobrazení. - Průměrný čas odezvy klame — sledujte pomalá percentila, protože ta zažívají uživatelé s největším objemem dat. - Optimalizovat bez měření znamená zrychlovat to, co nikoho nezdržovalo. „Systém je pomalý." Tato věta přichází čas od času do každého vývojového týmu a téměř vždy je nepřesná — ne proto, že by nebyla pravdivá, ale proto, že se netýká systému. Týká se jedné obrazovky, kterou někdo otevírá padesátkrát denně. První úkol tedy není zrychlovat, ale **zjistit co**. ## Měřte dřív, než začnete Bez čísel se optimalizuje podle dojmu a dojem bývá mimo. Typicky se přeinvestuje do infrastruktury, přestože problém je v jednom dotazu. Je potřeba vědět tři věci: **které obrazovky se otevírají nejčastěji**, **jak dlouho trvá jejich zobrazení** a **jak se ten čas dělí** mezi databázi, aplikační logiku a prohlížeč. A pozor na průměr. Pokud je průměrná odezva 300 ms, může to znamenat, že devadesát procent požadavků trvá 100 ms a zbytek tři sekundy. Právě ty tři sekundy zažívají uživatelé s největším množstvím dat — tedy obvykle ti nejdůležitější. Sledujte proto **pomalá percentila**, ne průměr. ## Nejčastější příčina: příliš mnoho dotazů V praxi jde o tohle asi v polovině případů. Obrazovka zobrazí seznam sta objednávek a pro každou si zvlášť vyžádá zákazníka. Místo dvou dotazů jich je sto jedna. Každý jednotlivě je rychlý, proto se v logu nic nezdá divné. Až jejich součet udělá ze tří setin sekundy tři sekundy. Řešení je obvykle jednoduché — načíst související data najednou — jenže najít to bez měření jde těžko. ## Druhá příčina: načítá se víc, než je třeba Seznam zobrazuje osm sloupců, ale z databáze se tahá celý záznam včetně poznámek a historie. Nebo se načte všech dvacet tisíc řádků a stránkuje se až v prohlížeči. Sem patří i **chybějící stránkování ve filtrech** a číselníky, které se načítají při každém otevření, přestože se mění jednou za rok. ## Třetí příčina: chybějící indexy Dokud je v tabulce tisíc řádků, nezáleží na tom. U statisíců už ano. Typicky se to projeví tak, že aplikace byla roky rychlá a „najednou" zpomalila — přičemž se nezměnil kód, jen narostla data. Indexy přitom nejsou zadarmo: zrychlí čtení a zpomalí zápis. Proto se přidávají cíleně na to, co se opravdu filtruje a řadí, ne na každý sloupec. Související téma rozebíráme i v článku o [vyhledávání ve firemní aplikaci](/blog/vyhladavanie-vo-firemnej-aplikacii-full-text-filtre-a-relevancia). ## Vnímaná rychlost je polovina dojmu Dvě aplikace se stejným časem odezvy mohou působit úplně jinak. Rozhoduje, jestli uživatel vidí, že se něco děje. - **Zobrazit kostru obrazovky hned** a doplňovat data, jakmile dorazí. - **Reagovat na kliknutí okamžitě**, i když se výsledek potvrdí až po odpovědi serveru. - **Nezablokovat celou stránku** kvůli jedné pomalé části. Toto není kosmetika. Uživatel, který vidí odezvu do stovky milisekund, hodnotí aplikaci jako svižnou, i když data dorazí až po sekundě. ## Co neřešit jako první Pro pořádek i druhá strana. **Přepsání na jiný framework** rychlost samo o sobě nezlepší. **Silnější server** pomůže jen tehdy, pokud je problém opravdu ve výkonu stroje, což bývá zřídka. A **cache** přidaná před vyřešením příčiny problém skryje do chvíle, než se zobrazí neaktuální data. ## Jak to udržet Výkon se zhoršuje postupně a nenápadně — přibude sloupec, přibude vazba, narostou data. Proto se vyplatí mít měření zapnuté trvale a upozornění, když se odezva zhorší oproti minulému týdnu. Zapadá to do stejné disciplíny, jakou popisujeme u [CI/CD a bezpečného nasazování](/blog/ci-cd-a-bezpecne-nasadzovanie-softveru): problém se má ozvat sám, ne přes stížnost. ## Kde začít Vezměte tři obrazovky, které se otevírají nejčastěji, změřte je a podívejte se na počet dotazů. Ve většině aplikací se právě tam najde úspora, která je vidět okamžitě a stojí den práce. Pokud vás aplikace zdržuje a chcete vědět, kde přesně, [ozvěte se](/kontakt). Děláme to v rámci [vývoje na míru](/riesenia/vyvoj) — příklady jsou v [referencích](/referencie). --- Webová verze: https://interfase.sk/cz/novinky/rychlost-firemni-aplikace-kde-se-realne-ztraci-cas llms.txt: https://interfase.sk/llms.txt