Instellingen van de W3 Total Cache Minify-plugin: Hoe kies ik het inbeddingstype? Mijn ervaring met probleemoplossing en levensreddende tips.

Vindt u het lastig om het juiste inbeddingstype voor W3 Total Cache Minify te kiezen? Dit artikel deelt de praktijkervaring van een webmaster en biedt een stapsgewijze handleiding voor het nauwkeurig selecteren van het juiste Minify-inbeddingstype, waarmee u inconsistenties in de website-stijl en laadproblemen voorkomt. Het bevat ook een gebruiksvriendelijke installatieoplossing die zelfs beginners gemakkelijk kunnen toepassen.hood.discount Versnel zonder te crashen!

Ik was een website aan het optimaliseren en toen ik de instellingen voor het minimaliseren van cache in W3 Total Cache opende, was ik compleet verbijsterd. Het keuzemenu voor het ingesloten cachetype had vier opties: Standaard (Blokkeren), JavaScript gebruiken voor niet-blokkerend, Asynchroon gebruiken voor niet-blokkerend en Vertraagd gebruiken voor niet-blokkerend.

Ik dacht er even over na: waar gaat dit allemaal over?

Geloof me, je bent niet de enige. Deze vier opties zullen waarschijnlijk zelfs een beginner in verwarring brengen, laat staan ​​iemand die al jaren met WordPress werkt. In dit artikel deel ik de valkuilen die ik ben tegengekomen en de lessen die ik heb geleerd. Je hoeft de documentatie niet te raadplegen; volg gewoon mijn instructies.

Wat zijn deze vier inbeddingstypen precies?

Laten we eerst eens kijken wat voor soort personages deze vier opties vertegenwoordigen.

Standaard (blok)Dit wordt standaardblokkering genoemd. Het is de meest eenvoudige aanpak: de browser stopt wanneer hij een script tegenkomt, downloadt en voert het volledig uit, en gaat vervolgens verder met het weergeven van de pagina. Klinkt betrouwbaar, toch? Maar het nadeel is dat de initiële paginalading wordt geblokkeerd; gebruikers moeten wachten tot het script klaar is met draaien voordat ze iets kunnen zien.

JavaScript gebruiken voor niet-blokkerendeDit is best interessant. In plaats van direct `<script>`-tags op de pagina te plaatsen, genereert het eerst een klein script en injecteert het vervolgens dynamisch de scripts die geladen moeten worden via JavaScript nadat de pagina is geladen. Op deze manier kan de pagina eerst worden weergegeven en kunnen de scripts geleidelijk worden geladen. Klinkt geweldig, toch? Het probleem is echter dat dit dynamische injectieproces de oorspronkelijke uitvoeringsvolgorde van de scripts kan verstoren. Als sommige scripts op uw pagina sterk afhankelijk zijn van deze uitvoeringsvolgorde, kunnen er problemen ontstaan.

Gebruik "asynchroon" voor niet-blokkerende bewerkingen.Dit houdt in dat je het `async`-attribuut toevoegt aan de `<script>`-tag. Het script wordt asynchroon op de achtergrond gedownload en direct na het downloaden uitgevoerd, zonder dat de pagina erop hoeft te wachten. Het nadeel is echter dat de uitvoeringsvolgorde volledig oncontroleerbaar is; het script dat als eerste klaar is met downloaden, wordt als eerste uitgevoerd, ongeacht de volgorde die je in de code hebt opgegeven.

"Vertraging" gebruiken voor niet-blokkerende toepassingenDit is wat het toevoegen van het `defer`-attribuut inhoudt. Het script wacht tot de hele pagina is geparseerd voordat het wordt uitgevoerd, en belangrijker nog, het behoudt de oorspronkelijke volgorde waarin je het hebt geschreven. Dit is erg gebruiksvriendelijk, omdat het het eerste scherm niet blokkeert en de volgorde niet verstoort.

Welke moet ik kiezen?

Simpel gezegd zijn deze vier opties vergelijkbaar met een meerkeuzevraag:Gaat u voor snelheid of voor orde?

Mijn suggestie is als volgt:

Als je website klein is, weinig scripts bevat en je geen extreem hoge eisen stelt aan de laadsnelheid, is de standaardinstelling (geblokkeerd) de eenvoudigste optie. Hoewel het iets trager is, zal het geen problemen veroorzaken.

Als je de laadsnelheid van het eerste scherm wilt verbeteren en je scripts geen sterke afhankelijkheden hebben zoals "A moet vóór B worden uitgevoerd", geef dan prioriteit aan..."Vertraging" gebruiken voor niet-blokkerende toepassingen(uitstellen). Dit is momenteel vrijwel de meest ideale oplossing, omdat het de weergave niet blokkeert en de volgorde niet verstoort.

Als je de functie probeert uit te stellen en je merkt dat sommige functies nog steeds problemen geven, overweeg dan het volgende...JavaScript gebruiken voor niet-blokkerendeDeze oplossing is radicaler, maar de compatibiliteit ervan is iets minder goed.

Gebruik "asynchroon" voor niet-blokkerende bewerkingen.(Async) is de optie die ik het minst aanbeveel. Omdat de uitvoeringsvolgorde volledig in de war is, kan het gemakkelijk vastlopen, tenzij je er absoluut zeker van bent dat al je scripts onafhankelijk van elkaar worden uitgevoerd.

