Als het gaat om de snelheid van jouw website, is het belangrijk om snelheid te beschouwen als een noodzakelijke functie, geen optionele functie, en het ook zo te behandelen. Er zijn veel factoren betrokken bij de bepaling hoe snel bezoekers de inhoud van jouw website te zien krijgen. Sommige van deze dingen factoren heb je niet onder controle: de snelheid van hun internetverbinding, hun geografische locatie, netwerk verstopping, enzovoort. Er zijn echter nog andere dingen die je wel kunt en moet beheersen.

Eén tool die je kunt gebruiken om snelheid-verminderende problemen te identificeren die onder jouw controle kunnen vallen, is Google PageSpeed Insights. Waarschijnlijk heb je PageSpeed Insights eerder gebruikt (als je dat nog niet hebt gedaan, is dit de cue om daar eerst naar toe te gaan voordat je de rest van dit artikel leest). Het is gratis en wijst op problemen die de levering van jouw websites vertragen, zoals bijvoorbeeld JavaScript en CSS die het renderen van de pagina blokkeren.

Veel voorkomend probleem: Render-blocking JavaScript en CSS

Er zijn tien snelheidsregels die worden gebruikt om sites te analyseren die worden gecontroleerd door PageSpeed Insights. Twee van deze regels hebben te maken met JavaScript en CSS-bronnen die inhoud boven de fold blokkeren. Voldoe je niet aan 1 van deze twee regels — en veel sites voldoen niet aan 1 of aan beide regels — dan zie je een “Should Fix” melding die je laat weten dat je: Render-blocking JavaScript en CSS boven de fold zou moeten elimineren.

Elimineer render-blocking Javascript en CSS voor content boven de fold

Elimineer render-blocking Javascript en CSS voor content boven de fold

Wat betekend dit eigenlijk? Hier is een uitgebreide uitleg.

Wanneer een browser een webpagina laadt, voorkomen JavaScript- en CSS-bronnen meestal dat de webpagina wordt weergegeven totdat deze zijn gedownload en verwerkt door de browser. In sommige gevallen is dit een goede zaak. Render bijvoorbeeld pure HTML voordat CSS wordt gedownload en je krijgt een flash van niet-gestylde content (FOUC), wat waarschijnlijk een slechtere ervaring voor je gebruikers is dan een paar honderdsten van een seconde langer wachten op het verschijnen van content.

Sommige bronnen moeten worden gedownload en verwerkt voordat je iets wilt weergeven. Veel CSS en JavaScript zijn echter voorwaardelijk, dat wil zeggen, ze worden alleen in specifieke gevallen toegepast of zijn gewoon niet nodig om inhoud boven de fold weer te geven. Als je de snelst mogelijke ervaring voor jouw gebruikers wilt produceren, moet je proberen bronnen die het renderen blokkeren te verwijderen wanneer deze niet vereist zijn voor weergave van inhoud boven de fold.

Ik wil over één punt duidelijk zijn: Soms kan het te veel moeite kosten of simpelweg onmogelijk zijn om alle resources voor het blokkeren van de render te verwijderen. Hierdoor kan zelfs de gevreesde FOUC (up) ontstaan die ik zojuist benoemde. Onthoud dat het niet ons doel is om een perfecte PageSpeed-score te behalen. Ons doel is om de best mogelijke gebruikerservaring te leveren, en dat betekent een website die zo snel mogelijk laadt zonder te knipperen met niet-gestylde inhoud.

In other words, use PageSpeed Insights to identify render-blocking files that you can try to eliminate, but let UX be your overruling guideline. You might also see this message appear in other speed test tools. For example, in GTmetrix it shows up as “Defer Parsing of JavaScript.”

Met andere woorden, gebruik PageSpeed Insights om bestanden voor het blokkeren van rendering te identificeren die je kunt proberen te elimineren, maar laat UX de leidraad zijn. Je kunt dit bericht ook zien in andere snelheid testhulpmiddelen. In GTmetrix wordt dit bijvoorbeeld weergegeven als “Defer parsing of JavaScript”.

Hoe elimineer je Render-blocking JavaScript en CSS

Er is een plugin voor dat, toch? Ja, zeker wel, maar je moet begrijpen wat er gebeurt voordat je begint met het gebruiken van plugins. Veel plugins zijn zeer instelbaar en weten hoe je render-blocking resources kan elimineren zal je helpen efficiënter om te gaan met de plugin naar keuze.

Verwijder JS van het Kritieke Render Pad

