Konzultanta potřebujete najmout předtím, než víte, že ho potřebujete. Velký rozhovor s Harrym Robertsem

Harry Roberts je přední světový odborník na rychlost webu a vše kolem CSS. Pracuje pro klienty jako BBC, Google, NHS, Kickstarter nebo Booking.com. Má za sebou přes stovku přednášek na konferencích po celém světě. Je autorem metodiky ITCSS a frameworku Inuit CSS.

Harry, označujete se jako web performance inženýr, dříve to byl front-end architekt. Jaký druh práce vlastně děláte? Je to víc vývoj, nebo konzultace?

Nyní určitě více konzultuji. Mí klienti obvykle mají své týmy vývojářů, s nimiž spolupracuji, takže místo toho, abych sám kódoval, hledám problémy. Především mě najímají proto, abych zjistil, na čem mají vývojáři pracovat, stávám se performance engineering manažerem. Kódování mi chybí, na druhou stranu, výzvy jsou u konzultování jiné – pracuji na něčem, co má větší dopad, pracuji více s lidmi a moc mě to baví.

Říkáte tedy, že kódování Vám chybí. Udržujete se v něm nějak v kondici? Web jde kupředu mílovými kroky…

Pro mě není důležité vyznat se v Reactu, Vue, Angularu nebo dalších nástrojích. Pro mě je podstatné vědět, že existují, jak zhruba fungují, protože přesně to potřebuji, když přijde nový klient, který vyvíjí React aplikaci, jiný zase v Ruby on Rails. Potřebuji tak mít nějaké povědomí o všem. Znát všechny technologie by bylo nemožné, a tak se o to ani nepokouším. Kódování mi chybí, hlavně řešit nějaké výzvy nebo si jen tak hrát v CodePenu. Takže to občas dělám pro radost.

Jaké problémy řeší Vaši klienti nejčastěji?

Z pohledu rychlosti jsou tu dva nejčastější technické problémy. Mám na mysli software třetích stran – reklama, sledování, analytika, A/B testování – to je pro mé klienty velký technický problém. Momentálně pracuji s jedním klientem z vydavatelského prostředí, který si vydělává pouze reklamou. Reklama generuje veškeré jejich příjmy a nyní jsou ve fázi, kdy mají obavy, že jejich web je reklamou zahlcen natolik, že začínají ztrácet návštěvníky.

Plně na klientovi renderovaná javascriptová aplikace je rychlá cesta k pomalému webu.

Druhý, také trochu technický problém je přílišné zahrávání si s JavaScriptem. Plno mých klientů z posledních let postavilo kompletně na klientovi renderované javascriptové aplikace, které jsou z principu pomalé. Plně na klientovi renderovaná javascriptová aplikace je rychlá cesta k pomalému webu. Velká část mé práce proto spočívá v pomoci klientům porozumět tomu, jaká je daň za JavaScript a pochopit, jak to mohou změnit a zmírnit důsledky.

Z méně technických výzev je to pak kultura rychlosti. Ve firmách bývám vždy dva až tři týdny a lidé jsou nadšení z toho, že se nám daří jejich web zrychlit. Když se pak ale odmlčím a po nějakých třech měsících se vrátím podívat, jak se jim daří, jejich web je opět pomalý. V mé nepřítomnosti se buď k udržování rychlosti webu vyloženě nutí, anebo ne a pak se sami pomalu vrací na počátek svého problému.

Je tedy třeba vklínit rychlost do jejich procesů, způsobu práce a nastavení mysli.

Přesně tak. Z velké části by stačilo měřit dopad rychlosti na výkon webu, stanovit si KPI. Můžeme pak změřit, že nám stoupá bounce rate nebo klesají konverze, kdykoli web běží pomaleji. A to už přiměje k panice i lidi v netechnických pozicích.

Co pro mě jako zákazníka znamená rychlý a spolehlivý web? Nejsou to jen pocity?

Tak trochu. Říkávám, že uživatel nemá stopky. Uživatelé mají svůj pohled na web. Nezajímá je čas ani čísla, ale to, zda jim používání webu připadalo rychlé a že nebylo stresující.

Uživatel nemá stopky.

