Hvor raskt nettstedet eller appen din først lastes inn, er førsteinntrykket brukerne dine får. I denne veiledningen viser vi utprøvde teknikker for å barbere bort verdifulle sekunder fra den første sideinnlastingen.
Innholdsfortegnelse
Innledende lastetid
Tiden det tar fra brukeren eller kunden din skriver inn domenenavnet til nettstedet ditt til de ser innhold er de viktigste sekundene du trenger for å gjøre et godt førsteinntrykk.
Amazon fant ut at hver 100 millisekund med ventetid kostet dem 1 % i salg.
Og likevel behandler mange nettutviklere dette som en ettertanke. Flere og flere biblioteker legges til for flere og flere funksjoner, og gradvis over tid begynner de å se færre konverteringer. Enda verre, disse tapene i konvertering er vanskelige å oppdage fordi de forlater en side som laster sakte før den rekker å sende noen beregninger.
Noen av disse er teknikker som kan implementeres på front-end og noen på back-end. Uansett må nettapper lastes raskt.
Legg til de riktige målene
Det første du må gjøre er å legge til mål. Det er mange stadier av lasteprosessen, og du vil ikke vite hvor flaskehalsen er uten å måle de riktige segmentene.
Følgende er de viktigste milepælene i lasteprosessen:
Mål | Diagram opprettet på Terrastruct
Hva dette betyr er at du bør spore beregninger for hvert segment av dette diagrammet.
La oss gå gjennom hvordan du kan gjøre det.
Nettleserforespørsel til svar levert:
Mål dette på serveren din. Du ønsker å få øyeblikket API-et ditt mottar forespørselen når det gir et svar. Avhengig av om det foretas eksterne anrop til for eksempel databaser, kan dette enten være svært kort eller en betydelig flaskehals.
Svar levert på mottatt svar:
Dette er vanskeligere å måle, men en måte å gjøre det på er å legge til et tidsstempel når svaret ditt forlater serveren din og måle det med gjeldende tid på brukerens side i det første mulige øyeblikket (en script-tag i hodet av HTML-en) side).
Svar mottatt på første innholdsrike maling:
Den første innholdsrike malingen refererer til når det første elementet gjengis på DOM. Det kan være noe så enkelt som litt tekst, eller bakgrunn, eller en lastespinn. Dette kan måles ved å kjøre Lighthouse i Chrome-utviklerverktøyene.
Første innholdsrike maling til største innholdsrike maling:
Den største innholdsrike malingen refererer til når det største elementet gjengis i brukerens nettleservisningsport. Dette signaliserer vanligvis slutten på «gjengivelses»-delen av sideinnlastingen, og brukeren ser en fylt skjerm. Dette måles også ved å kjøre Lighthouse.
Største innholdsrike maling til tid til interaktiv:
Til slutt refererer tid til interaktiv til når brukeren kan utføre handlinger som å bla, klikke og skrive. Det kan være spesielt frustrerende hvis denne varigheten er lang fordi de vil se en gjengitt skjerm foran seg, men ikke kan gjøre noe når de forventer at de er i stand til det! Dette er en annen beregning som Lighthouse hjelper oss med å måle.
Reduser kode
Nå som du har målinger, kan du begynne å gjøre optimaliseringer. Optimaliseringer har avveininger, og målingene vil fortelle deg hvilke som er verdt det.
Den raskeste siden å laste er en tom side, men mye kode kan legges til en app før noen kan merke forskjellen i lastehastighet mellom den og en tom side. Det som ofte skjer er at trinnene er så små at du ikke merker forskjellen fra bygg til bygg før det en dag begynner å føles tregt. Du innser at appen din er oppblåst, og det er på dette tidspunktet at reduksjon av kode vil gjøre en forskjell.
Du får to forbedringer i hastighet når du reduserer kode:
- Appen din overføres raskere over nettverket.
- Brukerens nettleser fullfører parsingen av koden raskere.
Den første speedupen er liten; siden forespørsler er komprimert over ledningen, hvis du kutter 1 MB kildekode, kan det utgjøre bare 10 KB besparelse på båndbredde. Hastigheten fra å analysere mindre er imidlertid betydelig. Brukerne dine kjører sannsynligvis appen din på et helt spekter av nettlesere og datamaskiner, mange av dem har ikke datakraften som kan analysere koden like raskt som den gjør på egen hånd.
Eller de kan kjøre på mobile enheter, med enda mindre datakraft. Forskjellen kan være i størrelsesorden sekunder.
Så jo mindre kode du har, desto raskere kan nettleseren fullføre parsingen og begynne å kjøre appen din. Selv om du vil vise en innlastingsskjerm som Javascript kontrollerer, har det gått foran parsingen av den koden.
Men du vil ikke kutte funksjoner eller faktisk slette kode. Heldigvis er det et par standardmetoder for å redusere kode uten å måtte gjøre det.
- Kjør koden din gjennom minifiers. Minifiers utfører optimaliseringer som å forkorte lange navn til korte (signUpDarkModeButton blir ss), fjerne mellomrom og andre for å få koden din så kompakt som mulig uten å miste noe.
- Importer deler. Bibliotekene er ofte oppblåste av ting du ikke trenger, men som er pakket sammen under en paraplypakke. Kanskje vil du bare ha en spesifikk funksjon av et hjelpebibliotek, så i stedet for å importere hele biblioteket, kan du importere akkurat den koden du trenger.
- Tree-shake død kode. Noen ganger legger du igjen kode for feilsøkingsformål eller har ikke ryddet grundig opp i en utdatert funksjon, og selv om den er i kildekoden din, blir den aldri kjørt. Det er verktøy i JavaScript-verktøykjeden, som Webpack, som kan oppdage død kode eller ubrukte avhengigheter og fjerne dem fra produksjonsbygget automatisk for deg.
Del koden i biter
Etter å ha redusert så mye kode du kan fra den generelle appen din, kan du tenke på å presse denne ideen ytterligere og redusere koden som trengs for den første belastningen.
La oss si at 20 % av koden din driver en funksjon i appen din som brukere bare kan komme til etter noen få klikk. Det ville være bortkastet tid for nettleseren å analysere den koden før den viser en lasteskjerm. Å dele opp koden din i biter kan redusere tiden til interaktiv betraktelig.
I stedet for å ha en sammenflettet avhengighetsgraf over importer for alle Javascript-filene dine, identifiser områder som enkelt kuttes. For eksempel, kanskje en komponent laster noen tunge biblioteker. Du kan isolere den komponenten til sin egen fil og deretter bare importere når brukeren er klar til å samhandle med den komponenten.
Det er flere biblioteker der ute for å utsette lasting, avhengig av hvilket rammeverk du bruker. Det er ingen grunn til å gå over bord med dette og dele ut hver komponent, for da har brukeren en rask innledende belastning og må vente på hver påfølgende interaksjon. Finn de største delene du kan segmentere, og del kildekoden din der.
Gjengivelse på serversiden
Gitt at nettlesere trenger å gjøre alt den intensive parsingen og kompileringen og ha brukere på Chromebooks og mobile enheter, er en vanlig teknikk for å redusere lastetidene å la serverne ta noe av denne belastningen. Hva dette betyr er at i stedet for å gi en tom side og deretter bruke Javascript for å fylle ut alt innholdet, slik de fleste enkeltside-apper gjør i disse dager, kan du kjøre en Javascript-motor på serveren din (vanligvis Node.js) og fylle ut så mye av data og innhold du kan.
Serverne dine vil være mye raskere og forutsigbare enn brukernes nettlesere. Uunngåelig vil de fortsatt trenge å analysere litt Javascript-kode for at appen skal være interaktiv. Likevel kan gjengivelse på serversiden fylle ut mye av det opprinnelige innholdet, slik at når brukeren får siden, viser den som et minimum allerede en lasteskjerm eller fremdriftslinje.
Og hvis data er nødvendig for den første visningen, trenger ikke klienten å gjøre en separat forespørsel for å få det; det vil allerede være hydrert i appen for klienten å bruke.
Komprimer eiendeler
Eiendeler gjør en side levende, og en side føles ikke fullstendig lastet før disse eiendelene er ferdige med gjengivelsen. Dette kan være bakgrunnen din, brukergrensesnittikoner, et brukerprofilbilde, til og med lastespinneren. Ofte kan eiendeler også endre oppsettet, så hvis en bruker begynner å prøve å samhandle med noe, kan siden fortsette å hoppe rundt mens eiendeler lastes inn. Noen ganger er disse ressursene den største innholdsrike malingen.
Men eiendeler er også en av de tyngste delene av en app. Et bilde kan komme inn på flere megabyte, og lasting av mange ikoner kan lett overskride nettleserens maksimale samtidige nettverksforespørselsgrense, noe som forårsaker en svimlende kø med lasting.
Du vil nesten aldri laste ned et bilde fra internett og deretter referere til det i appen din. Bildene bør endres til de minste mulige dimensjonene som de vil bli vist på. Hvis du har en brukerprofil vist i et lite element på 50 piksler x 50 piksler, uten å endre størrelsen, vil appen din ta deg tid til å laste ned hele bildet som ser skarpt ut som skrivebordsbakgrunn, og deretter endre størrelsen til den lille størrelsen.
For det andre kan bilder komprimeres avhengig av formatet. I disse dager er webm det foretrukne formatet, men feltet for komprimering på nettet blir stadig forbedret, og mange nye formater er i horisonten. På grunn av formatenes skiftende natur kan det hende at enkelte nettlesere ikke støtter de nyere! Heldigvis kan nettleserteknologi la brukerens nettleser laste uansett format de støtter.
Så komprimer til det nyeste og beste formatet, men behold også en mindre moderne versjon, og bruk bilde- og videoelementer som støtter fallende formater.
Konklusjon
Dette er fem av de mest effektive teknikkene for å gi brukerne dine en lynrask førstelasting på appen din. Disse vil forbedre konverteringsfrekvensen, brukergleden og til og med søkerangeringene dine, ettersom SEO belønner raske lastetider. På Terrastructbruker vi disse teknikkene og mer slik at brukerne kan lage og se diagrammer som du ser i denne artikkelen så raskt som mulig.