In ons voortdurende streven naar paginasnelheid cirkelen we vaak terug naar hetzelfde punt. Ondanks de inspanningen van product-, marketing- en groeiteams om technische teams te motiveren, worden taken die de prestaties van de site zouden kunnen verbeteren vaak uitgesteld vanwege de noodzaak van refactoring, en zelfs als ze klaar zijn, leveren ze niet altijd volledige resultaten op. In deze cyclus is het nuttig om enkele inzichtelijke perspectieven te overwegen op het bereiken van echte prestaties. Welke lessen kunnen we bijvoorbeeld leren van de snelheid van React.js en Vue.js of hun SSR-extensies (server-side rendering) zoals Next.js en Nuxt.js in vergelijking met andere platforms? Is het niet tijd om de MB's van jQuery- en CSS-bestanden te optimaliseren? Wanneer zullen grote bedrijven die hun webprestaties opofferen aan slecht geïnformeerde front-end-ontwikkelaars wakker worden? Laten we deze vragen een voor een bespreken.

Waarom zijn op Next.js en Nuxt.js gebaseerde sites snel?

De Next- en Nuxt-platforms, SEO-vriendelijke structuren gebouwd op React en Vue, vallen op door snelheidsprestaties. Maar waarom zijn deze platforms zo snel?

React.js en Vue.js zijn op componenten gebaseerde raamwerken die elke pagina opsplitsen in subcomponenten, zoals hieronder weergegeven.

 

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

 

Laten we een voorbeeld uit de praktijk nemen om dit punt te illustreren: een vermeldingspagina voor e-commerce. U kunt zich voorstellen dat deze vermeldingspagina de volgende subcomponenten bevat:

  • Voorvoegsel
  • Listing
    • Toegangsinformatie vermelden
      • Pagina titel
      • Breadcrumb
      • Aantal producten
    • Filter
      • Categoriefilter
      • Prijs filter
      • ...
    • sorteer
    • Productkaarten
      • Productfoto
    • Productdetails
      • Productnaam
      • Product prijs
        • Doorstreepte prijs
        • Verkoopprijs
      • Kortingspercentage
      • Campagne-informatie
    • Opdelen
    • Categorie inhoud
  • footer

Wanneer u een op componenten gebaseerde applicatie maakt met Nuxt.js, wordt elk van deze componenten afzonderlijk gecodeerd en opgenomen in de hoofdpagina. Neem bijvoorbeeld een bestand met de naam ProductPhoto.js. Welke functies er ook nodig zijn voor productfoto's (carrousel, responsieve beeldweergave, etc.), de JS-code wordt binnen dit onderdeel geschreven. Op dezelfde manier zijn alleen de CSS-bestanden die door deze component worden gebruikt, erin opgenomen. Dit betekent dat alleen de bestanden die voor elk onderdeel nodig zijn, worden uitgevoerd als het onderdeel wordt gebruikt.

Hoe wordt dit proces momenteel afgehandeld op de meeste webplatforms?

Een script.js-bestand bevat code voor alles, van lidmaatschap, filters en winkelwagenpagina's tot het menu, dat op alle pagina's wordt uitgevoerd. Het resultaat? 

 

afbeelding-1 (2).png

 

Websites met een 3 MB JS-bestand en een 1.5 MB CSS bestand. Het grootste probleem is niet alleen de bestandsgrootte, maar ook het feit dat je niet kunt verwachten dat de CPU van een gemiddeld mobiel Android-apparaat binnen milliseconden duizenden regels code kan uitvoeren. Door alleen de code uit te voeren die u nodig heeft, kunt u prestatiewinst behalen.

Hoe kan ik render-blokkerende bronnen elimineren?

Tegenwoordig gebruikt 32% van de top 1 miljoen websites de lettertypebibliotheek Font Awesome, die gemiddeld ongeveer 250 KB groot is. Aangezien asynchroon laden niet de voorkeur heeft vanwege het veegeffect, bedenk dan hoeveel lettertypen zichtbaar zijn op het eerste scherm van een pagina wanneer deze wordt geopend op mobiel of desktop. Uit een kort onderzoek op 50 verschillende platforms bleek dat er gemiddeld 3.4 pictogrammen werden gebruikt (meestal: winkelwagen, gebruiker, menu, melding). Om dus zonder problemen slechts vier pictogrammen te laden, laden we de hele bibliotheek.

 

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

 

Hoe beheren geavanceerde JS-frameworks dit? Door alleen het SVG-formaat te importeren van de pictogrammen die in de relevante component worden gebruikt, waardoor het niet meer nodig is om volledige lettertype- of CSS-bibliotheken te laden.

Wat vertelt Bootstrap versus React JS-gebruik ons?

De Bootstrap JS-bibliotheek heeft een marktaandeel van 26% op alle sites wereldwijd, terwijl het React-gebruik ongeveer 4% bedraagt. Bootstrap is populair vanwege de flexibiliteit en het gebruiksgemak, waardoor snelle ontwikkeling mogelijk is. Deze flexibiliteit brengt echter kosten met zich mee: algemene JS-functies, uitgebreide codedekking en functies voor functies die u misschien nooit zult gebruiken, zijn in uw project opgenomen.

 

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

 

Laten we ons dus afvragen: wat betekent een toename van meer dan 100% in het gebruik van de top 10,000 tot de top 1,000 sites aangeven? Het laat zien dat de besten details in hun voordeel gebruiken om nog beter te zijn.

 

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

 

Samenvattend: in plaats van onze sites te herschrijven met technologieën zoals Vervolgens Nuxt, Angular, React, Vue, enz., moeten we begrijpen wat deze technologieën goed doen op het gebied van snelheid en deze best practices toepassen op onze webapplicaties.