Laten we het eerst eens hebben over JavaScript. Het basisidee is om onnodige JavaScript-en jQuery-bronnen uit het kritieke render pad te verwijderen. Dit wordt meestal gedaan door het attribuut defer of async toe te voegen aan de HTML-elementen van het script die JavaScript resources aanroepen.

Het defer en async attribuut zijn niet gelijk aan elkaar en het verschil kan belangrijk zijn om te begrijpen.

  • Het async attribuut vertelt de browser om de resource onmiddellijk te downloaden zonder het HTML parsen te vertragen. Zodra de bron beschikbaar is, wordt het verwerken van de HTML gepauzeerd, zodat de bron kan worden geladen.
  • Het defer attribuut laat de browser weten dat het moet wachten met het downloaden van de bron totdat het HTML parsen voltooid is. Zodra de browser klaar is met de HTML code, worden deze gedownload en worden alle uitgestelde scripts weergegeven in de volgorde waarin ze in het document voorkomen.

Het grote verschil tussen beide attributen is dat defer ervoor zorgt dat scripts worden gedownload en op de webpagina worden toegepast in de volgorde waarin ze in het HTML-document voorkomen, terwijl async dat niet doet. Het resultaat is dat als async wordt gebruikt op alle JavaScript bronnen, het soms bronnen kan breken die afhankelijk zijn van bronnen die eerder in het document voorkomen. Het meest voorkomende probleem dat async produceert, is een aantal gebroken jQuery bronnen die worden geladen voordat jquery.js aan het document is toegevoegd.

Optimaliseer de levering van CSS Bronnen

Render-blocking CSS is ook lastig, zo niet onmogelijk om in z’n geheel te elimineren. De ideale samenstelling is om:

  • De styling die vereist is voor content boven de fold te identificeren en deze als inline-style te serveren in je HTML bestand.
  • Gebruik het media attribuut op de link elementen die CSS bestanden binnenhalen om CSS bronnen die voorwaardelijk zijn te identificeren, dat wil zeggen wanneer ze alleen nodig zijn voor specifieke apparaten of situaties.
  • Resterende CSS bronnen moeten asynchroon worden geladen, een actie die doorgaans wordt uitgevoerd door ze toe te voegen via deffered of asynchrone JavaScript. Om eerlijk te zijn, dit gaat best wel een stuk boven onze pet, nietwaar? Dit is absoluut front-end engineer territorium. Wat geweldig nieuws is als je een front-end engineer bent, maar de meesten van ons zijn dat niet. Het goede nieuws is dat dit een artikel is over WordPress, en je kunt het aantal JS- en CSS-bronnen die van invloed zijn op je site met de juiste plugin(s) elimineren of tenminste aanzienlijk verminderen.

Plugins om Render-Blocking JavaScript en CSS te Reduceren

Ter voorbereiding op dit artikel heb ik me een weg gebaand door een dozijn populaire WordPress plugins die zijn ontworpen om render-blocking JavaScript en CSS resources te verwijderen. Hiervan heb ik er vijf over gehouden die een meetbare reductie opleverden.

Ik moet ook vermelden dat ik tijdens dit proces geen cache plugins heb gebruikt. Mijn testsite is opgezet op een Kinsta pakket met ingebouwde caching op serverniveau. Als je geen klant bij Kinsta bent, zal het opzetten van een goede caching plugin de prestaties van jouw site verder verbeteren.

Voordat we echter aan de plugins kunnen beginnen, hebben we een benchmark score nodig. Wat ik heb gedaan, is het opzetten van een eenvoudige testsite bij Kinsta en een populair, gratis, jQuery-liefhebbend thema van WordPress.org: Sydney geïnstalleerd. Zonder iets anders te doen, hier is we waar we staan.

PageSpeed Insights zonder plugins

PageSpeed Insights zonder plugins

Niet slecht, maar er is zeker ruimte voor verbetering. Er zijn 2 JavaScript en 5 CSS bronnen die het renderen blokkeren.

Een andere test die we zullen gebruiken als een benchmark is de Pingdom Speed Test. In het bijzonder willen we kijken naar het aantal verzoeken om de webpagina te laden en zien hoe dat aantal verandert met verschillende plugins geactiveerd. Elke extra aanvraag betekent een nieuwe reactie van de server, dus veel plugins combineren CSS- en JavaScript-bronnen in minder bestanden om de website prestaties te versnellen.

Aangezien mijn website wordt gehost door Kinsta is de website al bliksemsnel en vereist 24 verzoeken om de homepagina te laden.

Snelheidstest zonder plugins

Snelheidstest zonder plugins

Laten we kijken hoe we de prestaties kunnen verbeteren door het uitproberen van een aantal plugins.

Speed Booster Pack

