Hlavní práce73640_brel05.pdf, 3.7 MB Stáhnout

(1)

Vysoká škola ekonomická v Praze

Fakulta informatiky a statistiky

Vliv renderingu webových aplikací na web vitals metrics a SEO

DIPLOMOVÁ PRÁCE

Studijní program: Aplikovaná informatika Studijní obor: Znalostní a webové technologie

Autor: Bc. Lukáš Březina

Vedoucí diplomové práce: Ing. et Ing. Stanislav Vojíř, Ph.D.

Praha, červen 2021

(2)

(3)

Poděkování

V první řadě bych rád poděkoval vedoucímu práce Ing. et Ing. Stanislavu Vojířovi, Ph.D. za všechen čas, odborné rady, trpělivost i slova povzbuzení po celou dobu vedení práce. Dále bych rád poděkoval Lukášovi Bartákovi a potažmo všem spolupracovníkům ve firmě COEX s.r.o., kteří byli inspirací pro volbu tohoto tématu práce, a kteří mi poskytli spoustu konzultací a tipů, jak postupovat. Poděkování patří také faráři Michaelovi Špilarovi za možnost implementování aplikace pro farní sbírky v jejich farnosti a za cennou zpětnou vazbu při tvorbě této aplikace. V neposlední řadě pak velké poděkování patří celé mé rodině, bez jejíž pomoci a podpory po celou dobu studia by tato práce nejspíš ani nemohla nevzniknout.

(4)

Abstrakt

V poslední dekádě v oblasti vývoje webových aplikací roste obliba tzv. client-side renderovaných aplikací. Server u těchto aplikací vrátí pouze základní HTML kostru odkazující na javascriptovou aplikaci, pomocí které se již stáhnou potřebná data a vykreslí se požadovaný obsah stránky. Tento přístup má své výhody z hlediska interaktivnosti aplikace, ale může mít také nevýhody, zejména v oblasti výkonnosti aplikace na slabších zařízeních a ztížené či problémové indexaci webu internetovými vyhledávači. Tento problém se snaží řešit další přístupy k renderingu webových aplikací. U těchto jednotlivých druhů renderingu jsou teoreticky popsána jejich specifika a vliv jejich volby na výkonnost a indexovatelnost aplikací. Tato tvrzení však nebývají podložena měřeními na konkrétních aplikacích.

V této práci jsou shrnuty možnosti, jak lze v současnosti renderovat webové aplikace. Tato problematika je řešena nejen z teoretického, ale i z praktického hlediska. Při realizaci práce byly navrženy a naimplementovány dvě reprezentativní webové aplikace za použití čtyř druhů renderingu – server rendering, client-side rendering, server-side rendering a prerendering. Za využití těchto aplikacích jsou dané druhy renderingu měřeny, porovnány a vyhodnoceny v oblasti výkonnosti a přizpůsobivosti pro webové vyhledávače. Porovnána je také náročnost implementace daných přístupů. Další přidanou hodnotou této práce je pak jedna z testovacích aplikací – aplikace elektronické farní sbírky, která je reálně používána, a díky které bylo možno měřit výkonnost jednotlivých druhů renderingů v reálném provozu.

Klíčová slova

Webová aplikace, rendering, server rendering, client-side rendering, server-side rendering, prerendering, výkonnost, search engine optimization

JEL klasifikace

C89

(5)

Abstract

In the last decade, the popularity of client-side rendered applications has been rising in the field of web application development. In these applications, the server returns only a basic HTML skeleton that points to a javascript application, that obtains the needed data and renders the desired page content. This approach has its advantages, especially in application interactivity, however it could have some disadvantages too – whether in worse performance when using less powerful devices or whether in more difficult and problematic content indexing by search engines. Other approaches to web application rendering attempt to address this problem. For these approaches, while the specifics of these renderings and the subsequent impact on performance and indexability are described in theory, their comparison on real-world applications is lacking.

This thesis summarizes how web applications can be rendered. This problem is addressed on both theoretical and practical level. As a part of this thesis, two representative web applications are designed and implemented using four types of rendering – server rendering, client-side rendering, server-side rendering and prerendering. These applications are then used to measure, compare, and evaluate these rendering types in terms of performance and search engine optimization. Implementation complexity between these renderings is also evaluated. Another added value of this work is one of the test applications – the parish donation application, which is being used by local parish and thanks to which it was possible to measure the performance of different types of renderings on real devices.

Keywords

Web application, rendering, server rendering, client-side rendering, server-side rendering, prerendering, performance, search engine optimization

JEL Classification

C89

(6)

Obsah

Úvod... 14

1 Druhy renderingu ... 16

1.1 Server rendering ... 16

1.2 Client-side rendering ... 17

1.3 Client-side rendering with prerendering... 19

1.4 Server-side rendering with (re)hydration ... 20

1.4.1 Rehydration ...21

1.4.2 Progressive hydration ... 22

1.4.3 Partial rehydration ... 22

1.4.4 Trisomorphic rendering ... 22

1.5 Static server-side rendering ... 23

1.6 Dynamic server rendering (Turbolinks style) ... 24

1.7 Dynamic rendering ... 24

1.8 Shrnutí ... 25

2 Měření výkonnosti webu ... 27

2.1 Metody měření ... 27

2.1.1 Syntetická měření ... 27

2.1.2 Měření reálných uživatelů ... 27

2.2 Metriky měření ... 28

2.2.1 Time To First Byte (TTFB) ... 28

2.2.2 First Paint (FP) ... 29

2.2.3 First Contentful Paint (FCP) ... 29

2.2.4 DOM Content Loaded (DCL) ... 29

2.2.5 First Meaningful Paint (FMP) ... 29

2.2.6 Largest Contentful Paint (LCP) ... 29

2.2.7 First Input Delay (FID)... 32

2.2.8 Time to interactive (TTI) ... 32

2.2.9 Total blocking time (TBT) ... 33

2.2.10 Cumulative Layout Shift (CLS) ... 33

2.2.11 Load ... 33

2.2.12 Speed Index ... 33

2.2.13 Lighthouse Performance Score ... 34

3 Vyhledávače, SEO a rendering ... 35

(7)

3.1 Definice SEO ... 35

3.2 SEO on-page optimalizace ... 35

3.2.1 Title tag ... 35

3.2.2 Meta tag description ... 36

3.2.3 Obsah stránky ... 36

3.2.4 Strukturovaná data ... 36

3.2.5 Přizpůsobení stránky pro mobilní zařízení ... 37

3.2.6 Sitemap ... 37

3.3 Metody měření SEO ... 37

3.3.1 Indexovatelnost ... 38

3.3.2 Měření počtu přístupů ... 38

3.3.3 Pořadí stránky ve výsledcích pro zadaný dotaz ... 38

3.3.4 Google Lighthouse SEO audit... 38

3.4 Specifika jednotlivých vyhledávačů ... 38

3.4.1 Google ... 38

3.4.2 Bing ... 39

3.4.3 Seznam vyhledávač ... 39

3.4.4 Facebook, Twitter ... 39

4 Jednostránková aplikace ... 40

4.1 Popis aplikace ... 40

4.2 Specifikace aplikace ... 40

4.2.1 Hlavička ... 41

4.2.2 Informace o sbírkách ... 41

4.2.3 Formulář pro vytvoření platby ... 41

