Hur man eliminerar renderingsblockerande JavaScript och CSS

När det gäller hastigheten på din webbplats är det viktigt att tänka på hastighet som en nödvändig funktion, inte en lyx, och att behandla den därmed. Det finns många saker som går in i ekvationen som avgör hur snabbt besökare börjar se innehåll när de besöker din webbplats. Några av dessa saker kan du inte styra: hastigheten på deras internetanslutning, deras geografiska läge, nätverkslatens och så vidare. Det finns dock andra saker som du kan och bör kontrollera.

Ett verktyg som du kan använda för att identifiera hastighetsreducerande problem som är under din kontroll är Google PageSpeed ​​Insights. Säkert har du använt PageSpeed ​​Insights tidigare (om du inte har det, det här är din signal att gå dit innan du läser resten av den här artikeln). Det är gratis och identifierar problem som saktar ner leveranserna av dina webbplatser, till exempel renderingsblockerande JavaScript och CSS.

• Vanligt problem: Renderingsblockerande JavaScript och CSS
• Hur man eliminerar Renderingsblockerande JavaScript och CSS
• Plugin för att minska Renderingsblockerande JavaScript och CSS

Vanligt problem: Renderingsblockerande JavaScript och CSS

Det finns tio hastighetsregler som används för att analysera webbplatser som körs genom PageSpeed ​​Insights. Två av dessa regler har att göra med JavaScript och CSS-resurser som blockerar det översta innehållet. Misslyckas någon av dessa två regler – och många, många webbplatser misslyckas med en eller båda, och du får se ett meddelande som ”Borde Fixas”, så att du vet att du borde: Eliminera renderingsblockerande JavaScript och CSS i det översta innehållet.

Vad betyder det egentligen? Här är en fördjupad förklaring.

När en webbläsare laddar en webbsida, hindrar JavaScript och CSS-resurserna vanligtvis att webbsidan visas tills de laddas ner och bearbetas av webbläsaren. I vissa fall är det här en bra sak. Till exempel, rendera ren HTML innan något CSS laddas ned och du får en blixt av ostylat innehåll (FOUC) vilket förmodligen är en sämre upplevelse för dina användare än att vänta några hundradelar av en sekund längre för att innehåll ska visas.

Vissa resurser behöver laddas ner och bearbetas innan de visar något. Men många CSS- och JavaScript-resurser är villkorliga – de är bara använda i specifika fall – eller behöver inte helt enkelt rendera det översta innehållet. För att producera den snabbaste möjliga upplevelsen för dina användare, bör du försöka eliminera eventuella renderingsblockerande resurser som inte krävs för att visa det översta innehållet.

Jag vill vara tydlig på en punkt: det kan vara för mycket arbete eller helt enkelt omöjligt att ta bort alla renderingsblockerande resurser. Att göra det kan till och med producera den fruktade FOUC (ovan) som jag nämnde för en minut sedan. Kom bara ihåg att det inte är vårt mål att uppnå en perfekt PageSpeed-poäng. I stället är vårt mål att leverera den bästa möjliga användarupplevelsen, och det betyder en webbplats som laddas så fort som möjligt utan att blinka ostylat innehåll.

Med andra ord, använd PageSpeed ​​Insights för att identifiera renderingsblockerande filer som du kan försöka eliminera, men låt UX vara din övergripande riktlinje. Du kan också se att detta meddelande visas i andra hastighetstestverktyg. I GTmetrix visas till exempel ”Defer Parsning of JavaScript”.

Hur man eliminerar Renderingsblockerande JavaScript och CSS

Det finns ett plugin för det, eller hur? Javisst, men du måste förstå vad som händer innan du börjar plugga in plugin. Många plugins är mycket konfigurerbara, och att veta hur renderingsblockerande resurser elimineras hjälper dig att arbeta mer effektivt med det plugin du väljer.

Rensa JS från den kritiska renderingsbanan

Först, låt oss prata JavaScript. Grundidén är att flytta onödiga JavaScript och jQuery-resurser ut ur den kritiska renderingsbanan. Detta görs vanligen genom att lägga till antingen defer– eller async-attributet till script-HTML-elementen som kallar JavaScript-resurser.

defer– och async-attributen skapas inte lika, och skillnaden kan vara viktig att förstå.

• Async-attributettalar om för webbläsaren att börja hämta resursen direkt utan att sakta ner HTML-parsing. När resursen är tillgänglig är HTML-parsing pausad så att resursen kan laddas.
• Defer-attributettalar om för webbläsaren att vänta på att ladda ner resursen tills HTML-parsingen är klar. När webbläsaren är klar med HTML-filen kommer den sedan att ladda ner och rendera alla uppskjutna skript i den ordning de visas i dokumentet.

