Effekten av rekommenderade prestanda tekniker för front-end prestanda på en webbapplikation

Effekten av rekommenderade prestanda

tekniker för front-end prestanda på en

webbapplikation

Fredrik Borssén, Drinas Kastrati

Handledare/Tutor, Name Anders Fröberg Examinator, Name Sahand Sadjadee

Upphovsrätt

Detta dokument hålls tillgängligt på Internet – eller dess framtida ersättare – under 25 år från publiceringsdatum under förutsättning att inga extraordinära omständigheter uppstår.

Tillgång till dokumentet innebär tillstånd för var och en att läsa, ladda ner, skriva ut enstaka kopior för enskilt bruk och att använda det oförändrat för ickekommersiell forskning och för undervisning. Överföring av upphovsrätten vid en senare tidpunkt kan inte upphäva detta tillstånd. All annan användning av dokumentet kräver upphovsmannens medgivande. För att garantera äktheten, säkerheten och tillgängligheten finns lösningar av teknisk och administrativ art.

Upphovsmannens ideella rätt innefattar rätt att bli nämnd som upphovsman i den omfattning som god sed kräver vid användning av dokumentet på ovan beskrivna sätt samt skydd mot att dokumentet ändras eller presenteras i sådan form eller i sådant sammanhang som är kränkande för upphovsmannens litterära eller konstnärliga anseende eller egenart.

För ytterligare information om Linköping University Electronic Press se förlagets hemsida http://www.ep.liu.se/_​.

Copyright

The publishers will keep this document online on the Internet – or its possible replacement – for a period of 25 years starting from the date of publication barring exceptional circumstances.

The online availability of the document implies permanent permission for anyone to read, to download, or to print out single copies for his/hers own use and to use it unchanged for non-commercial research and educational purpose. Subsequent transfers of copyright cannot revoke this permission. All other uses of the document are conditional upon the consent of the copyright owner. The publisher has taken technical and administrative measures to assure authenticity, security and accessibility.

According to intellectual property law the author has the right to be mentioned when his/her work is accessed as described above and to be protected against infringement.

For additional information about the Linköping University Electronic Press and its procedures for publication and for assurance of document integrity, please refer to its www home page: http://www.ep.liu.se/_​.

Sammanfattning

Webbapplikationer har blivit mer och mer en kritisk del för varje aspekt i våra liv. Det är något som alla har lättillgängligt och använder dagligen. Detta har noterats med åren och därav har många företag satsat på att utveckla webbapplikationer med fokus på att underlätta arbetet för sina anställda. Under dessa stora projekt som krävs för att få fullt fungerande applikationer och webbapplikationer finns det en tendens att prestandan för front-end hamnar i bakgrunden.

Det här examensarbetet fokuserar sig på att utvärdera effekten av rekommenderade förbättringar i prestandan. Dessa rekommenderingar fås genom körningar från prestanda verktyg samt från en litteraturstudie. Detta för att förhoppningsvis öka prestandan för framtida webbapplikationer som leder till att webbapplikationer ska vara smidigare och snabbare och därav öka arbetseffektiviteten. En webbapplikation som är till för att tracka containrar via GPS och RFID kommer att utvecklas, denna webbapplikationen kommer att utvecklas i React med likadana komponenter och programmeringsstil som det tekniska företaget Utsikt Bredband använder sig av. Prestandatester kommer sedan att köras på denna webbapplikation samt andra webbapplikationer som företaget använder sig av för att se hur prestandan ligger till. Detta blir följt av en djupdykning i litteratur där allmänna tekniker för att öka front-end prestandan kommer att undersökas. Varje teknik kommer sedan att undersökas där det kollas på hur pass bra implementerad denna teknik är i webbapplikationen som utvecklades. Detta resulterar sedan i en tabell där dessa tekniker visas upp tillsammans med hur mycket tid tekniken kan spara om den väl implementeras i företagets webbapplikationer, samt en skala på hur pass komplicerad implementationen kan vara.

Innehåll

2.1 Effekten av front-end optimering 13

2.2 HTTP requests 13 2.3 Cache Optimering 13 2.4 Optimering av koder 14 2.4.1 Optimering av HTML 14 2.4.2 Optimering av CSS 14 2.4.3 Optimering av JavaScript 14 2.4.4 React 15 2.5 Code splitting 15 2.6 Lighthouse 16 _{​2.6.1 Render-blocking Resources} 16 _{​2.6.2 Minify JavaScript} 16

_{​2.6.3 Preconnect to required origins} 17

3.0 Metod 18 3.1 Förstudie 18 3.2 Val av testmiljö 18 3.2.1 Tillvägagångssätt 18 3.3 Utveckling av webbapplikation 19 3.4 Undersökning av förbättringar 19

3.5 Metod för rekommenderade prestanda tekniker 20

3.6 Optimering av kod 20

4.0 Resultat 21

4.1 Prestanda Körningar 21

4.2 Remove unused CSS 22

4.3 Optimera Render-blocking resources 23

4.4 Optimera Minify JavaScript 23

4.5 Optimera Preconnect to required origins 24

4.6 HTML optimering 24

4.7 CSS optimering 24

4.8 JavaScript och React optimering 25

4.9 Code splitting 25 4.10 Sammanfattning av resultat 25 5.0 Diskussion 27 5.1 Källkritik 27 5.2 Metod 27 5.3 Resultat diskussion 29

5.4 Etiska och Samhälleliga aspekter 29

Figurer

3.1 Exempel på resultat från en prestanda körning 18 4.1 Förbättringar som ska göras efter körning 1 21

4.2 Antal filer som laddas ner 21

4.3 Förbättringar som ska göras efter körning 2 22 4.4 Förbättringar som ska göras efter körning 3 22

4.5 Resultat från första körningen 25

4.6 Resultatet från första körningen efter optimering 25 5.1 Resultat från en dator med bättre prestanda 27 5.2 Resultat från en dator med sämre prestanda 27

Tabeller

4.1 Resultattabell av körningar 20

4.2 Visar resultaten av alla tekniker 24

Grafer

1.Inledning