Jedny aerolinie – nebudu je jmenovat, nejsou mým klientem, ale často si u nich kupuji letenky – mají takový web, který je snad tou nejpomalejší a nejméně spolehlivou stránkou na světě. Kdykoli musím jejich web použít, cítím úzkost. Letenky stojí často stovky, někdy tisíce eur a já si nikdy nemůžu být jistý, jestli ten web znovu nezamrzne, nespadne, zda nebudu muset znovu načíst stránku, jestli platba neproběhla dvakrát, nebo dokonce vůbec ne…

Je to příklad čirého zoufalství, které by vyřešilo měření aspoň nějakých dat, třeba množství javascriptových chyb v produkčním prostředí. Přesně to jsou čísla, data, statistiky, které se snažím najít a jejichž sledování zabrání zoufalství uživatelů.

WebExpo 2019 obrazem

Dvanáctý ročník největší konference o webu ve střední Evropě právě skončil. Téměř čtyři dny nabité řečníky, workshopy a parties (někdy i na jevišti). Vše zarámované atmosférou historického centra Prahy.

Frontend GardenAdam Kudrna

Dnes existuje celá řada metrik pro měření rychlosti webu. Které jsou podle Vás nejdůležitější a jaké nástroje používáte pro jejich měření?

To zcela závisí na druhu webu. Pro webovou aplikaci typu Google Docs bychom mohli měřit, za jak dlouho má uživatel možnost zadávat obsah, byla by to metrika specifická pro danou aplikaci. Pro jízdní řády by to bylo, za jak dlouho uživatel zjistí, kdy mu jede další vlak. Pro online zpravodajství zase za jak dlouho si může uživatel přečíst název článku. Jsou to cíle velmi specifické pro daný druh webu. S využitím User timing API můžeme zjistit, jak dlouho trvalo vykreslit titulní obrázek nebo nadpis článku. Data z User timing API můžeme posílat do SpeedCurve nebo Google Analytics. Z dalších metrik je stále relativně užitečný speed index nebo time to interactive, naopak časy načtení můžeme úplně ignorovat.

Takže pokud záleží jen na tom, za jak dlouho mohu jako uživatel s webem pracovat, celkový čas načtení pro mě není relevantní.

Je to tak. Čas načtení můžeme ale i tak stále měřit, už jen proto, že je to snadné. Pokud se web načítá 50 vteřin, bude pravděpodobně pomalý a naopak. Takže souvisí to spolu, ale není to důležité.

Souvisí s rychlostí webu organizace kódu? Pokud ano, jak?

Jistě. Spousta lidí si neuvědomuje, jak moc CSS souvisí s rychlostí webu. CSS blokuje vykreslování, vaše stránka se vykreslí pouze tak rychle, jako její nejpomalejší styly. Modularizace CSS tak, aby každá stránka načítala jen takové CSS, které skutečně potřebuje a které se zbytečně neopakuje, je pro výkon prospěšná.

Vybavuji si klienty, kteří měli tak ohromné CSS, že jste skutečně mohli vidět, co je tím, co jejich web zpomaluje. Pokud máte ve stylech Foundation, Bootstrap, spousty pluginů a jQuery UI, pak 1,2MB CSS váš web opravdu zpomaluje. Takže ano, velmi to spolu souvisí. Dnes je úzkým hrdlem pro výkon JavaScript, ale ještě před pár lety, než vše začalo být plně javascriptové, to bylo CSS, byť to částečně platí dodnes.

AMP, Accelerated Mobile Pages, je nový open-source HTML framework na vzestupu. Staví na podmnožině HTML 5 a umožňuje stavět pekelně rychlé weby, zejména pokud se je podaří držet v AMP cache, např. u Googlu. Je AMP dostatečně zralý na to, aby byl brán vážně jako náhrada stávajícího ekosystému?

Záleží jakého ekosystému, byl bych však nerad, aby AMP cokoli nahrazoval. Záměr AMP se zdá být velmi dobrý. Všichni chtějí rychlý web. Problém je, že vývojáři se léta pokoušeli přesvědčit manažery nebo klienty o tom, že potřebují rychlý web, ale nikdo je neposlouchal. Když to samé zaznělo z mocného Googlu, manažeři a klienti otočili.

Je to nejuzavřenější otevřená platforma, jakou mohli stvořit.

Hlavní cíl AMP je tedy dobrý, implementace – vynucování nesprávného HTML – však připomíná vendor lock-in. Je to nejuzavřenější otevřená platforma, jakou mohli stvořit. Vlastní markup, spoléhání na ekosystém… Když se AMP rozhodne, že zruší podporu vlastních fontů, tak jste možná právě utratili stovky nebo i tisíce dolarů za vlastní písma, která nemůžete použít. Pracují na tom, poslouchají vývojářskou komunitu, ale stále je to standard, který navrhla a udržuje největší inzertní firma na světě. Zcela jistě to nedělají pro radost, ale z nějakého důvodu.

