Configuración do plugin W3 Total Cache Minify: como elixir o tipo de incrustación? A miña experiencia na resolución de problemas e consellos para salvar vidas

Tes dificultades para escoller o tipo de incrustación axeitado para W3 Total Cache Minify? Este artigo comparte a experiencia real dun webmaster e ofrece unha guía paso a paso para seleccionar con precisión o tipo de incrustación de Minify correcto, evitando erros de estilo do sitio web e fallos de carga. Tamén inclúe unha solución de configuración infalible que mesmo os principiantes poden aplicar facilmente, garantindo unha experiencia de WordPress fluída e rápida !

Estaba optimizando un sitio web e, cando abrín a configuración de Minify en W3 Total Cache, quedei completamente abraiado. O menú despregable para o tipo incrustado tiña catro opcións: Predeterminado (Bloquear), Usar JS para non bloquear, Usar "Asincrónico" para non bloquear e Usar "Retrasado" para non bloquear.

Penseino un intre, de que vai todo isto?

Créeme, non estás só. Estas catro opcións probablemente deixarán perplexo incluso a un novato, e moito menos a alguén que leva anos usando WordPress. Este artigo presenta os erros cos que me atopei e as leccións que aprendín directamente. Non necesitas consultar a documentación; só tes que seguir as miñas instrucións.

Cales son exactamente estes catro tipos de incrustación?

Falemos primeiro de que tipo de personaxe son estas catro opcións.

O bloqueo predeterminado é o enfoque máis sinxelo. Cando o navegador atopa un script, detense, descárgao e execútao completamente e, a continuación, continúa renderizando a páxina. Parece fiable, non si? Pero a desvantaxe é que a carga inicial da páxina atrasarase; os usuarios terán que esperar a que o script remate de executarse antes de poder ver nada.

Empregar JavaScript para non bloquear é bastante interesante. En lugar de escribir directamente as etiquetas `<script>` na páxina, primeiro xera un pequeno script e, a seguir, inxecta dinamicamente os scripts necesarios na páxina a través de JavaScript despois de que a páxina se execute. Deste xeito, a páxina pode renderizarse primeiro e os scripts poden cargarse gradualmente. Parece xenial, non si? Non obstante, o problema é que este proceso de inxección dinámica pode interromper a orde de execución orixinal dos scripts. Se algúns scripts da túa páxina dependen en gran medida da orde de execución, poden xurdir problemas.

Empregar "asíncrono" para unha execución non bloqueante simplemente implica engadir o atributo `async` á etiqueta `<script>`. O script descargarase de forma asíncrona en segundo plano e executarase inmediatamente ao completarse, sen que a páxina o espere. Non obstante, o inconveniente é que a orde de execución é completamente incontrolable; calquera descarga que se realice primeiro execútase, independentemente da orde que especifiques no código.

O uso de "delay" para a execución non bloqueante conséguese engadindo o atributo `defer`. O script agardará ata que se analize toda a páxina antes de executarse e, fundamentalmente, manterá a orde orixinal na que o escribiches. Isto é bastante doado de usar, xa que non bloquea a primeira pantalla nin interrompe a orde do script.

Cal debería escoller?

Para dicilo sinxelamente, estas catro opcións son coma unha pregunta de resposta múltiple: queres velocidade ou queres a orde?

A miña suxestión é a seguinte:

Se o teu sitio web é pequeno, ten poucos scripts e non tes uns requisitos de velocidade de carga extremadamente altos, usar a configuración predeterminada (bloqueada) é a opción máis sinxela. Aínda que é un pouco máis lenta, non causará ningún problema.

Se queres mellorar a velocidade na primeira pantalla e os teus scripts non teñen dependencias fortes como "A debe executarse antes de B", prioriza o uso de "aprazar" para a execución non bloqueante . Esta é case a solución ideal dispoñible actualmente, xa que evita bloquear a renderización e mantén a orde de execución.

Se algunhas funcións aínda teñen problemas despois de tentar aprazar, considere usar JavaScript para non bloquear . Esta estratexia é máis agresiva, pero a súa compatibilidade é lixeiramente peor.

Empregar "async" para non bloquear é a opción que menos recomendo. Debido a que a orde de execución está completamente desordenada, é doado que se bloquee a menos que esteas absolutamente seguro de que os teus scripts se executan de forma independente.