Webbapplikationer har under det senaste decenniet ökat i popularitet och användning. Detta är till stor del tack vare att det nu för tiden är så enkelt att berika sina webbapplikationer med bilder, spel, videos, med mera. Tillsammans med större och snyggare webbapplikationer följer en negativ del med, nämligen storleken av webbapplikationen. Konsekvensen med större webbapplikationer är den negativa påverkan på prestandan och desto mer prestandan är påverkad ju längre tid tar det för webbapplikationen att ladda sidan för användaren, speciellt på exempelvis ett dåligt nätverk. Detta är inget som är eftertraktat hos användare som med tiden har vuxit sig till att förvänta sig en bra prestanda från webbapplikationer. Faktum är att 53% av besökta webbapplikationer överges ifall det tar längre än tre sekunder för dem att ladda[1]. Vikten i att ha en bra front-end prestanda kan ses i företag som med hjälp av ökad prestanda på sina webbapplikationer har ökat sin inkomst. Företaget Mobify ökade sin inkomst med ungefär 530,000$ genom att optimera renderingstiden för sin checkout sida med bara 100 ms[17]. När företaget Auto Anything reducerade sin renderingstid med hälften såg man en ökad inkomst på 12-13%[17]. Så vikten i att ha bra prestanda i en webbapplikation är svårt att förneka.

1.1 Bakgrund

Utsikt bredband är ett tekniskt företag som utvecklar webbapplikationer för sina kunder. I dagsläget saknas det en webbapplikation som kan spåra och ge en bättre koll på lagerstatus för containrar. Huvudsyftet med att utveckla en sådan webbapplikation är att underlätta arbetet och därmed öka arbetseffektiviteten. Men för att detta ska funka måste prestandan hos webbapplikationen vara på topp. Med bättre prestanda kommer snabbare rendering av sidorna och en snabbare interaktions tid, vilket är nödvändigt för att webbapplikationen ska uppfylla sitt syfte.

1.2 Motivering

Att använda webbapplikationer för att få en förbättrad arbetseffektivisering har på senare år populariserats bland affärsansvariga[2]. Detta är något som har fallit i intresse för Utsikt bredband där de vill utveckla en webbapplikation för att underlätta arbetet med lagerstatus för containrar. Då all loggning och kontroll av containrarna sker manuellt måste flertal interna samtal göras per dag för att hålla koll på alla containrar. Dessa samtal måste i snitt göras 6 gånger per dag där varje samtal tar ca 5 minuter. Det resulterar i ca 30 minuter per dag som går åt för bara container plan. Årligen läggs mängder med timmar ner på detta och därmed försvinner pengar på ett arbete som kan förbättras. Denna förbättring sker med hjälp av en GPS tracker och en RFID läsare som är till för att hålla koll på företagets containrar.

Men för att webbapplikationen ska vara effektiv gäller det att prestandan är så bra som möjligt. För att uppnå detta är det viktigt att förstå prestandan av ens webbapplikation genom att utföra prestandatester med hjälp av prestanda verktyg på webbapplikationen[18][20]. Samt genom att implementera tekniker vars huvudsyfte är prestandan optimering får man en front-end som är lättanvändlig och hjälper webbapplikationen att agera mer som ett hjälpverktyg istället för ett hinder.

1.3 Syfte

Syftet med arbete är att undersöka effekten av de rekommenderade lösningsförslagen från ett presentationsverktyg samt allmänna tekniker som används för ökning av prestanda . För att uppnå detta har en webbapplikation att utvecklas i React där samma komponenter och programmeringsstil som företaget Utsikt Bredband använder sig av när de utvecklar sina appar.

1.4 Problemformulering

Problemen som detta arbete ska undersöka är följande:

● Är de rekommenderade lösningsförslagen från ett prestandaverktyg pålitliga när det gäller front-end prestanda på webbapplikationer.

1.5 Avgränsning

Följande begränsningar har vidtagits under arbetet: 1. Alla tester sker för front-end prestandan.

2. Inga nya verktyg ska installeras i företagets miljö.

1.6 Rapportöversikt

Följande kapitel innehåller teori, där litteratur gällande kod optimering och front-end presenteras. I kapitel 3 presenteras metoderna som utfördes för att besvara frågeställningen.

Därefter kommer kapitel 4,5 och 6. 4 Resultatet utav allt arbete och tester, 6 diskussionen av metod och resultat samt kapitel 7 som innefattar en sammanfattning av detta kandidatarbete.

1.7 Språkbruk

Front-end _{​Refererar till arbetet som krävs för att skapa användargränssnittet.} React.js (React) _{​Ett JavaScript-bibliotek som är till för att bygga webbgränssnitt.}

2. Teori

För att få en bättre förståelse i vad som kan hindra en webbapplikation från att ha en bra prestanda måste en djupare förståelse inom webbutvecklings optimering fås. Detta kapitel presenterar de tekniker och designval som ska användas för att göra en optimerad webbapplikation.

2.1 Effekten av front-end optimering

När man pratar om front-end optimering så menar man processen att förfina webbsidan för att få den att render sidorna snabbare, att göra den mer användarvänlig. Generellt så innebär processes att minska storleken på applikations filerna, ta bort onödig kod och minimera antalet filer som behövs laddad ner för att sidan ska kunna visas. Hur man optimerar sidan kan göras på ett flertal sätt, vilken eller vilka tekniker som används varier från sidan till sida. Nedan presenteras de mest vanliga tekniker som ska finnas i när man vill optimera front-end.

2.2 HTTP requests

När en webbsida besöks för första gången måste besökare ladda ner alla resurser istället för att ladda dem genom en webbläsarens cacheminne. Att reducera antalet HTTP requests är en vanlig tekniker för att få en optimerad sida. Varje video, bild, script och stylesheet som finns resulterar i en HTTP request från webbläsaren till server. Ju fler requests som måste göras till servern ju mer förlängs tiden för att sidan ska renderas. Laddningstiden förvärras bara ju fler användare som använder sidan. En annan anledning till varför HTTP requesten kan dra ner sidans prestanda är att filerna är för stora. Ju större filer ju längre HTTP requests måste göras.

Hur man löser dålig prestanda på grund utav HTTP requests kan ske på många sätt där de mest vanliga metoden är att använda verktyg som tex HubSpot, för att få en bättre överblick över hur många HTTP requests som görs samt hur lång tid det tar[3][6].

2.3 Cache Optimering

Cache minnet används för att lagra information såsom HTTP requests mellan klient och server. Med optimering utav Cache minnet så kan man minska data utbytet som sker mellan klienten och servern. Detta kan därmed förbättra prestandan för webbapplikationen. De nedladdade komponenterna är lagrade i webbläsarens cacheminne och webbläsaren läser från cacheminnet för att minska HTTP requests. [4]

Expires header är en tillvägagångssätt där webbservern kommunicerar med klienten och säger att så länge en komponent är tillgänglig i cache minnet så ska cache versionen av komponenten användas, vilket leder till en förminskning av HTTP requests. E-tag är en fysisk

