Když se mluví o rychlosti webu, mluví se skoro vždycky o zákazníkovi. O konverzním poměru, o míře okamžitého opuštění, o Core Web Vitals. To všechno platí a v tomhle článku se k tomu taky dostaneme.
Jenže polovina hodnoty rychlého e-shopu je schovaná tam, kam se marketér nikdy nepodívá: v administraci. Tam, kde váš tým každý den odpracuje osm hodin. Tam, kde se zakládají produkty, opravují ceny, řeší reklamace a naskladňuje zboží. A tam, kde vás pomalý systém stojí peníze, které nikdy neuvidíte ve výkazu, protože nemají vlastní řádek.
Tenhle článek je pokus ten řádek dopočítat.
Proč se o rychlosti administrace nikdy nemluví
Jsou pro to tři důvody a všechny tři jsou banální.
Nikdo ji neměří. Rychlost veřejné části webu vám změří PageSpeed Insights, Lighthouse i Google Search Console. Rychlost administrace vám nezměří nikdo, protože je za přihlášením. Žádný veřejný nástroj se tam nedostane.
Neprojeví se jako výdaj, ale jako „málo stíháme“. Když administrátor čeká na načtení, pořád mu běží mzda. Náklad je zaplacený, jen za něj nedostanete odpracovanou hodinu. V účetnictví to vypadá stejně jako produktivní práce.
Lidé si zvyknou. Po třech měsících nikdo neřekne „systém je pomalý“. Řekne „to je normální, máme velký katalog“. A začne si během načítání otevírat e-mail.
Přitom platí docela nepříjemná věc: administrace je na výkon citlivější než veřejná část webu. Veřejný web se dá schovat za cache a síť serverů po světě, návštěvník často dostane hotovou stránku vygenerovanou před hodinou. Administrace tuhle možnost nemá. Každý klik je čerstvý dotaz do databáze, na aktuální stav skladu, na aktuální stav objednávky. Nedá se předgenerovat. Buď to systém spočítá rychle, nebo tam váš zaměstnanec sedí a čeká.
Kolikrát za den administrátor klikne
Správa katalogu o padesáti tisících položkách a variantách znamená nepřetržité přecházení mezi objednávkami, kartami produktů, naskladňováním, cenotvorbou a filtry. Počet akcí s načtením, tedy kliknutí, které vyvolá nový požadavek na server, ne pouhé posunutí stránky, se liší podle role.
| Role | Typická náplň | Akcí s načtením za den |
|---|---|---|
| Zákaznická podpora a vyřizování objednávek | Vyhledání objednávky, detail, změna stavu, komunikace se zákazníkem | 200 až 400 |
| Standardní administrátor | Sklad, úpravy produktů, ceny, objednávky | 500 až 800 |
| Katalogový manažer a pořizování dat | Zalistování, varianty, parametry, popisky, fotky | 1 200 až 2 000 |
Ta čísla vypadají vysoko, dokud si nerozeberete jednu jedinou rutinu. Založení produktu s deseti variantami v běžné krabicové administraci vypadá takhle: otevřít seznam, založit nový produkt, uložit, přejít na varianty, projít deset kroků generování a ukládání, přejít na sklad, přejít na ceny, přejít na kategorie, nahrát fotky, uložit, zkontrolovat náhled.
Při dvaceti nových produktech denně jste na pěti až osmi stovkách akcí jen z téhle jedné činnosti. A to je zatím jen práce, kterou jste si naplánovali, bez jediné reklamace a bez jediné opravy ceny.
Modelový výpočet pomalého a rychlého systému
Počítám s 220 pracovními dny v roce, tedy s běžným rokem po odečtení víkendů, svátků a dovolené. Odezva je vzatá jako střed intervalu, který v praxi vidím: u pomalých systémů tři až pět sekund na akci, u rychlých půl sekundy až sekunda.
Pomalý systém: průměrně 4 sekundy na akci. Za osmihodinovou směnu se to nasčítá do desítek minut, které nikde nefigurují jako náklad.
Rychlý systém: průměrně 0,75 sekundy na akci. Úspora na jeden jediný klik je 3,25 sekundy.
| Typ uživatele | Akcí za den | Čekání v pomalém systému | Čekání v rychlém systému | Denní úspora | Roční úspora | V pracovních týdnech |
|---|---|---|---|---|---|---|
| Příležitostný operátor | 300 | 20 minut | 3,75 minuty | 16 minut | 60 hodin | 1,5 týdne |
| Standardní administrátor | 600 | 40 minut | 7,5 minuty | 32,5 minuty | 119 hodin | 3 týdny |
| Katalogový manažer | 1 500 | 100 minut | 18,75 minuty | 81 minut | 298 hodin | 7,5 týdne |
Přečtěte si prostřední řádek ještě jednou. Běžný administrátor u pomalého systému stráví čtyřicet minut denně čistým čekáním. Ne prací s katalogem, ale čekáním, až se katalog objeví na obrazovce.
A teď ta horší zpráva: čtyři sekundy jsou optimistický odhad pomalého systému. U přetíženého e-shopu s velkým katalogem se seznam produktů běžně otevírá osm i patnáct sekund a hromadná operace nad tisícem položek spadne na časovém limitu. Pak se čísla v tabulce nenásobí dvakrát, ale třikrát.
Kolik to je v korunách
Průměrná hrubá mzda je pro rok 2026 stanovená na 48 967 Kč měsíčně. Zaměstnavatel k ní platí 24,8 procenta na sociální a 9 procent na zdravotní pojištění, celkový náklad tedy vychází zhruba na 65 500 Kč měsíčně. Při fondu zhruba 168 hodin je to asi 390 Kč za hodinu.
Pozice v e-shopu bývají pod celostátním průměrem, takže počítám konzervativně i s variantou 300 Kč za hodinu celkových nákladů zaměstnavatele.
| Role | Ročně pročekáno | Náklad při 300 Kč za hodinu | Náklad při 390 Kč za hodinu |
|---|---|---|---|
| Příležitostný operátor | 60 hodin | 18 000 Kč | 23 400 Kč |
| Standardní administrátor | 119 hodin | 35 700 Kč | 46 400 Kč |
| Katalogový manažer | 298 hodin | 89 400 Kč | 116 200 Kč |
Tým pěti lidí ve složení dva operátoři, dva administrátoři a jeden katalogový manažer pročeká 657 hodin ročně. To je 197 000 až 256 000 Kč vyplacených za pozorování načítacího kolečka. Každý rok. Bez jediné faktury, kterou by šlo reklamovat.
A to je pořád jen ta viditelná část.
Co o tom říká výzkum
Tohle není marketingová teorie vymyšlená kvůli prodeji webů. Vztah mezi odezvou systému a produktivitou obsluhy patří k nejlépe zdokumentovaným jevům v oboru interakce člověka s počítačem. Měřil se už v době, kdy se pracovalo na terminálech.
Hranice jedné sekundy
Jakob Nielsen z Nielsen Norman Group shrnul tři prahy lidského vnímání odezvy, které se od Millerova výzkumu z roku 1968 nezměnily.
- 0,1 sekundy. Uživatel má pocit, že systém reaguje okamžitě a že objekty na obrazovce ovládá přímo.
- 1 sekunda. Hranice, do které zůstává tok myšlenek nepřerušený. Zdržení už zaregistruje, ale neztratí nit.
- 10 sekund. Hranice udržení pozornosti. Za ní se uživatel začne věnovat něčemu jinému a po návratu se musí v úloze znovu zorientovat.
Nielsen k tomu dodává důležitou věc pro web: aby měl uživatel pocit, že se po systému pohybuje volně, musí se nová stránka zobrazit do jedné sekundy. Při pomalejší odezvě lidé prokliknou méně obrazovek.
Všimněte si, kde v tomhle žebříčku leží ty vaše čtyři sekundy.
Čtyři sekundy jsou přesně to pásmo, kde uživatel ještě neodejde, ale už není v toku. Nejhorší možné místo
IBM: produktivita neroste lineárně, ale rychleji
V roce 1982 vydali Walter J. Doherty a Arvind J. Thadhani v IBM Systems Journal studii The Economic Value of Rapid Response Time. Jejím jádrem je zjištění, které se dnes cituje jako Dohertyho práh: když spolu člověk a počítač komunikují tempem, kdy ani jeden nečeká na druhého, produktivita prudce roste, náklady na odvedenou práci klesají a zvyšuje se i kvalita výstupu.
Zásadní bod studie je tenhle: produktivita roste rychleji, než odpovídá poklesu odezvy. Do té doby se věřilo, že dvousekundová odezva nevadí, protože uživatel mezitím přemýšlí nad dalším krokem. Data ukázala, že to není pravda. Lidé mají posloupnost kroků připravenou v krátkodobé paměti a čekání jim ji rozbíjí, po každém zdržení se k plánu musejí vracet.
Konkrétní čísla z té studie stojí za vypsání.
- Transakce za hodinu. Při odezvě 3 sekundy zvládl uživatel zhruba 180 transakcí za hodinu, při odezvě 0,3 sekundy jich zvládl 371. Zkrácení odezvy o 2,7 sekundy ušetřilo ve výsledku 10,3 sekundy uživatelova času, ne 2,7. Zbytek je mentální restart.
- Úloha se prodlouží víc než odezva. V počítačovém centru National Institutes of Health se s rostoucí zátěží zhoršila odezva na průměrné 4 sekundy a průměrná doba jedné pracovní úlohy se prodloužila z 32 na 48 minut. Uživatelé tak měsíčně strávili u terminálů o 22 500 hodin víc, aniž by odvedli víc práce.
- Kvalita, ne jen rychlost. Programátorský tým v Portsmouthu dostal odezvu zlepšenou z 2,3 na 0,84 sekundy. Projekt dokončil o čtyři týdny dřív a spotřeboval o 39 procent méně člověkoměsíců. Počet chybových hlášení klesl z 6,9 na 3,0 na sto funkčních bodů, tedy na méně než polovinu.
- Platí to i pro administrativu. Kritik by mohl namítnout, že jde o inženýry a programátory. Studie proto zahrnula i pracovníky plánující zásoby komponent, tedy práci velmi podobnou naskladňování a správě katalogu. Při běžné odezvě pět a víc sekund zvládali průměrně 99 transakcí za hodinu, při odezvě pod jednu sekundu 336.
Doherty a Thadhani stanovili jako cíl 400 milisekund místo tehdy uznávaných dvou sekund. Za čtyřicet let se hardware zrychlil o několik řádů. Reálná odezva administrací velkých e-shopů se přitom u řady provozů drží pořád nad dvěma sekundami, protože veškerý výkon spolykal software.
Zkrácení odezvy o 2,7 sekundy ušetřilo 10,3 sekundy uživatelova času. Ten rozdíl je mentální restart, který si čekání vybere navíc
Skryté náklady, které se v hodinách neobjeví
Čekání na stopkách je jen viditelná špička ledovce. Pod hladinou jsou čtyři efekty, které se počítají hůř, ale bolí víc.
Rozbité soustředění
Mozek vnímá odezvu do jedné sekundy jako plynulé pokračování vlastní činnosti. Při čtyřech až pěti sekundách pozornost kolísá, a čtyři sekundy jsou přesně ten interval, kdy si člověk stihne přepnout na chat, e-mail nebo mobil, ale nestihne tam nic udělat.
Návrat k původní úloze pak nestojí ty čtyři sekundy. Stojí desítky sekund navíc, protože se do hlavy musí vrátit kontext: u kterého produktu jsem byl, jakou cenu jsem chtěl nastavit, kolik kusů mi zbývalo naskladnit. Psycholožka Sophie Leroy pro tenhle jev zavedla pojem attention residue, tedy zbytková pozornost: část pozornosti zůstává viset u předchozí činnosti i poté, co ji člověk opustil.
Přesně to popsala i data IBM. Úspora 2,7 sekundy systémové odezvy přinesla 10,3 sekundy reálně ušetřeného času uživatele, skoro čtyřnásobek. Ten rozdíl je mentální režie, kterou čekání vytváří.
Vyšší chybovost
Pomalý systém mění chování lidí, a ne k lepšímu.
- Otevírají si deset panelů najednou, aby čekali paralelně. Pak si popletou, ve kterém panelu byl který produkt.
- Spěchají, aby dohnali ztracený čas. Nezkontrolují, co ukládají.
- Kupí práci do dávek a dělají ji unavení na konci dne místo průběžně.
- Vyhýbají se kontrole. Když ověření znamená další čtyřsekundové načtení, prostě se neověří.
U padesáti tisíc variant to znamená překlepy v cenách, špatně přiřazené kódy zboží, prohozené parametry, chybný stav skladu. Každá taková chyba stojí buď marži u špatné ceny, nebo reklamaci a poštovné u špatné varianty, nebo důvěru zákazníka.
Portsmouthský tým IBM vygeneroval při rychlé odezvě méně než polovinu chybových hlášení oproti srovnatelnému předchozímu projektu. Rychlost není jen o rychlosti, je taky o přesnosti.
Násobení v týmu
Ztráta se nesčítá, násobí. Tři až pět lidí v administraci znamená 300 až 1 000 hodin ročně spálených čekáním, tedy zhruba 90 000 až 390 000 Kč podle mzdových nákladů.
A pak přijde sezóna. Na Vánoce najmete brigádníky, kteří jsou v systému pomalejší už proto, že ho neznají, a k jejich nezkušenosti se přičte zpomalení ze zvýšené zátěže serveru. Přesně ve chvíli, kdy potřebujete odbavit trojnásobek objednávek, dá vám systém nejhorší odezvu roku.
A jeden náklad navíc: lidé
Tenhle se v tabulkách neobjeví vůbec. Práce v pomalém systému je otravná. Katalogový manažer, který stráví hodinu a půl denně sledováním načítacího kolečka, nemá pocit smysluplné práce, má pocit, že bojuje s nástrojem. Doherty a Thadhani mezi přínosy rychlé odezvy explicitně uvádějí i vyšší spokojenost zaměstnanců s vlastní prací. Fluktuace na pozici, kde se člověk musí zaučit na váš katalog, stojí desítky až stovky tisíc korun.
Proč jsou administrace pomalé
Aby článek nebyl jen o číslech, tady jsou skutečné příčiny, které za pomalou administrací u velkého katalogu stojí. Pokud vám je někdo nabízí vyřešit lepším hostingem, nabízí vám aspirin na zlomenou nohu.
Administrace se nedá cachovat
Veřejnou stránku produktu můžete vygenerovat jednou a poslat ji tisíckrát z cache. Administrace tuhle možnost z principu nemá, potřebuje aktuální stav. Každý klik proto znamená plný průchod aplikací a čerstvé dotazy do databáze.
Proto se u e-shopu, který přerostl svoji technologii, administrace zpomalí jako první. Je to nejcitlivější varovný signál, jaký máte k dispozici, a většina majitelů ho ignoruje, protože zákazník to nevidí.
Datový model, který nebyl stavěný na katalog
Nejrozšířenější open source řešení ukládají vlastnosti produktů modelem EAV, tedy entita, atribut, hodnota: každá vlastnost je samostatný řádek v jedné velké tabulce. Ve WooCommerce jde o tabulku wp_postmeta, kde jeden produkt generuje běžně desítky řádků a variantní produkt jich může mít stovky.
Důsledek: seznam produktů, který má zobrazit cenu, sklad a kód zboží a nechat se řadit podle ceny, musí spojit několik tabulek dohromady a databáze u toho nedokáže efektivně využít indexy. Vývojáři v hlášení chyb u WooCommerce popisují, že u katalogů nad deset tisíc položek se samotný dotaz na výpis produktů protáhne na jednotky sekund.
Není to chyba někoho konkrétního. Je to důsledek toho, že se univerzální systém pro obsah používá jako transakční databáze zboží. Flexibilita, která je skvělá u tisícovky produktů, se u padesáti tisíc stane brzdou.
Další typické příčiny
- Dotaz navíc na každý řádek. Výpis sta objednávek udělá jeden dotaz na seznam a pak sto dalších na zákazníky, sto na položky, sto na dopravu. Místo tří chytrých dotazů jich odejde tři sta.
- Chybějící nebo špatné indexy. Databáze prochází celou tabulku řádek po řádku, protože jí nikdo neřekl, kudy hledat.
- Filtry počítané za běhu. Každé otevření seznamu znovu přepočítává, kolik produktů je v jaké kategorii, značce a cenovém pásmu.
- Doplňky. V ekosystémech, kde se funkce přidávají moduly, se každý z nich načítá při každém požadavku do administrace. Jeden špatně napsaný doplněk umí přidat jednu až tři sekundy ke každému kliknutí sám o sobě.
- Hromadné operace v jednom požadavku. Přecenění pěti tisíc položek se pokusí proběhnout během jednoho požadavku a spadne na časovém limitu. Patří na pozadí, do fronty.
- Poddimenzovaná infrastruktura. Sdílený hosting s pomalým diskem a databáze bez dostatečné paměti na cache. U katalogu, který se do paměti nevejde, se každý dotaz stává čtením z disku.
- Nahrávání obrázků na počkání. Deset fotek k produktu se zpracovává do všech velikostí, zatímco uživatel kouká na kolečko. I tohle patří na pozadí.
Jak poznáte, že vás administrace brzdí
Vezměte stopky a projděte si těchhle sedm úkonů ve vlastní administraci, ideálně v úterý dopoledne, ne v neděli večer.
- 1Otevření seznamu produktů, první strana. Cíl pod 1 sekundu.
- 2Vyhledání produktu podle části názvu. Cíl pod 1 sekundu.
- 3Otevření karty produktu s dvaceti variantami. Cíl pod 1,5 sekundy.
- 4Uložení změny ceny u jedné varianty. Cíl pod 1 sekundu.
- 5Otevření seznamu objednávek s filtrem na nezaplacené. Cíl pod 1 sekundu.
- 6Přechod na padesátou stranu seznamu produktů. Cíl pod 1,5 sekundy.
- 7Hromadná změna kategorie u pěti set produktů. Musí proběhnout na pozadí a nesmí zamrznout obrazovku.
Body šest a sedm jsou diagnostické. Pokud první strana letí a padesátá se načítá deset sekund, máte problém s datovým modelem, ne s hostingem. S rostoucím katalogem se bude zhoršovat.
A doplňková otázka, která řekne nejvíc: kolik lidí ve vaší firmě má během práce v administraci otevřený ještě druhý panel? Pokud většina, systém je pomalý. Nezvykli si na něj, obešli ho.
Jak stavím rychlé administrace já
Tady je moje odpověď na to všechno a nebude se líbit každému, protože nezní „nainstalujeme šablonu“.
Píšu řešení na míru, s vlastním kódem a vlastním datovým modelem. Ne proto, že bych chtěl vymýšlet kolo, ale proto, že u katalogu s desítkami tisíc variant je datový model to jediné, co o rychlosti skutečně rozhoduje. A ten se v krabicovém řešení změnit nedá.
Co to konkrétně znamená:
- Databáze navržená pro váš katalog. Produkty, varianty a parametry ve strukturovaných tabulkách s indexy postavenými přesně na dotazy, které váš tým reálně dělá. Žádné skládání jednoho produktu z padesáti řádků univerzální tabulky.
- Vlastní server, vlastní kontrola. Provoz na vyhrazeném výkonu, s databází, která má dost paměti na to, aby vám pracovní data držela v operační paměti. Bez sousedů, kteří vám v pondělí ráno seberou výkon.
- Rozhraní, které si říká jen o data. Administrace je samostatná aplikace a při kliknutí si nestahuje celou stránku, jen pár kilobajtů dat. Rozdíl mezi třemi sekundami a dvěma sty milisekundami bývá přesně tady.
- Okamžitá odezva. Změna ceny se v tabulce projeví hned a na server odletí na pozadí. Uživatel nečeká na potvrzení, aby mohl pokračovat. Tohle je nejlevnější cesta pod Dohertyho práh 400 milisekund.
- Práce v seznamu, ne přes deset obrazovek. Editace ceny, skladu a stavu přímo v řádku výpisu, hromadné úpravy nad výběrem, klávesové zkratky. Cílem je snížit počet akcí, ne jen zrychlit jednu. To je druhá polovina rovnice z tabulky nahoře a v praxi ta vděčnější.
- Dlouhé operace na pozadí. Import, přecenění, generování variant a zpracování fotek jde do fronty. Uživatel vidí průběh a mezitím dělá něco jiného. Nic se nekousne na časovém limitu.
- Hledání a filtry na tom, co je na ně stavěné. Fulltext a filtrování přes vyhledávací engine, ne přes desítky spojení tabulek v relační databázi.
- Měření v provozu. Sbírám doby odezvy klíčových obrazovek. Když se pomalá stránka objeví, vím o ní dřív než váš tým a vím i proč.
Námitky, které slýchám
Je to jen pár sekund, to přece přežijeme. Ne?
Přesně proto je to drahé. Kdyby to bylo pět minut, dávno byste to řešili. Náklad, který je jednotlivě zanedbatelný a opakuje se šestsetkrát denně, je nejhůř odhalitelný typ nákladu, jaký ve firmě může být. Vraťte se k tabulce se 119 hodinami ročně u jednoho jediného člověka.
Nestačí koupit silnější server?
Někdy pomůže, když je úzkým hrdlem opravdu výkon. Ale pokud se seznam produktů skládá z tisíců dílčích dotazů kvůli datovému modelu, dvojnásobný procesor vám dá dvojnásobně rychlé provádění špatného postupu. Ze čtyř sekund uděláte dvě a půl. Cíl je 0,3 sekundy a tam se dvojnásobným hardwarem nedostanete.
Není krabicové řešení levnější?
V pořizovací ceně skoro vždycky. Otázka zní, co se stane ve třetím roce, až katalog naroste. Tým pěti lidí, který pročeká 657 hodin ročně, spálí za tři roky 600 000 až 770 000 Kč, a to je jen samotné čekání, bez chyb, bez fluktuace a bez ztracených konverzí na straně zákazníka. Vlastní řešení tedy není nákladová položka, ale investice se spočitatelnou návratností.
Jak se rychlost administrace vůbec změří, když je za přihlášením?
Nejjednodušší cesta jsou stopky a sedm úkonů popsaných výše, to zvládne kdokoliv ve firmě za deset minut. Přesnější odpověď dá měření přímo v aplikaci, kdy se zaznamenává doba odezvy klíčových obrazovek u skutečných uživatelů. Veřejné nástroje jako PageSpeed Insights se za přihlášení nedostanou, takže na administraci nefungují.
Poznám z chování systému, jestli je problém v datovém modelu, nebo v hostingu?
Docela spolehlivě. Když se první strana seznamu otevře rychle a padesátá pomalu, jde o datový model a o způsob stránkování, protože obojí běží na stejném serveru. Když je pomalé všechno stejnoměrně včetně přihlášení, je podezřelá spíš infrastruktura. Rozhoduje ale až pohled do dotazů, odhad z chování je jen první vodítko.
A ano, zákazník to vidí taky
Rychlost administrace a rychlost veřejné části webu obvykle nejsou dvě různé věci. Mají tutéž příčinu, tedy datový model a architekturu. Když se opraví ta, opraví se obojí. A na straně zákazníka jsou data ještě tvrdší.
Studie Deloitte a Google s názvem Milliseconds Make Millions analyzovala reálný provoz 37 značek napříč Evropou a Spojenými státy. Zlepšení rychlosti mobilního webu o pouhou desetinu sekundy přineslo v maloobchodu o 8,4 procenta vyšší konverze a o 9,2 procenta vyšší průměrnou hodnotu objednávky, v cestovním ruchu o 10,1 procenta vyšší konverze.
Desetina sekundy. Vy v administraci řešíte rozdíl třicetkrát větší.
Shrnutí
- Administrace se nedá schovat za cache, proto zpomalí jako první a je nejlepším varovným signálem, že e-shop přerostl svoji technologii.
- Rozdíl mezi čtyřsekundovou a 0,75sekundovou odezvou dělá 60 až 300 hodin ročně na jednoho člověka, tedy 1,5 až 7,5 pracovního týdne.
- U pětičlenného týmu jde o 200 000 až 260 000 Kč ročně jen za čekání, dřív než připočtete chyby a fluktuaci.
- Výzkum od roku 1968 do dneška ukazuje totéž: hranice plynulé práce je jedna sekunda, cílový práh 400 milisekund a produktivita s klesající odezvou roste rychleji než lineárně.
- Rychlost není otázka hostingu, ale datového modelu a architektury. A ta se rozhoduje na začátku projektu.
Chcete vědět, kolik to stojí konkrétně vás
Nabízím audit rychlosti administrace. Změříme reálné doby odezvy klíčových obrazovek u vás, spočítáme počet akcí vašeho týmu za den a dostanete konkrétní číslo v korunách za rok, spolu s tím, co ho způsobuje a co se s tím dá dělat.
Pokud z auditu vyjde, že vám stačí optimalizace stávajícího řešení, řeknu vám to. A pokud vyjde, že je čas na vlastní systém, budete přesně vědět, za jak dlouho se zaplatí.
Napište mi a domluvíme si nezávaznou konzultaci.
Zdroje
- Nielsen, J.: Response Times, The 3 Important Limits, Nielsen Norman Group
- Nielsen, J.: Powers of 10, Time Scales in User Experience, Nielsen Norman Group
- Doherty Threshold, Laws of UX
- Doherty, W. J., Thadhani, A. J.: The Economic Value of Rapid Response Time, IBM Systems Journal, 1982, plný text publikovaný se svolením IBM
- Why wp_postmeta Slows Large WooCommerce Stores, Webkul
- Slow on 100k+ Products, WooCommerce, hlášení chyby číslo 11913
- WooCommerce Admin Slow, 6 Fixes That Actually Work, WPBundle
- WooCommerce Admin Slow, 5 Signs to Watch, Woosa
- Minimální, průměrná a zaručená mzda 2026, Accace ČR
- Milliseconds make millions, web.dev, Google