Den stora skillnaden mellan de två är att defer säkerställer att skript laddas ner och appliceras på webbsidan i den ordning de visas i HTML-dokumentet, medan async inte gör det. Resultatet är att om det async används på alla JavaScript-resurser, kan det ofta bryta resurser som är beroende av resurser som visas tidigare i dokumentet. Det vanligaste problemet som async producerar är brutna jQuery-resurser som försöker ladda innan jquery.js har lagts till i dokumentet.

Optimera leverans av CSS-resurser

Renderingsblockerande CSS kan också vara svårt om inte omöjligt att helt eliminera. Det idealiska arrangemanget är att:

• Identifiera de stilar som krävs för att rendera det översta innehållet och leverera dessa stilar med HTML.
• Använd media-attributet på de link-element som drar in CSS-filer för att identifiera CSS-resurser som är villkorliga, det vill säga, bara behövs för specifika enheter eller situationer.
• Återstående CSS-resurser ska laddas asynkront, ett drag som vanligtvis görs genom att lägga till dem med uppskjutet eller asynkront JavaScript. För att vara ärliga är vi verkligen ute på djupt vatten här, eller hur? Detta är definitivt front-end-utvecklingsterritorium. Vilket är bra om du är en front-end-utvecklare, men de flesta av oss är inte det. Den goda nyheten är att det här är en artikel om WordPress, och du kan eliminera eller åtminstone avsevärt minska antalet renderingsblockerande JS- och CSS-resurser som påverkar din webbplats med rätt plugin(s).

Plugin för att minska Renderingsblockerande JavaScript och CSS

För att förbereda denna artikel arbetade jag igenom ett dussintals populära WordPress-plugins som utformades för att minska och eliminera renderingsblockerande JavaScript- och CSS-resurser och fastnade på fem som gav en mätbar reduktion.

Jag bör också nämna att jag inte använde några cachnings-plugin under denna process. Min testplats upprättades på en Kinsta-plan som levereras med inbyggd cachning på servernivå. Om du inte är en Kinsta-kund, kommer det att förbättra ditt webbplats prestanda att ställa in ett bra cachnings-plugin.

Men innan vi kommer till plugins behöver vi ett riktmärke. Vad jag har gjort är att skapa en enkel testplats på Kinsta och installerat ett populärt, gratis, jQuery-älskande tema från WordPress.org: Sydney. Utan att göra någonting annat, här är vi.

Inte så illa, men det finns säkert utrymme för förbättringar. Det finns två JavaScript och fem CSS-resurser i renderingsblockerande läge.

Ett annat test som vi ska använda som riktmärke är Pingdom Website Speed ​​Test. I synnerhet vill vi notera antalet begäranden som krävs för att ladda webbsidan och se hur det här numret ändras med olika plugin aktiverade. Varje ytterligare förfrågan innebär en till rundresa till servern, så många plugin kommer att kombinera CSS och JavaScript-resurser till färre filer för att påskynda webbplats-prestanda.

Eftersom min testplats är värd på Kinsta, är webbplatsen blixtsnabbt direkt och krävde 24 förfrågningar för att ladda hemsidan.

Låt oss se hur vi kan förbättra den prestandan genom att prova några plugin.

Speed Booster Pack

Först ut är Speed Booster Pack. Detta plugin är aktiv på över 40 000 WordPress-webbplatser och har en 3,6 av 5-stjärnklassificering på WordPress.org.

Plugininställningar finns i Inställningar > Speed ​​Booster Pack och menyn är ganska enkel samtidigt som det erbjuder ganska många konfigurationsalternativ.

Den allmänna alternativmenyn kan flytta skript till sidfot och skjut upp parsing av JavaScriptfiler. I kombination ska dessa två alternativ helt och hållet ta bort renderingsblockerande JavaScript. En annan meny med titeln behöver du fortfarande mer fart? tillåter laddning av CSS asynkront. Medan detta borde ha eliminerat alla renderingsblockerande CSS, så möjliggjorde det här alternativet den fruktade FOUC, så jag lämnade inte det här alternativet aktiverat.

Med pluginet konfigurerad, här är hur webbplatsen utfördes på PageSpeed ​​Insights.

Som förväntat finns det inga renderingsblockerande JavaScript-resurser kvar. Men eftersom asynkron CSS-laddning skapade en FOUC och måste lämnas avaktiverad blockerar alla fem CSS-resurserna fortfarande det översta innehållet.

Intressant nog ökade faktiskt antalet förfrågningar. Medan det inte fanns något som tyder på att antalet skulle ha minskat, är en ökning av antalet begäran en överraskning. Den totala prestandan förbättrades lite, så jag kommer inte att kalla Speed ​​Booster Pack värdelöst. Det finns dock mer effektiva alternativ.

JCH Optimize

Låt oss då titta på JCH Optimize. Medan pluginet har färre aktiva installationer än Speed ​​Booster Pack, har det en imponerande 4,6 stjärnor av 5 i betyg.