tag som används för att verifiera att den cachade komponenten är tillgänglig och giltig, om dessa krav inte uppfylls så måste webbläsaren skicka en GET requests.[5][16]

2.4 Optimering av koder

För att i huvudtaget kunna göra en hemsida behövs ett HTML dokument som är ett språk för att beskriva struktur i en webbsida. HTML kan man säga är själva basen för en hemsida. För att sedan göra presentationen bättre används CSS vilket är ett språk som beskriver presentation stilen. När man sedan ska göra webbsidan lite mer interaktiv med användare kommer JavaScript in i bilden. Alla dessa språk är nödvändiga för att göra en funktionsduglig hemsida. Men om ingen struktur följs och mycket dubblett kod skrivs kommer detta att påverka prestandan av webbsidan. Att skriva kod med struktur som är uppdelad i flera filer är inte bara för att göra det mer lättläsligt utan även att hjälpa prestandan för webbsidan.

2.4.1 Optimering av HTML

HTML [14] står för HyperText Markup Language och är ett märkspråk. HTML är en kritisk del av webbapplikationen och dess prestanda. När en webbsida uppdateras så kommer HTML dokument att laddas om på nytt. Om dokumenten då är väldigt stora kommer det att sakta ner hela processen att hämta datan på nytt[6]. Detta tack vare att HTTP requests är väldigt långa eller många om det är många dokument som måste laddas om på nytt, som beskrivet i sektion 2.2. Det är också bra att tänka på vart i koden man implementerar sina CSS stylesheet samt JavaScript. Inkluderar man sitt CSS stylesheet i toppen av HTML dokumentet, i _{​header taggen, underlättar} det progressiv rendering. Med hjälp av progressiv rendering så ger man webbläsaren ett försprång med att hämta alla nödvändiga bitar av webbsidan. Utan progressive rendering kan användare uppleva laddningstiden som seg då man bara får en blank bild medan webbsidan laddar[7].

2.4.2 Optimering av CSS

CSS [14] står för Cascading Style Sheets och är som tidigare nämnt till för att hjälpa till med presentationen av webbsidan. De enklaste sätten för att optimera CSS är att minimera, göra den mer kompakt och dela upp CSS filerna. Detta innebär att ta bort dubbletter av kod[16], ta bort vita tecken och dela upp filerna i olika stylesheets. Användning av CSS expressions, som är JavaScript som är implementerad i en CSS property, kan vara väldigt tungt för prestandan av webbsidan då dessa expressions körs varje gång sidan scrollas upp eller ner. Även när något så simpelt som när musen flyttas så körs CSS expressionen flera tusentals gånger[8].

av HTML dokumentet. Om JavaScriptet, mot förmodan, skulle implementeras i toppen av HTML dokumentet kommer det blockera nedladdningsprocessen av HTML och CSS elementen. Detta resulterar i en blank sida medan allt laddas, istället för en sida som laddas upp progressivt. Har man för många paket och annan kod som måste hämtas och laddas ner kan detta ge en segare upplevelse för användaren då JavaScript kan försena den interaktiva delen med gränssnittet tack vare kostnaden av kompileringen körning av scriptet. Detta förvärras bara med en dålig nätverksuppkoppling. Detta kan till stor del reduceras med hjälp av code-splitting(presenteras i sektion 2.5) och att komprimera filerna[9].

2.4.4 React

React är ett Javascript bibliotek som används vid framför allt uppbyggnaden av User Interface (UI) vilket är det visuella på hemsidan såsom menyer, sökrutor, knappar. Webbläsare skapar något som kallas för “Document Object Model” (DOM)[15] vilket är en representation på hur webbsidan är uppbyggd. Denna kan manipulera DOM genom att lägga till komponenter vilket sedan renderas på webbsidan. För att kunna manipulera DOM så använder man sig utav JavaScript eXtension (JSX) vilket är ett HTML-style baserad språk.

Genom att använda sig utav JSX för att uppdatera DOM:en så resulterar det till en ökad prestanda av webbsidan. Anledningen till varför React JS föredras över ren HTML är för att när ren HTML används måste hela DOM:en uppdateras och när det kommer till större dynamiska sidor men hög användarinteraktion och utseende uppdateringar så stöter man på prestationsproblem.[10] Men React JS använder sig utav Virtual DOM som är en DOM som sparas i minnet och om några utseende uppdateringar sker så skickas de först till den Virtuella DOM:en som jämför nuvarande och tidigare states och därefter beräknar minst antal uppdateringar som behövs göras för att kunna applicera dessa ändringar. Därefter så appliceras dessa ändringar med minimal read/write tid.

Återanvändbara komponenter är en ytterligare fördel med React, istället för att skapa en och samma knapp varje gång den ska användas så skapar man istället en dynamisk knapp komponent som man kallar på varje gång man behöver den. Hur dessa komponenter skapas utgör till stor del hur pass bra optimerad en React applikation kommer att vara. Funktions komponenter ger en liten ökning i prestandan. Men om komponenten som skapas är till bara för en väldigt lite bit kod som inte kommer förändras medan applikationen är igång kan mycket tid sparas genom att göra det till en vanlig JavaScripts funktion[11].

2.5 Code splitting

Code splitting en metod för att dela upp alla JavaScripts filer i flera små paket så ett stort paket slipper att laddas ned. Anledning till att göra detta är för att slippa ladda ner JavaScript som inte används till den nuvarande sidan som visas för användaren. Om användaren till exempel sitter med inloggningssidan behövs egentligen bara JavaScripten för att det ska kunna att integrera med just denna sidan. Men många moderna sidor gör nämligen att när man är på inloggningssidan laddar webbläsaren inte bara ner JavaScripten för denna specifika sidan utan även script för hela webbsidan. Detta är något som inte alls är nödvändigt och något som bara saktar ner prestandan för webbsidan. Ännu värre är det speciellt för mobiler som har lite sämre prestanda och nätverksuppkoppling än en dator.

● Vendor splitting_{​: Separerar vendor kod, vilket är kod i React, lodash osv, från} koden koden som finns i applikationer. Detta hindra den negativa prestandan som kan uppkomma vid ogiltig cache för återkommande besökare när antingen vendor eller app koden förändras.

Detta är något som bör implementeras i varje applikationer.

● Entry point splitting_{​: Separerar kod genom att kolla på entry points, vilket är} vart scripts för olika verktyg så som webpack eller Parcel startar. Funkar bäst för applikationer som inte använder sig utav client side routing

● Dynamic splitting_{​: Är separering av kod där dynamisk “import()” används. Detta} är bäst att implementera för single page applikationer.

2.6 Lighthouse