Als eerste hebben we Speed Booster Pack. Deze plugin is actief op meer dan 40,000 WordPress websites en heeft een 3.6 van de 5 sterren beoordeling op WordPress.org.

speed booster pack plugin

Speed Booster pack plugin

De instellingen van de plugin vind je onder Instellingen > Speed Booster Pack. Het menu is redelijk eenvoudig en biedt tegelijkertijd een flink aantal configuratie opties.

Het algemene opties kunnen scripts naar de footer verplaatsen en parsen van javascript-bestanden uitstellen. In combinatie zouden deze twee opties JavaScript volledig moeten uitsluiten van het render-blocking. Een ander menu met de titel Nog meer snelheid nodig? staat het laden van CSS asynchroon toe. Hoewel dit alle CSS voor render-blocking had moeten elimineren, zorgde deze optie voor de gevreesde FOUC, dus liet ik deze optie niet ingeschakeld.

Met de plugin geconfigureerd, zijn dit de resultaten van PageSpeed Insights.

PageSpeed Insights met de Speed Booster plugin

PageSpeed Insights met de Speed Booster plugin

Zoals verwacht, zijn er geen JavaScript-bronnen die voor render-blocking zorgen. Aangezien asynchroon CSS laden een FOUC produceerde en uitgeschakeld moesten blijven, blokkeren alle vijf CSS-bronnen nog steeds inhoud boven de fold.

Snelheidstest met de Speed Booster plugin.

Snelheidstest met de Speed Booster plugin.

Vreemd genoeg is het aantal verzoeken zelfs toegenomen. Hoewel er niets was om te suggereren dat het aantal had moeten afnemen, is het vergroten van het aantal verzoeken een verrassing. Het algehele prestatieniveau verbeterde wel een beetje, dus ik noem Speed Booster Pack geen mislukking. Er zijn echter effectievere opties beschikbaar.

JCH Optimize

Laten we vervolgens eens kijken naar JCH Optimize. Hoewel de plugin minder actieve installaties heeft dan Speed Booster Pack, heeft hij over een indrukwekkende score van 4,6 uit 5 sterren.

JCH Optimize plugin

JCH Optimize plugin

Deze plugin combineert en verkleint JavaScript en CSS bestanden en is, samen met vele andere functies, ontworpen om het laden van pagina’s te versnellen. Hoewel het elimineren van bronnen voor render-blocking nergens specifiek wordt vermeld, zou de combinatie van JavaScript- en CSS-bestanden betekenen dat er minder bronnen zijn om op de pagina te laden en dus minder JS- en CSS-bronnen in een render-blocking positie.

De plugin voegt een instellingenmenu toe onder Instellingen > JCH Optimize. Het instellingenmenu heeft verschillende pagina’s met veel verschillende configuratie opties. Om dingen relatief eenvoudig te maken, heb ik de automatische instelling Gemiddeld geselecteerd in het menu Basisopties.

De resultaten waren een beetje verwarrend.

PageSpeed Insights met de JHC plugin

PageSpeed Insights met de JHC plugin

Alle JavaScript bronnen zijn gecombineerd, wat betekent dat slechts één JS-resource de weergave van content boven de fold blokkeert. Tot nu toe goed bezig. De CSS resultaten zijn waar we een beetje verward raken. Er zijn nog steeds vijf CSS bronnen in een render-blocking positie. Het lijkt erop dat de plugin de inhoud van CSS-bestanden heeft gecombineerd en verkleind. Lettertype bestanden zijn echter uitgesloten en JCH heeft drie verschillende CSS bestanden geladen in plaats van alle drie in één CSS bestand te combineren.

Dat is niet wat ik verwachtte te zien. Laten we eens kijken wat de Speed Test van Pingdom van de veranderingen vindt.

Snelheidstest met JHC plugin

Snelheidstest met JHC plugin

Zoals verwacht, is het aantal verzoeken met één verminderd aangezien twee JavaScript bronnen zijn gecombineerd. Buiten dat, vertoont de test vrijwel onveranderde prestaties.

Ik verwachtte een meer meetbare verbetering van JCH. Ik verwachtte dat alle CSS-bestanden zouden worden gecombineerd en dat er nog maar twee resources zouden overblijven in een render-blocking positie: één gecombineerd JavaScript-bestand en één gecombineerd CSS-bestand. Ik weet niet zeker waarom dat niet is gebeurd. Een premium versie van JCH Optimize is beschikbaar. Het is dus mogelijk dat enkele van de geavanceerde functies het mogelijk maken om CSS bestanden verder te combineren en het aantal bronnen voor render-blocking te verminderen.

