"Chceme tvořit věci, jež jsou přátelské vůči budoucnosti", píše se v manifestu hnutí Future Friendly. Tento manifest pokazuje na momentální a pravděpodobný budoucí stav média Web, jehož obsah lze prohlížet na velkém množství rozmanitých zařízení. Samozřejmě není v lidských silách testovat webové projekty na všech typech zařízení. Nicméně existují techniky a pracovní postupy, které pomáhají webovým vývojářům tvořit projekty přátelštější vůči budoucnosti.
V několika posledních dnech jsem měl možnost nakouknout pod pokličku několika desítkám projektů a posoudit kvalitu jejich zpracování z pohledu front-end vývoje a Future Friendly filozofie. Byl jsem až překvapen, jak moc stejné, z velké míry výkonnostní, neduhy se vyskytovaly napříč všemi projekty. V následujících řádcích bych tedy rád upozornil ty nejzávažnější z nich.
Carousely všude, kam se podíváš
Velmi dobře chápu, že je třeba návštěvníka webové stránky upoutat nabídkou skvělých produktů nebo ukázat silné stránky organizace. Sahat však prvoplánovitě po carouselu je z designerského hlediska krátkozraké. Jaké jsou důvody, proč doporučuji zamyslet se nad jiným návrhovým vzorem, než je carousel?
- Na základě časového intervalu rotace carouselu si uživatel nestihne dočíst či dostatečně prohlédnout obsah slajdu. Může ho to naštvat či zmást.
- Přepínání mezi slajdy vyžaduje interakci a uživatel často neví, co uvidí na dalším slajdu.
- Carousely jsou JavaScriptové knihovny. Některé z nich vyžadují jQuery nebo jinou podpůrnou knihovnu. Zvětšuje to velikost načítaných dat a počet requestů na stránku.
- Samotný grafický návrh webu většinou zasazuje do carouselů mohutné fotografie, což též zvětšuje velikost načítaných dat a počet requestů na stránku.
- Carousely často nebývají připraveny pro zobrazení na mobilních zařízeních. Tedy nepodporují resposivitu a dotyková gesta. A pokud jsou připraveny, vývojáři neintegrují tuto funcionalitu do konečné podoby webové stránky.
Nechci nabádat ke kategorickému vyhýbání se carouselům. Používejte je pokud jste si jisti, že jde o tu nejsprávnější volbu návrhového vzoru. Avšak když 2/3 revidovaných webů měly na homepage carousel, je jasné, že je něco špatně.
Tuny dat a requestů, i když není třeba
Jsem nadšen, že implementace responsivního web designu začíná být standartem a vídám ho u čím dál většího počtu projektů. Nicméně podoba, v jaké ho vídám není dostačující. Vývojáři se soustředí pouze na responsivní layout webu. Co však opomíjí, jsou data.
Adaptaci na malé displeje vývojáři často řeší triviálním nastavením "display: none" elementům, jež nechtějí vidět na malém displeji. Ovšem načítaná data na pozadí nikterak neřeší. V konečném důsledku bývám svědkem více než stovky requestů na stránku, kdy se stahují data v jednotkách megabajtů. Bez rozdílu, zda jde o desktopové zobrazení či mobilní, kde bývá kvůli malému displeji polovina obsahu a grafických pozlátek.
Řešením je podmíněné načítání obsahu. Tedy na základě různých podmínek, kterými může být šířka displeje či podpora určité technologie zobrazovacího zařízení, požadujeme data ze serveru.
V reálné situaci to může vypadat tak, že pokud na malém displeji nechcete vidět např. carousel, tak na základě šířky displeje budete či nebudete žádat obrázky a JavaScriptové knihovny ze serveru. Tyto podmínky lze pro specifické situace vyřešit jednoduchou JS podmínkou či můžete použít komplexnější řešení, jakým je Modernizr s integrovaným YepNopem. Blíže se této problematice věnuje Jeremy Keith ve svém článku.
Neminifikovaný a nekonkatenovaný kód
Třetím častým neduhem je používání přehnaného množství JavaScriptových a CSS knihoven, které jsou jednotlivě nalinkovány do hlavičky webové stránky. Takto znovu narůstá velikost stahovanýh dat a počet requestů na stránku. Jestliže chceme používat různé knihovny, či si píšeme vlastní, je vhodné tyto knihovny pro produkční prostředí minifikovat a následně zkokatenovat. Sníží se jak velikost dat, tak i počet requestů, tedy čas potřebný k načtení webové stránky.
Samozřejmě je ke zvážení, co vše konkatenovat. Mohou být různé důvody, proč určitý kód nechat v samostatném souboru. Jak jsem uvedl výše, některý kód můžete načítat podmíněně nebo načítat z CDN. Je tedy vždy vhodné zhodnotit, který kód se načítá vždy z vašeho hostingu a stojí za to ho zkonkatenovat, a který načítáte podmíněně či z CDN. Pro nejen tyto úkoly rád doporučím nástroj Grunt.
Tento článek byl zaměřen na časté problémy, jež vídám u webových projektů. Z velké míry jde o výkonnostní neduhy, které zpomalují rychlost načítání stránky. Jestliže snížíme čas potřebný pro načtení webové stránky, uděláme naše uživatele šťastnějšími, což se v konečném důsledku pozitivně odrazí na našem úspěchu, případně úspěchu našich klientů.
Žádné komentáře :
Okomentovat