Lighthouse är ett verktyg för att öka prestandan och kvalitén på webbapplikationer. När verktyget körs utförs en mängder med tester på sidan som resulterar i en rapport som sammanfattar hur pass bra sidan gjorde ifrån sig. I denna rapport finner man hur snabbt dem olika delarna på sidan gick att ladda upp samt olika lösningsförslag.

2.6.1 Render-blocking Resources

Render-blocking är ett problem där renderingen av webbsidan blockeras. Några utav de mest vanliga felen är att inkludera JavaScripts i _{​header taggen i HTML dokumentet. Det som sker då} är att renderingen av webbsidan stoppas för att exekvera JavaScriptet. Detta är dock inte nödvändigt utan scriptet är något som kan laddas upp efter att sidan själv har laddats klart, det är därför bäst att inkludera JavaScriptet i slutet av _{​body taggen eller i ​footer taggen. Samma sak} gäller med CSS/stylesheets, om disabled attributen är aktiv först när sidan väl ska renderas laddar inte webbläsaren ner stylesheets. Denna attribute kan sättas till false efter att webbsidan är färdigladdad för att slippa _{​Render-blocking​.}

2.6.2 Minify JavaScript

Att tackla problemet med _{​Minify JavaScript innebär att reducera storleken på JavaScripts filerna} och därmed snabba på renderingen av webbsidan. För att uppnå detta finns det två vanliga tekniker som brukar följas. Första tekniken går under namnet_{​Minification vilket är att ta bort alla} vita tecken och kod som inte är nödvändig, detta för att göra en mindre JavaScript fil. Ett

2.6.3 Preconnect to required origins

Om data ska hämtas från en extern sida kan man i förtid förvarna webbläsaren att en koppling vill göras så snart som möjligt till den externa sidan för att få tag i datan som är nödvändig för att rendera webbsidan. Detta är känt som _{​Preconnect to required origins och kan implementeras på} tre olika sätt _{​Preload​, ​Preconnect ​och ​Prefetch​. Preload informerar webbläsaren att en specifik} resurs behövs för navigeringen och borde hämtas snarast möjligt[19]. Preconnect infomrerar webbläsaren att webbsidan tänker göra en koppling till en extern sida och detta borde ske snarast möjligt. En negativ aspekt med Preconnect är att en etablera en koppling till en extern sida kan ta lite tid speciellt för ett långsamt nätverk. Om denna koppling inte används inom tio sekunder kommer webbläsaren per automatik stänga ner kopplingen och den tiden som lades ner för att sätta upp kopplingen kommer att ha varit i onödan. Prefetch är annorlunda i den mening att den säger inte till webbläsaren att hämtning av en viss extern resurs ska ske med högsta prio utan mer när det väl finns tid. Datan kommer att hämtas när webbläsaren ska hämta resurser med lägst prioritering. Om Prefetch används på en resurs som per automatik har en hög prioritering för nedladdning kan _{​double-fetching ske. Detta innebär att just denna resurs hämtas två gånger. En} gång med hög prioritering och en gång med en låg prioritering.

3.0 Metod

Det här kapitlet beskriver vilka metoder som används för att besvara frågeställningarna. Vilken verktyg som valdes att användas kommer även att beskrivas.

3.1 Förstudie

För att kunna besvara frågeställningen utfördes en förstudie på olika metoder där mätningen av prestanda på olika webbapplikationer är i fokus. Förstudien gick ut på att söka efter tidigare studier och artiklar som handlade om front-end prestanda för webbapplikationer. Vilken testmiljö och verktyg som valdes att användas presenteras i sektion 3.2. Dessa artiklar gav även en djupare och nödvändig kunskap i front-end prestanda i allmänhet.

3.2 Val av testmiljö

För att kolla prestandan på en testmiljö kan inbyggda verktyg i webbläsare användas. De mest populära verktygen för detta är FireFox Developer Tools som finns i Firefox och DevTools som finns i Google Chrome. För att kunna besvara vilket verktyg som verkar bäst för just detta ändamål utfördes en djupdykning i de olika funktionerna som finns i verktygen.

3.2.1 Tillvägagångssätt

Några utav de viktigaste funktionerna var att kunna se vilka filer som laddas ner, ändra nätverkshastighet, kunna simulera webbsidan på olika enheter och användarvänlig.

● Att se vilka filer som laddas ner är en grundläggande funktion och är en funktion som existerar i båda miljöerna.

● Att justera nätverkshastigheten, även känt som throttling, är en funktion som ger användaren möjlighet att ändra nätverkshastigheten. Detta är bra då man kan simulera upplevelsen för en användare med lite sämre nätverksuppkoppling.

● Kolla prestandan på en hemsida är den viktigaste funktionen. Denna funktion finns i båda miljöer men hos DevTools är funktionen redan inbyggd medan hos FireFox Developer Tools är det en extension som måste laddas ner separat.

● Simulera webbapplikationer på olika enheter underlättar arbetet för utvecklaren att göra webbapplikationer optimal för många olika enheter. Precis så som funktionen för att kolla prestanda är detta också en grundläggande

● Att verktyget är lätthanterligt med ett bra och tydligt gränssnitt är avgörande för användarvänligheten.

3.3 Utveckling av webbapplikation

Webbapplikation som utvecklades är uppbyggd utav komponenter av material-ui. Dessa komponenter används i företagets andra webbapplikationer och ger webbsidan ett snyggt och stilrent användargränssnitt. Webbapplikationen är även utvecklad med samma programmeringsstil som företaget använder sig av då den ska vara så simplistisk som möjlig för framtida vidareutvecklingar som ska göras på webbapplikationen. Front-end var i störst fokus när det gällde utvecklingen av webbapplikationen men lite inslag av back-end kom i form av dekoda datan från RFID och GPS. Eftersom webbapplikationen är uppbyggd med likadana komponenter, programmeringsstil och är i allmänhet väldigt lik företagets andra appar ger prestandatester på denna webbapplikation en bra inblick i hur den allmänna prestandan är för de andra webb applikationerna som företaget använder sig utav.

3.4 Undersökning av förbättringar

Efter man har kört testerna via Lighthouse verktyget presenteras datan, datan som presenteras ser ut på följande sätt.

Figur 3.1. Exempel på resultat från en prestanda körning genom verktyget Lighthouse.

Dem mätvärdena som visas är följande:

● First Contentful Paint (FCP). _{​Denna parameter kollar hur lång tid det tar innan första} bilden eller texten visas på hemsidan.

● Speed Index. _{​Denna parameter mäter hur snabbt sidans innehåll visas på hemsidan under} sidans laddning.