Zoals het er nu uitziet, is JCH Optimize niet erg efficient voor het optimaliseren van deze specifieke testsite.

Autoptimize

Met meer dan 600.000 actieve installaties en een 4.7 uit 5 sterren beoordeling, is Autoptimize een van de meest populaire snelheid optimaliserende plugins in de WordPress plugin directory. Het verdient ook meteen een goed cijfer dankzij de liefdadige en genereuze instelling van de ontwikkelaar.

autoptimize plugin

Autoptimize plugin

Deze plugin is ontworpen om eenvoudig in gebruik te zijn en voldoet aan die belofte. Terwijl veel van de andere opties die ik bekeek complexe menu’s hadden, is Autoptimize heel eenvoudig. Het enige wat ik deed was naar Settings > Autoptimize gaan en de drie belangrijkste checkboxen selecteren die op die pagina worden weergegeven.

autoptimize instellingen

Autoptimize instellingen

Hier onder staat hoe de testsite presteerde bij PageSpeed Insights na de simpele minder-dan-30-seconden optimalisatie.

PageSpeed Insights met de Autoptimize plugin

PageSpeed Insights met de Autoptimize plugin

Het is gelukt om het aantal render-blocking resources te verminderen van 7 naar 4. Dat is erg goed. Nu kijken we hoe het aantal verzoeken is veranderd.

Snelheidstest met Autoptimize plugin

Snelheidstest met Autoptimize plugin

Het totale aantal verzoeken is aanzienlijk gedaald van 24 naar 17 en het prestatieniveau is gestegen tot een zeer indrukwekkende 92. Het lijkt erop dat Autoptimize populair is vanwege een goede reden. Ik moet vermelden dat Kinsta een trend van incompatibiliteit met Autoptimize heeft opgemerkt wanneer sommige sites aangepaste CSS in header.php inline hebben. Als je bijvoorbeeld aangepaste CSS code gebruikt in het header.php bestand van jouw thema, moet je extra voorzichtig zijn als je Autoptimize uitprobeert.

Async Javascript

Volgende op de lijst is Async Javascript. Deze plugin is in korte tijd erg populair geworden en wordt onderhouden door dezelfde ontwikkelaar van Autoptimize. De plugin is van 4.000 installaties naar meer dan 40.000 installaties in minder dan een jaar gegaan met een zeer sterke beoordeling: 4.4 van de 5 sterren. Dit is wederom een dood-eenvoudige plugin. Gewoon installeren en activeren. Ga naar de Async Javascript optie die is toegevoegd aan het Admin menu. Selecteer het selectievakje naast Asynchrone JavaScript inschakelen. Selecteer de radio input voor de methode: Defer of Async. Sla vervolgens de wijzigingen op en kijk hoe jouw site presteert.

In het geval van mijn testsite laadde async een aantal jQuery bestanden voordat jquery.js de site uiteindelijk brak. Dus ik ging met de defer methode. Met die opties geselecteerd, is hier hoe de testen verliepen. Als eerste, PageSpeed Insights.

PageSpeed Insights met de Async plugin

PageSpeed Insights met de Async plugin

Zoals verwacht zijn alle JavaScript bronnen verwijderd uit de render-blocking positie maar de CSS is niet veranderd. Dit is prima aangezien deze plugin is ontworpen om alleen JavaScript aan te pakken.

Snelheidstest met Async Plugin

Snelheidstest met Async Plugin

De prestatie van de website, via Pingdom’s Website Speed Test, was nauwelijks veranderd met deze plugin geïnstalleerd Nogmaals, dit bevestigd alleen maar dat deze plugin precies doet wat hij belooft: het elimineren van render-blocking JavaScript.

Combinatie van Async JS en Autoptimize

Het Async Javascript menu vestigt de aandacht op het feit dat het is ontworpen om goed samen te werken met Autoptimize. Omdat ik Autoptimize al had geinstalleerd, probeerde ik dit uit. Na het activeren van Autoptimize verscheen er een nieuw selectievakje in het Async Javascript instellingen menu om Ondersteuning Autoptimize in te schakelen. Hieronder zien we hoe de site presteerde met die optie ingeschakeld.

PageSpeed Insights met Async en Autoptimize plugins

PageSpeed Insights met Async en Autoptimize plugins

Perfect. Met beide plugins ingesteld is het gelukt om het totale aantal van render-blocking resources terug te brengen naar maar 3 CSS bronnen. Hoe zijn de aantal verzoeken beïnvloed?

Snelheidstest met Async en Autoptimize plugins

Snelheidstest met Async en Autoptimize plugins

De website is super snel en heeft maar 17 verzoeken.