Twee grote valkuilen waar ik in ben getrapt.

Praten is makkelijk. Ik heb twee fouten opgeschreven die ik heb gemaakt; je kunt ze vergelijken met je eigen ervaringen om te zien of je ze kunt vermijden.

Het eerste probleem: aangepaste WordPress-thema's kunnen niet in realtime worden bekeken.

Een tijdlang gebeurde het volgende: na het klikken op 'Opslaan' werd de preview niet vernieuwd tijdens het aanpassen van een thema. Ik bracht wijzigingen aan, vernieuwde de pagina, en het resultaat bleef hetzelfde.

Na enig onderzoek ontdekte ik dat de compressiefunctie van Minify de boosdoener was. De oplossing is simpel:

Open de W3 Total Cache-plug-inAlgemene instellingen,harder zetten"compressie"Schakel die optie uit. Klik vervolgens op het kleine pijltje onder 'Instellingen opslaan' in de rechterbovenhoek en selecteer '...'.Instellingen opslaan en cache wissenDeze stap is cruciaal; als je de cache niet wist, zie je nog steeds de oude versie.

Als je klaar bent, ga dan terug naar de thema-aanpassingen en de live preview zal weer normaal functioneren.

Het tweede probleem: het zoekvak van het Astra-thema reageert niet wanneer erop geklikt wordt.

Ik ben dit probleem al een tijdje geleden tegengekomen. Ik gebruikte het Astra-thema en op een dag merkte ik ineens dat het zoekvak niet meer reageerde, hoe ik er ook op klikte. Eerst dacht ik dat het een probleem met het thema zelf was, maar later ontdekte ik dat het werd veroorzaakt door de Minify-instellingen van W3TC.

De oplossing is als volgt:

Ga naar W3 Total Cache → Algemene instellingen → Geavanceerde compressie-instellingen → JS → Instellingen voor de minimalisatie-engine → Taalinstellingen en wijzig het inbeddingstype naar een van deze twee:

1. Voorheen werd niet-blokkerende werking bereikt met behulp van JavaScript.
2. Gebruik daarna JavaScript voor niet-blokkerende doeleinden.

Op dezelfde manier zorgt het wissen van de cache en het vernieuwen van de pagina ervoor dat het zoekveld weer goed werkt.

Wat betreft de keuze voor deze twee opties in plaats van andere, heb ik wat onderzoek gedaan. Simpel gezegd zijn de front-end componenten van het Astra-thema erg gevoelig voor de timing van de scriptuitvoering, en bepaalde niet-blokkerende methoden kunnen ervoor zorgen dat de gebeurtenisafhandeling mislukt. Door de modus "niet-blokkerend met JS" te gebruiken, wordt ervoor gezorgd dat het script pas wordt uitgevoerd nadat de pagina volledig is geladen, waardoor de ongeordende uitvoering die bij asynchrone methoden voorkomt, wordt vermeden.

落地清单

Tot slot is hier een checklist die je direct kunt volgen:

De eerste stap is het verduidelijken van uw doel. Wilt u de snelst mogelijke laadtijd van de pagina, of geeft u prioriteit aan stabiliteit en een foutloze werking? Dit bepaalt welk type embedding u moet gebruiken.

De tweede stap is om niet alles in één keer te veranderen. Zoek eerst een minder belangrijke pagina om de wijziging te testen, observeer deze een dag of twee en voer de wijziging pas door op de hele website als je zeker weet dat er geen problemen zijn.

Ten derde, wis altijd de cache na elke wijziging. Het cachemechanisme van W3TC voorkomt dat u de laatste wijzigingen ziet, dus de stap "cache wissen en opnieuw testen" is absoluut essentieel.

Ten vierde, gebruik de ontwikkelaarstools van je browser of tools zoals PageSpeed ​​Insights om de laadsnelheid voor en na de aanpassing te vergelijken. Laat de data voor zich spreken, niet alleen je onderbuikgevoel.

Schrijf aan het einde

Eerlijk gezegd was ik lange tijd verbijsterd toen ik deze instelling voor ingebedde typen voor het eerst zag. De standaard blokkerende modus leek te traag, terwijl de asynchrone modus de volgorde van bewerkingen niet garandeerde en uitstel mogelijk compatibiliteitsproblemen zou veroorzaken. Ik wist niet goed welke optie ik moest kiezen.

Maar later besefte ik dat het een afweging is. Je kunt niet tegelijkertijd de snelste en de meest stabiele oplossing hebben; je moet altijd een van beide opofferen. Mijn ervaring is om eerst `defer` te gebruiken, wat momenteel de veiligste niet-blokkerende oplossing is, en vervolgens een callback te gebruiken als er problemen optreden.

Mocht je soortgelijke problemen tegenkomen, of als je na het volgen van mijn methode nog steeds andere problemen hebt, aarzel dan niet om contact met me op te nemen. Websiteontwikkeling draait om vallen en opstaan; niemand is daarop een uitzondering.

Bedankt voor het lezen van mijn artikel. Tot de volgende keer.