4.2.4 Výpis akcí ve farnosti ... 43

5 Specifikace e-shop aplikace ... 45

5.1 Popis aplikace ... 45

5.2 Specifikace komponent aplikace ... 45

5.2.1 Záhlaví ... 45

5.2.2 Hlavička ... 45

5.2.3 Banner ... 46

5.2.4 Karta produktu ... 46

5.2.5 Stránkovač ... 47

5.2.6 Karta vlastnost produktu ... 47

5.2.7 Box přidat do košíku ... 48

(8)

5.2.8 Patička ... 48

5.3 Specifikace jednotlivých stránek aplikace ... 49

5.3.1 Domovská stránka ... 49

5.3.2 Detail kategorie... 49

5.3.3 Detail produktu ... 49

5.3.4 Statická stránka ... 50

6 Metodologie testování a vyhodnocování ... 51

6.1 Testovací aplikace ... 51

6.2 Metody renderingu ... 51

6.3 Výkonnostní metriky ... 52

6.3.1 Syntetické měření pomocí Lighthouse ... 52

6.3.2 Syntetické měření pomocí Pagespeed.cz ... 52

6.3.3 Měření reálných uživatelů ... 52

6.4 Měření SEO ... 52

6.4.1 Výsledek vyhledávání ... 53

6.4.2 Pořadí ve vyhledávačích pro dosud neexistující produkty ... 53

6.4.3 Google product snippet ... 53

6.4.4 Facebook snippet ... 53

7 Implementace... 54

7.1 Technologie pro implementaci ... 54

7.2 Instalace, spuštění, nasazování ... 54

7.3 Jednostránková aplikace ... 55

7.3.1 A/B proxy... 55

7.3.2 Sbírání metrik reálných uživatelů ... 55

7.3.3 Farní události... 56

7.3.4 Frontend aplikace ... 57

7.4 E-shop ... 61

7.4.1 Backend ... 61

7.4.2 Frontend aplikace ... 62

8 Objektivní vyhodnocení ... 65

8.1 Jednostránková aplikace ... 65

8.1.1 Výkonnostní syntetické měření pomocí Lighthouse ... 65

8.1.2 Výkonnostní syntetické měření pomocí Pagespeed.cz ... 66

8.1.3 Výkonnostní měření reálných uživatelů ... 67

8.2 E-shop – výkonnost ... 67

(9)

8.2.1 Výkonnostní syntetické měření pomocí Lighthouse ... 67

8.2.2 Výkonnostní syntetické měření pomocí Pagespeed.cz ... 69

8.3 E-shop – SEO ... 71

8.3.1 SEO – Výsledek vyhledávání ... 71

8.3.2 SEO – počet zaindexovaných výsledků ... 74

8.3.3 SEO – Pozice ve vyhledávačích pro dosud neexistující produkty ... 74

8.3.4 SEO – Google product snippet ... 75

8.3.5 SEO – Facebook snippet... 75

9 Subjektivní vyhodnocení ... 77

9.1 Implementační přívětivost ... 77

9.1.1 Srovnání architektur, nasazování do produkce a potřebných znalostí programátorů ... 77

9.1.2 Svůdnost ke špatným praktikám ... 78

9.2 Uživatelská přívětivost ... 78

Závěr ... 80

Použitá literatura ... 82 Přílohy ... I Příloha A: Wireframe aplikace farní sbírky ... I Příloha B: Wireframe e-shop zahradnictví ... IV Příloha C: Zdrojové kódy aplikací ... VIII

(10)

Seznam obrázků

Obrázek 1 Jak funguje rendering engine (Garsiel, 2009) ... 16

Obrázek 2 Trisomorphic rendering diagram (Miller a Osmani, 2019) ... 23

Obrázek 3 Dynamic rendering (Google LLC, 2020a) ... 25

Obrázek 4 Shrnutí jednotlivých metod renderingu (Miller a Osmani, 2019) ... 26

Obrázek 5 Postupný vznik událostí pro vykreslování stránky (Michálek, 2020a) ... 28

Obrázek 6 LCP vs FCP (Michálek, 2020c) ... 32

Obrázek 7 Jednostránková aplikace: hlavička ... 41

Obrázek 8 Jednostránková aplikace: informace o sbírkách ... 41

Obrázek 9 Jednostránková aplikace: formulář pro zadání platby – dar farnosti ... 42

Obrázek 10 Jednostránková aplikace: formulář pro zadání platby – nedělní sbírka... 43

Obrázek 11 Jednostránková aplikace: výpis akcí ve farnosti ... 44

Obrázek 12 E-shop: záhlaví ... 45

Obrázek 13 E-shop: hlavička ... 46

Obrázek 14 E-shop: testimonial ... 46

Obrázek 15 E-shop: Karta produktu ... 47

Obrázek 16 E-shop: stránkovač ... 47

Obrázek 17 E-shop: Karta vlastnost produktu s ikonkou ... 48

Obrázek 18 E-shop: Karta vlastnost produktu bez ikonky ... 48

Obrázek 19 E-shop: box přidat do košíku... 48

Obrázek 20 E-shop: patička ... 49

Obrázek 21 Ukázka Google tabulky se záznamy výkonnostních metrik... 56

Obrázek 22 Výsledek vyhledávání: Google.com ... 72

Obrázek 23 Výsledek vyhledávání: Seznam.cz ... 73

Obrázek 24 Výsledek vyhledávání: Bing.com ... 74

Obrázek 25 Google product snippet preview... 75

Obrázek 26 Facebook snippety – vlevo nahoře CSR, vpravo nahoře SR, vlevo dole SSR, vpravo dole prerender ... 76

(11)

Seznam tabulek

Tabulka 1 Metriky, jejich váhy a ideální hodnoty pro získání 100 % hodnocení v Lighthouse

Performance Score od Lighthouse verze 6 (Michálek, 2020a) ... 34

Tabulka 2 Jednostránková aplikace: synteticky naměřené výkonnostní metriky pomocí Lighthouse ... 66

Tabulka 3 Jednostránková aplikace: synteticky naměřené výkonnostní metriky pomocí Pagespeed.cz ... 66

Tabulka 4 Jednostránková aplikace: naměřené výkonnostní metriky reálných uživatelů . 67 Tabulka 5 E-shop: průměr skóre napříč stránkami pro mobilní zařízení ... 68

Tabulka 6 E-shop domovská stránka: synteticky naměřené výkonnostní metriky pomocí Lighthouse ... 68

Tabulka 7 E-shop detail produktu: synteticky naměřené výkonnostní metriky pomocí Lighthouse ... 68

Tabulka 8 E-shop detail kategorie: synteticky naměřené výkonnostní metriky pomocí Lighthouse ... 69

Tabulka 9 E-shop statická stránka: synteticky naměřené výkonnostní metriky pomocí Lighthouse ... 69

Tabulka 10 E-shop domovská stránka: synteticky naměřené výkonnostní metriky pomocí Pagespeed.cz ... 70

Tabulka 11 E-shop detail produktu: synteticky naměřené výkonnostní metriky pomocí Pagespeed.cz ... 70

Tabulka 12 E-shop statická stránka: synteticky naměřené výkonnostní metriky pomocí Pagespeed.cz ... 70

