MarisaHardee: Die Seite wurde neu angelegt: „Typické chyby, na které narazíte: optimalizace naslepo bez měření, přehnané vkládání všeho do jednoho obřího souboru, který se stejně celý nevyužije, a testování jen na rychlé firemní síti. Vyzkoušejte stránku i na mobilních datech a se simulovaným zpomalením. Po každé změně měřte znovu a porovnávejte stejnou metriku. Zlepšení o desítky procent bývá reálné už po úpravě obrázků, komprese a cache, tedy bez zás…“

2026-10-11T15:03:28Z

Die Seite wurde neu angelegt: „Typické chyby, na které narazíte: optimalizace naslepo bez měření, přehnané vkládání všeho do jednoho obřího souboru, který se stejně celý nevyužije, a testování jen na rychlé firemní síti. Vyzkoušejte stránku i na mobilních datech a se simulovaným zpomalením. Po každé změně měřte znovu a porovnávejte stejnou metriku. Zlepšení o desítky procent bývá reálné už po úpravě obrázků, komprese a cache, tedy bez zás…“

Neue Seite

Typické chyby, na které narazíte: optimalizace naslepo bez měření, přehnané vkládání všeho do jednoho obřího souboru, který se stejně celý nevyužije, a testování jen na rychlé firemní síti. Vyzkoušejte stránku i na mobilních datech a se simulovaným zpomalením. Po každé změně měřte znovu a porovnávejte stejnou metriku. Zlepšení o desítky procent bývá reálné už po úpravě obrázků, komprese a cache, tedy bez zásahu do kódu aplikace. Rychlost načítání nezávisí jen na serveru. Většinu zpoždění způsobuje to, co si prohlížeč musí stáhnout a zpracovat až po odeslání prvního požadavku. Než začnete cokoli měnit, změřte reálný stav. V nástrojích pro vývojáře v prohlížeči otevřete panel síťových požadavků a zkontrolujte velikost přenášených dat, počet požadavků a takzvaný waterfall. První smysluplné vykreslení by se mělo vejít do dvou sekund, celková doba do načtení stránky by neměla přesáhnout tři až čtyři sekundy. Měřte opakovaně a vždy na čisté cache, jinak výsledky zkreslí uložené soubory. Zapomeňte na to, že se agilní rituály dají dělat na dálku stejně jako naživo. Denní stand-up po videu je slabý odvar. Mnohem lepší je zavést dvě úrovně komunikace: krátký písemný update každé ráno a jednou týdně delší synchronizace se všemi. Písemný update nesmí být výčet činností, ale odpověď na tři otázky: co je hotové, co blokuje, co potřebuji od ostatních. Tím se předejde zbytečným schůzkám a zároveň vzniká dokumentace pro ty, kdo pracují v jiném čase. Dalším krokem je izolace testů. Každý test by měl být nezávislý a měl by mít vlastní simulované prostředí. Nepoužívejte sdílený stav mezi testy, jinak se výsledky mohou lišit podle pořadí spouštění. Pro vazby, které se mění v čase, použijte falešné hodiny nebo plánovač, abyste mohli simulovat plynutí času bez čekání. U asynchronních operací nahraďte skutečné čekání synchronním dokončením nebo použijte řízené sliby. Tím se vyhnete náhodným selháním a testy poběží výrazně rychleji. Druhým viníkem je příliš mnoho skriptů a stylů. Prohlížeč musí nejdřív stáhnout, pak zpracovat a teprve potom vykreslit obsah. Slučte soubory tam, kde to jde, odstraňte nepoužívané pluginy a knihovny, které na stránce nic nedělají. Skripty, které nejsou potřeba pro první vykreslení, načítejte s atributy pro odložené nebo asynchronní načtení. Pozor na skripty vkládané do hlavičky bez těchto atributů — blokují vykreslení a uživatel vidí prázdnou stránku. Serverová část se často podceňuje. Zapněte kompresi přenášených textových odpovědí, nastavte dlouhou platnost cache pro statické soubory a ověřte, zda hosting zvládá souběžné požadavky. U dynamických stránek pomůže ukládání hotového výstupu do mezipaměti. Databázové dotazy v cyklu, chybějící indexy nebo načítání celých tabulek kvůli jedné hodnotě dokážou stránku zpomalit víc než samotný přenos dat. Změřte dobu odezvy serveru zvlášť od doby načítání v prohlížeči, ať víte, kde má smysl zasahovat. Kde nejčastěji vzniká zpoždění Největší chybou bývá neoptimalizovaný obrázkový obsah. Fotky v plném rozlišení z foťáku mají klidně několik megabajtů, přitom je zobrazíte v rozměru pár set pixelů. Zmenšete je na cílovou velikost, převeďte do moderního formátu a nastavte atributy šířky a výšky, aby se stránka při načítání neposouvala. U obrázků mimo první obrazovku použijte odložené načítání. Stejný princip platí pro písma: každý řez znamená další požadavek, takže si vystačíte s jedním nebo dvěma řezy a ideálně je hostujte lokálně. Mezi časté chyby patří testování pouze na nejnovější verzi systému, ignorování chování offline a opomenutí rotace displeje. Další problém je testování na zařízeních, která mají příliš mnoho aplikací na pozadí, takže výsledky neodpovídají realitě běžného uživatele. Vyplatí se také sledovat výkon: dobu startu, spotřebu paměti a plynulost posouvání. Pomalá aplikace působí dojmem chyby i tehdy, když logicky funguje správně. Při testování sledujte, jak se limit chová při souběžných požadavcích. Typická chyba je testovat pouze jeden požadavek za sekundu a pak být překvapen, že ostrý provoz dostává 429. Použijte nástroj, který umí poslat stovky požadavků najednou, a ověřte, že se počítadla správně resetují. Do odpovědi přidejte hlavičku Retry-After, aby klient věděl, kdy může zkusit znovu. Pokud omezujete podle IP, pamatujte, že za proxy musíte nastavit trust proxy, jinak všechny požadavky vypadají jako z jedné adresy. Testování mobilních aplikací se výrazně liší od testování webu. Aplikace běží na různém hardwaru, s odlišnými verzemi operačního systému, různě velkými displeji a v podmínkách, které nelze plně nasimulovat na počítači. Právě proto je potřeba kombinovat několik přístupů a nástrojů. Žádný jediný nástroj nepokryje vše a žádná metoda sama o sobě neodhalí všechny chyby.

Automatizované testy versus ruční průchod aplikací - Versionsgeschichte