Hur snabbt din webbplats eller app laddas från början är det första intrycket som dina användare får. I den här guiden listar vi beprövade tekniker för att raka bort värdefulla sekunder från den första sidladdningen.
Innehållsförteckning
Initial laddningstid
Tiden som det tar från det att din användare eller kund anger ditt webbplatsdomännamn tills de ser innehåll är de viktigaste sekunderna du behöver för att göra ett bra första intryck.
Amazon fann att var 100:e millisekund av latens kostade dem 1 % i försäljning.
Och ändå, många webbutvecklare behandlar detta som en eftertanke. Fler och fler bibliotek läggs till för fler och fler funktioner, och gradvis med tiden börjar de se färre konverteringar. Ännu värre är att dessa förluster i konvertering är svåra att upptäcka eftersom de överger en sida som laddas långsamt innan den hinner skicka några mätvärden.
Några av dessa är tekniker som kan implementeras på front-end och några på back-end. Oavsett, webbappar måste laddas snabbt.
Lägg till rätt mått
Det första du behöver göra är att lägga till mått. Det finns många steg i laddningsprocessen, och du kommer inte att veta var flaskhalsen är utan att mäta rätt segment.
Följande är de viktigaste milstolparna i lastningsprocessen:
Mått | Diagram skapat på Terrastruct
Vad detta betyder är att du bör spåra mätvärden för varje segment i detta diagram.
Låt oss gå igenom hur du kan göra det.
Webbläsarbegäran till svar visas:
Mät detta på din server. Du vill få det ögonblick som ditt API får förfrågan till när det levererar ett svar. Beroende på om externa samtal till exempelvis databaser görs kan detta vara antingen mycket kort eller en betydande flaskhals.
Svar på det mottagna svaret:
Detta är svårare att mäta, men ett sätt att göra det är att lägga till en tidsstämpel när ditt svar lämnar din server och mäta det med den aktuella tiden på användarens sida vid första möjliga ögonblick (en skripttagg i huvudet på HTML-koden) sida).
Svar mottaget på den första nöjda målningen:
Den första innehållsrika färgen hänvisar till när det första elementet renderas på DOM. Det kan vara något så enkelt som lite text eller bakgrund eller en laddningssnurra. Detta kan mätas genom att köra Lighthouse i Chromes utvecklarverktyg.
Första innehållsrika färg till största innehållsrika färg:
Den största innehållsrika färgen hänvisar till när det största elementet renderas i användarens webbläsares vyport. Detta signalerar vanligtvis slutet på ”renderingsdelen” av sidladdningen och användaren ser en fylld skärm. Detta mäts även genom att köra Lighthouse.
Största innehållsrika färg till tid till interaktiv:
Slutligen, tid till interaktiv hänvisar till när användaren kan utföra åtgärder som att rulla, klicka och skriva. Det kan vara särskilt frustrerande om denna varaktighet är lång eftersom de kommer att se en renderad skärm framför sig men inte kan göra någonting när de förväntar sig att de kan! Detta är ytterligare ett mått som Lighthouse hjälper oss att mäta.
Minska kod
Nu när du har mätningar kan du börja göra optimeringar. Optimering har kompromisser, och mätningarna kommer att berätta vilka som är värda det.
Den snabbaste sidan att ladda är en tom sida, men mycket kod kan läggas till i en app innan någon kan märka skillnaden i laddningshastighet mellan den och en tom sida. Det som ofta händer är att stegen är så små att man inte märker skillnaden från bygg till bygg förrän en dag, det börjar bara kännas långsamt. Du inser att din app är uppsvälld, och det är vid denna tidpunkt som minskning av kod kommer att göra skillnad.
Du får två förbättringar i hastighet när du minskar kod:
- Din app överförs snabbare över nätverket.
- Användarens webbläsare slutar tolka koden snabbare.
Den första hastigheten är liten; eftersom förfrågningar komprimeras över tråden, om du skär 1 MB källkod, kan det uppgå till endast 10 KB i besparingar på bandbredd. Men snabbheten från att analysera mindre är betydande. Dina användare kör förmodligen din app på ett helt spektrum av webbläsare och datorer, av vilka många inte har den datorkraft som kan analysera koden lika snabbt som den gör på egen hand.
Eller de kan köras på mobila enheter, med ännu mindre datorkraft. Skillnaden kan vara i storleksordningen sekunder.
Så ju mindre kod du har, desto snabbare kan webbläsaren slutföra analysen och börja köra din app. Även om du vill visa en laddningsskärm som Javascript kontrollerar, har den föregåtts av analysen av den koden.
Men du vill inte klippa funktioner eller faktiskt radera kod. Lyckligtvis finns det ett par standardmetoder för att reducera kod utan att behöva göra det.
- Kör din kod genom minifierare. Minifierare utför optimeringar som att förkorta långa namn till korta (signUpDarkModeButton blir ss), ta bort blanksteg och andra för att få din kod så kompakt som möjligt utan att förlora något.
- Importera delar. Biblioteken är ofta uppsvällda med saker du inte behöver men som kommer förpackade under ett paraplypaket. Kanske vill du bara ha en specifik funktion av ett verktygsbibliotek, så istället för att importera hela biblioteket kan du importera precis den kod du behöver.
- Tree-shake död kod. Ibland lämnar du kod i felsökningssyfte eller har inte rensat upp en föråldrad funktion ordentligt, och även om den finns i din källkod, körs den aldrig. Det finns verktyg i JavaScript-verktygskedjan, som Webpack, som kan upptäcka död kod eller oanvända beroenden och ta bort dem från produktionsbygget automatiskt åt dig.
Dela upp koden i bitar
Efter att ha reducerat så mycket kod du kan från din övergripande app, kan du tänka på att ytterligare pressa den här idén och minska koden som behövs för den initiala laddningen.
Låt oss säga att 20 % av din kod driver någon funktion i din app som användare bara kan komma åt efter några klick. Det skulle vara bortkastad tid för webbläsaren att analysera den koden innan den visar en laddningsskärm. Att dela upp din kod i bitar kan avsevärt minska tiden till interaktiv.
Istället för att ha en sammanflätad beroendegraf över importer för alla dina Javascript-filer, identifiera områden som lätt skärs ut. Till exempel kanske en komponent laddar några tunga bibliotek. Du kan isolera den komponenten till sin egen fil och sedan bara importera när användaren är redo att interagera med den komponenten.
Det finns flera bibliotek där ute för att skjuta upp laddningen, beroende på vilket ramverk du använder. Det finns ingen anledning att gå överbord med detta och dela ut varje komponent eftersom användaren då har en snabb initial laddning och måste vänta på varje efterföljande interaktion. Hitta de största bitarna som du kan segmentera och dela upp din källkod där.
Rendering på serversidan
Med tanke på att webbläsare behöver göra all den intensiva analysen och kompileringen och ha användare på Chromebooks och mobila enheter, är en vanlig teknik för att minska laddningstider att låta dina servrar ta en del av den belastningen. Vad detta betyder är att istället för att ge en tom sida och sedan använda Javascript för att fylla i allt innehåll, som de flesta ensidesappar gör nu för tiden, kan du köra en Javascript-motor på din server (vanligtvis Node.js) och fylla i så mycket av data och innehåll du kan.
Dina servrar kommer att vara mycket snabbare och förutsägbara än användarnas webbläsare. Oundvikligen kommer de fortfarande att behöva analysera lite Javascript-kod för att appen ska vara interaktiv. Ändå kan rendering på serversidan fylla i mycket av det initiala innehållet så att när användaren får sidan visar den som ett minimum redan en laddningsskärm eller förloppsindikator.
Och om data behövs för den initiala vyn, behöver klienten inte göra en separat begäran för att få det; det kommer redan att vara hydrerat i appen för klienten att använda.
Komprimera tillgångar
Tillgångar får en sida att vakna till liv, och en sida känns inte helt laddad förrän dessa tillgångar har renderats. Detta kan vara din bakgrund, användargränssnittsikoner, en användarprofilbild, till och med laddningssnurran. Ofta kan tillgångar också ändra layouten, så om en användare börjar försöka interagera med något kan sidan fortsätta att hoppa runt medan tillgångar laddas in. Ibland är dessa tillgångar den största innehållsrika färgen.
Men tillgångar är också en av de tyngsta delarna av en app. En bild kan komma in på flera megabyte, och laddning av många ikoner kan lätt överskrida webbläsarens maximala samtidiga nätverksbegäran, vilket orsakar en häpnadsväckande laddningskö.
Du vill nästan aldrig ladda ner en bild från internet och sedan referera till den i din app. Bilder bör storleksändras till de minsta möjliga mått som de kommer att visas vid. Om du har en användarprofil som visas i ett litet element på 50 pixlar gånger 50 pixlar, utan att ändra storlek, tar din app tid att ladda ner hela bilden som ser skarp ut som skrivbordsunderlägg och sedan ändra storleken på den till den lilla storleken.
För det andra kan bilder komprimeras beroende på deras format. Nuförtiden är webm det föredragna formatet, men fältet för komprimering på webben förbättras ständigt och många nya format är i horisonten. På grund av att formaten förändras, kanske vissa webbläsare inte stöder de nyare! Lyckligtvis kan webbläsartekniken låta användarens webbläsare ladda vilket format de stöder.
Så, komprimera till det senaste och bästa formatet, men behåll också en mindre modern version och använd bild- och videoelement som stöder fallande format.
Slutsats
Det här är fem av de mest effektiva teknikerna för att ge dina användare en blixtsnabb första laddning av din app. Dessa kommer att förbättra dina omvandlingsfrekvenser, användarglädje och till och med sökrankningar, eftersom SEO belönar snabba laddningstider. På Terrastructanvänder vi dessa tekniker och mer så att användare kan skapa och visa diagram som du ser i den här artikeln så snabbt som möjligt.