Tabulka 13 E-shop detail kategorie: synteticky naměřené výkonnostní metriky pomocí Pagespeed.cz ... 70

Tabulka 14 Počty naindexovaných stránek různých verzí renderingů ... 74

Tabulka 15 Bing.com pozice jednotlivých renderingů ve výsledcích vyhledávání ... 75

Tabulka 16 Seznam.cz pozice jednotlivých renderingů ve výsledcích vyhledávání ... 75

(12)

Seznam výpisů programového kódu

Výpis 1.1 Nástin HTTP odpovědi pro server-rendered stránku úkolníčku ... 17

Výpis 1.2 Nástin HTTP odpovědi pro client-rendered stránku úkolníčku ... 19

Výpis 1.3 client-side rendered stránka úkolníčku ... 19

Výpis 1.4 Nástin HTTP odpovědi pro CSR with prerendering stránku úkolníčku ... 20

Výpis 1.5 Server-side rendering with (re)hydration ...21

Výpis 7.1 Příkazy pro nainstalování, spuštění a nasazení aplikací použitých v práci ... 55

Výpis 7.2 Sběr a odeslání naměřených výkonnostních metrik... 56

Výpis 7.3 NestJS: Logika generování platebního kódu ... 58

Výpis 7.4 Ukázka view vrstvy formuláře pro platby ... 59

Výpis 7.5 Angular: Logika generování platebního QR kódu ... 60

Výpis 7.6 Angular: šablona platebního formuláře ... 61

Výpis 7.7 Angular: definice routes pro detail kategorie ... 62

Výpis 7.8 NestJS: definice routes pro detail kategorie... 63

Výpis 7.9 Services: získání stránkovaných produktů kategorie ... 63

Výpis 7.10 NestJS: práce s route parametry ... 64

Výpis 7.11 Angular: práce s route parametry ... 64

(13)

Seznam zkratek

SSR server-side rendering SPA single page application SEO search engine optimization

API application programming interface DOM Document Object Model

HTML HyperText Markup Language CDN content delivery network

URL Uniform Resource Locator (webová adresa) LPS Lighthouse performance score

FCP First contentful paint

SI Speed index

LCP Largest contentful paint TTI Time to interactive TBT Total blocking time CLS Cummulative layout shift

CI/CD Continuous integration / Continuous delivery RUM Real user monitoring

(14)

Úvod

V posledních dekádě se díky rostoucí popularitě javascriptových frameworků, jako jsou React, Angular či VueJS, stále více prosazuje koncepčně odlišný přístup k vývoji a ke způsobu, jakým webových aplikace podávají prohlížečům obsah. V nových webových aplikacích se lze stále častěji setkat s tím, že je kompletní obsah stránky vykreslen až v prohlížeči klienta pomocí javascriptu.

V původním, čistě serverově orientovaném přístupu, obdržel prohlížeč po odeslání požadavku na stránku odpověď v podobě HTML s kompletním obsahem stránky – tzv.

server rendering. Aplikace napsané v javascriptových frameworcích fungují na jiném principu – tzv. client-side rendering (CSR). Prohlížeč od serveru obdrží základní kostru HTML dokumentu, ve kterém je zakomponován zdrojový kód aplikace v javascriptu. Tento kód má pak již na starosti vygenerování potřebných HTML elementů, stažení dat potřebných k zobrazení z příslušného API, či navigaci v rámci aplikace. Tento způsob renderingu¹ se může negativně projevit na výkonnosti webové aplikace, obzvláště pak na mobilních zařízeních, které mají menší výpočetní výkon. Pro vykreslení aplikace musí tato zařízení vykonat mnohem více práce než jen zpracovat HTML. Dalším následkem této volby může být negativní vliv na SEO. Pro indexování obsahu stránky je nutné spustit javascriptový kód a odhalit, kdy už je stránka kompletně vykreslena. Tyto problémy se snaží řešit jak samy frameworky, tak služby třetích stran, a to různými přístupy k renderingu těchto aplikací.

Mezi tyto přístupy momentálně patří například server-side rendering či prerendering.

Různé přístupy k renderingu, ze kterých tato práce částečně vychází, shrnuje článek (Miller a Osmani, 2019), který však obsahuje pouze vágní informace o výkonnostních důsledcích různých druhů renderingů, nikoliv však na konkrétních aplikacích, které by šly porovnat mezi sebou. Server-side rendering (SSR), či prerendering jsou v různých článcích na internetu uváděny jako metody, jak zlepšit výkonnost CSR aplikací. Tato tvrzení ale nebývají podložena konkrétními aplikacemi a naměřenými hodnotami. Co víc, nikdo už tyto metody nesrovnává s klasickým server renderingem – srovnání by vyžadovalo implementaci stejné aplikace dvakrát v různých technologiích. Motivací této práce je objasnit a poskytnout podložené následky volby jednotlivých druhů renderingu při tvorbě webových aplikací. Tyto informace pak mohou pomoci softwarovým architektům s rozhodnutím o použité technologii či architektuře pro tvorbu webové aplikace.

Cílem této práce je shrnout existující druhy renderingů webových aplikací a porovnat a změřit následky volby druhu renderingu na výkonnost, SEO a implementační přívětivost. Dále je cílem potvrdit, či vyvrátit následující hypotézy:

h1: Server-side rendering a prerendering zlepšují výkonnost client-side renderingu

h2: Server rendering dosahuje oproti zbylým renderingům výrazně lepších hodnot v metrikách TTI a TBT, horší je naopak ve FCP a LCP.

1 V celé práci je používán anglický termín rendering, protože se jedná o zaužívaný pojem a česká alternativa vykreslení přesně nevystihuje podstatu slova v tomto kontextu

(15)

h3: Google umí plně indexovat obsah client-side renderingu, stále ale dává prioritu prerendered/server-side rendered/server rendered aplikacím h4: Bing, Seznam vyhledávač a roboti Facebooku neumí načíst/indexovat

obsah client-side renderované stránky

V první části práce bude provedena rešerše přístupů k renderování webových aplikací, způsobů a metrik měření jejich výkonnosti a základů SEO. V rámci práce budou naimplementovány dvě aplikace reprezentující různé kategorie aplikací s potřebou SEO.

Každá z aplikací bude naimplementována dvakrát – jednou jako serverově renderovaná, podruhé jako CSR, SSR a prerendered. Na těchto implementacích bude poté měřena, vyhodnocena a porovnána výkonnost a přizpůsobenost těchto druhů renderingů pro vyhledávače. Použity budou kvalitativní i kvantitativní metody testování aplikací.

V rámci této práce je předpokládáno, že má čtenář zkušenosti s vývojem webových aplikací, zná základní návrhové vzory v těchto aplikacích používané a má alespoň základní zkušenosti se SEO. Testovací aplikace budou zastupovat nejčastěji používané kategorie aplikací a implementují nejpoužívanější druhy renderingů. Tyto aplikace budou navrhnuty a vytvořeny až v průběhu řešení této práce. Pro implementaci CSR části bude použit framework Angular, protože je používán autorem této práce i v komerčním prostředí, kde budou výsledky této práce díky tomuto omezení lépe využity.