● Time to Interactive (TTI). _{​Denna parameter kollar hur lång tid det tar innan hemsidan} är fullständigt interaktiv.

● First Meaningful Paint (FMP). _{​Parametern mäter hur snabbt det primära innehållet} visas på sidan. Då denna parametern är så simulär FCP används denna parametern ej.

● First CPU Idle (FCI). _{​Denna parameter mäter hur lång tid det tar en hemsida att bli} minimalt interaktiv. Exempelvis när majoriteten av alla UI element är interaktiva.

● First Input Delay (FID). _{​Denna parameter mäter tiden mellan första interaktionen och} tiden det tar browsern att svara på denna interaktion.

Bland datan visas det även information om ändringar som kan implementeras som potentiellt kan öka prestandan hos webbsidan. Några utav de ändringar som kom efter kört tester på webbapplikationen var att eliminera _{​render-blocking resources​, ​Minify JavaScript​, ​Preconnect to} required origins_{​. Nedan kommer metoder presenteras för att försöka tackla dessa problem. Sedan} kommer en lite mer djupdykning ske där mer allmänna metoder för att förbättra front-end prestandan.

3.5 Metod för rekommenderade prestanda tekniker

För att lösa problemet med render-blocking resources kommer det först tittas på om inkluderingar med JavaScript och CSS mallar och stylesheets sker på ett korrekt sätt. Det innebär att JavaScript inkluderas i slutet av _{​body taggen eller i ​footer taggen och att stylesheets har en} disabled attribute som ändras till true först när webbsidan är färdig med att renderas[21].

Det som kommer att kollas här är att kolla i JavaScripten och om det finns möjlighet för att göra koden mindre genom _{​minification​.[16]}

För att veta om Preconnect to required origins är värt att implementera måste varje resurs prioritet kollas noga. Detta för att undvika problem såsom bortkastad tid med en uppkoppling eller att hämta en resurs två gånger _{​double-fetching​.}

3.6 Optimering av kod

Efter att ha kollat på dem tips på förbättringar som gavs ut från lighthouse så kollades webbapplikationen på dem mer allmänna teknikerna för att öka prestandan på webbapplikationer. Detta innebär då att koden ska undersökas för potentiell optimering, om chace optimering används och om code splitting är implementerat. Det som ska kollas på är hur pass koden använder sig utav de metoder som presenterades i sektion 2.3 “Optimering av koder”. När det gäller Cache optimering ska det undersökas om expires header används och om det inte används, hur kan detta implementeras. Till sist kommer en undersökning på code splitting göras. Det kommer kollas på om det används och i så fall hur.

4.0 Resultat

I detta kapitel beskrivs resultatet som kom upp genom att utfört metoderna som presenteras i kapitel 3. Resultatet kommer att presenteras i sektioner, en sektion för varje teknik som har undersökts. Resultatet sammanfattas sedan i slutet av kapitlet.

4.1 Prestanda Körningar

För att få bättre förståelse och överblick på hur prestandan för webbapplikationer är, samt en bättre förståelse på vad och hur den ska förbättras så kördes prestandatester via developer verktyget Lighthouse. Testerna utfördes på flertal olika webbapplikationer, bland de webbapplikationer som testades fanns också _{​Företags Projekt som är en webbapplikation} utvecklad av företaget. Då företagets egenutvecklade webbapplikationer går under kodnamn refereras den istället som_{​Företagets Projekt i framtiden. De andra webb applikationerna är sidor} som är utvecklade av andra företag och har då en annan komponent uppbyggnad. Den utvecklade webbapplikationen och _{​Företagets Projekt använder sig utav likadana komponenter samt} programmeringsstil och är därav bra att använda som referenspunkt i hur pass bra prestanda de två webb applikationerna har i jämförelse med varann samt med andra webbapplikationer. Testerna använder sig av följande parametrar

● Clear Storage. _{​Med denna markerad gör man testet som om det vore första gången} användaren besökt webbsidan. Det vill säga ingen sparad data i cachen, local Storage, cookies med mera. Med denna omarkerad utförs testerna med sparad data.

● Best practice. _{​Gör diverse olika tester för att se hur om goda kod vanor används.} Resultatet variera mellan 0 till 100, där 100 är det bästa resultatet.

● Performance._{​Performance är en sammansättning av flera parametrar som ger ut ett snitt} i prestanda mellan 0 till 100 där 100 är det bästa resultatet.

● Device. _{​Under den här kategorin markerades Mobile.} Resultatet presenteras i tabellen nedanför.

Tabell 4.1. Resultattabell av körningar.

Resultatet visar tydligt att både den utvecklade webbapplikationen och företagets arbetsmiljö presterar dåligt när _{​Clear Storage är markerad, men en markant bättre ökning av prestandan när} data i cache och localStorage används. Det kan noteras att hemsidor som Facebook och Aftonbladet har en ganska bra performance även fast Clear Storage är markerad.

Det som var i fokus var att förbättra prestandan när Clear Storage är markerad. I resultatet som returnerades av Lighthouse fanns en lista på tekniker som kan implementeras för

att öka prestandan. På toppen av listan låg Minify JavaScript resources följt av Render-blocking resources, Preconnect to required Origins samt att ta bort CSS sheets som inte inte används.

Figur 4.1. Förbättringar som ska göra efter körning 1

4.2

_​

_​

Remove unused CSS

Då detta var den mest simpla lösningen att implementera så prioriterades detta först. I HTML dokumentet fanns externa CSS stylesheets som aldrig användes vilket kan ses i bilden nedan.

Figur 4.2. Antalet filer som laddas ner samt användningen av filen presenterat i procent.

I figuren syns det att två utav CSS filerna som laddas ner används inte i huvudtaget och är därav helt onödig. Dessa filer implementeras i varje webbapplikation som företaget utvecklat, dock har det aldrig noterats att dessa CSS filer har använts.

4.3

_​

Optimera

_​

Render-blocking resources

Efter att ha kört testerna via Lighthouse på webbapplikationen var Render-blocking bland toppen av listan på problem som Lighthouse rekommenderade att fixa. Det första som kollades var om dem simplaste lösningarna för Render-blocking hade implementeras, vilket är vart man har inkludering av JavaScript och CSS stylesheets. I HTML dokumentet hade inte inkluderingen skett som det skulle. JavaScriptet inkluderades i _{​header taggen vilket hindrar renderingen av} webbsidan. JavaScriptet inkluderas då istället i botten av _{​body ​taggen. Inkluderingen av CSS} stylesheets saknade disabled attributen, vilket lades till. Efter att ha implementerat dessa delar och kört ett till test med Lighthouse var problemet med Render-blocking och unused CSS borta. Enligt Lighthouse rapporten sparar dessa simpla lösningar 2.3 sekunder. Efter andra körningen återstod nu bara Minify JavaScript och Preconnect to required origins kvar.