Takže cíl AMP je dobrý, dělají to lépe než kdysi, přesto tomu úplně nefandím. Myslím, že ikonku blesku ve výsledcích vyhledávání by měly mít i jiné rychlé weby, to může Google zjistit při procházení. Zároveň, pokud je to rychlý AMP web, znamená to, že je rychlá i jeho verze bez AMP? Ale to je na delší diskusi.

Jste autorem ITCSS, metodiky pro organizaci škálovatelného a udržitelného CSS kódu. Jak byste popsal základní ideu ITCSS?

Tradiční pojetí CSS je v zásadě jeden monolitický stylopis, kde každou novou věc přilepujeme na jeho konec. Takové CSS roste a roste. Později jsme začali CSS modularizovat, součástí toho byly i preprocesory, což už vypadalo lépe, ale stále jsme neměli žádnou jednotnou strukturu. I tak jsme mohli opět skončit přilepováním na konec našeho hlavního CSS souboru. Mým záměrem proto bylo eliminovat lidský pohled na strukturování stylů, např. na typografii, stránku, tlačítka. Rozdělil jsem styly do vrstev, které více odpovídají tomu, jak CSS funguje. Základním principem je psát CSS tak, jak by si je prohlížeč přál obdržet, tedy věci s nízkou specificitou a dalekým dosahem nejdříve, v rychlosti nastylovat celý DOM, a postupně dávat prohlížeči design s vyšší specificitou a explicitou. Tím získáme nízkou redundanci, vyhneme se soubojům se specificitou a píšeme styly v podobě, v které jsou vhodnější pro prohlížeč spíše než pro člověka.

Rozdělil jsem styly do vrstev, které více odpovídají tomu, jak CSS funguje.

ITCSS bylo vždy tak trochu obestřeno mlhou. Často jste o něm mluvil, napsal nějaké články, i jiní o ITCSS psali a mluvili, nicméně oficiální web je prázdný dodnes. Rozhodl jste se detaily svého vynálezu držet v tajemství. Proč to? Bylo to potřeba?

Není to sice closed-source, na druhou stranu ani open-source…

Takže něco jako AMP?

Vlastně možná ano. V první řadě se nestydím za to, že jsem vývojář na volné noze. Nemohu dávat zdarma vše, co vím. Většinu zdarma dávám, ale ITCSS je pro mě a mé klienty cenné duševní vlastnictví. Lidé mají k dispozici různé dílky v článcích, sám jsem se o ITCSS ve svých prezentacích také zmiňoval, nicméně vždy jsem si je držel ne sice v tajemství, ale blízko svému srdci. Je to ostatně i cenný zdroj příjmů. Chystám se dát část ITCSS k dispozici, protože se nyní zaměřuji méně na CSS a více na rychlost webu. V mezičase jsme také společně se SkillShare spustili ITCSS kurz, který je zdarma.

Je tedy v pořádku, pokud ITCSS používám ve svých projektech?

Samozřejmě. ITCSS je bez licence. Neexistuje k němu žádný kód, protože to není knihovna, ale způsob myšlení. Něco jako MVC.

Robin Pokorný (přichází a připojuje se s dotazem): Dáte si s námi stejk?

Zatím nemám hlad, ale dejte si!

Co si myslíte o CSS v JavaScriptu?

Nevidím na tom nic špatného. Je to ale hodně kontroverzní. Říkám k tomu, že když jsme kdysi začali používat SASS, technicky to bylo CSS v Ruby. A nikomu to nevadilo, nikdo tomu neříkal „CSS v Ruby“. Ve chvíli, kdy jsme totéž začali dělat v JavaScriptu, CSS vývojáři, kteří nemají JavaScript v lásce, se vyděsili: „Ne, neberte nám naše CSS!“

Dokud k uživateli přichází CSS, netrápí mě, v čem je napsané.

