Lektioner från React och Vue Frameworks för Page Speed

I vår kontinuerliga strävan efter sidhastighet befinner vi oss ofta på att cirkla tillbaka till samma punkt. Trots ansträngningar från produkt-, marknadsförings- och tillväxtteam för att motivera tekniska team, skjuts uppgifter som kan förbättra webbplatsens prestanda ofta upp på grund av behovet av omstrukturering, och även när de är klara ger de inte alltid fullständiga resultat. I den här cykeln är det fördelaktigt att överväga några insiktsfulla perspektiv på att uppnå verklig prestation. Vilka lärdomar kan vi till exempel dra av hastigheten hos React.js och Vue.js eller deras SSR-tillägg (server-side rendering) som Next.js och Nuxt.js jämfört med andra plattformar? Är det inte dags att optimera MB för jQuery- och CSS-filer? När kommer stora företag som offrar sin webbprestanda till dåligt informerade front-end-utvecklare att vakna? Låt oss ta upp dessa frågor en efter en.

Varför är Next.js- och Nuxt.js-baserade webbplatser snabba?

Next och Nuxt-plattformarna, som är SEO-vänliga strukturer byggda på React och Vue, sticker ut för hastighetsprestanda. Men varför är dessa plattformar så snabba?

React.js och Vue.js är komponentbaserade ramverk som delar upp varje sida i underkomponenter, som visas nedan.

Låt oss ta ett exempel från verkligheten för att illustrera denna punkt: en e-handelssida. Den här listsidan kan tänkas ha följande underkomponenter:

• Sidhuvud
• notering
  • Lista inträdesinformation
    • Sidans titel
    • Synlig
    • Antal produkter
  • Filter
    • kategori filter
    • Prisfilter
    • ...
  • sortering
  • Produktkort
    • Produktfoto
  • Produktinformation
    • Produktnamn
    • Produktpris
      • Genomslagspris
      • Försäljningspris
    • Rabatt
    • Kampanjinformation
  • Paginering
  • Kategoriinnehåll
• Sidfot

När du skapar en komponentbaserad applikation med Nuxt.js kodas var och en av dessa komponenter separat och inkluderas på huvudsidan. Tänk till exempel på en fil med namnet ProductPhoto.js. Oavsett vilka funktioner som behövs för produktfoton (karusell, responsiv bildvisning etc.), skrivs JS-koden i denna komponent. På samma sätt ingår bara de CSS-filer som används av den här komponenten. Detta innebär att endast de filer som krävs av varje komponent exekveras om komponenten används.

Hur hanteras denna process för närvarande på de flesta webbplattformar?

En script.js-fil innehåller kod för allt från medlemskap, filter och kundvagnssidor till menyn som körs på alla sidor. Resultatet? 

Webbplatser med en 3 MB JS-fil och en 1.5 MB CSS fil. Det största problemet är inte bara filstorlekarna utan det faktum att du inte kan förvänta dig att en genomsnittlig Android-mobilenhets CPU ska köra tusentals rader kod inom millisekunder. Genom att bara köra den kod du behöver kan du uppnå prestandavinster.

Hur eliminerar man renderingsblockerande resurser?

Idag använder 32 % av de 1 miljon bästa webbplatserna Font Awesome-teckensnittsbiblioteket, som i genomsnitt är cirka 250 kB. Med tanke på att asynkron laddning inte är att föredra på grund av snärteffekten, tänk på hur många teckensnitt som är synliga på den första skärmen på en sida när den öppnas på mobil eller dator. En kort studie på 50 olika plattformar fann i genomsnitt 3.4 ikoner som användes (vanligast: kundvagn, användare, meny, avisering). För att bara ladda fyra ikoner utan problem laddar vi alltså hela biblioteket.

Hur hanterar avancerade JS-ramverk detta? Genom att endast importera SVG-formatet för ikonerna som används i den relevanta komponenten, eliminerar behovet av att ladda hela teckensnitt eller CSS-bibliotek.

Vad berättar Bootstrap vs. React JS-användning för oss?

Bootstrap JS-biblioteket har en marknadsandel på 26 % på alla webbplatser världen över, medan React-användningen är cirka 4 %. Bootstrap är populärt för sin flexibilitet och användarvänlighet, vilket möjliggör snabb utveckling. Denna flexibilitet kommer dock till en kostnad: allmänna JS-funktioner, omfattande kodtäckning och funktioner för funktioner som du kanske aldrig använder ingår i ditt projekt.

Så låt oss fråga: Vad innebär en mer än 100% ökning av användningen från topp 10,000 1,000 till topp XNUMX XNUMX webbplatser indikerar? Det visar att de bästa vänder detaljer till sin fördel för att bli ännu bättre.

Sammanfattningsvis, Istället för att skriva om våra webbplatser med teknik som Därefter Nuxt, Angular, React, Vue, etc., bör vi förstå vad dessa tekniker gör rätt för hastighet och tillämpa dessa bästa praxis på våra webbapplikationer.