Figur 4.3. Förbättringar som ska göra efter körning 2

4.4 Optimera Minify JavaScript

Nästa moment var att kolla på hur pass bra teknikerna för Minify JavaScript används i koden. I och med att webbapplikationen är skriven i React resulterar detta i att JavaScript filerna blir väldigt stora då de utgör nästintill hela webbapplikationen. Det första som kollades var om någon typ av verktyg används för att paketera alla scripten i en bundle, detta för att få en mer komprimerad och mindre fil. Det noterades ganska fort att webpack v 4 är något som faktiskt används för att skapa bundle.js. Anledningen till varför Lighthouse nämner att Minify JavaScript är ett problem för prestandan beror då inte på att det är fel på _{​minification ​utan att filerna inte} komprimeras med hjälp utav ett verktyg till ett mindre format, som tex Gzip.

Den tredje körningen resulterande i en rapport där bara Preconnect to required origins återstår.

4.5

_​

Optimera

_​

Preconnect to required origins

För att se hur prestandan förbättras med Reconnect to required origins implimterades _{​rel​attribute} i _{​link ​taggen för nedladdningen av ett stylesheet från Atlas Microsoft. Med preload} implementerad kom ett varningsmeddelande där det stod att länken använder preload men länken inte används under de första tre sekunderna som sidan renderas. Därav säger webbläsaren att preload i detta läge är till största del onödig. Inget större utslag på prestandan eller tiden noterades. När Preconnect sedan implementerades samlade data på nedladdningstiden på stylesheets från Atlas Microsoft. Sex tester kördes med Preconnect och sex utan Preconnect. Tiderna för Preconnect adderades sedan och delades på antalet gånger testerna kördes för att få ut en medelhastighet, samma sak gjorde för utan Preconnect. Med Preconnect blev medelhastigheten 14.32ms och utan Preconnect 15.26ms. En ökning på knappt en millisekund. Ingen nedkoppling av kopplingen noterades.

Sista attributen att testa var Prefetch. Samma typ av test gjordes som med Preconnect. Sex tester kördes där medelhastigheten på nedladdningen av stylesheets gjordes. I detta fall hamnade medelhastigheten på 16.82ms. En annan observation som gjordes var att när prefetch implementerades i länken för att hämta stylesheets från fonts från Google leaps så inträffade double-fetching _{​(sektion 3.5.3) vilket innebär att filen hämtas två gånger.}

Då Preconnect gav det bästa resultatet samt inga negativa effekter som kunde observeras lät vi Proconnect stanna för den fjärde körningen. Den fjärde körningen resulterade i att opportunity fliken var nu borta. Observerar man den första körningen och kollar på “Estimated Savings” så genom att implementera dessa små och enkla ändringarna sparas det 4.67 sekunder.

4.6 HTML optimering

HTML koden som finns i företagets olika arbetsmiljöer är kort och i företagets fall så existerar enbart en html fil. Detta resulterar till att koden är bra optimerad. Render-blocking är en stor del av HTML optimering och optimerades i sektion 4.1, det löste CSS och JavaScript implementationen och gav därav ut ett optimalt resultat.

4.7 CSS optimering

När undersökningen gjordes på CSS så undersöktes det om koden var optimerad i den mening att inte dubblett kod används, inga CSS stylesheets som har skapats men inte används och CSS expressions är något som inte används för flitigt. Det noterades fort att alla CSS stylesheets som används utav företaget kommer från en extern källa, antingen från Microsoft Azure, Fonts från

4.8 JavaScript och React optimering

När det väl skulle kollas hur pass optimerad JavaScripts koden är kollades det även i samma veva hur pass optimerad React var då webbapplikationen är skriven i React. Steget för att göra JavaScripts optimerad var redan avklarad vilket var att JavaScriptet ska implementeras i botten av HTML dokumentet. Detta steg var redan gjort efter att Render-blocking resources undersöktes. Undersökningen riktade sig sedan in på att kolla på optimeringen av React. Applikationen är uppbyggd med klass komponenter istället för funktions komponenter. Dessa Klass komponenter innehåller olika komponenter som har importerats in från Material UI, samt innehåller dem olika tillstånd som komponenterna kan ha. Ett litet mindre test gjordes där ett par utav klass komponenterna byttes ut med funktions komponenter som använder sig utav _{​Hook för} att hantera dem olika tillstånden. När webbapplikationen sedan testades igen var det en skillnad på 0.69 sekunder.

4.9 Code splitting

Under tiden alla dessa undersökningar skedde noterades det ganska fort att code splitting är inget som har implementeras i webbapplikationen. Varje fil som finns har många olika import i sig, vissa används inte och många är dubbletter som finns i andra filer. Under tiden Minify JavaScript undersöktes noterades det även att webpack används, dock används inte någon utav code splitting funktionerna som är tillgängliga i webpack. Code splitting kan ske på ett antal olika sätt (sektion 2.5) och med webpack ger möjligheten till att implementera dessa metoder.

Flera försök gjordes på att försöka implementera Code Splitting, dock var dessa försöka aldrig lyckade och delades sig inte in i filer så som önskat.

4.10 Sammanfattning av resultat

Tabellen nedan visar den estimerade tiden som sparas genom att implementera tekniken. Notera även att dessa estimerade tider är den sparade tiden för webbapplikation som har utvecklats.

Tabell 4.2. Visar resultatet av alla tekniker. Tabellen visar estimerad tidsoptimering samt implementerings komplexitet.

Ett simpelt rankningssystem skapades som är baserat på hur pass svårt just denna teknik är att implementera i den utvecklade webbapplikationen. En 1:a representerar att tekniken är väldigt simpel att implementera, bara några få rader kod behöver ändras eller flyttas runt. En 5:a

däremot representerar en väldigt komplex implementation där mycket kod i många filer måste ändras samt att vissa externa verktyg kan behöva installeras.

Under alla körningar som har gjorts så har det även noterats att många små filer i form av bilder eller rader kod som laddas ner men ej används. Det är förståeligt att dessa små filer inte hamnar på toppen av listan av saker att göra för en utvecklare. Men när dessa små filer blir fler och fler kommer det i slutändan att påverka prestandan på webbsidan.

