I vår kontinuerlige jakt på sidehastighet, ser vi ofte at vi går tilbake til samme punkt. Til tross for innsatsen til produkt-, markedsførings- og vekstteam for å motivere teknologiteam, blir oppgaver som kan forbedre nettstedets ytelse ofte utsatt på grunn av behovet for omfaktorering, og selv når de er ferdige, gir de ikke alltid fullstendige resultater. I denne syklusen er det fordelaktig å vurdere noen innsiktsfulle perspektiver på å oppnå reell ytelse. Hvilken lærdom kan vi for eksempel lære av hastigheten til React.js og Vue.js eller deres SSR (server-side rendering) utvidelser som Next.js og Nuxt.js sammenlignet med andre plattformer? Er det ikke på tide å optimalisere MB-ene til jQuery- og CSS-filer? Når vil store selskaper som ofrer nettytelsen til dårlig informerte front-end-utviklere våkne? La oss ta disse spørsmålene en etter en.
Hvorfor er Next.js og Nuxt.js-baserte nettsteder raske?
Next- og Nuxt-plattformene, som er SEO-vennlige strukturer bygget på React og Vue, skiller seg ut for hastighetsytelse. Men hvorfor er disse plattformene så raske?
React.js og Vue.js er komponentbaserte rammeverk som bryter ned hver side i underkomponenter, som vist nedenfor.
La oss ta et eksempel fra den virkelige verden for å illustrere dette punktet: en e-handelsside. Denne oppføringssiden kan tenkes å ha følgende underkomponenter:
- Header
- Listing
- Oppføringsinformasjon
- Side tittel
- Brødsmule
- Produktantall
- Filtrer
- Kategorifilter
- Pris filter
- ...
- Sortering
- Produktkort
- Produktfoto
- Produktdetaljer
- Produktnavn
- Produktpris
- Gjennomstrekningspris
- Salgs pris
- Diskonteringsrente
- Kampanjeinformasjon
- Paginering
- Kategoriinnhold
- Oppføringsinformasjon
- Bunntekst
Når du oppretter en komponentbasert applikasjon med Nuxt.js, blir hver av disse komponentene kodet separat og inkludert i hovedsiden. Tenk for eksempel på en fil som heter ProductPhoto.js. Uansett hvilke funksjoner som trengs for produktbilder (karusell, responsiv bildevisning, etc.), er JS-koden skrevet i denne komponenten. På samme måte er bare CSS-filene som brukes av denne komponenten inkludert i den. Dette betyr at bare filene som kreves av hver komponent, kjøres hvis komponenten brukes.
Hvordan håndteres denne prosessen for tiden på de fleste nettplattformer?
En script.js-fil inneholder kode for alt fra medlemskap, filtre og handlekurvsider til menyen, som kjører på alle sider. Resultatet?
Nettsteder med en 3 MB JS-fil og en 1.5 MB CSS fil. Hovedproblemet er ikke bare filstørrelsene, men det faktum at du ikke kan forvente at en gjennomsnittlig Android-mobilenhets CPU skal kjøre tusenvis av linjer med kode i løpet av millisekunder. Ved å kjøre kun koden du trenger, kan du oppnå ytelsesgevinster.
Hvordan eliminere gjengivelsesblokkerende ressurser?
I dag bruker 32 % av de 1 million beste nettstedene Font Awesome-skriftbiblioteket, som i gjennomsnitt er på rundt 250 KB. Vurderer at asynkron lasting ikke er foretrukket på grunn av flick-effekten, tenk på hvor mange fonter som er synlige på den første skjermen på en side når den åpnes på mobil eller skrivebord. En kort studie på 50 forskjellige plattformer fant et gjennomsnitt på 3.4 ikoner som ble brukt (oftest: handlevogn, bruker, meny, varsling). For å laste bare fire ikoner uten problemer, laster vi derfor hele biblioteket.
Hvordan håndterer avanserte JS-rammeverk dette? Ved å bare importere SVG-formatet til ikonene som brukes i den relevante komponenten, eliminerer behovet for å laste hele font- eller CSS-biblioteker.
Hva forteller Bootstrap vs. React JS-bruk oss?
Bootstrap JS-biblioteket har en markedsandel på 26 % på tvers av alle nettsteder over hele verden, mens React-bruken er rundt 4 %. Bootstrap er populær for sin fleksibilitet og brukervennlighet, noe som muliggjør rask utvikling. Denne fleksibiliteten har imidlertid en kostnad: Generelle JS-funksjoner, omfattende kodedekning og funksjoner for funksjoner du kanskje aldri bruker er inkludert i prosjektet ditt.
Så la oss spørre: Hva betyr en mer enn 100% økning i bruken fra topp 10,000 1,000 til topp XNUMX nettsteder indikerer? Det viser at de beste snur detaljer til sin fordel for å bli enda bedre.
Oppsummert, i stedet for å omskrive nettstedene våre med teknologier som Neste, Nuxt, Angular, React, Vueosv., bør vi forstå hva disse teknologiene gjør riktig for hastighet og bruke disse beste fremgangsmåtene på nettapplikasjonene våre.
