Kvôli aktuálnej situácii s koronavírusom všetko prechádza do online sveta, no “vďaka” tomu sú rôzne svetové konferencie dostupnejšie, aj z pohodlia vlastného gauča. Konferencia web.dev LIVE trvala 3 dni a záznam zo všetkých prezentácií je už dostupný na Youtube kanáli Google Chrome Developers. Tém bolo viac než dostatok, väčšina sa zaoberala hlavne performance, security a PWA aplikáciam. A ak si doteraz nevedel, či dokonca ani nepočul, o Core Web Vitals, tak toto je zdroj, od ktorého sa dozvieš všetko potrebné.

V tomto článku nebudem rozpisovať celý program. Konferenciu som zhrnul do 5 blokov, ktoré rozoberajú hlavné témy, prípadne zaujímavé prezentácie s priloženým odkazom na video. Ako to býva, našli sa aj témy, ktoré mňa veľmi nezaujali alebo boli slabšie spracované, ale vyhodnoť podľa programu sám, či ťa nejaká téma neosloví viac ako mňa.

Prehľad, debugging a optimalizovanie Core Web Vitals

Google zaviedol 3 hlavné kvalitatívne metriky, podľa ktorých sa bude po novom sledovať, aký dobrý je používateľský zážitok na danom webe. Tieto metriky budú v ročných intervaloch aktualizované a merať ich zvládnu už takmer všetky nástroje od Google, určené na meranie performance. V Lighthouse od verzie 6 budú tieto metriky priamo ovplyvňovať výpočet Performance score.

Lighthouse v6 Performance score:
– 15 % First Contentful Paint (FCP)
– 15 % Speed Index (SI)
– 25 % Largest Contentful Paint (LCP)
– 15 % Time to Interactive (TTI)
– 25 % Total Blocking Time (TBT)
– 5 % Cumulative Layout Shift (CLS)

Largest Contentful Paint (LCP)
Metrika popisuje rýchlosť načítania najväčšieho prvku na stránke, čo pomáha určiť, ako rýchlo sa načíta hlavný obsah stránky. Pre dobré LCP by sa mal obsah načítať do 2,5 sekundy. Súvisiacou metrikou je napríklad First Contentful Paint (FCP), ale ak zobrazuje stránka ako FCP len loading screen alebo logo, pre užívateľa nie je obsah ešte dôležitý. Preto má nová metrika väčší zmysel. A čo spôsobuje pomalé LCP? Ide napríklad o pomalú odozvu servera, render blokujúce CSS a JS, alebo pomalé načítanie resources, ako veľké obrázky.

First Input Delay (FID)
Metrika podobná Time To Interactive (TTI) meria rozdiel medzi akciou užívateľa a jej vykonaním. TTI meria čas od načítania stránky do plnej interaktivity. FID je vhodnejšia metrika práve preto, že zobrazuje reálny čas odozvy stránky na akciu užívateľa. Ideálna rýchlosť odozvy je určená do 100 ms. Keďže je FID merané pomocou nástrojov monitoringu reálnych užívateľov, v Chrome devtools túto metriku nenájdeš. Slabé FID spôsobujú dlhé tasky v JS main thread alebo render blokujúce skripty.

Cumulative Layout Shift (CLS)
Frustráciu hlavne mobilných užívateľov predstavuje táto metrika, ktorá určuje stabilitu webu po načítaní. To znamená, ako veľmi obsah stránky počas načítania “poskakuje”. Metriku ovplyvňujú najmä dynamické prvky, napríklad reklamy alebo asynchrónny obsah stránky, ako info bloky atď. Odporúča sa dať pozor aj na webové fonty, obrázky alebo video bez definovaných rozmerov. Metrika vracia hodnotu medzi 0 – 1 a ideálne je držať jej hodnotu pod 0,1.

Viac detailov sa dozvieš priamo v prezentácii, kde sa preberajú novinky v Speed Toolingu.

Počas konferencie sa spomenulo viacero nástrojov a možností, ako jednotlivé metriky merať:
Chrome UX Report (CrUX)
Chrome UX Report API

Pagespeed Insights
Pagespeed Insights API

Chrome UX Dashboard
Lighthouse CI
Web Vitals Chrome extension
Web Vitals JS library
Sitekit WordPress plugin

A ako tieto metriky optimalizovať bolo veľmi dobre predvedené v Case Study e-shopu Chloe v prezentácii od Addy Osmani.

Optimalizovanie CLS:

• definovanie width a height obrázkom,
• používať aspect-ratio,
• pre lepší feeling pri lazy-loadingu používať background, podľa načítaného obrázka,
• “rezervovanie” miesta pre asynchrónny a dynamický obsah,
• minimalizovať načítanie obsahu nad už existujúci obsah stránky.

Optimalizovanie LCP:

• zobrazenie obrázka v správnej veľkosti a odstránenie nepoužitých veľkostí,
• lazy-loading obrázkov by mal načítať obrázky až v momente, keď sú vo viewporte,
• defer načítanie nie blokujúceho CSS a JS,
• vytvorenie critical CSS,
• implementácia CDN,
• používanie WebP formátu.