Efter att ha implementerat alla dessa tekniker gjordes en sista körning. _{​Figur 5 visar} prestanda resultatet av den första körningen som utfördes där kodoptimeringen ännu inte implementerats,_{​figur 6 visar prestanda resultatet efter implementationen av de olika teknikerna.} Förbättringen på prestandan är 6 poäng och förminskningar på de olika parametrarna.

5.0 Diskussion

5.1 Källkritik

I ett område som hela tiden är under konstant utveckling i form av nya bibliotek, nya tekniker, nya språk, med mera, så verkar det som fokuseringen på prestandan hamnar på efterkälke. Detta märktes när vetenskapliga artiklar skulle hittas. En av de större utmaningarna var att hitta vetenskapliga artiklar där webbapplikations prestanda är i fokus. Efter att ha sökt mycket efter bra vetenskapliga artiklar om prestanda som är fokuserad på front-end var det ganska klart att just detta område var inget som folk fokusera sina forskningar på. Detta känns lite konstigt då vikten av prestandan hos en webbapplikation är en utav de viktigaste faktorerna för att den ska kunna vara användbar. Endast några få artiklar hittades medan majoriteten som hittades var i andra språk vilket gjorde det oanvändbara för oss i våran studie. Detta ledde i sin tur till att vi vände oss mycket åt Google Developers. Google Developers är Googles sida för devtools, APIs och liknande tekniska områden. Det finns även dokumentation om hur dessa verktyg ska användas samt diskussionsgrupper där verktygen diskuteras. Med lite mer djupdykning skulle man nog antagligen hittat ännu fler vetenskapliga artiklar som kunde ha varit till nytta. Men tack vare det rådande läget i världen samt några andra faktorer som var bortom vår kontroll var tiden begränsad.

5.2 Metod

Det finns många olika varianter av verktyg som mäter prestanda på webbapplikationer, efter att ha gått igenom ett fåtal av de större verktygen så valde vi att använda ett inbyggt prestanda verktyg vid namnet Lighthouse. Anledningen till varför vi valde just detta verktyg för att mäta prestandan var för att vi angås att då verktyget var utvecklat av Google vilket är sedd som en tek-jätte så ansågs Lighthouse som ett verktyg med kvalitet. Verktyget blev valt även för att det redan är inbyggd i Google Chrome browsern vilket underlättade arbetet då man kunde skippa installations faserna.

Efter att ha gjort ett flertal körningar märktes det tillslut att resultaten som Lighthouse presenterade varierade dator till dator samt nät till nät, detta är ett problem då man inte kunde få fram exakta värden då alla har olika datorer samt olika hastigheter på nätverken. Som en webbutvecklare så är det viktigt att alla som besöker webbapplikationen får samma upplevelse då man vill att folk ska komma tillbaka. Med variation av prestanda så elimineras möjligheten till likadan prestandan för alla användare. I figurerna nedan visas prestanda körningen på webbapplikationen men från två olika datorer, en dator som har lite bättre hårdvara och en med lite sämre.

Figur 5.1, Resultat från en dator med bättre prestanda med clear storage incheckad.

Figur 5.2, Resultat från en dator med sämre prestanda med clear storage incheckad.

Om detta är något som hade noterats tidigare hade man kunnat kolla i hur stor vikt körningen från olika enheter har på prestandan.. När det kommer till replikerbarheten så faller våran metod något då vi använder oss utav en privat webbapplikation som är utvecklad specifikt för ett bolag. Om ett försök att återskapa detta arbete skulle göras skulle möjligheten till att använda sig utav samma webbapplikation saknas då tillgång till företagets webbapplikationer måste ges. I form av validiteten så är hela resultat egentligen beroende av rapporterna från Lighthouse. Om det skulle komma fram att algoritmerna som Lighthouse använder sig av inte är så pålitliga skulle det påverka resultatet stort då det skulle vara svårt att säga hur pass stor påverkan de implementerade teknikerna har på prestandan.

HTTP-requests och cache optimering var två områden där mer information samt djupdykning hade behövts. Båda dessa områden var serverbaserade vilket i sin tur ledde till att vi inte kunde påverka eller optimera dessa områden. Men en framgångsrik optimering av dessa två områden skulle leda till en hög tidsoptimering då man både skulle minska Http-requests som

5.3 Resultat diskussion

Arbetets syfte var att undersöka effekten av de rekommenderade lösningsförslagen från ett presentationsverktyg samt allmänna tekniker som används för ökning av prestanda. Detta togs fram med hjälp av en webbapplikation som utvecklades med samma komponenter och programmeringsstil som företaget använder sig utav. Prestanda tester kördes senare på webbapplikation tillsammans med andra webbapplikationer företaget har samt andra hemsidor. Arbetet har i huvudsak fokuserat sig på prestanda bara för front-end delen och inte back-end. Men för att få en hel bild om prestandaökning och få ut den maximala prestandan från en webbapplikation bör inte back-end ignoreras, då många tekniker för ökningen av den övergripanden prestandan faller inom back-end området. Bland dessa tekniker infaller cache optimering och http-requests vilket noterades när testerna för resultatet utfördes.

Från resultatet så kan man anta att fokus på prestanda inte verkar vara i störst i fokus när det gäller utvecklingen av webbapplikationer. Då ett företag som Utsikt Bredband som är stort företag med en god teknisk kunskap missar väldigt små och simpla tekniker som kan både ha en stor och liten påverkan på prestandan. Vikten i att inte glömma de mest simpla och grundläggande programmeringsmetoder märktes när Render-blocking resources undersöktes. En sådan simpel lösning som vart man implementerar ett script kan ge en ökning på några sekunder. Men trots att vissa små programmeringsmetoder missades var det andra bra optimeringstekniker som användes, webpack var ett utav dessa.

Generellt så har dessa resultat gett oss insikt i vikten av att lägga den extra tid som behövs för att undvika dessa fallgropar av prestandan. Med några få justeringar såsom vart man importerar filer, vilka verktyg som används och allmän bra strukturen på kod kan ge en prestandaökning från några få millisekunder till ett par sekunder. Ett intressant vidare arbete är att kolla på hur pass bra andra teknikföretag har implementerat dessa tekniska metoder för att ökningen av prestanda. Att se om dessa fallgropar är något som är allmänt som företag faller i eller om detta var mer isolerade händelse. Ännu en intressant område att undersöka skulle vara varför den utvecklade webbapplikationen har så dålig prestanda i jämförelse med de andra webbsidorna från tabellen 4.1.

5.4 Etiska och Samhälleliga aspekter

