Inställningar för W3 Total Cache Minify-plugin: Hur väljer man inbäddningstyp? Min felsökningserfarenhet och livräddande råd

Har du svårt att välja rätt inbäddningstyp för W3 Total Cache Minify? Den här artikeln delar med dig av en webbansvarigs verkliga erfarenheter och ger en steg-för-steg-guide för att korrekt välja rätt Minify-inbäddningstyp, för att undvika problem med webbplatsens stil och laddningskrascher. Den innehåller också en idiotsäker installationslösning som även nybörjare enkelt kan tillämpa.hood.discount Accelerera utan att krascha!

Jag optimerade en webbplats och när jag öppnade Minify-inställningarna i W3 Total Cache blev jag helt mållös. Rullgardinsmenyn för den inbäddade typen hade fyra alternativ: Standard (Block), Använd JS för icke-blockering, Använd "Asynkron" för icke-blockering och Använd "Fördröjd" för icke-blockering.

Jag funderade på det en stund, vad handlar allt detta om?

Lita på mig, du är inte ensam. Dessa fyra alternativ kommer förmodligen att förvirra även en nybörjare, än mindre någon som har använt WordPress i åratal. Den här artikeln presenterar de fallgropar jag har stött på och de lärdomar jag har fått direkt. Du behöver inte konsultera dokumentationen; följ bara mina instruktioner.

Vilka är egentligen dessa fyra inbäddningstyper?

Låt oss först prata om vilken typ av karaktär dessa fyra alternativ är.

Standard (blockerad)Detta kallas standardblockering. Det är den enklaste metoden: webbläsaren stannar när den stöter på ett skript, laddar ner och kör det helt och fortsätter sedan att rendera sidan. Låter pålitligt, eller hur? Men nackdelen är att din första sidinläsning kommer att blockeras; användare måste vänta på att skriptet ska köras klart innan de kan se något.

Använda JS för icke-blockerandeDet här är ganska intressant. Istället för att skriva `<script>`-taggar direkt på sidan, matar den först ut ett litet skript och injicerar sedan dynamiskt de skript som behöver läsas in på sidan via JavaScript efter att sidan körts. På så sätt kan sidan renderas först och skripten laddas gradvis. Låter bra, eller hur? Problemet är dock att denna dynamiska injiceringsprocess kan störa den ursprungliga exekveringsordningen för skripten. Om vissa skript på din sida är starkt beroende av exekveringsordningen kan problem uppstå.

Använd "asynkron" för icke-blockerandeDetta innebär att attributet `async` läggs till i taggen `<script>`. Skriptet laddas ner asynkront i bakgrunden och körs omedelbart efter nedladdningen, utan att sidan väntar på det. Nackdelen är dock att körningsordningen är helt okontrollerbar; det skript som slutför nedladdningen först körs först, oavsett vilken ordning du angav i koden.

Använda "fördröjning" för icke-blockeringDet här är vad det innebär att lägga till attributet `defer`. Skriptet väntar tills hela sidan har analyserats innan det körs, och viktigast av allt, det bibehåller den ursprungliga ordningen du skrev det i. Detta är ganska användarvänligt, eftersom det varken blockerar den första skärmen eller stör ordningen.

Vilken ska jag välja?

Enkelt uttryckt är dessa fyra alternativ som en flervalsfråga:Vill du ha snabbhet eller ordning?

Mitt förslag är följande:

Om din webbplats är liten, har få skript och du inte har extremt höga krav på laddningshastighet är det enklaste alternativet att använda standardinställningen (blockerad). Även om den är lite långsammare kommer den inte att orsaka några problem.

Om du vill förbättra hastigheten på första skärmen och dina skript inte har starka beroenden som "A måste köras före B", prioritera...Använda "fördröjning" för icke-blockering(uppskjuta). Detta är nästan den mest ideala lösningen för närvarande, eftersom den varken blockerar rendering eller stör ordningen.

Om du försöker defer och fortfarande upptäcker att vissa funktioner har problem, överväg då...Använda JS för icke-blockerandeDenna lösning är mer radikal, men dess kompatibilitet är något sämre.

Använd "asynkron" för icke-blockerande(async) är det alternativ jag minst rekommenderar. Eftersom exekveringsordningen är helt felaktig är det lätt att krascha om du inte är helt säker på att dina skript körs oberoende av varandra.

