iRozhlas — web rychlejší než zpravodajství

Začátkem roku jsme byli pozváni do výběrového řízení na front-end dodavatele nového zpravodajského portálu. Hned jsme věděli, že jde o projekt velice ambiciózní, který tvoří spousta chytrých a schopných lidí. Pro nás jednoduše záležitost, u které nesmíme chybět. A měli jsme štěstí, protože výběrko jsme vyhráli!

No tak co, nakódíte pár boxíků…

Klíčové parametry

U každého našeho projektu hledáme tři stěžejní body, podle kterých si po spuštění ověříme, zda jsme splnili nastavené cíle. Jednoduše se jedná o ukazatele, podle nichž určujeme úspěšnost a kvalitu řešení. Pro iRozhlas byly nejdůležitější:

1. rychlost
   Vycházela z projektového zadání a stala se hlavní prioritou celé práce. To, že nemáme reklamu, nás motivovalo porazit všechny konkurenty. Zaměřili jsme se na ty nejmenší detaily. Sečtené mikrooptimalizace udělaly zásadní rozdíl.
2. přístupnost
   Je běžnou součástí našich projektů. Vnímáme, že web děláme především pro lidi — uživatele, a to bez rozdílu. Kde jinde přístup k informacím vytunit na maximum než na zpravodajském portále? Je důležité si uvědomit, že chystáme front-end, který bude oslovovat širokou veřejnost. A co víc, poskytuje veřejná data. Přístup k informacím musí být snadný pro všechny uživatele. Proto jsme detailně rozebrali, jak a které HTML5 značky použít, jaké prvky navíc podpoříme wai-aria specifikací a kde je potřeba strukturu trochu rozšířit o mikrodata pomocí JSON-LD.
3. modernizace
   Viděli jsme příležitost posunout odvětví zpravodajských webů k modernějším technologiím, přístupům a uživatelskému zážitku. Určitě musíme využít SVG, HTTP2, Offline, historyAPI a mnoho dalšího.

Architektura a tooling

Vybrat správnou architekturu komponent nebo najít průsečík, kde a jak komponenty dělit, je vždy kodérský oříšek. Věděli jsme, že projekt bude dlouhodobě rozvíjený. Ambicí je zpravodajství obohatit o nové formáty komunikace, které budou na webu přibývat postupně. Proto musí být front-end snadno udržitelný a dobře rozšiřitelný. Jakou cestu tedy zvolit?

Chvíli jsme na tomto projektu experimentovali s myšlenkou funkcionálních css, ale po pár testech jsme to zavrhli. Ve výsledku by to bylo kontraproduktivní. Obzvlášť, co se responsivní verze týče.

Nakonec jsme zvolili derivát všeho. Obecně se snažíme vyzobávat z návrhových vzorů, metodik a frameworků to, co považujeme za funkční v široké škále typů projektů. Tyto části pak začleňujeme do našeho know-how. Proto vrstvení komponent vychází z atomic designu, zápis komponent z BEM, ale využíváme i utilitní třídy, takže se spíše blížíme k ITCSS.

Z toolignu je asi nejpodstatnější zmínit Webpack 2, kde využíváme eliminaci nepoužívaného kódu (tree-shaking) a také code-splitting pro umocnění využití HTTP2. Práci nám také ulehčil svgstore, kombinovaný se SVGO pro vytvoření datově optimalizovaných SVG ikonek.

Lazyloading

Řešení lazyloadingu je na tomto projektu ovládané viditelnou částí — viewportem s offsetem pod fold. Tím uživatele nezahlcujeme daty, které třeba ani nezobrazí. Pro obrázky to je základ, zvlášť pokud je chcete servírovat pro aktuální rozlišení a zařízení. Tuto metodu jsme využili třeba i pro YouTube API, audio, atd. Dosáhli jsme tak neuvěřitelného zrychlení jak samotného načtení, tak výkonu serveru.

Fotogalerie

Už dost bylo fotogalerií ze 13 století. Nikdo nechce reloadovat každou fotku a na touch zařízeních chceme swipe. Minimální velikost a maximální uživatelský zážitek nás vedl k radikálnímu rozhodnutí — naprogramujeme ji na míru.

Galerii si vyzkoušejte klidně sami

Vanilla JS