Můj názor na CSS v JavaScriptu je, že je to jen prostředník. Dokud je CSS tím, co se po drátu posílá k uživateli, ať už je uložené v externím souboru nebo je importované jako inline styly, nevadí mi to. Nemyslím si, že CSS v JavaScriptu by byl špatný nápad. Jediné, co je špatný nápad – ale dnes už se to neděje tolik, jako v počátcích CSS v JavaScriptu –, je parsovat CSS za běhu aplikace. Znamenalo to tehdy, že vaše CSS bylo jedním dlouhým řetězcem v JavaScriptu, který se pokaždé na klientovi parsoval do CSS. To není dobré.

Takže můj názor na CSS v JavaScriptu je, že dokud se uživateli posílá CSS, tak mi to nevadí, ať už je to vanilla CSS, SASS, Emotion, Styled Components…

Jaký má na webový projekt vliv vývoj UI knihovny ve smyslu udržitelnosti a výkonu?

Výhody UI knihovny poznáte, když chcete dělat redesign nebo jen drobné úpravy vzhledu, toho by mělo být možné dosáhnout na jednom místě. UI knihovna se pak automaticky nasadí všude. Také to znamená, že když narazíte na chybu a máte spousty různých stránek, produktů nebo značek, jeden tým může tu chybu opravit a ostatní týmy dostanou opravu bez práce.

Ohledně výkonu se vracíme k tomu, co jsme si již říkali – menší CSS vždy zlepší čas zahájení vykreslování. Design systémy, UI knihovny, či ať už tomu říkáme jakkoli, mají za cíl právě snížit velikost CSS. Tlačítka máme v kódu jen jednou. Carousely máme jen jednou. Doufejme – nebo možná raději ani jednou…

V CSS je řada skvělých nových vlastností jako grid nebo custom properties, které nám zjednodušují život. Jak si s nimi poradíte, když potřebujete podporovat Internet Exporer?

V podporování prohlížečů jsem poměrně nemilosrdný. V zásadě myslím, že obsah by měl zůstat dostupný. Rychlý příklad. Pracuji pro britskou vládu, konkrétně Národní zdravotnickou službu (NHS), na kterou jsem velmi hrdý, jen mají potíže s podporou prohlížečů. Mají 65 milionů potenciálních zákazníků z celé Británie, kteří mohou používat připojení a zařízení jakéhokoli typu, jakýkoli prohlížeč.

Zároveň spousta doktorů v nemocnicích či jinde uvízlo na Windows XP. Musíme tedy podporovat skutečně dlouhý seznam zastaralých prohlížečů. Jedna z prvních věcí, které jsem NHS řekl, byla, že se nebudeme snažit o to, aby jejich web vypadal všude úplně stejně. Pokud používáte Internet Explorer 8, většina webu vám stejně nefunguje. Bylo by proto opravdu divné, kdybychom utráceli čas a tisíce a tisíce liber za to, aby náš web vypadal dobře v IE 8. Pokud tito lidé používají IE 8 pouze v práci, jsou na to zvyklí. Pokud používají IE 8 doma, protože je to jejich volba, většina webu jim stejně nefunguje.

Pokud používáte Internet Explorer 8, většina webu vám stejně nefunguje. Bylo by proto opravdu divné, kdybychom utráceli čas a tisíce a tisíce liber za to, aby náš web vypadal dobře v IE 8.

Můj názor tedy je, že pokud uživatel může přečíst text, uvidí obrázek a dovede webem procházet, nezajímá ho, jak web vypadá. Důležité informace by měly být vždy dostupné.

Pokud chci využít grid, který nefunguje v IE 10, jednoduše nabídnu uživatelům IE 10 jednosloupcový layout, jako na mobilu. Nebudu utrácet tisíce liber za psaní pravděpodobně mnohem horšího kódu. Buďme pragmatičtí, využijme silných stránek prohlížečů, případně jejich slabin a ušetřme lidem čas i peníze.

A custom properties bych nedoporučil na cokoli kritického. Hodí se třeba na tmavé téma, to není kritické. Na stylování celé typografické škály webu už bych custom properties nepoužil, je to příliš zásadní na to, aby to mohlo nefungovat. Zde bych využil SASS a pro cokoli nekritického ať to jsou custom properties.

Jak lidé reagují na to, že konzultujete jejich práci? Neznamená to pro ně, že to celé dělají špatně?

To je výborná otázka. Řeknu Vám tajemství. Existuje tzv. Prime Directive od Norma Kertha, je to roky staré a je to součást agilního manifestu. Při každé retrospektivě se nahlas čte tato věta: „Ať už jsme zjistili cokoli, upřímně věříme, že jsme udělali vše, co bylo v našich silách a možnostech.“ A já tomu věřím. Nemyslím si, že by někdo z mých klientů dělal weby schválně pomalé, to by bylo divné. Jsou to jednoduše vývojáři, kteří jsou pod tlakem, kteří mají termíny, svazuje je třeba i interní politika.