V kapitole 1 je ukotvena definice renderingu, kterým se tato práce zabývá a dále v ní jsou shrnuty přístupy k renderingu webových aplikací a jejich specifika. Druhá kapitola pojednává o způsobech měření výkonnosti webových aplikací a definuje metriky, pomocí kterých lze tuto výkonnost měřit. Ve třetí kapitole jsou shrnuty základy SEO a provedena rešerše, jak se jednotlivé vyhledávače vypořádávají s různými druhy renderingu. Čtvrtá a pátá kapitola specifikuje testovací aplikace v rámci této práce implementované. V šesté kapitole je rozepsána metodologie testování měření a vyhodnocování těchto implementací.

Sedmá kapitola popisuje implementační detaily aplikací naimplementovaných v rámci této práce. V osmé kapitole jsou jednotlivé renderingy vyhodnoceny na základě objektivních měřítek specifikovaných v šesté kapitole. V deváté kapitole jsou implementace renderingů autorem práce subjektivně vyhodnoceny – jak ze strany uživatelské, tak ze strany implementační.

(16)

1 Druhy renderingu

Ze začátku je potřeba vyjasnit, o jakém renderingu webových aplikací tato práce pojednává.

Rendering v nejobecnější definici může být definován jako proces, ve kterém je popis trojrozměrné scény (modelu) přeměněn na obrázek. (Pharr et al., 2017) V kontextu webových prohlížečů se jedná o vykreslení HTML dokumentu pomocí renderovacího enginu prohlížeče. Proces, který renderovací engine prohlížeče po načtení dat, je znázorněn na Obrázek 1. V prvním kroku engine převede HTML na DOM strom obsahující jednotlivé elementy. V druhé části se zpracovávají kaskádové styly, obvykle definované pomocí CSS.

Spojením informací v HTML a CSS se vytvoří renderovací strom. Tento strom již obsahuje jednotlivé obdélníky a pořadí, v jakém budou vykresleny, spolu s atributy, jako jsou jejich barva či rozměry. Třetím krokem je přiřazení konkrétních souřadnic na obrazovce, kde budou elementy renderovacího stromu vykresleny. Posledním krokem je již samotné vykreslení elementů na obrazovku. (Garsiel, 2009)

Obrázek 1 Jak funguje rendering engine (Garsiel, 2009)

Renderingem, kterým se tato práce zabývá, jsou myšleny různé přístupy k tomu, jak lze vytvořit výsledný DOM strom. Tento strom lze kromě parsování HTML, které dostane prohlížeč ze serveru, měnit také pomocí javascriptu na klientské straně. Tyto přístupy se dají kombinovat. V práci je tedy řešeno, v jaký čas a jakými výpočetními prostředky se generuje HTML, popř. DOM strom stránky.

V následujících podkapitolách jsou popsány jednotlivé přístupy k renderingu. Je vycházeno především ze článku (Miller a Osmani, 2019), kde jsou jednotlivé druhy velice dobře popsány a shrnuty. U každého druhu je rozebrána typická architektura aplikace rendering využívající a princip fungování. Je naznačeno, jak se u jednotlivých druhů renderingu pracuje s daty a jak vypadá odpověď na HTTP požadavek pro jednoduchou aplikaci úkolníčku. Také je u každého druhu dán za příklad framework, knihovna, či aplikace, tento druh renderingu používající.

1.1 Server rendering

Jedná se o nejstarší, nejklasičtější a také nejrozšířenější podobu renderingu webových aplikací. Prohlížeč na HTTP požadavek obdrží v odpovědi HTML dokument již obsahující data, která má prohlížeč vykreslit (viz Výpis 1.1). V tomto dokumentu jsou uvedeny odkazy na kaskádové styly upravující vzhled stránky. Javascript se při tomto druhu renderingu obvykle používá hlavně pro „zinteraktivnění“ aplikace – např. validování uživatelských vstupů ve formuláři, pokročilé animace, drag&drop operace atd. Serverově renderované aplikace jsou také specifické tím, že jejich stav (např. položky v košíku) je obvykle uchováván kompletně na serveru. Změna tohoto stavu probíhá obvykle posláním příslušného HTTP požadavku, který opět vrátí kompletní HTML dokument zobrazující již aktualizovaný stav.

(17)

Z hlediska softwarové architektury jsou serverově renderované aplikace obvykle monolitického typu.² Jedná se tedy o jedinou aplikaci řešící vše od zpracování HTTP požadavku, přístupu k databázi, až po sestavení samotného HTML.

Na tvorbu serverově renderované aplikace existuje nespočet frameworků a jazyků, ve kterých je možno je psát. Nejčastěji používaným je jazyk PHP (W3Techs.com, 2020). Za zmínku stojí také často používané jazyky Python, Java, C#, Ruby, či Javascript. Zástupcem serverově renderované aplikace může být například InSIS, který je napsaný v Perlu³.

Výpis 1.1 Nástin HTTP odpovědi pro server-rendered stránku úkolníčku

<!DOCTYPE html>

<head>

<title>Úkolníček</title>

</head>

<body>

<h1>Výpis úkolů</h1>

<ul>

<li><a href="/ukol/1">Vyvenčit psa</a></li>

<li><a href="/ukol/2">Vynést koše</a></li>

</ul>

<button>Přidat</button>

</form>

</body>

</html>

1.2 Client-side rendering

Narozdíl od serverově renderovaných aplikacívrací obvykle veškeré HTTP požadavky stejný obsah. Jedná se o HTML dokument obsahující odkazy na kaskádové styly a javascriptové souboury. HTML dokument obvykle obsahuje ve své části body pouze text, popř. animaci, vizualizující načítání aplikace (viz Výpis 1.2). Jak a odkud se vezmou potřebná data pro daný požadavek, či jak se tato data u klienta v prohlížeči vykreslí, řeší již javascriptová aplikace odkazovaná v HTML dokumentu. Obvykle tedy javascript po načtení

2 Více o specificích monolitických webových aplikací v (DHH, 2016)

3 https://insis.vse.cz/

(18)

odešle několik HTTP požadavků na API, ze kterých získá potřebná data. Tato data poté vykreslí do DOM stromu (viz Výpis 1.3). Dost často tyto aplikace uchovávají také velkou část informací o stavu aplikace – např. košík, informace o přihlášeném uživateli či jazyk aplikace. Změna stavu obvykle probíhá tak, že se na pozadí pošle HTTP požadavek na změnu stavu a v případě úspěchu se překreslí pouze části aplikace ovlivněné změnou tohoto stavu (např. změna čísla s počtem položek v košíku v hlavičce po odebrání z košíku). Hlavní výhodou aplikací renderovaných na klientské straně je tedy absence kompletního přenačítávání celé stránky s každou změnou stavu. Zásadní nevýhodou je pomalé první načtení stránky.

Z architektonického hlediska se obvykle jedná o client-server architekturu⁴. Webová aplikace má obvykle dvě oddělené části – tzv. backend (server) a frontend (client), které mezi sebou komunikují pomocí API. Backendová část obvykle řeší ukládání a zpřístupnění dat, náročnější business logiku, komunikaci s jinými třetími stranami, či výpočetně náročné operace. Frontendová část tvoří uživatelské rozhraní aplikace a má na starosti rendering.