Op zichzelf staand, ben ik geen grote voorstander van Async Javascript. Het gebruikt meer ruimte in het instellingen menu om reclame te maken voor de premium versie van de plugin dan voor de plugin instellingen. Het voegt een primair item toe aan het Admin menu in plaats van het toe te voegen als submenu in het Instellingen menu, waar het eigenlijk thuishoort. JavaScript is verkeerd gespeld door Javascript te schrijven. Oke, ik geef toe dat de laatste klacht triviaal is, maar als de P in WordPress er toe doet, doet de S in JavaScript dat ook.

Update: De auteur van de plugin heeft deze feedback opgelost nadat ons bericht was gepubliceerd door de advertentieruimte te verkleinen, de locatie van de plugin in het Instellingen menu te plaatsen en heeft zelfs de spelling van JavaScript te corrigeren. Wij zijn onder de indruk. Ongeacht mijn gedachten over Async Javascript als alleenstaande plugin doet het in combinatie met Autoptimize uitstekend werk door JavaScript volledig te blokkeren en de hoeveelheid CSS te verkleinen.

Hummingbird

De laatste plugin die ik heb getest was Hummingbird van WPMU DEV. Dit is een plugin die ik gebruik op sommige van mijn eigen websites. Dit was vroeger een premium plugin, maar hij is nu gratis beschikbaar! Deze plugin leverde de meest significante reductie in render-blocking resources op, dus hij is vermeldenswaardig.

Hummingbird WordPress plugin

Hummingbird WordPress plugin

Hummingbird is een complexe plugin, maar nog redelijk gebruiksvriendelijk gezien de hoeveelheid mogelijkheden die de plugin biedt. Om bronnen voor het render-blocking te verplaatsen, gaat u naar Hummingbird > Minificatie en selecteer je Bestanden controleren. In het resulterende scherm kan je CSS- en JavaScript-bestanden selecteren om naar de footer of header te verplaatsen, evenals bestanden selecteren om te combineren en te verkleinen.

Ik combineerde en verkleinde alle bestanden en verplaatste ze allemaal naar het footer gedeelte afgezien van twee uitzonderingen: het primaire style.css bestand van het thema en jquery.js. Ik vond dat beide bestanden op hun oorspronkelijke locatie moesten verschijnen om te voorkomen dat de site werd gebroken of er een FOUC werd geproduceerd. Hier is te zien hoe de site presteerde in PageSpeed Insights met deze instellingen.

PageSpeed Insights met de Hummingbird plugin

PageSpeed Insights met de Hummingbird plugin

Als verwacht, er zijn 2 render-blocking resources over: style.css en jquery.js. Prima, laten we kijken wat Pingdom ons nog verteld.

Snelheidstest met de Hummingbird plugin

Snelheidstest met de Hummingbird plugin

Hoewel de algehele prestatie niet zo hoog is als bij Autoptimize, zijn we erin geslaagd het totale aantal verzoeken terug te brengen tot de laagste waarde die we tot nu toe hebben gezien: 16.

Async JS Werkt Prima Samen met Hummingbird

Hoewel de het er erg goed uitziet, bedacht ik me dat Async Javascript ons kan helpen jQuery.js te verplaatsen zonder iets te breken. Na het activeren van Async Javascript en het opnieuw uitvoeren van PageSpeed Insights, zie ik dat we bijna alle render-blocking bronnen hebben geëlimineerd.

Elimineer render-blocking JavaScript

Elimineer render-blocking JavaScript

Het enige dat nog in de weg staat is style.css. De laatste stap om ons in staat te stellen om alle render-blocking bronnen volledig te elimineren, is inline style.css. Het is ons echter gelukt om een bericht over het moeten herstellen van de problemen te zien veranderen in een bericht Overweeg dit te herstellen in PageSpeed Insights. Ik ontwijk de definitie van Google over wanneer ik me zorgen moet maken over een bericht voor het Overwegen van een oplossing en bevestig dat wat we tot nu toe hebben bereikt een doorslaand succes is.

Samenvatting

Niet alle plugins die claimen JavaScript en CSS aan te pakken en te elimineren in relatie tot de render-blocking zijn gelijkwaardig aan elkaar. Autoptimize in combinatie met Async Javascript is de beste gratis optie die ik vond voor mijn testsite. De Hummingbird plugin samen met Async Javascript leverde ook overtuigende resultaten op in PageSpeed Insights.

Dit artikel is verre van volledig en er zijn veel andere plugins die je kunt gebruiken om render-blocking aan te pakken. Welke plugins gebruik jij en raad je aan om JavaScript en CSS voor render-blocking te verwijderen?

43
keer gedeeld