Druhým častým problémem je neefektivní práce s obrázky. Formát typu JPEG je vhodný pro fotografie, ale nevhodný pro grafiku s ostrými hranami. Pro ikony a loga použijte vektorový formát, který si poradí s libovolným rozlišením. U fotografií si dejte pozor na rozměry – není nutné posílat obrázek o šířce 4000 pixelů, když ho zobrazíte v kontejneru o šířce 800 pixelů. Pomocí nástroje pro kompresi můžete dosáhnout až devadesátiprocentní úspory velikosti bez viditelné ztráty kvality. Vždy kontrolujte, zda server neposílá i takzvaný náhled, který generuje zbytečnou zátěž.<br>
<br>
<br>
<br>
<span style="font-weight: 800;">Prvním krokem je redukce</span> počtu požadavků na server. Každý soubor, ať jde o stylopis, skript nebo písmo, znamená samostatné komunikační kolo. Zkuste sloučit malé soubory do jednoho balíku, ale pozor na velikost – jeden obří soubor může být horší než pět menších. Zásadní je také pořadí načítání. Kritický obsah, který vidíte hned na první obrazovce, musí být načten přednostně. Vše ostatní, jako jsou analytické nástroje nebo posuvníky, nechte načíst až po interakci uživatele. K tomu slouží atribut pro odložené načítání skriptů, který běžně používáte.<br>
<br>
<br>
<br>
Na závěr – testování mobilních aplikací není jednorázová fáze, ale kontinuální proces. Zavádějte testy do průběžné integrace a spouštějte je při každém commit, ideálně na nejmenším počtu zařízení, která reprezentují hlavní skupiny uživatelů. Důležité je také sledovat metriky z produkce, jako jsou pády, ANR (Application Not Responding) a výkon. Až získáte dostatek dat, budete schopni optimalizovat svůj testovací plán a prioritizovat oblasti, které skutečně ovlivňují spokojenost uživatelů.<br>
<br>
<br>
<br>
Typickým chybou je měřit pokrytí na projektu, který má hodně uživatelského rozhraní a málo jednotkových testů. Testy UI jsou pomalé a křehké, a pokud se je snažíte pokrýt měřením, zjistíte, že čísla jsou nízká, ale práce s nimi je neúměrně náročná. V takovém případě je lepší se zaměřit na kritické algoritmy a logiku, a UI testy nechat být, nebo je alespoň nesledovat v rámci stejné metriky. Stejně tak nemá smysl měřit pokrytí u prototypů a jednorázových skriptů, které se zahodí.<br>
<br>
<br>
<br>
Dále prověřte, jestli váš hosting neposílá uživatelům zbytečně mnoho dat. Technologie pro automatickou kompresi textu by měla být zapnutá. Pokud ji váš hosting nepodporuje, můžete ji aktivovat vlastním konfiguračním souborem. Ale pozor – kontrola správného nastavení je nutná, protože špatně napsaný konfigurační soubor může celý web rozbít. Než cokoli nasadíte na ostrém provozu, vyzkoušejte to na testovací kopii. Změřte čas načítání před a po provedení změny.<br>
<br>
<br>
<br>
Kdy se vyplatí sáhnout po cloudových zařízeních a kdy po fyzických? Pro začátek si vystačíte s lokálními emulátory a simulátory, ale ty neodhalí problémy s výkonem na slabším hardwaru nebo s teplotou procesoru při delším zatížení. Pokud vyvíjíte aplikaci pro širokou veřejnost, je rozumné investovat do přístupu k reálným zařízením přes cloudové služby. Umožní vám to testovat na stovkách modelů bez nutnosti fyzického vlastnictví. Pozor ale na to, že cloudové služby ne vždy simulují přesně chování senzorů (např. GPS, akcelerometr) nebo síťovou konektivitu. Proto kombinujte: klíčové scénáře ověřte na fyzických zařízeních, která máte k dispozici, a širokou škálu pokryjte cloudem.<br>
<br>
<br>
<br>
Async akce jsou složitější, protože obsahují side efekty – volání API, časovače nebo jiné asynchronní operace. Bez integračního prostředí je můžete otestovat tak, že si vytvoříte mock funkcí pro dispatch a getState. Async akce obvykle vracejí funkci, která přijímá dispatch. Vy tedy zavoláte tuto funkci s mockovaným dispatch a počkáte na dokončení všech Promise. Poté zkontrolujete, jaké akce byly dispatchovány a v jakém pořadí. Tímto způsobem ověříte, že async akce správně reaguje na úspěch i na chybu API.<br>
<br>
<br>
<br>
Měření pokrytí kódu testy je užitečný nástroj, ale často se z něj stává fetiš. Mít 100% pokrytí neznamená, že je aplikace bez chyb. Spíše to může znamenat, že testy kontrolují jen to, co se snadno testuje, a ignorují složitější scénáře. Klíčové je vědět, kdy měření dává smysl a kdy jen vytváří falešný pocit bezpečí.<br>
<br>
<br>
<br>
Nakonec se zaměřte na to, co se děje při samotném zobrazování stránky. Pokud používáte hodně externích skriptů, které blokují vykreslení, prohlížeč čeká, až se načtou, a teprve poté ukáže stránku. To je nejhorší scénář. Řešením je načítat tyto skripty asynchronně, aby vykreslení neblokovaly. Typickým příkladem jsou chaty, widgety nebo mapy. Zkuste si srovnat, co je pro vaše návštěvníky skutečně důležité, a co je jen nadbytečná dekorace. Po každém odstranění jednoho zbytečného prvku znovu změřte rychlost. Nárůst rychlosti v řádu desetin sekundy je vidět i v uživatelských statistikách – okamžitě se projeví na nižším počtu opuštěných stránek.