Dous grandes erros nos que caín

Falar é barato. Anotei dous erros que cometin; podes comparalos coa túa propia experiencia para ver se podes evitalos.

A primeira trampa: os temas personalizados de WordPress non se poden previsualizar en tempo real.

Durante un tempo, ao personalizar un tema, despois de premer en Gardar, a vista previa non se actualizaba. Facía algúns cambios, actualizaba a páxina e seguía igual.

Despois dalgunha investigación, descubrín que a función de compresión de Minify era a culpable. A solución é sinxela:

Vaia á configuración xeral do complemento W3 Total Cache , busque a opción "Compresión" e desmárquea. Despois, faga clic na pequena frecha que está debaixo de "Gardar configuración" na esquina superior dereita e seleccione " Gardar configuración e borrar caché ". Este paso é crucial; sen borrar a caché, seguirá vendo a versión antiga.

Unha vez que remates, volve á personalización do tema e a vista previa en directo volverá á normalidade.

O segundo problema: a caixa de busca do tema Astra non responde ao premer nela.

Atopei este problema hai bastante tempo. Estaba a usar o tema Astra e, de súpeto, decateime de que a caixa de busca non respondía por moito que premese nela. Ao principio, pensei que era un problema co propio tema, pero máis tarde descubrín que estaba causado pola configuración de Minify de W3TC.

A solución é a seguinte:

Vaia a W3 Total Cache → Configuración xeral → Configuración avanzada de compresión → JS → Configuración do motor Minify → Configuración rexional e cambie o tipo de incrustación a un destes dous:

1. Anteriormente, a non bloqueo conseguíase usando JavaScript.
2. Despois, usa JS para non bloquear

Do mesmo xeito, limpar a caché e actualizar a páxina permitirá que a caixa de busca funcione correctamente.

En canto a por que se escolleron estas dúas opcións en lugar doutras, investiguei un pouco. En poucas palabras, os compoñentes front-end do tema Astra son bastante sensibles ao tempo de execución do script e certos métodos non bloqueantes poden provocar que a vinculación de eventos falle. Usar o modo "non bloqueante con JS" garante que o script se execute só despois de que a páxina remate de cargar, evitando ao mesmo tempo a execución desordenada que se observa co modo asíncrono.

Lista de lugares para visitar

Finalmente, aquí tes unha lista de verificación que podes seguir directamente:

O primeiro paso é aclarar o teu obxectivo. Queres a carga inicial da páxina máis rápida ou priorizas a estabilidade e un funcionamento sen erros? Isto determinará que tipo de incrustación debes usar.

O segundo paso é non cambialo todo á vez. Primeiro, busca unha páxina menos importante para probala, obsérvaa durante un día ou dous e só a promociona a todo o sitio se estás seguro de que non hai problemas.

En terceiro lugar, limpa sempre a caché despois de cada modificación. O mecanismo de caché do W3TC evitará que vexas os últimos cambios, polo que o paso "limpa a caché e proba de novo" é absolutamente esencial.

En cuarto lugar, usa as ferramentas de desenvolvemento do teu navegador ou ferramentas como PageSpeed ​​​​Insights para comparar a velocidade de carga antes e despois. Deixa que os datos falen por si mesmos, non só a túa intuición.

Escribe ao final

Para ser sincero, cando vin por primeira vez esta configuración de tipo incrustado, quedei abraiado durante moito tempo. O modo de bloqueo predeterminado parecía demasiado lento, mentres que o modo asíncrono non garantía a orde e o adiamento podía causar problemas de compatibilidade. Non estaba seguro de que opción escoller.

Pero máis tarde decateime de que é unha contrapartida. Non podes ter o máis rápido e o máis estable ao mesmo tempo; sempre tes que sacrificar un. A miña experiencia é usar primeiro defer, que actualmente é a solución sen bloqueos máis segura, e despois usar unha devolución de chamada se xorden problemas.

Se te atopas con problemas semellantes ou se aínda tes outros problemas despois de seguir o meu método, non dubides en falalo. O desenvolvemento web baséase en probas e erros; ninguén é unha excepción.

Grazas por ler o meu artigo. Ata a próxima.