Kort samengevat: hoe JavaScript op je website versnellen
- Uitstellen is niet genoeg: Elke JavaScript-performancegids zegt dat je niet-essentiële scripts moet uitstellen, maar diezelfde tags die je hebt uitgesteld blijven ongebruikte DOM-toegang, verlopen leveranciersafhankelijkheden en Polyfill-achtig verlopen-domein-risico verschepen over 490.000 sites die ze nooit hebben verwijderd.
- Zie wat waar draait: De first-party JavaScript-agent van cside volgt het runtimegedrag van elk third-party script in de browser, zodat je ziet welke code waar draait, serveert statische scripts vaak sneller via cache, zonder sampling en met autonome blokkering erbovenop.
- Eén eigenaar, één dashboard: Voor de volgende Core Web Vitals-review: beslis of performance en beveiliging van third-party scripts één eigenaar en één dashboard krijgen, of gesplitst blijven tussen engineering en marketing tot een verlopen CDN beide onderuithaalt.
Weinig tijd? Bekijk cside's in-browser Magecart- en skimmerblokkering. Dit dekt alles hieronder in één deployment.
Elimineer render-blokkerende bronnen, verminder ongebruikte JavaScript en minimaliseer main thread werk staan meestal bovenaan het PageSpeed Insights-rapport. Ze hebben het over potentiële besparingen, maar behalve het gebruik van de defer-tag is er niet veel informatie over hoe je dit doet.
Toch zijn er een paar extra manieren om je pagina's sneller te laten laden door JavaScript aan te pakken.
Laten we eerst deferring behandelen, en je daarna wat extra opties geven.
Defer of async?
Kort gezegd - het uitstellen van het laden van scripts zorgt ervoor dat je site sneller lijkt te laden dan bij gebruik van 'async'. Afhankelijk van je gebruik kan dit echter wel of niet de beste manier zijn.
Het 'defer'-attribuut stelt de browser in staat om door te gaan met het parsen van HTML terwijl het script op de achtergrond wordt gedownload. Maar het wacht met de uitvoering van het script tot nadat het HTML-parsen is voltooid. Dit is waarom de content 'paint' op je site sneller laadt. De webpagina is sneller volledig geladen voor je bezoeker om te zien, dan zonder of met het 'async'-attribuut.
Het 'async'-attribuut stelt de browser in staat om door te gaan met het parsen van de HTML-content terwijl het script op de achtergrond wordt gedownload. Maar zodra het script is gedownload, wordt het onmiddellijk uitgevoerd. Mocht het HTML-parsen niet klaar zijn, dan zou dit worden onderbroken. Dus hoewel de HTML sneller laadt dan zonder async, kan de potentiële onderbreking van het laden van de HTML ervoor zorgen dat je site langzamer lijkt te laden.
Wanneer gebruik je defer of async?
'Async'-scripts worden uitgevoerd zodra ze zijn gedownload, wat niet noodzakelijkerwijs de volgorde is waarin ze in het document verschijnen. Het 'defer'-attribuut behoudt de volgorde en zorgt ervoor dat scripts worden uitgevoerd nadat het document is geparsed.
'Async' is bijzonder nuttig voor scripts die NIET afhankelijk zijn van Document Object Model (DOM)-elementen of andere scripts. Een uitgesteld script wacht tot de DOM klaar is, waardoor het een veiligere keuze is voor scripts die de DOM moeten manipuleren.
Welk type scripts manipuleert de DOM?
Bibliotheken zoals jQuery of aangepaste scripts in het algemeen. Deze manipuleren de DOM en moeten worden geladen met het 'defer'-attribuut om ervoor te zorgen dat de DOM volledig is geladen voordat ze worden uitgevoerd. En als je scripts hebt die afhankelijk zijn van andere scripts die eerst moeten worden geladen, zorgt het gebruik van 'defer' ervoor dat ze worden uitgevoerd in de volgorde waarin ze in het document verschijnen.
Analytics, advertenties en minder vitale scripts hoeven over het algemeen niet zo snel mogelijk te worden geladen. Het is een keuze die je zelf moet maken, maar de meeste mensen geven de voorkeur aan een sneller ladende site boven een paar milliseconden sneller werkende scripts.
Een goede vuistregel is om defer te gebruiken voor niet-essentiële JavaScript. Als het script niet afhankelijk is van de DOM of van andere scripts, dan is het gebruik van async of geen attribuut prima.
Ongebruikte JavaScript verminderen
Tijd voor wat voorjaarsschoonmaak. Schud de boom en ontdoe je van dode code, hier bedoeld als ongebruikte JavaScript. Dit komt zowel de snelheid als de veiligheid ten goede. We hebben tot nu toe meerdere artikelen geschreven over de problemen die kunnen ontstaan door JavaScript van derden. Ons hele bedrijf is opgericht om te helpen beschermen tegen de kwetsbaarheden die daarmee gepaard gaan. En vaak blijven websites scripts draaien die niet meer worden gebruikt, met grote risico's als gevolg.
Dit was recent het geval bij de Polyfill web supply chain-aanval, waarbij een oud domein werd gekocht door een nieuwe partij en vervolgens voor kwaadaardige doeleinden werd gebruikt. Meer dan 490.000 websites hadden naar dit domein verwezen en liepen mogelijk schade op.
Andere manieren zijn tools die ooit werden gebruikt maar niet meer, of frameworks die een overvloed aan JavaScript-bibliotheken meebrengen die niet in gebruik zijn op een bepaalde site. Lees meer over de risico's van hoe verlopen domeinen kunnen leiden tot cybersecurity-problemen hier.
Hoe meer JavaScript je op je site hebt, hoe groter het risico dat je loopt.
Het was vroeger praktisch onmogelijk om wijzigingen in scripts van derden te detecteren. Gelukkig is dit niet langer het geval. We zijn er trots op dat we een oplossing hebben gebouwd die monitort en waarschuwt, en zelfs kwaadaardige scripts autonoom kan blokkeren voordat aanvallen doorkomen.
Als je een monitoringtool zoals cside gebruikt, kun je gemakkelijk zien welke code waar wordt geladen, en wat die code daadwerkelijk doet. Met deze informatie is het veel eenvoudiger om deze voorjaarsschoonmaak uit te voeren en ongewenste scripts te verwijderen.
Maar cside gaat zelfs een stap verder, wat ons bij het volgende punt brengt.
JavaScript optimaliseren om sneller te laden
cside haalt alle andere scripts op je site aan onze kant op om ze te analyseren voordat ze in de browser worden geladen. Dit is verreweg de veiligste oplossing. Niets kwaadaardigs kan de browser van je gebruikers raken, wat hen en jezelf volledig beveiligt.
Maar dit brengt een paar uitdagingen met zich mee. Omdat de JavaScript wordt gecontroleerd voordat deze laadt, voegt dit natuurlijk latentie toe. Simpelweg uitstellen is niet altijd mogelijk, omdat we alle scripts in de proxy laden, ook de noodzakelijke die de Document Object Model (DOM)-elementen beïnvloeden, zoals eerder uitgelegd.
Voor sommige toepassingen zou dit nog steeds prima zijn. Voor andere zou dit een dealbreaker zijn.
Voor ons was dit ook een dealbreaker. Ja, veiligheid eerst. Maar als de nadelen te groot worden, zullen bedrijven aarzelen om de beste standaarden te adopteren. En we moeten ervoor zorgen dat er zo min mogelijk nadelen zijn.
Daarom hebben we cside zo ontwikkeld dat het scripts daadwerkelijk optimaliseert om sneller te laden dan normaal, waardoor de latentie volledig wordt gemitigeerd. Vaak maken we deze scripts, en dus websites, zelfs sneller in plaats van langzamer.
Omdat we elke sessie voortdurend controleren, komen we duizenden keren per dag dezelfde scripts tegen. We slaan elke versie van een script op en cachen deze indien mogelijk. Dit zorgt ervoor dat we de gecachte versies kunnen laden, wat sneller is dan zelfs het opnieuw laden van de originele versies.
We herschrijven speciaal caching-headers zodat een geblokkeerd script ook geblokkeerd blijft voor klanten die het mogelijk al in hun cache hebben, terwijl de caching-prestaties behouden blijven.
We hebben onze infrastructuur ook zo ontwikkeld dat deze ongelooflijk snel werkt. Vergeleken met andere leveranciers die ongenoemd blijven, serveert cside een script van 20,3 kb sneller dan zij een script van 1,2 kb kunnen serveren. Bij ons duurde dit 10ms terwijl het bij hen 13ms duurde in onze tests, een snelheidswinst van 22x, ervan uitgaande dat alle andere factoren gelijk blijven.
Ten slotte wordt JavaScript vaak geminificeerd en geobfusceerd. Minificeren is een gangbare manier om wat kleine snelheidswinst te behalen. Dat laatste kan negatieve effecten hebben op de prestaties. Weet gewoon dat je in cside de gedeobfusceerde versies van de scripts kunt bekijken om beter te begrijpen wat de code doet.
Compressie
Een andere manier om JavaScript te optimaliseren, is het gebruik van GZip, Brotli of een andere compressie. Dit zijn algoritmen die de grootte van bestanden die van de server naar de browser worden verzonden, verkleinen. Het werkt door redundante gegevens binnen een bestand te identificeren en te elimineren.
Er zijn een paar kanttekeningen, maar het is meestal beter om het te gebruiken dan niet. Het kost tijd om bestanden te zippen en te unzippen, maar meestal minder dan de tijd die wordt bespaard door een groter bestand te downloaden. Daarom kom je nog steeds als winnaar uit de bus.
Dit werkt vooral goed op tekstbestanden, zoals HTML, CSS en ook JavaScript.
Preloading en prefetching
Preloading stelt je in staat om kritieke bronnen (zoals JavaScript) op te halen voordat de browser ze nodig heeft. Deze bronnen zijn dan beschikbaar zodra ze nodig zijn, waardoor laadtijden worden verkort. De browser geeft deze bronnen prioriteit en downloadt ze tijdens het initiële laden van de pagina.
Het vooraf laden van een JavaScript-bestand zorgt er bijvoorbeeld voor dat het beschikbaar is wanneer de browser het punt in de HTML bereikt waar het normaal gesproken dat script zou laden. Dit voorkomt vertragingen die worden veroorzaakt doordat de browser het bestand op dat moment moet ophalen.
Dit klinkt misschien hetzelfde als de 'defer'- of 'async'-attributen, maar er zijn enkele belangrijke verschillen.
Preloading zorgt ervoor dat kritieke bronnen zoals CSS, lettertypen en belangrijke JavaScript-bestanden vroeg worden opgehaald en door de browser worden geprioriteerd voor onmiddellijke beschikbaarheid.
Onthoud dat het 'defer'-attribuut wordt gebruikt om de uitvoering van JavaScript uit te stellen totdat het HTML-document volledig is geparsed. En het 'async'-attribuut stelt scripts in staat om te worden opgehaald en uitgevoerd zodra ze beschikbaar zijn, zonder te wachten tot het HTML-parsen is voltooid.
Een ander voorbeeld van preloading is het gebruik van een aangepast lettertype op je site. Als dit lettertype niet snel wordt geladen, zien gebruikers mogelijk eerst een standaardlettertype, wat leidt tot een flits van ongestylede tekst. Door het lettertype vooraf te laden, zorg je ervoor dat dit niet gebeurt.
Prefetching richt zich vervolgens op het ophalen van bronnen tijdens de inactieve tijd van de browser voor toekomstige behoeften, zoals bronnen voor de volgende pagina waar de gebruiker waarschijnlijk naartoe zal navigeren. Laden tijdens die inactieve periodes vermindert wachttijden aanzienlijk.
Minimaliseer main-thread werk
De main-thread is waar de browser het meeste werk doet dat nodig is om een pagina weer te geven, zoals het parsen en uitvoeren van HTML, CSS en JavaScript. Deze snel en efficiënt houden is nodig voor een over het algemeen goede gebruikerservaring.
PageSpeed Insights geeft enkele tips hierover.
Rendering kan worden geoptimaliseerd door je te beperken tot compositor-only eigenschappen. Dit zijn CSS-eigenschappen die volledig door de compositor van de browser kunnen worden afgehandeld, waarbij de main thread en de noodzaak voor layout- of paint-operaties worden omzeild. Het vereenvoudigen van paint complexity door de gebieden die moeten worden geschilderd te verminderen, kan de browser verder helpen de pagina efficiënter te renderen, waardoor laadtijden versnellen.
Als het gaat om stijl en layout, kan het vereenvoudigen van je CSS en het vermijden van complexe selectors de tijd die wordt besteed aan stijlberekeningen aanzienlijk verminderen. Het zal waarschijnlijk een balans zijn tussen ontwerp en prestaties.
Het vermijden van layout thrashing is essentieel. Layout thrashing treedt op wanneer we opeenvolgende lees- en schrijfbewerkingen naar de DOM uitvoeren, waardoor de browser wordt verhinderd de layout te optimaliseren. Dit dwingt de browser om een layout te berekenen die nooit op het scherm wordt weergegeven.
Overweeg het uitstellen van niet-kritieke CSS, door niet-essentiële stijlen asynchroon te laden, om te voorkomen dat ze main thread-operaties blokkeren tijdens het kritieke renderpad.
Terug naar JavaScript.
Voor scriptevaluatie is het debouncen van input handlers nuttig. Het helpt de frequentie waarmee event handlers worden aangeroepen te verminderen, waardoor de belasting op de main thread afneemt. Merk op dat web workers een beperkte omgeving hebben. Ze kunnen de DOM niet direct manipuleren of bepaalde API's gebruiken die beschikbaar zijn voor de main thread.
Ten slotte kan garbage collection worden geoptimaliseerd door het geheugengebruik te monitoren. Het gebruik van tools zoals 'measureMemory()' helpt bij het volgen en beheren van geheugengebruik, waardoor de tijd die wordt besteed aan garbage collection wordt verminderd. Efficiënt geheugenbeheer helpt de main thread vrij te houden voor kritiekere taken.
Prestaties koppelen aan veiligheid
Al deze oplossingen helpen je JavaScript te versnellen en zo betere prestaties te bereiken. cside kan ook helpen door scripts te cachen en te optimaliseren.
Maar we willen benadrukken dat het bij ons in de eerste plaats om veiligheid draait. Het feit dat we scripts versnellen, was vooral nodig voor adoptie door onze gebruikers. Browser supply chain-aanvallen nemen toe. En kwaadwillenden richten zich vaak op JavaScript van derden. cside analyseert elk script voordat het in de browser laadt en blokkeert alles wat kwaadaardig is.
Een proactieve aanpak die zowel jou als je gebruikers behoedt voordat er iets ergs gebeurt.
Je kunt gratis aan de slag met cside.
