Configuració del complement W3 Total Cache Minify: com triar el tipus d'incrustació? La meva experiència en la resolució de problemes i consells que salven vides

Tens dificultats per triar el tipus d'incrustació correcte per a W3 Total Cache Minify? Aquest article comparteix l'experiència real d'un webmaster i proporciona una guia pas a pas per seleccionar amb precisió el tipus d'incrustació de Minify correcte, evitant errors d'estil del lloc web i errors de càrrega. També inclou una solució de configuració infal·lible que fins i tot els principiants poden aplicar fàcilment.WordPress Accelera sense xocar!

Estava optimitzant un lloc web i quan vaig obrir la configuració de Minify a W3 Total Cache, em vaig quedar completament bocabadat. El menú desplegable del tipus incrustat tenia quatre opcions: Per defecte (bloqueig), Utilitza JS per a no bloquejants, Utilitza "asíncrona" per a no bloquejants i Utilitza "retardada" per a no bloquejants.

Ho pensat un moment, de què va tot això?

Creu-me, no estàs sol. Aquestes quatre opcions probablement deixaran desconcertat fins i tot un principiant, i molt menys algú que fa anys que utilitza WordPress. Aquest article presenta els entrebancs que he trobat i les lliçons que he après directament. No cal que consultis la documentació; només cal que segueixis les meves instruccions.

Quins són exactament aquests quatre tipus d'incrustació?

Parlem primer de quin tipus de personatge són aquestes quatre opcions.

Per defecte (bloquejat)Això s'anomena bloqueig per defecte. És l'enfocament més senzill: el navegador s'atura quan troba un script, el descarrega i l'executa completament i després continua renderitzant la pàgina. Sembla fiable, oi? Però la contrapartida és que la càrrega inicial de la pàgina es bloquejarà; els usuaris hauran d'esperar que l'script acabi d'executar-se abans de poder veure res.

Ús de JS per a no bloquejosAixò és força interessant. En comptes d'escriure directament les etiquetes `<script>` a la pàgina, primer genera un petit script i, a continuació, injecta dinàmicament els scripts que s'han de carregar a la pàgina mitjançant JavaScript després que la pàgina s'estigui executant. D'aquesta manera, la pàgina es pot renderitzar primer i els scripts es poden carregar gradualment. Sona molt bé, oi? Tanmateix, el problema és que aquest procés d'injecció dinàmica pot interrompre l'ordre d'execució original dels scripts. Si alguns scripts de la vostra pàgina depenen en gran mesura de l'ordre d'execució, poden sorgir problemes.

Utilitzeu "asíncrona" per a no bloquejarAixò implica afegir l'atribut `async` a l'etiqueta `<script>`. L'script es descarregarà asíncronament en segon pla i s'executarà immediatament després de la descàrrega, sense que la pàgina l'esperi. Tanmateix, l'inconvenient és que l'ordre d'execució és completament incontrolable; l'script que acabi de descarregar primer s'executa primer, independentment de l'ordre que hàgiu especificat al codi.

Ús de "retard" per a no bloqueigAixò és el que significa afegir l'atribut `defer`. L'script esperarà fins que s'hagi analitzat tota la pàgina abans d'executar-se i, el que és més important, mantindrà l'ordre original que vau escriure. Això és força fàcil d'utilitzar, ja que no bloqueja la primera pantalla ni interromp l'ordre.

Quin hauria de triar?

En poques paraules, aquestes quatre opcions són com una pregunta de resposta múltiple:Voleu rapidesa o ordre?

El meu suggeriment és el següent:

Si el vostre lloc web és petit, té pocs scripts i no teniu uns requisits de velocitat de càrrega extremadament alts, utilitzar la configuració predeterminada (bloquejada) és l'opció més fàcil. Tot i que és una mica més lent, no causarà cap problema.

Si voleu millorar la velocitat de la primera pantalla i els vostres scripts no tenen dependències fortes com ara "A s'ha d'executar abans de B", prioritzeu...Ús de "retard" per a no bloqueig(ajornar). Aquesta és gairebé la solució més ideal actualment, ja que no bloqueja la renderització ni interromp l'ordre.

Si proveu de defer i encara trobeu que algunes funcions tenen problemes, considereu...Ús de JS per a no bloquejosAquesta solució és més radical, però la seva compatibilitat és lleugerament pitjor.

Utilitzeu "asíncrona" per a no bloquejar(async) és l'opció que menys recomano. Com que l'ordre d'execució està completament desordenat, és fàcil que es bloquegi tret que estigueu absolutament segurs que els vostres scripts s'executen de manera independent.