Pro dosažení opravdu rychlého načtení je především nutné zbavit se datově obřích javascriptových knihoven a frameworků. Většinou z nich stejně využijete jen část. Navíc výběrem jedné knihovny ovlivníte celou codebase a to jsme nechtěli. Stoprocentní kontrola nad daty a chováním našich skriptů nás vedla k minimální závislosti na kódu třetích stran. Ano, zní to paranoidně, ale věřte, že opravdu kvalitních ES modulů pro tento typ projektu je málo.

Mobilní featury

Zvětšování písma, inverzní a textová verze, či desktop na mobilu? To vše bez pomoci ze strany serveru, protože máme možnost jen jedné serverové cache?

No dobře. Museli jsme ale udělat drobný ústupek co se dat týče. Vše jsme zakomponovali do stylů tak, aby datový nárůst byl pro tyto varianty co nejmenší. Samotné zobrazení variant neřídí server, ale cookies. Například desktop verze na mobilu jsme docílili přepsáním viewport tagu javascriptem.

Standardní, inverzní, textová a zvětšená varianta

Pozor, pozor, spouští se nový iRozhlas.cz

Poslední dny před spuštění bylo čím dál tím větší napětí. Chtěli jsme, aby výsledek byl dokonalý. Celé Velikonoce nám vrtal v hlavě červík, zda jsme na něco nezapomněli.

Čekali jsme se zatajeným dechem, kdy přijde hodina H. Projekt se nakonec spustil v úterý 18.4.2017 brzo ráno…

…a reakce? To nás opravdu zahřálo na front-endovém srdci, protože je jasné, že jsme splnili nastavené cíle.

Bugy, ze kterých jsme se poučili

Nebyla to pouze idylická cesta k super výsledku. Objevilo se i pár záludností, které nám na chvíli zatopily v hlavách. O pár bychom se rádi podělili.

Opera Mini

Když nám tento screen poprvé přišel, dívali jsme se na sebe jak na blázny.

To musí být nějaká chyba načtení, napadlo nás. Vypadá to jako verze bez stylů, ale zároveň s barvami z CSS. To přece není možné!

To, že Opera Mini není plnohodnotný browser jsme věděli, zvlášť skrz její postoj k javascriptu. Navíc, přes veškeré snahy, se nám to na našich instalacích Opery nedařilo nasimulovat.

Po nějakém čase bádání jsme přišli na to, že se jedná o režim zobrazení, který se dá v Opeře nastavit. Konkrétně “jednosloupcové zobrazení”. Fix je naštěstí jednoduchý, stačí LINKu vašich stylů rozšířit media attribut o klíčové slovo handheld.

Position: fixed; Magic

Možná jste se setkali s otravným overscrollem na iOS, který je aktivní i ve chvíli, kdy nemáte co scrollovat. Dá se eliminovat jednoduchý trikem — css pravidlem position:fixed. To se dá na element, který vám drží 100% viewportu.

I přes veškerou snahu vyhnout se javascriptu, nám nakonec nezbylo nic jiného, protože fixní pozice je bugy při změně orientace.

Flexbox

O flexboxu se toho ve světě front-endu píše opravdu hodně. Všichni jej vychvalují až do nebes a doporučují jej implementovat ve velkém. Pokud ale potřebujete širokou kompatilibiltu, byli bychom s jeho nasazením opatrní.

Je pořád hodně bugů, kterým se musíte vyhnout. Také nás trochu pozlobil autoprefixer poháněný Caniuse databází. Pro staré androidy, i přes veškeré nastavování, negeneroval správné vlastnosti.

Front-end tým

• Michal: celý projekt supervizoval a optimalizoval rychlost načtení a výkonu. Pracoval na lazyloadingu a offline verzi.
• Petr: vybudoval celou architekturu komponent, ze kterých se skládají jednotlivé šablony. Naprogramoval interakční prvky a neúnavně ladil vše k maximální dokonalosti. iRozhlas představil také na jedné z přednášek Frontedistů.
• Karel: připravoval pro zpravodajský server unikátní fotogalerii.
• Tomáš: pomáhal projekt ideově rozvrhnout a křížově testovat.

Projektový tým

• Jiří Špaček: Project manager
• Štěpán Korčiš: Design
• Jan Pospíšil, Marek Vantuch: Backend

Závěrem bychom také rádi poděkovali Radkovi Pavlíčkovi a Romanu Kabelkovi za pomoc s otestování přístupnosti.