Detta plugin kombinerar och minifierar JavaScript och CSS, och tillsammans med många andra funktioner är det utformat för att påskynda sidladdning. Medan eliminering av renderingsblockerande resurser inte nämns specifikt någonstans, bör kombinationen av JavaScript och CSS-filer innebära att det finns färre resurser som krävs för att ladda sidan och färre JS- och CSS-resurser i ett renderingsblockerande läge.

Pluginet lägger till en inställningsmeny i Inställningar > JCH Optimize. Inställningsmenyn har flera sidor med många olika konfigurationsalternativ. För att göra saker relativt enkla valde jag de genomsnittliga automatiska inställningarna i menyn Grundalternativ.

Resultaten var lite förbryllande.

Alla JavaScript-resurser har kombinerats, vilket innebär att endast en JS-resurs blockerar rendering av det översta innehållet. Än så länge är allt bra. CSS-resultaten är dock lite mer förbryllande. Det finns fortfarande fem CSS-resurser i ett renderingsblockerande läge. Det verkar som om pluginet har kombinerat och minifierat innehållet i CSS-filer. Font-filer har dock uteslutits, och JCH har laddat tre olika CSS-filer i stället för att kombinera alla tre i en enda CSS-fil.

Det var inte vad jag förväntade mig att se. Låt oss se vad Pingdoms webbplatshastighetstest tycker om förändringarna.

Som förväntat har antalet förfrågningar minskats med en eftersom två JavaScript-resurser har kombinerats. Annat än det visar testet prestanda som är praktiskt taget oförändrat.

Jag förväntade mig en mer mätbar förbättring från JCH. Jag förväntade mig att alla CSS-filer skulle kombineras och det skulle bara finnas två renderingsblockerande resurser kvar: en kombinerad JavaScript-fil och en kombinerad CSS-fil. Jag är inte säker på varför det inte hände. En premiumversion av JCH Optimize är tillgänglig. Så det är möjligt att några av de avancerade funktionerna skulle göra det möjligt att kombinera CSS-filer ytterligare och minska antalet återställningsskyddande resurser.

Som det verkar här är JCH Optimize inte till stor hjälp för att optimera den här testplatsen.

Autoptimize

Med över 600 000 aktiva installationer och en 4,7 av 5 stjärnor, är Autoptimize ett av de mest populära hastighetsoptimeringsprogrammen i WordPress-plugin-katalogen. Det får också god betyg direkt tack vare plugin-författarens välgörande och generösa attityd.

Detta plugin är utformat för att vara enkelt att använda och det lever upp till det löftet. Medan många av de andra alternativen jag tittade på hade väldigt komplexa menyer är Autoptimize väldigt enkelt. Allt jag gjorde var att gå till Settings > Autoptimize och välja de tre primära kryssrutealternativen som visas på den sidan.

Så här har min testplats presterat på PageSpeed ​​Insights efter den enkla 30 sekunders eller snabbare optimeringen.

Vi har lyckats minska antalet renderingsblockerande resurser från totalt sju till fyra. Mycket bra. Nu ska vi se hur antalet förfrågningar har ändrats.

Det totala antalet förfrågningar har minskat avsevärt från 24 till 17, och prestandaklassen har hoppat till en mycket imponerande 92. Det verkar som om Autoptimize är populärt av mycket bra skäl. Jag bör nämna att Kinsta har märkt en trend av Autoptimize-inkompatibilitet med vissa webbplatser som har anpassade CSS i header.php. Om du till exempel har anpassad CSS kodad i temats header.php-fil, var försiktig om du testar Autoptimize.

Async Javascript

Nästa på listan är Async Javascript. Detta plugin har vuxit mycket populärt på kort tid och underhålls av samma utvecklare som Autoptimize. Den har gått från 4 000 installationer till över 40 000 installationer på under ett år med ett mycket starkt betyg: 4.4 av 5 stjärnor. Detta är ett annat löjligt enkelt plugin. Installera bara och aktivera det. Gå till alternativet Async JavaScript tillagt Admin-menyn. Markera kryssrutan bredvid Aktivera Async JavaScript. Välj alternativknappen för antingen Defer- eller Async-metoden. Spara sedan ändringarna och se hur din webbplats presterar.

När det gäller min testplats, laddade async vissa jQuery-filer före jquery.js som bröt webbplatsen. Så jag valde defer-metoden. Med de alternativen, här är hur det gick på testen. Först ut, PageSpeed ​​Insights.

Webbplatsens prestanda på Pingdoms webbplatshastighetstest var ganska oförändrat efter att pluginet installerats. Återigen bekräftar detta bara att det här pluginet gör exakt vad det säger att det kommer att göra: eliminera renderingsblockerande JavaScript.