Dos grans paranys en què vaig caure

Parlar és barat. He escrit dos errors que vaig cometre; podeu comparar-los amb la vostra pròpia experiència per veure si els podeu evitar.

El primer inconvenient: els temes personalitzats de WordPress no es poden previsualitzar en temps real.

Durant un temps, en personalitzar un tema, després de fer clic a Desa, la vista prèvia no s'actualitzava. Feia alguns canvis, actualitzava la pàgina i continuava igual.

Després d'una mica d'investigació, vaig descobrir que la funció de compressió de Minify era la culpable. La solució és senzilla:

Accediu al complement W3 Total Cache常规设置,apareix"compressió"Desmarqueu aquesta opció. A continuació, feu clic a la fletxa petita que hi ha a sota de "Desa la configuració", a la cantonada superior dreta, i seleccioneu "..."Desa la configuració i esborra la memòria cauAquest pas és crucial; si no esborreu la memòria cau, continuareu veient la versió antiga.

Quan hagis acabat, torna a la personalització del tema i la vista prèvia en directe tornarà a la normalitat.

El segon problema: el quadre de cerca del tema Astra no respon quan es fa clic.

Vaig tenir aquest problema fa força temps. Estava utilitzant el tema Astra i, de sobte, vaig descobrir que el quadre de cerca no responia independentment de com hi feia clic. Al principi, vaig pensar que era un problema amb el tema en si, però més tard vaig descobrir que era causat per la configuració de Minify del W3TC.

La solució és la següent:

Aneu a W3 Total Cache → Configuració general → Configuració avançada de compressió → JS → Configuració del motor de minificació → Configuració regional i canvieu el tipus d'incrustació a un d'aquests dos:

1. Anteriorment, la no-bloqueig s'aconseguia mitjançant JavaScript.
2. Després, utilitzeu JS per no bloquejar

De la mateixa manera, esborrar la memòria cau i actualitzar la pàgina permetrà que el quadre de cerca funcioni correctament.

Quant a per què s'han triat aquestes dues opcions en lloc d'altres, he fet una mica de recerca. En poques paraules, els components del front-end del tema Astra són força sensibles al moment d'execució de l'script, i certs mètodes no bloquejants poden fer que l'enllaç d'esdeveniments falli. L'ús del mode "no bloquejant amb JS" garanteix que l'script s'executi només després que la pàgina hagi acabat de carregar, evitant alhora l'execució desordenada que es veu amb l'async.

Llista de llocs per visitar

Finalment, aquí teniu una llista de comprovació que podeu seguir directament:

El primer pas és aclarir el vostre objectiu. Voleu la càrrega inicial de la pàgina més ràpida o prioritzeu l'estabilitat i un funcionament sense errors? Això determinarà quin tipus d'incrustació heu d'utilitzar.

El segon pas és no canviar-ho tot de cop. Primer, busqueu una pàgina menys important per provar-la, observeu-la durant un dia o dos i només la promocioneu a tot el lloc web si esteu segurs que no hi ha cap problema.

En tercer lloc, esborreu sempre la memòria cau després de cada modificació. El mecanisme de memòria cau del W3TC us impedirà veure els darrers canvis, per la qual cosa el pas "esborreu la memòria cau i torneu a provar" és absolutament essencial.

En quart lloc, feu servir les eines de desenvolupament del vostre navegador o eines com PageSpeed ​​​​Insights per comparar la velocitat de càrrega abans i després. Deixeu que les dades parlin per si soles, no només la vostra intuïció.

Escriu al final

Si he de ser sincer, quan vaig veure per primera vegada aquesta configuració de tipus incrustat, em vaig quedar bocabadat durant molta estona. El mode de bloqueig per defecte semblava massa lent, mentre que el mode asíncron no garantia l'ordre, i ajornar-lo podia causar problemes de compatibilitat. No estava segur de quina opció triar.

Però més tard em vaig adonar que és un compromís. No pots tenir el més ràpid i el més estable alhora; sempre has de sacrificar-ne un. La meva experiència és utilitzar primer el defer, que actualment és la solució no bloquejant més segura, i després utilitzar una callback si sorgeixen problemes.

Si trobeu problemes similars o si encara teniu altres problemes després de seguir el meu mètode, no dubteu a parlar-ne. El desenvolupament web es basa en l'assaig i l'error; ningú n'és una excepció.

Gràcies per llegir el meu article. Fins la propera.