Uživatel celou dobu interaguje pouze s touto částí, která jeho akce převádí na jednotlivá API volání. Velkou výhodou této architektury webových aplikací je to, že v tomto případě mohou být podle potřeby použito a libovolně kombinováno více backendových částí (např. aplikace sdružující více informačních systémů), více frontendových částí (web, mobilní aplikace, televizní aplikace) či různé technologie/architektury pro API (REST⁵, GraphQL⁶, Websocket⁷). V případě frontend části se stala standardem component-oriented architektura (dshaps, 2016), která se také velmi liší od architektury používané v monolitických serverově renderovaných aplikací. Základem jsou znovu-použitelné malé celky skládající se z šablony, stylů a logiky – tzv. komponenty.

Nejznámější frameworky či knihovny využívající client-side rendering jsou React⁸, Angular⁹ a Vue¹⁰. Typickou client-side rendered aplikací je např. Gmail¹¹.

4 Více do detailu rozebraná specifika client-server architektury lze nalézt např. v (The Open University, 2020)

5 Více o REST konceptu v (Pichlík, 2017)

6 Více o GraphQL v (GraphQL Foundation, 2020)

7 Více o Websocketech např. v (Malý, 2009)

8 https://reactjs.org/

9 https://angular.io/

10 https://vuejs.org/

11 https://mail.google.com/

(19)

Výpis 1.2 Nástin HTTP odpovědi pro client-rendered stránku úkolníčku

<!DOCTYPE html>

<head>

<title>Úkolníček</title>

</head>

<body>

<app-root>

</body>

</html>

Výpis 1.3 client-side rendered stránka úkolníčku

…

<body>

<app-root>

<app-vypis-ukolu>

<ul>

<li><a href="/ukol/1" routerLink="ukol/1">Vyvenčit psa</a></li>

<li><a href="/ukol/2" routerLink="ukol/1">Vynést koše</a></li>

</ul>

</app-vypis-ukolu>

<app-novy-ukol>

<form>

</form>

</app-novy-ukol>

</app-root>

</body>

…

1.3 Client-side rendering with prerendering

Jedná se o jeden z přístupů, jak zlepšit rychlost prvního načtení stránky. Aplikace je psána stejným způsobem, jako client-side rendered aplikace. Proces sestavení aplikace je ale upraven tak, že negeneruje prázdný HTML dokument, ale již kompletní vygenerovanou HTML strukturu včetně dat (viz Výpis 1.4). Po načtení javascriptu se ale musí stránka znovu

(20)

načíst a zinteraktivnit – což se provede tak, že je kompletní obsah DOM stromu zahozen a znovu vyrenderován pomocí klientského javascriptu. Nevýhodou tohoto přístupu je, že s každou změnou obsahu musí proběhnout opětovné sestavení aplikace.

Výpis 1.4 Nástin HTTP odpovědi pro CSR with prerendering stránku úkolníčku

…

<body>

<app-root>

<app-vypis-ukolu>

<ul>

</ul>

</app-vypis-ukolu>

<app-novy-ukol>

<!— submit nic neudělá dokud nenastartuje js aplikace -->

<form>

</form>

</app-novy-ukol>

</app-root>

</body>

…

1.4 Server-side rendering with (re)hydration

Javascript může být kromě prohlížeče spouštěn také na serveru, a to díky Node.js. (Node.js, 2021) Tohoto faktu využívá právě server-side rendering. Server-side renderingem rozumíme spuštění kódu client-side rendered aplikace pro daný požadavek na serveru. Výstup tohoto spuštění je tedy HTML dokument včetně stylů, který odpovídá tomu, co vyrenderuje klientská aplikace po načtení. Problém nastává v okamžiku, kdy výstup tohoto HTML dokumentu zobrazí prohlížeč. Stránka sice vypadá až na výjimky identicky jako vyrenderovaná pomocí client-side renderingu, ale není interaktivní – javascriptový kód registrující event listenery byl již spuštěn na serveru. „Zinteraktivnění“ takto vygenerovaného dokumentu se nazývá hydration. (Miller a Osmani, 2019)

(21)

Výpis 1.5 Server-side rendering with (re)hydration

…

<body>

<app-root>

<app-vypis-ukolu>

<ul>

</ul>

</app-vypis-ukolu>

<app-novy-ukol>

<!— submit nic neudělá dokud nenastartuje js aplikace -->

<form>

</form>

</app-novy-ukol>

</app-root>

<!— data potřebná pro vyrenderování klientskou stranou, která už ale jednou v DOM jsou -->