„Ať už jsme zjistili cokoli, upřímně věříme, že jsme udělali vše, co bylo v našich silách a možnostech.“

Kdykoli předávám klientovi svůj revizní dokument, první věc, která v něm stojí, je právě Prime Directive. Říkám jim, zejména vývojářům, kteří se mohou cítit ohroženi: nepřiložil jsem ruku k dílu, nevyvinul jsem jedinou funkcionalitu, neměl jsem žádné termíny. Mým úkolem je najít věci, které jste neviděli, to je můj jediný úkol. Vy jste jako vývojáři museli řešit spoustu problémů, abyste stihli deadline, zatímco mě najali k tomu, abych se soustředil na jedinou věc, která mě shodou okolností baví, a samozřejmě najdu věci, které jste vy nenašli. A nemyslím si, že jste odvedli špatnou práci. Jsem tu od toho, abychom ji udělali ještě lepší.

Jak při konzultování přesvědčíte lidi ke změně, pokud přes krátkodobé komplikace nevidí dlouhodobé přínosy?

Pomáhám jim tím projít. Mou prací není říkat „udělej tohle, protože je to jednoduché nebo protože bys měl“, místo toho jim říkám, „tohle bude nějakou dobu trvat, a proto jsem tady, uděláme to společně.“

Jiná věc je, že mám hromadu klientů, kteří si mě najali, zaplatili mi, a přesto nedělají to, co jsem jim poradil. Částečně se cítím provinile a říkám si, že jsem selhal, nic se nezměnilo, ale částečně to beru tak, že je to jen a jen jejich chyba. Jsem tu, abych jim pomohl, ale když nechtějí…

Před lety jsem měl klienta, který si mě najal z jiného důvodu, byly to CSS konzultace, a já jim říkal: „Vím, že jsem tu kvůli jiné práci, ale váš největší problém je rychlost, váš web je příliš pomalý.“ Byl to stále ještě prototyp, takže bylo dost času na to to opravit. Odpověděli, že je výkon netrápí, protože všichni jejich zákazníci budou na WiFi, budou mít iPhone a kdo ví co ještě. Nebyl jsem si jistý, jak to chtěli zařídit, ale řekl jsem jim svůj profesionální názor, že zlepšení CSS jejich produkt nezlepší, ale zvýšení rychlosti ano. Zůstali jsme jen při CSS. A letos jsem od nich dostal e-mail: „Zákazníci v Mexiku začali používat náš web a nemají ani iPhony, ani WiFi… Můžete nám pomoci web zrychlit?“ A já odpověděl, že ano, ale že jsem na to upozorňoval. I to se děje.

Kdy si potřebuji najmout konzultanta?

Má rafinovaná odpověď je „předtím, než víte, že ho potřebujete“. Potíž je, že to nikdy nenastane. Bohužel, většina e-mailů, které dostávám, je od klientů, kteří svůj web již postavili, jsou v cílové rovince, jenže pak si uvědomí, že tenhle příběh nebude mít šťastný konec. Po vší té práci se tedy obrátí na mě s dotazem, zda si myslím, že je to dostatečně dobré. A já jim odpovídám: ne, není, tohle opravdu potřebujete předělat.

Konzultanta si potřebujete najmout předtím, než víte, že ho potřebujete.

Jenže už je pozdě.

Většinou dostávám e-maily až když je příliš pozdě. Přál bych si, abych je dostával dříve.

Ale pak by Vás nepotřebovali, ne?

Ne tak docela. Nedávno jsem dostal jednu poptávku od klienta, který psal: podívejte, máme v plánu redesignovat svůj web, chceme začít na zelené louce a chceme si být jistí, že to děláme pořádně. Mě tedy nepotřebují, protože neudělali nic špatně, ale pokud mě najmou včas, mohu jim ukázat workflow, nástroje, nastavit procesy a performance budgety. A díky tomu nikdy neudělají nic špatně. Tedy to možné je. Potíž je, že většina firem neutrácí peníze, dokud nemá problém. Zatímco já bych preferoval, aby utráceli peníze za to, že se problémům vyhnou. Na druhou stranu, dokud peníze utrácejí, tak s tím problém nemám.