I vores kontinuerlige stræben efter sidehastighed finder vi ofte os selv i at cirkle tilbage til det samme punkt. På trods af indsatsen fra produkt-, marketing- og vækstteams for at motivere tech-teams, bliver opgaver, der kan forbedre webstedets ydeevne, ofte udskudt på grund af behovet for refaktorering, og selv når de er færdige, giver de ikke altid fuldstændige resultater. I denne cyklus er det en fordel at overveje nogle indsigtsfulde perspektiver på at opnå reel præstation. Hvilke lektioner kan vi for eksempel lære af hastigheden af ​​React.js og Vue.js eller deres SSR (server-side rendering) udvidelser som Next.js og Nuxt.js sammenlignet med andre platforme? Er det ikke tid til at optimere MB'erne af jQuery- og CSS-filer? Hvornår vil store virksomheder, der ofrer deres webydelse til dårligt informerede frontend-udviklere, vågne op? Lad os tage fat på disse spørgsmål et efter et.

Hvorfor er Next.js- og Nuxt.js-baserede websteder hurtige?

Next- og Nuxt-platformene, som er SEO-venlige strukturer bygget på React og Vue, skiller sig ud for hastighedsydelse. Men hvorfor er disse platforme så hurtige?

React.js og Vue.js er komponentbaserede rammer, der opdeler hver side i underkomponenter, som vist nedenfor.

 

billede (2).png
Kilde: https://dev.to/yakimych/seriously-do-react-hooks-replace-state-containers-3cpl

 

Lad os tage et eksempel fra den virkelige verden for at illustrere dette punkt: en e-handelsside. Denne listeside kan tænkes at have følgende underkomponenter:

  • Header
  • Listing
    • Oplysninger om opslag
      • Sidetitel
      • Brødkrumme
      • Produktantal
    • filtre
      • Kategorifilter
      • Prisfilter
      • ...
    • Sortering
    • Produktkort
      • Produktbillede
    • Produkt detaljer
      • Produktnavn
      • Produktpris
        • Gennemstreget pris
        • Udsalgspris
      • Rabat
      • Kampagneoplysninger
    • Paginering
    • Kategori indhold
  • Sidefod

Når du opretter en komponentbaseret applikation med Nuxt.js, kodes hver af disse komponenter separat og inkluderes på mastersiden. Overvej f.eks. en fil med navnet ProductPhoto.js. Uanset hvilke funktioner der er nødvendige for produktfotos (karrusel, responsiv billedvisning osv.), er JS-koden skrevet i denne komponent. Tilsvarende er det kun de CSS-filer, der bruges af denne komponent, der er inkluderet i den. Det betyder, at kun de filer, der kræves af hver komponent, udføres, hvis komponenten bruges.

Hvordan håndteres denne proces i øjeblikket på de fleste webplatforme?

En script.js-fil indeholder kode til alt fra medlemskab, filtre og kurvesider til menuen, som kører på alle sider. Resultatet? 

 

billede-1 (2).png

 

Hjemmesider med en 3 MB JS-fil og en 1.5 MB CSS fil. Hovedproblemet er ikke kun filstørrelserne, men det faktum, at du ikke kan forvente, at en gennemsnitlig Android-mobil enheds CPU udfører tusindvis af linjer kode inden for millisekunder. Ved kun at køre den kode, du har brug for, kan du opnå præstationsgevinster.

Hvordan fjerner man gengivelsesblokerende ressourcer?

I dag bruger 32 % af de 1 million bedste websteder Font Awesome skrifttypebiblioteket, som i gennemsnit er på omkring 250 KB. I betragtning af at asynkron indlæsning ikke foretrækkes på grund af svirpeffekten, så tænk på, hvor mange skrifttyper der er synlige på den første skærm på en side, når den åbnes på mobil eller desktop. En kort undersøgelse på 50 forskellige platforme fandt i gennemsnit 3.4 brugte ikoner (oftest: kurv, bruger, menu, notifikation). For at indlæse kun fire ikoner uden problemer indlæser vi således hele biblioteket.

 

billede-2 (1).png
Kilde: https://trends.builtwith.com/widgets/Font-Awesome

 

Hvordan håndterer avancerede JS rammer dette? Ved kun at importere SVG-formatet af de ikoner, der bruges i den relevante komponent, eliminerer behovet for at indlæse hele skrifttype- eller CSS-biblioteker.

Hvad fortæller Bootstrap vs. React JS-brug os?

Bootstrap JS-biblioteket har en markedsandel på 26 % på tværs af alle websteder verden over, mens React-brugen er omkring 4 %. Bootstrap er populær for sin fleksibilitet og brugervenlighed, hvilket muliggør hurtig udvikling. Denne fleksibilitet har dog en omkostning: Generelle JS-funktioner, omfattende kodedækning og funktioner til funktioner, du måske aldrig bruger, er inkluderet i dit projekt.

 

billede-3 (1).png
Kilde: https://w3techs.com/technologies/comparison/js-bootstrap,js-react

 

Så lad os spørge: Hvad betyder en mere end 100% stigning i brugen fra top 10,000 til top 1,000 websteder angiver? Det viser, at de bedste vender detaljer til deres fordel for at blive endnu bedre.

 

billede-4 (2).png
Kilde: https://w3techs.com/technologies/comparison/js-bootstrap,js-react

 

Sammenfattende, i stedet for at omskrive vores websteder med teknologier som Dernæst Nuxt, Angular, React, Vueosv., bør vi forstå, hvad disse teknologier gør rigtigt for hastighed og anvende disse bedste praksisser på vores webapplikationer.