var DATA = { "ukoly": [ {

"id": "1",

"name": "Vyvenčit psa“, },

{

"id": "2",

"name": "Vynést koše“, }

] }

</script>

</body>

…

V následujících odstavcích bude popsáno několik způsobů, jak lze tuto hydration provést.

1.4.1 Rehydration

První možností je tzv. rehydration. Součástí dokumentu vráceným serverem je kromě onoho statického HTML také skript klientské aplikace a serializovaná data, která byla použita pro její rendering. Prohlížeč tedy HTML dokument vykreslí a přibalený skript se spustí jako při klasicky klientsky renderované aplikaci. Protože už má dostupná všechna data, která by obvykle získával voláním např. XmlHttpRcequestu v serializované podobě, může klient renderovat aplikaci velmi rychle. Po dokončení se serverem renderovaný DOM kompletně zahodí a nahradí DOMem vyrenderovaným klientem.

(22)

Když je někde popsán server-side rendering (SSR) ve SPA aplikacích, je tím většinou myšlen právě tento způsob renderingu s rehydration – hlavně proto, že prozatím jiný způsob hydratace není v současné době ve stabilních verzích frameworků Angular, ReactJS ani VueJS implementován.

1.4.2 Progressive hydration

Problémem rehydratace je velká výpočetní zátěž při načítání stránky. Toto se nejvíce projevuje zejména na výpočetně slabších zařízeních, jako jsou chytré telefony. Hlavním problémem je, že stránka na takovémto telefonu vypadá funkčně, ale není interaktivní třeba i po několik sekund.

Jedním z přístupů, jak tento problém vyřešit, je rozdělit úkol hydratace na mnoho menších.

Způsob, jakým to lze udělat, je staticky zanalyzovat celou aplikaci, a pro každou komponentu zjistit, jaké má závislosti a jaké události jdoucí z komponenty ovlivní jaké jiné komponenty v aplikaci. Díky tomu jsme aplikaci schopni rozdělit na mnoho malých částí, které lze dynamicky načítat a spouštět až v případě potřeby. Toto je pro frameworky či knihovny zajišťující rendering implementačně velice náročný úkol. S progressive hydration se již experimetuje v ReactJS (Markbåge, 2019) a diskutuje již několik let v Angularu (Cross, 2016). Velmi pěkně shrnuje problémy a nástrahy implementace progressive hydration v Angularu ve svém komentáři k návrhu implementace Minko Gechev (Gechev, 2020).

1.4.3 Partial rehydration

Partial rehydration je progressive hydration posunutá o úroveň dál. Již během buildu jsou identifikovány komponenty, které jsou statické (pro jejich funkčnost není potřeba javascript). Tyto komponenty můžeme vyrenderovat na serveru a odstranit veškerý javascriptový kód, který by tyto komponenty jinak obsluhoval. Zbylé nestatické komponenty jsou po načtení hydratovány na klientské straně obdobně jako při rehydration, či progressive hydration.

Správně naimplementovat tento přístup je velice obtížné. Nastávají zde problémy při přechodu mezi stránkami řízenými klientskou částí kódu – zde se již nevolá SSR, které by tyto statické komponenty vyrenderoval. Pěkný článek popisující pokus o implementaci tohoto přístupu v Reactu, resp. frameworku nad ním postaveným Next.js je k nalezení v (Bombach, 2019).

1.4.4 Trisomorphic rendering

V tomto případě rendering může probíhat na třech místech: serveru, klientovi a service workeru v prohlížeči. Při prvním načtení aplikace obdrží prohlížeč verzi vyrenderovanou na serveru – čímž se řeší problém indexace roboty a výpočetní náročnosti CSR. Všechny další navigace v aplikaci již jdou skrze service worker¹², který je schopen na pozadí dopředu vyrenderovat všechny stránky aplikace, uložit je a na každý požadavek na konkrétní stránku

12 Skript, který běží na pozadí prohlížeče a může zachytávat a měnit veškeré odchozí síťové požadavky (Google Developers, 2021)

(23)

vrátit tuto předrenderovanou verzi. To teoreticky umožňuje ještě rychlejší přechody mezi stránkami v rámci aplikace než v případě CSR, protože rendering stránky proběhl již na pozadí, v době, kdy byly volné výpočetní prostředky. Tento přístup může fungovat pouze když může být použit stejný kód pro vykreslení a navigaci napříč serverem, service workerem a klientskou aplikací. Více informací o tomto druhu renderingu lze nalézt v diagramu Obrázek 2.

Jedná se o velice experimentální druh renderingu, konkrétní příklad knihovny či fungující aplikace využívající tento druh renderingu se nepodařilo nalézt.

Obrázek 2 Trisomorphic rendering diagram (Miller a Osmani, 2019)

1.5 Static server-side rendering

Aplikace je psaná stejně jako client-side renderovaná aplikace (používáme komponenty, fetch API, …). Při sestavení aplikace jsou vygenerovány kompletní HTML soubory pro každou stránku aplikace. Na rozdíl od prerenderingu je z těchto souborů kompletně odstraněn javascript, takže aplikace je kompletně statická.

Tento druh renderingu je použitelný pouze pro velmi specifické případy. Pro každou změnu obsahu stránky musí být aplikace znovu sestacena. Oproti klasickému HTML je výhoda v tom, že kód může být strukturován do znovupoužitelných komponent, a tedy mohou jednotlivé stránky sdílet společné části. Na rozdíl od server renderingu např. v PHP, není potřeba vlastního hostingu s běžícím PHP, který je hůře škálovatelný. Výstupem jsou totiž statické HTML soubory, které můžeme umístit třeba na CDN, které aplikaci rozdistribuuje velice levně po celém světě.

Příkladem frameworku využívající tohoto druhu renderingu je Docosaurus (Facebook Inc., 2020a). Jejich stránka je zároveň napsána v tomto frameworku, takže se jedná i o příklad aplikace s tímto druhem renderingu.

(24)

Odpověď serveru na HTTP požadavek je v tomto případě nerozlišitelná od ukázky kódu uveden ve Výpis 1.1.

1.6 Dynamic server rendering (Turbolinks style)

Jedná se o vylepšení klasického server renderingu. Dynamic server rendering eliminuje nutnost kompletního znovunačtení stránky s každou navigací / akcí v aplikaci. Toho dociluje tím, že zachytí veškeré navigační požadavky, provede je pomocí XHR API z javascriptu a výslednou odpovědí nahradí aktuální DOM. Kromě toho se již navštívené stránky ukládají do cache, takže přechod na již navštívenou stránku je proveden okamžitě. V případě, že pro celou aplikaci existuje pouze jediné CSS a jediný JS, šetří se s každou navigací na stránce čas s jejich parsováním a spouštěním. Nevýhodou je, že události document.ready, či window.load jsou aktivovány pouze při prvním načtení. S každou další navigací dochází k aktivaci jiné události, definované knihovnou zajišťující tento rendering. V knihovně Turbolinks se například jedná o turbolinks:load (Basecamp, LLC, 2020). Tato skutečnost může rozbít již existující javascriptové knihovny spoléhající na skutečnost, že s každou navigací dojde k aktivaci události document.ready a budou spuštěny na ni navázané funkce.

Jak již z povahy tohoto řešení vyplývá, odpověď na HTTP požadavek je totožná s Výpis 1.1.

Příkladem knihovny implementující tento druh renderingu je již výše zmíněný Turbolinks (Basecamp, LLC, 2020). Příkladem aplikace tento rendering používající může být například aplikace Wallmine. (Wallmine, 2020).

1.7 Dynamic rendering

Dynamic rendering je Googlem doporučené dočasné řešení (Google LLC, 2020a), jak umožnit crawlerům vyhledávačů¹³ a jiným robotům číst client rendered aplikace.

Principiálně funguje tak, že uživatelům s prohlížeči posíláme klasickou client rendered aplikaci. Requesty crawlerů jsou přesměrovány na renderer, který vrací již plně vyrenderované HTML. Tento renderer obvykle funguje tak, že stránku načte v headless Chrome, které aplikaci vyrenderuje (GoogleChrome, 2020), (prerender, 2020). Tento výsledek pak vrátí.

Příkladem rendererů, které lze použít jsou Rendetron (GoogleChrome, 2020) či Prerender.io (prerender, 2020).

13 Roboti, kteří prochází webovými stránkami a čtou jejich obsah, který je poté vyhledávači indexován

(25)

Obrázek 3 Dynamic rendering (Google LLC, 2020a)

Velkou výhodou tohoto druhu renderingu oproti SSR je jednoduchost implementace.

Zajímavým problémem tohoto druhu renderingu je, že již z principu dodává jinou verzi stránek vyhledávacím robotům než uživatelům. Této technice se říká maskování a je považováno za porušení podmínek Google (Google LLC, 2020c). V tomto případě ale Google vysloveně uvádí, že „Pokud dynamic rendering produkuje podobný obsah, Googlebot nebude pohlížet na dynamic rendering jako na maskování.“. (Google LLC, 2020a) Jak je ale správně poznamenáno ve článku (Lavall, 2020), je otázka, co už Google bot nemusí považovat za „podobný obsah“ a ve výsledku takto renderovaný obsah penalizovat.

Anthony Lavall ve výše uvedeném článku také zmiňuje další nevýhodu tohoto přístupu a tou je aktuálnost dat. Služby, jako výše zmíněný prerender.io, ukládají již vygenerované odpovědi do cache, a to minimálně po dobu několika dnů. Přeskočení ukládání do cachetaké není řešením – následkem by byla velká výpočetní zátěž na straně serveru a pomalé odpovědi crawlerům.

1.8 Shrnutí

Článek, který byl primárním zdrojem pro tuto kapitolu (Miller a Osmani, 2019), uvádí toto shrnutí jednotlivých přístupů k renderingu a uvádí je do kontextu jednotlivých výkonnostních metrik, které budou popsány v následující kapitole:

(26)

Obrázek 4 Shrnutí jednotlivých metod renderingu (Miller a Osmani, 2019)

Autoři článku také uvádí, že je při výběru renderingu nutno rozumět tomu, jaká úzká hrdla jednotlivé druhy renderingu mají. Výběr konkrétního druhu renderingu by měl záviset na konkrétní aplikaci a jaká očekávání po stránce výkonu a použitelnosti od ní zadavatel požaduje. V neposlední řadě výběr renderingu také ovlivňuje nejen použité technologie, ale celkovou architekturu aplikace a prostředí/počítače, na kterých poběží.

Při rešerši akademických článků, které by se zabývaly porovnáváním renderingů v oblasti výkonnosti se povedlo nalézt jediný článek (Fadhilah Iskandar et al., 2020) porovnávající pouze client-side a server rendering pomocí nástroje Google Audit. Dle jejich měření server rendering dosahuje – jak v SEO přizpůsobenosti, tak výkonnosti – lepších výsledků server rendering. Kromě tohoto článku se podařilo nalézt diplomovou práci (Beke, 2018) zabývající se také porovnáváním client-side a server renderingu. V této práci autor zmiňuje, že se mu nepodařilo nalézt žádný relevantní akademický článek zabývající se tímto tématem.

Porovnáním výkonnosti aplikace v prohlížeči a zátěži na straně provozovatele v případě změny ze server renderingu na client-side rendering se zabývá také bakalářská práce (Mukhamadiev, 2018). V akademickém článku (P Kishore a M, 2020) jsou pak porovnávány client-side a server rendering z hlediska architektury aplikací. Mimo to existuje několik publikací popisující, jak implementovat SSR – za zmínku stojí např. (Thakkar, 2020) či (Sun, 2019).

(27)

2 Měření výkonnosti webu

V této kapitole jsou shrnuty a teoreticky popsány metody měření a metriky používány k měření výkonnosti webů. Výběr konkrétních metrik a metod, pomocí kterých budou měřeny aplikace vytvořené v rámci této práce, budou popsány v kapitole 6.

Změřit výkonnost webové aplikace není zdaleka tak jednoduchý úkol, jak se může na první pohled zdát. Pro demonstraci lze ukázat například naivní přístup k měření výkonnosti. Nechť je metrikou čas, za jak dlouho budeme mít kompletní odpověď na HTTP požadavek. Taková metrika může být vypovídající pro aplikace renderované na serveru. V momentě, kdy bude aplikace napsaná jako client rendered SPA, odpověď přijde vždy téměř okamžitě. V tomto případě se hlavní část práce začne dít až při spuštění javascriptu, který začne přes API stahovat potřebná data, což může trvat dalších několik sekund. Z uživatelského pohledu tedy může serverově renderovaná aplikace působit mnohem výkonněji než SPA aplikace, přestože čas odpovědi na HTTP požadavek může být násobně delší.

Jak lze vidět z výše popsaného příkladu, vymyslet metriku, která by věrohodně měřila výkon webové aplikace z uživatelského pohledu, není jednoduchý úkol. Za poslední léta vývoje a měření výkonnosti webových aplikací bylo vymyšleno několik různých metrik, které jsou v této kapitole popsány.

2.1 Metody měření

Měřit výkonnost webu lze dvěma způsoby – synteticky, nebo na reálných zařízeních návštěvníků. Každý ze způsobů má své výhody a nevýhody, které jsou shrnuty v této podkapitole.

2.1.1 Syntetická měření

Syntetické měření je nejčastěji používaná technika. Na web se obvykle pošle robot, který simuluje reálného uživatele, jeho konkrétní prohlížeč, rozlišení, rychlost internetu atd. Mezi nástroje/stránky pracující na principu syntetických měření patří Lighthouse, PageSpeed Insights, WebpageTest.org, Pagespeed.cz a další. (Michálek, 2019e) Syntetická měření mají výhodu v reprodukovatelnosti měření a v okamžité odezvě na nové změny ve stránce.

Nevýhodou může být nepřesná emulace pomalejších zařízení a nutnost specifikace zařízení, na kterých bude aplikace testována, což může vést k získání dat neodpovídajících realitě.

2.1.2 Měření reálných uživatelů

Měření reálných uživatelů (real user monitoring, RUM) je lepší metodika z hlediska věrohodnosti naměřených dat. Do stránky se obvykle vloží skript, který měří reálné uživatele aplikace. Některé analytické nástroje to už dnes umí, jen jsou nastavené spíše na velké weby a firmy. Nevýhodou je tedy náročnost implementace tohoto měření a s ním spojené vysoké náklady této metodiky. (Michálek, 2019e)

(28)

U většiny webů RUM metriky zobrazí i PageSpeed Insights – z veřejné databáze Chrome UX Report (CrUX). Sbírat tato data od uživatelů umí také SpeedCurve, jedná se ale o nákladnou službu. Další možností je použít knihovnu javascriptovou knihovnu web-vitals (Google LLC, 2021b), která umožní zaznamenat metriky v prohlížečích. Jejich sbírání, ukládání a vyhodnocování je již ale potřeba vyřešit svépomocí.

2.2 Metriky měření

Nejdůležitějšími metrikami, podle kterých budou primárně měřeny i aplikace v této práci, budou metriky tzv. Core web vitals, kterými jsou LCP, FID a CLS (Google LLC, 2020e) a popř. také Lighthouse performance score, které by mělo být syntetickou obdobou těchto core web vitals. Tato kombinace metrik by měla co nejvěrohodněji reprezentovat výkonnost webu z uživatelského hlediska. (Google LLC, 2020d) Kromě toho by Google měl tyto metriky od roku 2021 zohledňovat ve svém vyhledávacím algoritmu a zvýhodňovat weby, které dosahují v těchto metrikách nižších hodnot. (Subramanian, 2020)

Přehled jednotlivých momentů během vykreslování stránky lze vidět na Obrázek 5.

Obrázek 5 Postupný vznik událostí pro vykreslování stránky (Michálek, 2020a)

2.2.1 Time To First Byte (TTFB)

„Time to First Byte (TTFB) refers to the time between the browser requesting a page and when it receives the first byte of information from the server. This time includes DNS lookup and establishing the connection using a TCP handshake and SSL handshake if the request is made over HTTPS.“ (Mozilla Contributors, 2019)

Metrika TTFB tedy měří hlavně rychlost odpovědi serveru na požadavek klienta. Při čistě serverově renderovaných webových aplikacích lze z této metriky vyčíst slabá místa aplikace.

(29)

2.2.2 First Paint (FP)

„First Paint, part of the Paint Timing API, is the time between navigation and when the browser renders the first pixels to the screen, rendering anything that is visually different from what was on the screen prior to navigation. It answers the question »Is it happening?«“(Mozilla Contributors, 2021b)

Jak vyplývá z uvedené definice, tato metrika určuje, kdy se něco začalo vykreslovat. Tento údaj sám o sobě není příliš vypovídající. Uživatele většinou zajímá, kdy se vykreslil obsah stránky. Pro měření vykreslení se dnes tedy dává spíše přednost metrikám FCP a FMP.

(Michálek, 2019h)

2.2.3 First Contentful Paint (FCP)

„First Contentful Paint (FCP) is when the browser renders the first bit of content from the DOM, providing the first feedback to the user that the page is actually loading. … The First Contentful Paint time stamp is when the browser first rendered any text, image (including background images), non-white canvas or SVG. This excludes any content of iframes, but includes text with pending webfonts. This is the first time users could start consuming page content.“ (Mozilla Contributors, 2020a)

Touto metrikou lze tedy změřit, v jakém bodě se uživateli vykreslí nějaký obsah (klidně i text „Načítám“). Jedná se o jednu z důležitých metrik, která se používá pro vyhodnocování výkonnosti webu, je také součástí web vitals metrik. (Google LLC, 2019a)

2.2.4 DOM Content Loaded (DCL)

„The DOMContentLoaded event fires when the initial HTML document has been completely loaded and parsed, without waiting for stylesheets, images, and subframes to finish loading.“ (Mozilla Contributors, 2020c).

Jak již definice napovídá, jedná se o jednu z událostí životního cyklu stránky, na který můžeme přidat eventListener v javascriptu. Jedná se ale spíše o technickou metriku, která sice koreluje s nižší bounce rate, je to ovšem tím, že DCL koreluje s FCP a FMP. (Michálek, 2019f)

2.2.5 First Meaningful Paint (FMP)

„First Meaningful Paint (FMP) is the paint after which the biggest above-the-fold layout change has happened and web fonts have loaded. It is when the answer to "Is it useful?"

becomes "yes", upon first meaningful paint completion.“ (Mozilla Contributors, 2020b) Tato metrika tedy informuje, kdy začne být viditelný primární obsah stránky (např. nadpis stránky). Metrika FMP se již dnes považuje za nespolehlivou, nahrazuje se metrikou LCP.

(Michálek, 2019d)

2.2.6 Largest Contentful Paint (LCP)

„The Largest Contentful Paint (LCP) metric reports the render time of the largest image or text block visible within the viewport.“ (Google LLC, 2020b)

(30)

Tato metrika je aktuálně doporučována jako hlavní metrika, jakou změřit moment, ve kterém je stránka pro uživatele užitečná. Nahrazuje původně doporučované FMP a SI, které měly problém se spolehlivostí měření, či měřily nerelevantní elementy. (Michálek, 2020c) Měření momentu LCP probíhá tak, že je v každém momentu renderování vybrán tzv. LCP candidate – prvek, který byl do dané chvíli největší. LCP candidate může být v průběhu renderingu nahrazen jiným větším prvkem, který se stává novým LCP kandidátem. Hledání nových kandidátů LCP končí v momentě, kdy uživatel provede interakci se stránkou (tapnutí, kliknutí, vstupem z klávesnice nebo scrollováním stránky) nebo odejde ze stránky pryč, např. vložením nového URL. Poslední LCP kandidát vyhrává a jako LCP je reportován čas jeho renderování. (Michálek, 2020c)

Pro ilustraci lze na Obrázek 6 vidět, kdy nastává FCP a kdy LCP. Také je ilustrován průběh algoritmu pro vyhodnocení největšího prvku na stránce – LCP kandidát je reprezentován zeleným vyplněným obdélníkem.

(31)

(32)

Obrázek 6 LCP vs FCP (Michálek, 2020c)

2.2.7 First Input Delay (FID)

„First input delay (FID) measures the time from when a user first interacts with your site (i.e. when they click a link, tap on a button, or use a custom, JavaScript-powered control) to the time when the browser is actually able to respond to that interaction. It is the length of time, in milliseconds, between the first user interaction on a web page and the browser’s response to that interaction. Scrolling and zooming are not included in this metric“. (Mozilla Contributors, 2021a)

Jedná se o událost, kterou ovlivňuje hlavně JavaScript. Stránka je zobrazená a uživatel se snaží kliknout na tlačítko, rolovat s ní, či udělat jinou akci. Stránka ale nereaguje, protože hlavní vlákno prohlížeče je zaměstnané zpracováváním kódu. Tuto metriku lze již z definice měřit pouze na reálných uživatelích. Obdobou této metriky v syntetickém měření je metrika TTI (2.2.8). Pokud je to možné, je lepší použít metriku FID, protože měří odezvu stránky pro reálné uživatele. (Michálek, 2019c).

2.2.8 Time to interactive (TTI)

„TTI measures how long it takes a page to become fully interactive. A page is considered fully interactive when:

• The page displays useful content, which is measured by the First Contentful Paint,

• Event handlers are registered for most visible page elements, and

• The page responds to user interactions within 50 milliseconds.“

(Google LLC, 2019c).

Jedná se tedy o metriku, která říká, kdy je stránka vyrenderována a zároveň schopna spolehlivě reagovat na uživatelský vstup. (Michálek, 2019a)

(33)

2.2.9 Total blocking time (TBT)

„TBT measures the total amount of time that a page is blocked from responding to user input, such as mouse clicks, screen taps, or keyboard presses. The sum is calculated by adding the blocking portion of all long tasks between First Contentful Paint and Time to Interactive. Any task that executes for more than 50 ms is a long task. The amount of time after 50 ms is the blocking portion. For example, if Lighthouse detects a 70 ms long task, the blocking portion would be 20 ms.“ (Google LLC, 2019d)

Tato metrika odpovídá na otázku „Jak moc špatně napsaný JavaScript na stránce je?“. Na tuto otázku již z výše zmíněných metrik snaží odpovídat TTI a FID. Na rozdíl od FID lze ale tuto metriku měřit synteticky. A oproti TTI se do této metriky nepromítá čas odpovědi serveru (TTFB), a jiných vlivů. (Michálek, 2020d)

2.2.10 Cumulative Layout Shift (CLS)

„CLS measures the sum total of all individual layout shift scores for every unexpected layout shift that occurs during the entire lifespan of the page. A layout shift occurs any time a visible element changes its position from one rendered frame to the next.“ (Walton a Mihajlija, 2020)

Tato metrika se snaží měřit vizuální stabilitu během vykreslování stránky. Problém, který se tato metrika snaží změřit popisuje (Michálek, 2020b): „Stránka vypadá, že je vykreslená…

už už se chystáme kliknout… ale v tom se spustí externí skript, posune nám rozvržení a my klikáme na reklamu.“.

2.2.11 Load

„The load event is fired when the whole page has loaded, including all dependent resources such as stylesheets and images. This is in contrast to DOMContentLoaded, which is fired as soon as the page DOM has been loaded, without waiting for resources to finish loading.“

(Mozilla Contributors, 2020d)

Jedná se o javascriptovou událost, kterou můžeme zachytit eventListenerem „load“. Jedná se o tradičně nejpoužívanější metriku rychlosti webu. Tato metrika ale neříká zhola nic o uživatelském požitku ze stránky. Když totiž bude stránka zobrazená, interaktivní (a už dávno konzumovaná uživatelem) a na pozadí ještě stahuje velké obrázky do patičky, uživatel o tom vůbec neví. Přitom událost „load“ se vykoná až po tomto načtení na pozadí, což může v této metrice vycházet dost nehezky. (Michálek, 2019g).

2.2.12 Speed Index

„Speed Index (SI) is a page load performance metric that shows you how quickly the contents of a page are visibly populated. It is the average time at which visible parts of the page are displayed. Expressed in milliseconds, and dependent on the size of the viewport, the lower the score, the better.“ (Mozilla Contributors, 2021c)

Speed Index je navázán na konkrétní technologický kontext – prohlížeč, šířku okna nebo typ připojení. Speed index se měří ze záznamu obrazovky při načítání stránky. Tento způsob sběru není realizovatelný pro RUM, lze jej měřit jen pomocí syntetických testů. Další