Webbplatsens prestanda på Pingdoms webbplatshastighetstest var ganska oförändrat efter att pluginet installerats. Återigen bekräftar detta bara att det här pluginet gör exakt vad det säger att det kommer att göra: eliminera renderingsblockerande JavaScript.

Kombinera Async JS och Autoptimize

Async JavaScript-menyn drar uppmärksamheten till att den är utformad för att fungera bra med Autoptimize. Eftersom jag redan hade Autoptimize installerat gav jag det ett försök. Efter att ha aktiverat Autoptimize visas en ny kryssruta i Async JavaScript-inställningsmenyn för Aktivera Autoptimize support. Med den här kryssrutan aktiverad, här är hur webbplatsen presterade.

Utmärkt. Med båda pluginen har vi lyckats får ner det totala antalet renderingsblockerande resurser till bara tre CSS-resurser. Hur har vi påverkat antalet förfrågningar?

Webbplatsen är blixtsnabb och skickar endast 17 förfrågningar.

På egen hand är jag inte ett stort fan av Async Javascript. Det dedikerar mer utrymme i inställningsmenyn för att annonsera premiumversionen av pluginet än till plugin-inställningarna. Det lägger till ett primärt objekt på Admin-menyn istället för att lägga till det som en undermenyobjekt i menyn Inställningar där den verkligen hör hemma. Det felstavar JavaScript genom att skriva det Javascript. Okej, jag erkänner att sista grejen är trivialt, men om P i WordPress spelar roll, så gör S i JavaScript det också.

Uppdatering: Författaren till pluginet tog tag i dessa klagomål efter att vårt inlägg publicerades genom att minska annonsens storlek, flytta platsen för pluginet i Admin-menyn och till och med fixa stavningen av JavaScript. Vi var imponerade. Oavsett mina tankar om Async JavaScript på egen hand; när det är parat med Autoptimize gör det ett bra jobb med att helt eliminera renderingsblockerande JavaScript och trimma ner mängden renderingsblockerande CSS.

Hummingbird

Det sista pluginet jag testade var Hummingbird av WPMU DEV. Detta är ett plugin som jag använder på några av mina egna webbplatser. Detta brukade vara ett premium-plugin men det är nu tillgängligt gratis! Det gav den mest signifikanta minskningen av renderingsblockerande resurser, så det är värt att omnämnas.

Hummingbird är ett komplext plugin, men också ganska användarvänligt med tanke på hur mycket det erbjuder. För att flytta renderingsblockerande resurser gå till Hummingbird > Minifiering och välj Kontrollera filer. Från den resulterande skärmen kan du välja CSS och JavaScript-filer för att flytta till sidfot eller rubrik, samt filer som ska kombineras och minifiera.

Jag kombinerade och minifierade alla filer och flyttade dem alla till sidfoten med två undantag: temats primära style.css- fil och jquery.js. Jag fann att båda dessa filer måste visas på sin ursprungliga plats för att undvika att bryta webbplatsen eller producera en FOUC. Med de här inställningarna kan du se hur webbplatsen presterade i PageSpeed ​​Insights.

Som förväntat är vi nere på bara två renderingsblockerande resurser: style.css och jquery.js. Bra. Låt oss se vad Pingdom kan berätta för oss.

Medan den totala prestandaklassen inte är lika hög som med Autoptimize har vi lyckats trimma det totala antalet förfrågningar till det lägsta värdet vi hittills har sett: 16.

Async JS fungerar bra med Hummingbird

Medan saker ser väldigt bra ut, förekommer det att Async Javascript kan hjälpa oss att flytta jquery.js utan att bryta någonting. Efter att ha aktiverat Async Javascript och köra PageSpeed ​​Insights igen ser jag att vi nästan helt har eliminerat alla renderingsblockerande resurser.

Allt som står kvar i vägen är style.css. Det sista steget som gör det möjligt för oss att helt eliminera alla renderingsblockerande resurser skulle vara att infoga style.css. Vi har dock lyckats gå från att se ett borde fixas meddelande till ett överväg fixa-meddelande i PageSpeed ​​Insights. Jag kommer att förlita mig på Googles definition av när du ska oroa dig för ett Överväg Fixa – meddelande och säger att det vi hittills har uppnått är en rungande framgång.

Sammanfattning

Inte alla plugins som hävdar att adressera och eliminera renderingsblockerande JavaScript och CSS-problem skapas lika. Autoptimize i kombination med Async JavaScript är det bästa gratisalternativet jag hittade för min testplats. Hummingbird tillsammans med Async JavaScript gav också resultat som äntligen gjorde PageSpeed ​​Insights nöjd.

Den här artikeln är långt ifrån uttömmande, och det finns många fler plugin som du kan använda för att adressera renderingsblockerande resurser. Vilka plugin använder du och rekommenderar för att ta bort renderingsblockerande JavaScript och CSS?