Optimalizovanie FID:

• servovať užívateľovi len tie skripty, ktoré reálne potrebuje,
• neblokovať main thread.

Vývoj natívnej PWA aplikácie a Google Workbox knižnica

Vytvoriť PWA aplikáciu je celkom jednoduché a vďaka minimálnej námahe vieš vytvoriť takmer z akejkoľvek stránky inštalovateľnú “aplikáciu”, nezávisle na tom, či ide o mobil alebo desktop, iOS alebo Android. Na konferencii rozoberali, ako vyvíjať PWA priamo pre Android pomocou toolu Bubblewrap, ale aj rôzne pokročilé stratégie, na čo je pri vývoji potrebné myslieť. V ukážkach kódu sa využívali knižnice z Google Workbox, ktoré pridávajú offline podporu pre Web aplikácie.

Možnosť inštalovania PWA aplikácie má pár kritérií:

• validný JSON web manifest súbor,
• aplikácia musí byť zabezpečená SSL certifikátom,
• registrovaný service worker,
• mala by byť, samozrejme, responzívna a mať definovanú ikonu správnej veľkosti.

V prípade, že aplikácia má webovú, ale aj natívnu aplikáciu, konfiguráciou related_applications je možné definovať jej natívne verzie a v prípade, že má užívateľ už aplikáciu nainštalovanú, napríklad priamo cez obchod, bude preferovaná táto verzia. Toto chovanie je možné upraviť.

Ako to už pri všetkých cool veciach býva, používatelia s IE si PWA veľmi neužijú.

Ďalšie informácie o PWA nájdeš aj na stránke web.dev.

Ako pracovať s úložiskom pre web aplikácie?

Na strane klienta je viacero možností, ako dáta ukladať. Z prednášky “Storage for the web” odporúčali využívať najmä IndexedDB pre ukladanie dát a Cache API pre HTML, JS a CSS. Cookies sa na ukladanie dát neodporúčajú vôbec a aj pri implementácii localStorage je potrebné myslieť na to, že ide o synchrónne volanie, môže teda blokovať main thread.

Každý browser ma definované svoje limity, koľko dát je možné v úložisku ukladať:

• Firefox: 2GB,
• Safari: 1GB,
• Chrome: až 60 percent z celkovej veľkosti disku.

Čo sa stane pri plnom disku? Ak sa zápis a prípadné chyby nebudú vôbec riešiť, browser automaticky uložené dáta vymaže v prípade plného disku. To môže mať za následok straty dôležitých dát, respektíve problémy vo funkčnosti aplikácie. Je teda žiadané, aby sa tieto chyby odchytávali a určilo sa programaticky, aké dáta sa majú vymazať, alebo nechalo sa priamo užívateľovi určiť, ktoré dáta chce vymazať. Aby sa predišlo náhodnému odstráneniu dát, používa sa Persistent Storage.

Jednotlivé prehliadače majú aj iné pravidlá, podľa ktorých sú dáta vymazané:
Firefox: LRU eviction policy, pri plnom disku sa odstránia dáta z najstaršie navštíveného originu, potom z ďalšieho, až kým browser nie je v limite.
Chrome: LRU policy.
Safari: No eviction policy, ale podľa aktualizácií by sa mali vymazať dáta stránky, ktorá nebola počas 7 dní navštívená. Toto by nemalo platiť pre nainštalované PWA aplikácie.

Tvorba layoutu pomocou jedného riadku CSS

Prezentácia bola výbornou ukážkou možností či už flexboxu, ale najviac príkladov bolo najmä na grid, ktorý je nepochopiteľne nedocenený. U nás v tíme taktiež, kvôli podpore a historickým dôvodom používame skôr flexbox, ale viem si predstaviť, že gridu dáme čoskoro šancu. Jednotlivé layouty popisovať nebudem, radšej si pozri priamo stránku autorky, kde sú ukážky so zdrojovým kódom. Prípadne, ak rád počúvaš podcasty, počúvaj jej podcast o CSS.

Nástroj na pomoc pri výbere správneho bundlera – tooling.report

Za zmienku určite stojí aj nástroj tooling.report, v ktorom autori porovnávajú najpoužívanejšie bundler-y ako webpack, browserify, rollup a parcel. Každý jeden bundler je podrobený veľkému množstvu testov, v ktorých sa rozoberajú jeho možnosti. Ku každému testu je pripravený krátky článok s detailnejšími informáciami. Ak sa rozhoduješ, ktorý bundler použiť alebo vyskúšať, toto je stránka určite pre teba.

Konferencia bola plná nových informácií a zaujímavých nástrojov, preto určite odporúčam konferenciu si pozrieť, alebo aspoň vybrať témy, ktoré ťa zaujímajú. Na záver prikladám odkazy s playlistom prezentácií jednotlivých dní, a ak budeš mať nejaké otázky, prípadne chuť o niečom konkrétnom podiskutovať, ozvi sa do komentárov :).

Day 1: Chrome web.dev Live 2020
Day 2: Chrome web.dev Live 2020
Day 3: Chrome web.dev Live 2020