Hvor hurtigt dit websted eller din app indlæses i starten, er det første indtryk, dine brugere får. I denne vejledning viser vi gennemprøvede teknikker til at barbere værdifulde sekunder fra den første sideindlæsning.
Indholdsfortegnelse
Indledende indlæsningstid
Den tid, det tager, fra din bruger eller kunde indtaster dit websteds domænenavn, til de ser indhold, er de vigtigste få sekunder, du har for at gøre et godt førstehåndsindtryk.
Amazon fandt ud af, at hver 100 millisekunders latenstid kostede dem 1 % i salg.
Og alligevel behandler mange webudviklere dette som en eftertanke. Flere og flere biblioteker tilføjes for flere og flere funktioner, og gradvist over tid begynder de at se færre konverteringer. Endnu værre er disse tab i konverteringen svære at opdage, fordi de forlader en side med langsom indlæsning, før den når at sende nogen metrics.
Nogle af disse er teknikker, der kan implementeres på front-end og nogle på back-end. Uanset hvad skal webapps indlæses hurtigt.
Tilføj de rigtige mål
Den første ting du skal gøre er at tilføje mål. Der er mange stadier af indlæsningsprocessen, og du ved ikke, hvor flaskehalsen er uden at måle de rigtige segmenter.
Følgende er de vigtigste milepæle i lastningsprocessen:
Mål | Diagram oprettet den Terrastruct
Hvad dette betyder er, at du skal spore metrics for hvert segment af dette diagram.
Lad os gå igennem, hvordan du kan gøre det.
Browseranmodning til svar leveret:
Mål dette på din server. Du ønsker at få det øjeblik, din API modtager anmodningen, når den leverer et svar. Alt efter om der foretages eksterne opkald til fx databaser, kan dette enten være meget kort eller en væsentlig flaskehals.
Svar afgivet på det modtagne svar:
Dette er sværere at måle, men en måde at gøre det på er at tilføje et tidsstempel, når dit svar forlader din server og måle det med den aktuelle tid på brugerens side i det første mulige øjeblik (et script-tag i hovedet af HTML-koden) side).
Svar modtaget på første tilfredse maling:
Den første indholdsfulde maling refererer til, hvornår det første element gengives på DOM. Det kan være noget så simpelt som noget tekst eller baggrund eller en indlæsningsspinner. Dette kan måles ved at køre Lighthouse i Chrome-udviklerværktøjerne.
Første indholdsfyldte maling til største indholdsfyldte maling:
Den største indholdsfulde maling refererer til, når det største element gengives i brugerens browservisningsport. Dette signalerer typisk slutningen af ”gengivelses”-delen af sideindlæsningen, og brugeren ser en udfyldt skærm. Dette måles også ved at køre Lighthouse.
Største indholdsrig maling til tid til interaktiv:
Endelig refererer tid til interaktiv til, hvornår brugeren kan udføre handlinger som at rulle, klikke og skrive. Det kan især være frustrerende, hvis denne varighed er lang, fordi de vil se en gengivet skærm foran dem, men ikke kan gøre noget, når de forventer, at de er i stand til det! Dette er en anden metrik, som Lighthouse hjælper os med at måle.
Reducer kode
Nu hvor du har målinger, kan du begynde at foretage optimeringer. Optimeringer har afvejninger, og målingerne vil fortælle dig, hvilke der er det værd.
Den hurtigste side at indlæse er en tom side, men der kan tilføjes en masse kode til en app, før nogen kan bemærke forskellen i indlæsningshastighed mellem den og en tom side. Det, der ofte sker, er, at stigningerne er så små, at du ikke kan mærke forskellen fra bygning til bygning, før det en dag begynder at føles langsomt. Du indser, at din app er oppustet, og det er på dette tidspunkt, at reduktion af kode vil gøre en forskel.
Du får to forbedringer i hastigheden, når du reducerer kode:
- Din app overføres hurtigere over netværket.
- Brugerens browser afslutter parsingen af koden hurtigere.
Den første speedup er lille; da anmodninger er komprimeret over ledningen, hvis du skærer 1 MB kildekode, kan det kun svare til 10 KB besparelse på båndbredde. Fremskyndelsen fra at parse mindre er dog betydelig. Dine brugere kører sandsynligvis din app på et helt spektrum af browsere og computere, hvoraf mange ikke har den computerkraft, der kan parse koden lige så hurtigt, som den gør på egen hånd.
Eller de kan køre på mobile enheder med endnu mindre computerkraft. Forskellen kan være i størrelsesordenen sekunder.
Så jo mindre kode du har, jo hurtigere kan browseren afslutte parsingen og komme i gang med at køre din app. Selvom du ønsker at vise en indlæsningsskærm, som Javascript styrer, er den gået forud for parsing af denne kode.
Men du ønsker ikke at skære funktioner eller faktisk slette kode. Heldigvis er der et par standardpraksis til at reducere kode uden at skulle gøre det.
- Kør din kode gennem minifiers. Minifiers udfører optimeringer som at forkorte lange navne til korte (signUpDarkModeButton bliver ss), fjerne mellemrumstegn og andre for at få din kode så kompakt som muligt uden at miste noget.
- Importer partialer. Biblioteker er ofte oppustede med ting, du ikke har brug for, men som er pakket sammen under en paraplypakke. Måske ønsker du kun en bestemt funktion af et hjælpebibliotek, så i stedet for at importere hele biblioteket, kan du importere lige den kode, du har brug for.
- Træ-ryst død kode. Nogle gange efterlader du kode til fejlfindingsformål eller har ikke ryddet grundigt op i en forældet funktion, og selvom den er i din kildekode, bliver den aldrig kørt. Der er værktøjer i JavaScript-værktøjskæden, som Webpack, der kan registrere død kode eller ubrugte afhængigheder og fjerne dem fra produktionsbygningen automatisk for dig.
Opdel koden i bidder
Efter at have reduceret så meget kode som du kan fra din samlede app, kan du overveje at presse denne idé yderligere og reducere den nødvendige kode til den indledende belastning.
Lad os sige, at 20 % af din kode driver en eller anden funktion i din app, som brugerne kun kan komme til efter et par klik. Det ville være spildtid for browseren at parse den kode, før den viser en indlæsningsskærm. At opdele din kode i bidder kan reducere tiden til interaktiv markant.
I stedet for at have en sammenflettet afhængighedsgraf over importer for alle dine Javascript-filer, skal du identificere områder, der nemt kan skæres. For eksempel kan en komponent måske indlæse nogle tunge biblioteker. Du kan isolere den komponent i sin egen fil og derefter kun importere, når brugeren er klar til at interagere med den komponent.
Der er flere biblioteker derude til at udskyde indlæsningen, afhængigt af hvilken framework du bruger. Der er ingen grund til at gå overbord med dette og opdele hver komponent, for så har brugeren en hurtig indledende belastning og skal vente på hver efterfølgende interaktion. Find de største stykker, som du kan segmentere, og opdel din kildekode der.
Gengivelse på serversiden
I betragtning af at browsere skal udføre al den intensive parsing og kompilering og have brugere på Chromebooks og mobile enheder, er en almindelig teknik til at reducere indlæsningstider at få dine servere til at tage noget af denne belastning. Hvad dette betyder er, at i stedet for at give en tom side og derefter bruge Javascript til at udfylde alt indholdet, som de fleste enkeltside-apps gør i disse dage, kan du køre en Javascript-motor på din server (normalt Node.js) og udfylde så meget af data og indhold, som du kan.
Dine servere vil være meget hurtigere og forudsigelige end brugernes browsere. Uundgåeligt skal de stadig parse noget Javascript-kode, for at appen kan være interaktiv. Alligevel kan gengivelse på serversiden fylde meget af det indledende indhold, så når brugeren får siden, viser den som minimum allerede en indlæsningsskærm eller statuslinje.
Og hvis der er behov for data til den indledende visning, behøver klienten ikke at lave en separat anmodning for at få det; det vil allerede være hydreret i appen, som klienten kan bruge.
Komprimer aktiver
Aktiver gør en side levende, og en side føles ikke fuldstændig indlæst, før disse aktiver er færdige med at blive gengivet. Dette kan være din baggrund, brugergrænsefladeikoner, et brugerprofilbillede, selv indlæsningsspinneren. Ofte kan aktiver også ændre layoutet, så hvis en bruger begynder at forsøge at interagere med noget, kan siden fortsætte med at hoppe rundt, mens aktiver indlæses. Nogle gange er disse aktiver den største indholdsrige maling.
Men aktiver er også en af de tungeste dele af en app. Et billede kan komme ind på flere megabyte, og indlæsning af mange ikoner kan nemt overskride browserens maksimale samtidige netværksanmodningsgrænse, hvilket forårsager en svimlende kø af indlæsning.
Du vil næsten aldrig downloade et billede fra internettet og derefter henvise til det i din app. Billeder skal ændres til deres mindst mulige dimensioner, som de vil blive vist ved. Hvis du har en brugerprofil vist i et lille element på 50 pixel gange 50 pixel, uden at ændre størrelsen, vil din app tage sig tid til at downloade det fulde billede, der ser skarpt ud som skrivebordsbaggrund og derefter ændre størrelsen til den lille størrelse.
For det andet kan billeder komprimeres afhængigt af deres format. I disse dage er webm det foretrukne format, men komprimeringsfeltet på nettet bliver konstant forbedret, og mange nye formater er i horisonten. På grund af formaternes skiftende karakter understøtter nogle browsere muligvis ikke de nyere! Heldigvis kan browserteknologi lade brugerens browser indlæse, hvilket format de understøtter.
Så komprimer til det nyeste og bedste format, men behold også en mindre moderne version, og brug billed- og videoelementer, der understøtter faldende formater.
Konklusion
Dette er fem af de mest effektive teknikker til at give dine brugere en lynhurtig første indlæsning af din app. Disse vil forbedre dine konverteringsrater, brugerglæde og endda søgerangeringer, da SEO belønner hurtige indlæsningstider. På Terrastructanvender vi disse teknikker og mere, så brugerne kan oprette og se diagrammer, som du ser i denne artikel, så hurtigt som muligt.