Två stora fallgropar jag hamnade i

Prat är billigt. Jag har skrivit ner två misstag jag gjorde; du kan jämföra dem med din egen erfarenhet för att se om du kan undvika dem.

Den första fallgroparna: Anpassade WordPress-teman kan inte förhandsgranskas i realtid.

Ett tag, när jag anpassade ett tema, uppdaterades inte förhandsgranskningen efter att ha klickat på spara. Jag gjorde några ändringar, uppdaterade sidan, och det var fortfarande detsamma.

Efter lite undersökning upptäckte jag att Minifys komprimeringsfunktion var boven i dramat. Lösningen är enkel:

Åtkomst till W3 Total Cache-pluginetAllmänna Inställningar,dyka upp"kompression"Avmarkera det alternativet. Klicka sedan på den lilla pilen under "Spara inställningar" i det övre högra hörnet och välj "...".Spara inställningar och rensa cachenDet här steget är avgörande; om du inte rensar cachen kommer du fortfarande att se den gamla versionen.

När du är klar, gå tillbaka till temaanpassning, så kommer live-förhandsvisningen att vara tillbaka till det normala.

Det andra problemet: Astra-temats sökruta svarar inte när man klickar på den.

Jag stötte på det här problemet för ett tag sedan. Jag använde Astra-temat, och en dag upptäckte jag plötsligt att sökrutan inte svarade oavsett hur jag klickade på den. Först trodde jag att det var ett problem med själva temat, men senare upptäckte jag att det orsakades av W3TC:s Minify-inställningar.

Lösningen är följande:

Gå till W3 Total Cache → Allmänna inställningar → Avancerade komprimeringsinställningar → JS → Minify Engine-inställningar → Språkinställningar och ändra inbäddningstypen till en av dessa två:

1. Tidigare uppnåddes icke-blockering med hjälp av JavaScript.
2. Använd sedan JS för icke-blockerande

På samma sätt kommer sökrutan att fungera korrekt om du rensar cachen och uppdaterar sidan.

När det gäller varför dessa två alternativ valdes istället för andra har jag gjort lite research. Enkelt uttryckt är Astra-temats frontend-komponenter ganska känsliga för tidpunkten för skriptkörning, och vissa icke-blockerande metoder kan orsaka att händelsebindning misslyckas. Att använda läget "icke-blockerande med JS" säkerställer att skriptet körs först efter att sidan har laddats klart, samtidigt som man undviker den oordnade körningen som ses med asynkron.

Lista över platser att besöka

Slutligen, här är en checklista som du kan följa direkt:

Det första steget är att klargöra ditt mål. Vill du ha den snabbaste initiala sidinläsningen, eller prioriterar du stabilitet och felfri drift? Detta avgör vilken inbäddningstyp du ska använda.

Det andra steget är att inte ändra allt på en gång. Först, hitta en mindre viktig sida att testa, observera den i en dag eller två, och marknadsför den bara till hela webbplatsen om du är säker på att det inte finns några problem.

För det tredje, rensa alltid cachen efter varje ändring. W3TC:s cachemekanism förhindrar att du ser de senaste ändringarna, så steget "rensa cachen och testa igen" är absolut nödvändigt.

För det fjärde, använd din webbläsares utvecklarverktyg eller verktyg som PageSpeed ​​Insights för att jämföra laddningshastigheten före och efter. Låt informationen tala för sig själv, inte bara din magkänsla.

Skriv i slutet

Ärligt talat, när jag först såg den här inställningen för inbäddad typ blev jag förbluffad länge. Standardblockeringsläget verkade för långsamt, medan asynkront läge inte garanterade ordningen, och uppskjutning kunde orsaka kompatibilitetsproblem. Jag var osäker på vilket alternativ jag skulle välja.

Men jag insåg senare att det är en avvägning. Man kan inte ha både det snabbaste och det mest stabila; man måste alltid offra den ena. Min erfarenhet är att använda defer först, vilket för närvarande är den säkraste icke-blockerande lösningen, och sedan använda en callback om problem uppstår.

Om du stöter på liknande problem, eller om du fortfarande har andra problem efter att ha följt min metod, tveka inte att diskutera det. Webbplatsutveckling handlar om trial and error; inget är ett undantag.

Tack för att du läste min artikel. Vi ses nästa gång.