Elimineer render-blokkerende bronnen, verminder ongebruikte JavaScript en minimaliseer main thread werk worden meestal bovenaan het PageSpeed Insights-rapport gevonden. Ze praten over potentiële besparingen, maar behalve het gebruik van de defer-tag, is er niet veel informatie over hoe dit te doen.
Hoewel er een paar extra manieren zijn 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 het 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 dit onderbreken. Dus hoewel de HTML sneller laadt dan zonder async te gebruiken, 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 in 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 ze een veiligere keuze zijn voor scripts die de DOM moeten manipuleren.
Welk type scripts manipuleren 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 vergeleken met 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.
Verminder ongebruikte JavaScript
Tijd voor wat voorjaarsschoonmaak. Schud de boom en ontdoe je van dode code, hier bedoeld als ongebruikte JavaScript. Dit komt niet alleen de snelheid ten goede, maar ook de veiligheid. We hebben tot nu toe meerdere artikelen geschreven over de problemen die kunnen komen met JavaScript van derden. Ons hele bedrijf werd opgericht om te helpen beschermen tegen de kwetsbaarheden die ermee gepaard gaan. En vaak blijven websites scripts draaien die niet langer worden gebruikt met grote risico's die daarmee gepaard gaan.
Dit was onlangs 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 leden mogelijk aanvallen.
Andere manieren zijn in de vorm van tools die ooit werden gebruikt maar niet meer, of frameworks die komen met een overvloed aan JavaScript-bibliotheken 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 erg trots dat we een oplossing hebben gebouwd die niet alleen monitort en waarschuwt, maar zelfs in staat is om kwaadaardige scripts autonoom te blokkeren voordat aanvallen doorkomen.
Als je een monitoringtool zoals cside gebruikt, kun je gemakkelijk zien welke code waar wordt geladen, evenals wat die code daadwerkelijk doet. Met deze informatie is het veel gemakkelijker 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 laadt alle andere scripts op je site in een proxy om het te analyseren voordat het in de browser wordt geladen. Dit is verreweg de veiligste oplossing. Niets kwaadaardigs kan de browser van je gebruikers aanraken, 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 anderen 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 de hele tijd controleren, komen we duizenden keren per dag dezelfde scripts tegen. We slaan elke versie van een script op en cachen het indien mogelijk. Dit zorgt ervoor dat we de gecachte versies kunnen laden, wat sneller is dan zelfs het laden van de originele versies vanaf nieuw.
We herschrijven speciaal caching-headers zodat we een script blokkeren en het nog steeds geblokkeerd hebben voor klanten die het mogelijk al in hun cache hebben, terwijl we de caching-prestaties behouden.
Bovendien hebben we onze infrastructuur ontwikkeld om ongelooflijk snel te werken. Vergeleken met andere leveranciers die ongenoemd zullen blijven, serveert onze proxy een 20,3 kb script sneller dan zij een 1,2 kb script kunnen serveren. Die van ons duurde 10ms terwijl die van hen 13ms duurde in onze tests, een snelheidswinst van 22x, ervan uitgaande dat alle andere factoren constant blijven.
Ten slotte wordt JavaScript vaak geminificeerd en geobfusceerd. Minificeren is een veelgebruikte manier om kleine snelheidswinsten te behalen. Het laatste kan negatieve effecten hebben op de prestaties. Weet gewoon dat je in cside de gedeobfusceerde versies van de scripts kunt zien 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. Het 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 bij, 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 bovenop.
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 ze door de browser nodig zijn. Deze bronnen zijn dan beschikbaar zodra ze nodig zijn, waardoor laadtijden worden verkort. De browser zal deze bronnen prioriteren en ze downloaden tijdens het initiële laden van de pagina.
Bijvoorbeeld, het vooraf laden van een JavaScript-bestand zorgt ervoor dat het beschikbaar is wanneer de browser het punt in de HTML bereikt waar het normaal gesproken dat script zou laden. Dit voorkomt vertragingen 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 dan weer, 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 dan 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 tijden 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. Het snel en efficiënt houden ervan is nodig voor een over het algemeen goede gebruikerservaring.
PageSpeed Insights geeft enkele tips hierover.
Rendering kan worden geoptimaliseerd door vast te houden aan 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 om de pagina efficiënter te renderen, waardoor laadtijden worden versneld.
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. Dit kan worden bereikt door de scope en complexiteit van stijlberekeningen te 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, het asynchroon laden van niet-essentiële stijlen om te voorkomen dat ze main thread-operaties blokkeren tijdens het kritieke renderpad.
Terug naar JavaScript.
Voor scriptevaluatie is het debouncing van input handlers nuttig. Het helpt de frequentie van event handlers die worden aangeroepen te verminderen, waardoor de belasting op de main thread wordt verminderd. 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 meer kritieke taken.
Prestaties koppelen aan veiligheid
Al deze oplossingen zullen je helpen om JavaScript te versnellen om betere prestaties te bereiken. cside kan helpen door scripts ook te cachen en te optimaliseren.
Maar we willen benadrukken dat we in de eerste plaats allemaal over veiligheid gaan. Het feit dat we scripts versnellen was vooral nodig voor adoptie door onze gebruikers. Browser supply chain-aanvallen nemen toe. En slechte actoren richten zich vaak op JavaScript van derden. cside analyseert elk script voordat ze in de browser laden en blokkeert alles wat kwaadaardig is.
Een proactieve aanpak die zowel jou als je gebruikers redt voordat er iets ergs gebeurt.
Je kunt gratis aan de slag met cside.
