/* eshop/clients/angular/src/app/categories/categories.component.ts */
page: params[1].get('page') ?? this.page.toString(),
pageSize: params[1].get('pageSize') ?? this.pageSize.toString(), category: params[0].get('slug') ?? '',
})),
tap((params) => {
this.page = +params.page;
this.pageSize = +params.pageSize;
}),
switchMap((p) => this.productsService.getAll(p)) );
7.4.2.4 Práce se SEO
Práce se SEO je v Angularu a NestJS dosti odlišná. Aplikace implementované v Angularu mají statický index.html, kde se samotný Angular napojuje až dovnitř tagu body – hlavička HTML dokumentu tedy leží úplně mimo dosah frameworku a k její úpravě je potřeba použít javascript. V Angularu byla využita knihovna ngx-seo obsahující services ulehčující tuto manipulaci s elementy v hlavičce. V případě nastavení SEO pro detail kategorie tak stačilo zavolat na její SeoSocialShareService metodu setData s požadovanými daty.
V případě NestJS je situace jednodušší – šablony s každým požadavkem vykreslují také hlavičky, takže lze konkrétní požadované meta tagy a jiné napřímo vypsat v šabloně. Část šablony vykreslující SEO lze vidět v eshop/clients/server-rendered/src/views/shared/seo.ejs
8 Objektivní vyhodnocení
Na naimplementovaných aplikacích byla měřena výkonnost jednotlivých druhů renderingů.
U e-shopu bylo také měřeno, jak dobře zvládají vybrané vyhledávače indexovat jednotlivé druhy renderingu. Všechna syntetická měření byla prováděna najednou, není tedy předpoklad vlivu rychlosti internetu, či cold startů lambda funkcí na naměřené hodnoty.
Podrobněji je metodika těchto měření a vyhodnocování popsána v kapitole 6.
Aby šlo lépe porovnat, jak si jednotlivé renderingy vedou mezi sebou, ve všech tabulkách v této kapitole jsou jednotlivé buňky obarveny škálou barev v pořadí zelená, žlutá, oranžová a červená. Tyto barvy jsou přiřazeny podle pořadí daného renderingu v dané metrice od nejlepšího po nejhorší.
8.1 Jednostránková aplikace
U jednostránkové aplikace bylo kromě syntetického měření také měřena výkonnost jednotlivých renderingů na zařízeních skutečných návštěvníků. V rámci syntetických měření nejlepších výsledků dosahovala server rendered verze. V případě měření reálných uživatelů si výrazně nejlépe vedla prerendering verze.
Syntetická měření pomocí Lighthouse dosáhly ve většině metrik lepších výsledků než měření těch samých metrik pomocí PageSpeed.cz. Hlavní rozdíl mezi druhy měření byl především v metrikách FCP a SI – jaký je za tím důvod se ale nepodařilo zjistit.
Důležitým zjištěním bylo, že při měření reálných uživatelů dosáhly SSR a server rendered verze výrazně horších výsledků než CSR a prerendering. Horší výkonnost právě těchto verzí je nejspíše způsobena cold startem Firebase funkcí. Tento jev se bohužel už z definice nemůže projevit u syntetických měření, čímž se jen potvrzuje důležitost měřit výkonnost webů na reálných uživatelích – mohou se projevit skryté vlivy na jejich výkonnost. Tento konkrétní výkonnostní problém lze jednoduše vyřešit volbou jiného hostingu, v rámci této práce již na tuto změnu a opětovný sběr dat bohužel nezbyl čas.
8.1.1 Výkonnostní syntetické měření pomocí Lighthouse
Jak lze vidět v následující tabulce (Tabulka 2), při syntetickém měření v desktopovém módu dosáhly všechny druhy renderingů velmi dobrých výsledků, které se od sebe signifikantně nelišily. Zajímavostí na měřeních je výrazně horší hodnota CLS pro prerendered a server rendered verzi, která bude nejspíše způsobena pomalejším načítáním vlastních Google fontů.
To, že se tento jev nevyskytuje při CSR a SSR verzích, bude nejspíše způsobeno tím, že se fonty stihnout stáhnout a načíst dříve, než stihne javascript vykreslit měřený text.
Při testování v režimu mobilních zařízení se již začaly více projevovat rozdíly v jednotlivých druzích renderingů. Jediný server rendering v tomto případě dosáhl perfektního skóre LPS, prerendering verzi uteklo o 1 bod. Vliv na toto pořadí měla především metrika LCP, která v případě CSR vychází jako nevyhovující.
Z tabulky lze také vyčíst, že server rendering oproti ostatním renderingům dosahuje opravdu výrazně lepších výsledků v metrikách TTI a TBT. Oproti hypotéze ale nijak nezaostává
v metrikách FCP a LCP. Z výsledků měření na mobilních zařízení si také lze všimnout, že SSR a prerendering podle očekávání zlepšily výrazně metriky LCP a SI. Na výsledném LPS se jejich zlepšení ale až tak neprojevilo, a to zejména z horšího TTI, CLS a TBT.
Tabulka 2 Jednostránková aplikace: synteticky naměřené výkonnostní metriky pomocí Lighthouse
Rendering LPS FCP SI LCP TTI TBT CLS
SSR 98 0,4 1 1 0,9 50 0,07
prerender 95 0,4 0,4 0,9 0,8 10 0,39
server render 96 0,4 0,7 0,8 0,4 0 0,42
CSR 99 0,7 0,7 0,9 0,8 20 0,05
SSR mobile 86 1,5 2,3 3,5 4,6 200 0,04
prerender mobile 89 1,5 1,5 3,4 3,4 170 0,05
server render mobile 93 1,5 1,8 3,2 1,5 0 0,05
CSR mobile 82 2,5 2,5 4,1 3,9 170 0,03
8.1.2 Výkonnostní syntetické měření pomocí Pagespeed.cz
Poslední výkonnostní metriky naměřené nástrojem Pagespeed.cz lze vidět v Tabulka 3.
Všechny verze renderingů jsou tímto nástrojem monitorovány déle než měsíc. V případě LPS se jak pořadí, tak hodnoty metrik jednotlivých renderingů dosti měnily – v extrémních případech až o 22 bodů pro stejnou metriku. Bohužel nelze příliš určit, co tyto odchylky způsobuje. Příčinou rozdílů může být jak hosting aplikací, tak nestabilita měřícího prostředí nástroje Pagespeed až po změny v obsahu stránky – přece jen události ve farnosti se mění v průběhu času. Tak či tak je dosti diskutabilní, jak moc lze brát v úvahu hodnoty naměřené tímto nástrojem.
Kompletní historii měření lze nalézt na https://pagespeed.cz/r/dfd49e8aff7b.
Tabulka 3 Jednostránková aplikace: synteticky naměřené výkonnostní metriky pomocí Pagespeed.cz
Rendering LPS FCP SI LCP TTI TBT CLS
SSR 82 2,64 5,14 3,26 3,57 210 0,06
prerender 76 2,97 3,01 4,65 3,9 210 0,06
server render 85 2,64 4,71 3,26 2,64 0 0,06
CSR 80 2,64 3,36 4,24 3,49 200 0,06
8.1.3 Výkonnostní měření reálných uživatelů
Měření výkonu na zařízeních návštěvníků webu a sběr dat probíhalo od 6. února do 18.
dubna 2021. Během této doby bylo nasbíráno 1172 záznamů. Výsledné hodnoty uvedené v Tabulka 4 jsou vždy 7. decilem ze všech naměřených hodnot pro danou metriku a rendering.
Výkonnostní zpomalení aplikací používajících pro rendering serverovou stranu bylo popsáno již v úvodu této podkapitoly. To, že jsou horší výsledky dány právě cold startem bylo usouzeno především na základě rozdílných hodnot TTFB pro jednotlivé druhy renderingů.
Za povšimnutí stojí lepší výsledky prerenderingu oproti CSR v metrikách FCP a LCP – předgenerované HTML v tomto případě relativně statické stránky opravdu zrychluje vykreslení stránky uživatelům. Další zajímavostí jsou velmi nízké hodnoty FID – za ideální se považují hodnoty do 100ms, což s přehledem splňují všechny druhy renderingů.
Tabulka 4 Jednostránková aplikace: naměřené výkonnostní metriky reálných uživatelů
Rendering FCP LCP FID CLS TTFB
8.2.1 Výkonnostní syntetické měření pomocí Lighthouse
V případě desktopové verze vyšlo na všech stránkách a ve všech druzích renderingu skóre vyšší než 95. Lighthouse i Google považují skóre nad 90 jako perfektní, nemá je tedy cenu příliš analyzovat, protože nemají velkou výpovědní hodnotu.
U testů v režimu mobilních zařízení už se více projevují specifika jednotlivých druhů renderingů. V tabulce Tabulka 5 jsou zprůměrovány výsledky měření přes všechny stránky pro mobilní zařízení.
Lze vidět, že server rendering v tomto případě dosahuje výrazně lepšího Lighthouse performance skóre. Server rendering dosahuje oproti zbylým renderingům výrazně lepších výsledků v metrikách TTI a TBT. Oproti zbylým renderingům dosahuje server rendering horších hodnot ve FCP, rozdíl oproti zbylým renderingům je ale minimální (130ms později oproti nejlepšímu CSR). V případě LCP dosahuje dokonce nejlepších výsledků ze všech renderingů, ikdyž jsou zde rozdíly minimální.
Z měření se nepotvrdilo, že by SSR a prerendering zlepšoval celkovou výkonnost stránky (LPS). Sice zlepšují metriky LCP a CLS, takže vykreslování v tomto případě na uživatele působí rychlejším a stabilnějším dojmem, ale zhoršují metriky TTI a TBT, což má za následek pozdější reakce na uživatelské vstupy a aplikace může působit zasekaným dojmem.
Ve zbylých tabulkách (Tabulka 6 - Tabulka 9) lze vidět výsledky měření pro jednotlivé druhy stránek. Za povšimnutí stojí, jak velký vliv má množství vykonávaného javascriptu na metriky TTI a TBT – rozdíl mezi statickou stránkou, kde jde v podstatě čistě jen o nastartování Angularu a stránkou detailu kategorie, kde se musí inicializovat stránkování je skoro trojnásobný. Stránka detailu kategorie celkově dosti zhoršila výsledky CSR, SSR a prerenderingu – nejspíš právě proto, že je na ní potřeba provést nejvíce práce v prohlížeči klienta.
Tabulka 5 E-shop: průměr skóre napříč stránkami pro mobilní zařízení
Rendering LPS FCP SI LCP TTI TBT CLS
SSR 77,75 1,7 2,18 3,48 4,18 542,5 0,22
prerender 75,75 1,68 1,85 3,55 4,38 557,5 0,19
server render 89,5 1,78 2,43 3,33 2,25 27,5 0,17
CSR 76,25 1,65 1,88 4,3 3,85 382,5 0,38
Tabulka 6 E-shop domovská stránka: synteticky naměřené výkonnostní metriky pomocí Lighthouse
Rendering LPS FCP SI LCP TTI TBT CLS
SSR 98 0,6 0,7 1,1 0,8 10 0,08
prerender 98 0,5 0,5 1 0,7 10 0,08
server render 97 0,5 1,1 1 0,5 0 0,04
CSR 98 0,5 0,6 1,1 0,6 0 0,09
SSR mobile 73 1,7 1,9 4,5 4,5 480 0,11
prerender mobile 70 1,7 1,7 4,7 4,5 470 0,16
server render mobile 84 1,6 2,7 4,3 2,2 30 0,1
CSR mobile 74 1,7 1,8 4,9 3,9 390 0,16
Tabulka 7 E-shop detail produktu: synteticky naměřené výkonnostní metriky pomocí Lighthouse
Rendering LPS FCP SI LCP TTI TBT CLS
SSR 99 0,5 0,6 0,8 0,6 0 0,06
prerender 99 0,5 0,5 0,7 0,7 10 0,06
server render 100 0,5 0,8 0,7 0,5 0 0,02
CSR 98 0,5 0,6 1,1 0,6 0 0,04
SSR mobile 84 1,7 2,1 2,6 3,7 430 0,39
prerender mobile 85 1,7 1,7 2,6 3,8 440 0,44
server render mobile 93 1,7 2,1 2,6 2,4 30 0,34
CSR mobile 77 1,6 1,9 3,9 4,1 380 0,42
Tabulka 8 E-shop detail kategorie: synteticky naměřené výkonnostní metriky pomocí Lighthouse
Rendering LPS FCP SI LCP TTI TBT CLS
SSR 94 0,5 0,9 1 1,3 120 0,14
prerender 97 0,5 0,5 1,1 1,3 40 0,11
server render 96 0,6 1,6 0,9 0,6 0 0,07
CSR 97 0,5 0,7 1,1 0,6 0 0,11
SSR mobile 61 1,7 2,8 4,2 5,1 960 0,3
prerender mobile 58 1,7 2,4 4,3 5,1 970 0,11
server render mobile 86 1,7 2,5 3,7 2,2 30 0,24
CSR mobile 72 1,6 2 4,5 4,1 390 0,88
Tabulka 9 E-shop statická stránka: synteticky naměřené výkonnostní metriky pomocí Lighthouse
Rendering LPS FCP SI LCP TTI TBT CLS
SSR 99 0,5 0,6 0,8 0,6 10 0,05
prerender 99 0,5 0,5 0,7 0,6 0 0,05
server render 99 0,6 0,8 0,8 0,6 0 0
CSR 99 0,5 0,6 0,8 0,6 0 0,05
SSR mobile 93 1,7 1,9 2,6 3,4 300 0,06
prerender mobile 90 1,6 1,6 2,6 4,1 350 0,06
server render mobile 95 2,1 2,4 2,7 2,2 20 0
CSR mobile 82 1,7 1,8 3,9 3,3 370 0,06
8.2.2 Výkonnostní syntetické měření pomocí Pagespeed.cz
Jak lze vidět z tabulek níže, pořadí renderingů v naměřených hodnotách vesměs odpovídá měřením na lokálním počítači. Na rozdíl od lokálního syntetického měření jsou hodnoty stejně jako u jednostránkové aplikace posunuty do horšího skóre. Shodně jako v případě měření u farních sbírek, se měření v různých dnech dosti lišila. Je tedy otázka, jak věrohodné
výsledky z tohoto měření jsou. Jednotlivé stránky a historii jejich měření lze nalézt pod těmito odkazy:
• Domovská stránka: https://pagespeed.cz/r/faaec312600d
• Detail produktu: https://pagespeed.cz/r/e2b5f760c2af
• Detail kategorie: https://pagespeed.cz/r/082926336764
• Statická stránka: https://pagespeed.cz/r/f7651e1fd2a3
Tabulka 10 E-shop domovská stránka: synteticky naměřené výkonnostní metriky pomocí Pagespeed.cz
Rendering LPS FCP SI LCP TTI TBT CLS
SSR 66 2 5 4,6 4,5 490 0,06
prerender 73 2 2,5 4,6 4,4 440 0,06
server render 74 1,6 7,1 4,3 1,9 30 0,1
CSR 73 1,6 3,9 4,5 3,8 400 0,16
Tabulka 11 E-shop detail produktu: synteticky naměřené výkonnostní metriky pomocí Pagespeed.cz
Rendering LPS FCP SI LCP TTI TBT CLS
SSR 86 2 2,5 6 3 260 0,06
prerender 79 1,6 2,7 7,8 1,6 0 0,39
server render 82 1,6 3,7 6,7 3,3 390 0,33
CSR 70 2,2 3,2 5,6 3,8 220 0,39
Tabulka 12 E-shop statická stránka: synteticky naměřené výkonnostní metriky pomocí Pagespeed.cz
Rendering LPS FCP SI LCP TTI TBT CLS
SSR 82 2 5,4 2,9 2,8 390 0,06
prerender 76 2,2 4,1 3,6 3,8 470 0,06
server render 88 2 6,4 2,5 2 20 0
CSR 82 1,6 3,9 3,8 2,9 290 0,11
Tabulka 13 E-shop detail kategorie: synteticky naměřené výkonnostní metriky pomocí Pagespeed.cz
Rendering LPS FCP SI LCP TTI TBT CLS
SSR 68 1,6 5,9 3,5 4,1 470 0,7
prerender 73 2,2 5,3 3,8 4,5 280 0,46
server render 76 2 8,6 3,8 2,1 30 0
CSR 66 1,6 6,1 4,4 3,9 320 1,18
8.3 E-shop – SEO
Při vyhodnocování a měření SEO se vyskytlo několik problémů, které měly za následek to, že se nepodařilo jednotlivé stránky zaindexovat tak, jak bylo zamýšleno v podkapitole 6.4.
Proběhlo několik pokusů zaindexovat zamýšlené produkty ve všech verzích renderingu, bohužel se nepovedlo docílit, aby Google vyhledávač přestal označovat jednotlivé verze jako kanonické a tím je vyřadil z výsledků vyhledávání. Bohužel každý pokus opravy stál hodně času – zejména po stránce indexovací, kdy vyhledávači trvalo 2–4 týdny, než započalo indexování a v administrační konzoli se objevila zpětná vazba, co nevyhovuje. Samotné implementační pokusy o opravu byly také časově náročné – e-shop byl během této snahy znovu nasazen na domény třetího řádu, byly přidány reálné popisy produktů a ke každé verzi renderingu byly vytvořeny samostatné backendy vracející odlišné titulky stránek. Tyto problémy měly za následek, že do doby odevzdávání diplomové práce již Google a Bing vyhledávače nestihly bezchybně zaindexovat produkty ve všech verzích renderingu. Ze zamýšleného porovnání pozice ve vyhledávačích pro dosud neexistující produkty se tedy nepodařilo získat dostatečně kvalitní výsledky.
Z výsledků, které se podařilo nasbírat nicméně jasně vyplývá, že pokud je pro webovou aplikaci důležitá indexovatelnost, pouhý client-side rendering není dostatečný. Bing, Seznam, ani sociální sítě, neumí z takto renderovaných webových stránek vyčíst nic, kromě staticky definovaných hodnot společných pro celou aplikaci. Google, který sice takto renderované stránky opravdu umí spolehlivě indexovat, ale při indexování dává přednost serverově renderovaným stránkám, kterých zaindexuje více a rychleji.
Při pokusech o indexaci se ale projevily zajímavé rozdíly mezi jednotlivými druhy renderingu – a to v počtu indexovaných stránek. Do vyhodnocování je tedy přidána tato metrika, která může napovědět, jak rychle jsou schopny vyhledávače indexovat jednotlivé druhy renderingů – a pravděpodobně i jak často tyto jejich crawlery stránky navštěvují.
8.3.1 SEO – Výsledek vyhledávání
Při vizuálním porovnání výsledků vyhledávání pro jednotlivé druhy renderingů lze na první pohled zjistit, že ze všech vyhledávacích robotů při indexování spouští javascript na stránce pouze Google vyhledávač.
8.3.1.1 Google
Jak lze vidět na obrázku (Obrázek 22), Google zvládá správně naindexovat všechny druhy renderingů včetně client-side renderované verze.
Obrázek 22 Výsledek vyhledávání: Google.com
8.3.1.2 Seznam.cz
V případě vyhledávače Seznam.cz lze vidět (Obrázek 23), že tento vyhledávač při indexování nespouští javascript. Ze všech kromě CSR byl schopen vyčíst titulek a obsah stránky specifický pro produkt. To, že byl vůbec schopen tento produkt v případě CSR vyhledat je nejspíš způsobeno tím, že jeho název je uveden také v URL. Zajímavým jevem je, že v případě prerenderingu vyhledávač zobrazuje také informace ze strukturovaných dat.
Dělá to i v případě jiných produktů, zvláštní ale je, že ne v případě SSR či server renderingu, který tyto data obsahuje také.
Obrázek 23 Výsledek vyhledávání: Seznam.cz
8.3.1.3 Bing.com
Napříč tomu, že by dle dokumentace Bing měl umět indexovat CSR, je z výsledků vyhledávání vidět, že při indexování javascript spuštěn nebyl. U žádné verze vyhledávač nezobrazoval rozšířené výsledky týkající se produktu na stránce.
Zajímavostí u tohoto vyhledávače také bylo, že jako jediný u většiny stránek z prerendered verze byl zaindexován pouze text „Redirecting to /product/Ergonomic-Soft-Salad/“. Hosting v tomto případě nejspíš vracel přesměrovávací HTTP stavový kód, který již crawler – jak by bylo očekáváno – nenásledoval.
Obrázek 24 Výsledek vyhledávání: Bing.com
8.3.2 SEO – počet zaindexovaných výsledků
Při ladění indexování bylo překvapením, jak velké množství a jak rychle indexovaly Google a Bing vyhledávače serverově renderovaný obsah. Z počtu naindexovaných stránek (Tabulka 14) lze také vyčíst, že i když Google umí CSR indexovat, dává při indexování přednost serverově renderovaným variantám. Data o počtu zaindexovaných stránek Seznam vyhledávačem mohou být zavádějící – Seznam totiž neobdržel sitemap soubor, ale byly mu vkládany URL k indexaci ručně. Je možné, že se při tomto manuálním zadávání stala někde chyba.
Tabulka 14 Počty naindexovaných stránek různých verzí renderingů
Vyhledávač Server render CSR SSR prerender
Google.com 310 4 51 5
Bing.com 306 5 61 66
Seznam.cz 4 6 17 11
8.3.3 SEO – Pozice ve vyhledávačích pro dosud neexistující produkty Jak již bylo zmíněno výše, v čase vypracovávání diplomové práce se nepodařilo stihnout naindexovat každý produkt ve všech verzích renderingu.
Vyhledávač Bing naindexoval ve všech verzích pouze 3 produkty, kdy na prvním místě ve výsledcích vyhledávání vždy skončila serverově renderovaná verze.
V případě Seznam vyhledávače se podařilo naindexovat 5 produktů, z pořadí jednotlivých verzí ve výsledcích toho moc vyčíst nelze – vypadá to, že v tomto případě byly výsledky řazeny spíše náhodně.
Tabulka 15 Bing.com pozice jednotlivých renderingů ve výsledcích vyhledávání
Rendering 1. 2. 3. 4.
SSR 0 2 0 1
prerender 0 0 3 0
server render 3 0 0 0
CSR 0 1 0 2
Tabulka 16 Seznam.cz pozice jednotlivých renderingů ve výsledcích vyhledávání
Rendering 1. 2. 3. 4.
SSR 2 0 3 0
prerender 1 0 2 2
server render 2 0 0 3
CSR 0 5 0 0
8.3.4 SEO – Google product snippet
Google test rozšířených výsledků vrátil pro všechny druhy renderingů stejný výsledek:
„Stránka je vhodná pro rozšířené výsledky“ a v náhledu product snippetu ve vyhledávání lze vidět (Obrázek 25), že ze strukturovaných dat byla správně vyčtena cena a dostupnost.
Obrázek 25 Google product snippet preview
8.3.5 SEO – Facebook snippet
Jak lze vidět na obrázku (Obrázek 26), Facebook při generování náhledů k příspěvkům nespouští javascript na stránce, což má za následek, že v CSR ze stránky vyčte jen generický titulek stránky. Z ostatních renderingů již vyčte všechny informace, které byly nadefinované do og tagů.
Obrázek 26 Facebook snippety – vlevo nahoře CSR, vpravo nahoře SR, vlevo dole SSR, vpravo dole prerender
9 Subjektivní vyhodnocení
Cílem této práce je kromě objektivního vyhodnocení jednotlivých druhů renderingů pomocí definovaných metrik a měření také subjektivně srovnat přívětivost a výhody implementace jednotlivých verzí renderingu. V rámci subjektivního vyhodnocení jsou také porovnány jednotlivé implementace z uživatelského hlediska.
9.1 Implementační přívětivost
I když se přístupy v programování určitých částí v různých druzích renderingu dosti liší, výslednou aplikaci lze udělat perfektně fungující a výkonnou jak v Angularu, tak NestJS.
V každém z těchto frameworků jsou ale různé části různě složité, a to je to hlavní, v čem se liší.
9.1.1 Srovnání architektur, nasazování do produkce a potřebných znalostí programátorů
Rozdělení aplikací na frontendovou a backendovou část, což bývá obvyklé při CSR a jeho alternativách, obvykle také vede k rozdělení programátorských týmů na dva – frontend a backend. To ve výsledku umožňuje hlubší specializace programátorů na danou oblast. Ve frontendové části je obvykle kromě výkonnosti také třeba řešit právě SEO, UX, design, kompatibilitu napříč prohlížeči a zařízeními, či přizpůsobení handicapovaným. V případě backendu pak do hry vstupují různé druhy specializovaných databází, které by měl dobrý backend developer ovládat. Jak bylo ale naznačeno i v této práci, onen frontend lze psát kompletně na serverové části, která komunikuje s REST API backendu. Problém zde ale nastává v tom, že frontend developeři dost často neznají MVC návrhový vzor, který se na serverové části obvykle používaná. Místo toho jsou zvyklí pracovat s komponentovou strukturou jejich aplikací. Tomuto přístupu také nahrává fakt, že již mnoho designérů umí přistupovat k návrhu stránek pomocí komponent, což vede k plynulejší implementaci designů do kódu.
Rozjet a nasadit do produkce CSR aplikaci bylo nejjednodušší ze všech implementovaných verzí. Řešení funguje spolehlivě a zadarmo.
Rozjetí SSR je již mnohem obtížnější úloha. Nejenže je potřeba rozjet NodeJS server, o který je potřeba se starat (jak bylo v rámci této práce zjištěno, „bezúdržbové“ řešení v podobě lambda funkcí není pro tento případ ideální), ale v případě Angularu je také třeba používat SSR kompatibilní knihovny a kdekoliv v kódu se vyvarovat přístupu ke globálním objektům jako window či document. V případě použití takového objektu celý proces obsluhující SSR spadne, a aplikace vrací chybu 500.
Prerendering je v případě aplikací používající REST API pocitově ze všech druhů renderingu nejnáročnější. Co se týče kódu, aplikace musí splňovat ty samé požadavky, co pro SSR. Na rozdíl od SSR sice nepotřebuje pro provoz server, pro správnou funkčnost je ale potřeba nastavit CI/CD aplikace, které se spustí s každou změnou dat v REST API. Další věc, kterou je třeba pro správnou funkčnost vyřešit, je automatizované generování URL
určených k prerenderingu, které se vkládají jako vstup do sestavovacího skriptu. Proces sestavování aplikace pak trvá tím dýl, čím více stránek je potřeba prerenderovat – což se může prodražit v CI/CD řešeních. V případě, že se všechny tyto problémy vyřeší, provoz takové aplikace je pak již na rozdíl od serverových verzí bez problémů.
Rozjet server rendering odpovídá náročnosti zařízení infrastruktury pro SSR. V případě, že by byl místo javascriptu použit např. jazyk PHP, s existencí hostingů může být i tento přístup velice levný a nenáročný. Celkově by autor zařadil náročnost tohoto řešení mezi CSR a SSR.
Rozjet server rendering odpovídá náročnosti zařízení infrastruktury pro SSR. V případě, že by byl místo javascriptu použit např. jazyk PHP, s existencí hostingů může být i tento přístup velice levný a nenáročný. Celkově by autor zařadil náročnost tohoto řešení mezi CSR a SSR.