Den initiala laddningstiden för din webbplats eller app är det första intrycket användarna får. I den här artikeln går vi igenom effektiva metoder för att kapa viktiga sekunder från den initiala sidladdningen.
Inledande laddningstid
Den tid det tar från det att en besökare anger din webbadress tills innehållet visas är några av de viktigaste sekunderna för att skapa ett positivt första intryck.
Amazon upptäckte att varje hundradels sekunds fördröjning kostade dem 1% av försäljningen.
Trots detta behandlar många webbutvecklare detta som en eftertanke. Fler och fler bibliotek läggs till för allt fler funktioner, vilket gradvis leder till minskade konverteringar. Det värsta är att dessa förluster är svåra att upptäcka eftersom användare lämnar långsamma sidor innan mätvärden kan registreras.
Vissa av dessa tekniker kan implementeras på frontend, medan andra på backend. Oavsett vilket måste webbapplikationer laddas snabbt.
Implementera korrekta mätningar
Det första steget är att införa mätningar. Det finns många faser i laddningsprocessen, och utan att mäta de korrekta segmenten kan man inte lokalisera flaskhalsarna.
Här är de viktigaste milstolparna i laddningsprocessen:
Mätvärden | Diagram skapat på Terrastruct
Detta innebär att du bör spåra mätvärden för varje segment i diagrammet.
Låt oss utforska hur du kan göra detta.
Webbläsarförfrågan till svar:
Mät detta på din server. Fokusera på tidsintervallet från det att ditt API tar emot en begäran tills det ger ett svar. Beroende på om externa anrop, till exempel till databaser, görs, kan detta vara antingen mycket snabbt eller en betydande flaskhals.
Svar ankommer till webbläsaren:
Detta är svårare att mäta, men en metod är att lägga till en tidsstämpel när ditt svar lämnar servern och mäta det mot den aktuella tiden på användarens sida så tidigt som möjligt (med en scripttagg i HTML-kodens head-sektion).
Svar mottaget till den första färdigmålningen:
Den första innehållsrika målningen avser när det första elementet visas i DOM. Det kan vara så enkelt som lite text eller en bakgrundsfärg eller en laddningsindikator. Detta kan mätas med Lighthouse i Chromes utvecklarverktyg.
Första innehållsrika målningen till största innehållsrika målningen:
Den största innehållsrika målningen syftar på när det största elementet visas i användarens webbläsarfönster. Detta indikerar ofta slutet av ”renderingsdelen” av sidladdningen, och användaren ser en fullständig skärm. Detta mäts också med Lighthouse.
Största innehållsrika målningen till tiden tills interaktiv:
Slutligen avser tid till interaktiv den tidpunkt då användaren kan genomföra åtgärder som att rulla, klicka och skriva. Det kan vara frustrerande om detta tar lång tid, eftersom de ser en renderad skärm men inte kan interagera! Lighthouse hjälper oss även att mäta detta.
Minska mängden kod
När du har mätvärden kan du börja med optimeringar. Optimeringar innebär kompromisser, och mätningarna visar vilka som är värda det.
Den snabbaste sidan att ladda är en tom sida, men mycket kod kan läggas till innan man märker skillnaden i laddningshastighet. Ibland är stegen så små att man inte märker skillnaden från version till version, tills det en dag börjar kännas långsamt. När din app blivit uppsvälld, är det dags att minska kodmängden.
Du får två hastighetsförbättringar när du minskar kod:
- Din app överförs snabbare via nätverket.
- Användarens webbläsare tolkar koden snabbare.
Den första hastighetsökningen är liten; eftersom förfrågningar komprimeras, kan 1 MB mindre källkod ge 10 KB i bandbreddsbesparingar. Men hastigheten av att analysera mindre kod är betydande. Dina användare kör troligen din app i olika webbläsare och datorer, många saknar kapacitet att tolka koden lika snabbt.
Eller så använder de mobila enheter med ännu mindre processorkraft. Skillnaden kan uppgå till sekunder.
Ju mindre kod du har, desto snabbare kan webbläsaren slutföra analysen och börja köra appen. Även om du visar en laddningsskärm som Javascript styr, föregås detta av analysen av den koden.
Men du vill inte ta bort funktioner eller radera kod. Lyckligtvis finns det flera metoder för att reducera kod utan att göra det.
- Använd en minifierare för din kod. Minifierare utför optimeringar som att förkorta långa namn till korta (signUpDarkModeButton blir ss), ta bort mellanslag och annat för att göra din kod så kompakt som möjligt utan att förlora funktionalitet.
- Importera specifika delar. Bibliotek är ofta fullpackade med saker du inte behöver. Om du bara vill ha en viss funktion från ett verktygsbibliotek, importera bara den koden du behöver.
- Använd ”tree-shaking” för oanvänd kod. Ibland finns det kod kvar för felsökning eller så har du inte städat upp en gammal funktion ordentligt. Verktyg som Webpack kan identifiera oanvänd kod och ta bort den från produktionsbyggen.
Dela upp koden i mindre delar
Efter att ha reducerat så mycket kod du kan från din totala applikation, kan du fundera på att dela upp den ytterligare för att minska koden som behövs för den initiala laddningen.
Anta att 20% av din kod driver en funktion som användare endast kan komma åt efter några klick. Då vore det onödigt för webbläsaren att analysera den koden innan en laddningsskärm visas. Att dela upp din kod i mindre bitar kan avsevärt minska tiden till interaktiv.
Istället för att ha en sammanvävd graf över import för alla dina Javascript-filer, identifiera områden som kan delas upp. En komponent kanske laddar tunga bibliotek. Du kan isolera komponenten i en egen fil och importera den först när användaren är redo att interagera med den.
Det finns flera bibliotek för att skjuta upp laddningen, beroende på vilket ramverk du använder. Det finns ingen anledning att dela upp varje komponent eftersom det kan leda till en snabb initial laddning, men att användaren måste vänta vid varje efterföljande interaktion. Hitta de största delarna som kan segmenteras och dela upp koden där.
Server-side rendering
Med tanke på att webbläsare behöver göra all analys och kompilering, och att användare använder Chromebooks och mobila enheter, är en vanlig teknik för att minska laddningstider att låta servrarna ta en del av belastningen. Istället för att ge en tom sida och sedan använda Javascript för att fylla i innehållet, som många SPA gör, kan du köra en Javascript-motor på din server (vanligtvis Node.js) och fylla i så mycket data och innehåll som möjligt.
Dina servrar är mycket snabbare och mer förutsägbara än användarnas webbläsare. Oundvikligen kommer de fortfarande behöva analysera lite Javascript-kod för att appen ska vara interaktiv. Ändå kan server-side rendering fylla i en stor del av det initiala innehållet, så att när användaren får sidan, visar den åtminstone en laddningsskärm eller förloppsindikator.
Och om data krävs för den initiala vyn, behöver inte klienten göra en separat begäran, utan den är redan integrerad i appen.
Komprimera resurser
Resurser ger liv åt en sida och sidan känns inte helt laddad förrän de har renderats. Det kan vara bakgrund, ikoner, profilbilder, till och med laddningsindikatorn. Resurser kan även ändra layouten, så om en användare försöker interagera med något kan sidan fortsätta att hoppa runt medan resurser laddas in. Ibland är resurser den största innehållsrika målningen.
Men resurser är även en av de tyngsta delarna av en app. En bild kan vara flera megabyte, och laddning av många ikoner kan lätt överskrida webbläsarens maximala samtidiga nätverksbegäran, vilket orsakar en lång laddningskö.
Du bör inte ladda ner en bild från internet och sedan referera till den i din app. Bilder bör skalas till de minsta mått de ska visas i. Om du har en profilbild i ett element på 50 x 50 pixlar, utan att ändra storlek, kommer din app att lägga tid på att ladda ner en stor bild och sedan anpassa den.
Bilder kan även komprimeras beroende på format. Webb är det föredragna formatet, men komprimering på webben förbättras ständigt. På grund av att formaten förändras kanske vissa webbläsare inte stöder de nyare! Lyckligtvis kan webbläsarteknik tillåta användarens webbläsare att ladda det format den stöder.
Komprimera därför till det senaste formatet, men behåll även en äldre version och använd bild- och videoelement som stöder alternativa format.
Slutsats
Dessa är fem av de mest effektiva teknikerna för att ge användarna en snabb initial laddning av appen. Dessa förbättrar konverteringsfrekvens, användarupplevelse och även sökrankning eftersom SEO gynnar snabba laddningstider. På Terrastruct använder vi dessa tekniker och mer, så att användare kan skapa och visa diagram så snabbt som möjligt.