Snabbare front-end leder till bättre upplevelse på webbapplikationen av användarna, vilket i sin tur kan leda till mer trafik på hemsidan. Bra prestanda är något alla webbsidor kan gynna sig av vare sig det är ett företag som säljer produkter på nätet, eller ökad arbetsproduktivitet för ett företag som använder webbapplikationer i ett arbetssyfte. Detta är positivt för företaget i sig men detta kan i sin tur leda till att webbutvecklarna måste lägga mer timmar på planering av applikation, implementation och test faser samt prestandaoptimering.

Mer planering och test faser kan leda till att buggar och andra problem i applikationen hittas snabbare. Detta kommer gynnar både användaren och företaget då mindre driftstörningar uppkommer då man under utvecklingen hanterat och fixat buggar och problem. Det i sin tur leder till att man som utvecklare utvecklar sin förmåga att optimera applikationer.

6.0 Slutsats

I denna artikel har en webbapplikation utvecklats i React. Webbapplikationen har utvecklats med samma komponenter och programmeringsstil som företaget Utsikt Bredband använder sig av när de utvecklar sina egna webbapplikationer. Flera prestandatester utfördes med hjälp av DevTools verktyget i Google Chrome. Resultatet från dessa tester och tekniker som tagits fram från en litteraturstudie användes för att försöka förbättra front-end prestandan i webbapplikationen. I resultatet kapitlet undersöks om dessa tekniker har implementeras i webbapplikationen och om detta inte är fallet, hur mycket tid som sparas om det väl implementeras. Resultatet blev att den estimerade tidsoptimering blev hela 5.35 sekunder första gången webbapplikationen besöks. Från resultaten samt vår litteraturstudie verkar det som att fokusen på att öka prestanda på front-end hamnar i andra hand. Man kan dra slutsatsen att dessa tekniker som har används kan bli sedda som vanliga fallgropar som måste aktas för när en utveckling av en webbapplikation sker. Från tabellen 4.2 i sektionen 4.9 kan man göra en ytterligare tabell där det är rankat i vilken ordning de rekommenderade lösningsförslagen bör fixas för företaget.

Tabell 6.1. Prioriterings Tabell där det tekniska måttet högst upp ligger högst i prio.

Denna tabell är i detta fall mer skräddarsydd för företaget men kan användas som en allmän guide om vad som ska ligga i fokus när en webbapplikation utvecklas. Vidare studier behövs för att få ett resultat på tidsoptimering när det gäller code splitting. Tillsist, för att få en bättre och mer övergripande överblick gjordes en tabell där laddningstiden för varje kategori som används Lighthouse visas.

Graf 6.1 Resultat Tabell som visar renderingstiden för samt efter implementation av teknikerna, på Y-axeln visas tiden i sekunder

Tabellen visar tydligen en förminskning med ett antal sekunder på varje kategori vilket ledde till en webbapplikationen som var i allmänhet mycket snabbare och mer användarvänlig.

Litteratur

[1] Daniel An. “Find out how you stack up to new industry benchmarks for mobile page speed” , 2018,

www.thinkwithgoogle.com/marketing-resources/data-measurement/mobile-page-speed-new-indu stry-benchmarks/

[2_​]Sinha Neeta, Aror Poonam.”Effects of growing mobile usage at workplace and its impact on work productivity- A detailed analysis”, 2005

[3]_​Lindsay Kolowich, “How to reduce your website’s HTTP requests”_{​ ​, 2019 ,}

blog.hubspot.com/marketing/reduce-http-requests

[4] _​Jeff Posnick, Ilya Grigorik, “Prevent unnecessary network requests with the HTTP Cache” , Apr. 17 2020. _​web.dev/http-cache/_​ .

[5]_​ GTmetrix, “Yslow: Add expires Header” , _{​gtmetrix.com/add-expires-headers.html} [6]_​B. Cao, et al."The solution of web font-end performance optimization," 2017 10th International Congress on Image and Signal Processing, BioMedical Engineering and

Informatics_{​ (​CISP-BMEI​)​, Shanghai, 2017, pp. 1-5, doi: 10.1109/CISP-BMEI.2017.8302083.}

[7]Patrick Steele-Idem,”Async Fragments:Rediscovering Progressive HTML Rendering with Marko”, Dec. 8 2014 ,

tech.ebayinc.com/engineering/async-fragments-rediscovering-progressive-html-rendering-with-marko/

[8] Addy Osmani, ”JavaScript Start-up Optimization”, Juli. 2 2018,

developers.google.com/web/fundamentals/performance/optimizing-content-efficiency/javascript-startup-optimization#top_of_page

[9]Houssein Djirdeh, “Reduce JavaScript Payloads with Code Splitting”, Sep. 19 2018,

web.dev/reduce-javascript-payloads-with-code-splitting/

[13] _​Ports, Dan R. K. et al. “Transactional Consistency and Automatic Management in an

Application Data Cache.” _{​OSDI​ (2010).}

[14] Rolf Staflin. HTML och CSS boken. Pagina Förlags AB, 2008. ISBN: 978-91-636- 0939-82.

[15] Jeremy Keith. DOM Scriptning. Apress, 2005. ISBN: 987-1-59059-533-6.

[16]_​Iliev, et al. "Front end optimization methods and their effect." 2014 37th International Convention on Information and Communication Technology, Electronics and Microelectronics

(MIPRO)_{​. IEEE, 2014. doi: 10.1109/MIPRO.2014.6859613}

[17] Jeremy Wagner, “Why Performance Matters” , Maj. 10 2020,

developers.google.com/web/fundamentals/performance/why-performance-matters

[18] Rijwan Khan, Mohd Amjad, “Performance testing (load) of web applications based on test case management_{​”, ​Perspectives in Science​ (2016) 8, 2016 pp. 355—357,}

doi.org/10.1016/j.pisc.2016.04.073

[19] _​P. Ling, "Based on web application front-end performance optimization, Proceedings of 2011 International Conference on Electronic & Mechanical Engineering and Information Technology, Harbin, 2011, pp. 234-237, doi: 10.1109/EMEIT.2011.6022862.

[20] Remakanth, et al. ” A Survey on Performance Testing Approaches of Web Application and Importance of WAN Simulation in Performance Testing”. International Journal on Computer Science and Engineering. 4. 2012,

www.researchgate.net/publication/266462778_A_Survey_on_Performance_Testing_Approaches _of_Web_Application_and_Importance_of_WAN_Simulation_in_Performance_Testing

[21]Jovanovski, et al. "Critical CSS Rules—Decreasing time to first render by inlining CSS rules for over-the-fold elements." Postproceedings of 2016 Seminar on Advanced Techniques and Tools for Software Evolution (SATToSE)”. 2016. _​grammarware.net/text/2016/critical.pdf