Setările pluginului W3 Total Cache Minify: Cum se alege tipul de încorporare? Experiența mea de depanare și sfaturile care salvează vieți

Întâmpinați dificultăți în alegerea tipului de embedding potrivit pentru W3 Total Cache Minify? Acest articol prezintă experiența unui webmaster din lumea reală și oferă un ghid pas cu pas pentru a selecta cu precizie tipul de embedding Minify potrivit, evitând erorile de stil ale site-ului web și blocările de încărcare. De asemenea, include o soluție de configurare sigură pe care chiar și începătorii o pot aplica cu ușurință, asigurând o experiență WordPress rapidă și fără probleme !

Optimizam un site web și când am deschis setările Minify în W3 Total Cache, am fost complet uluit. Meniul derulant pentru tipul încorporat avea patru opțiuni: Default (Block), Use JS for Non-Blocking, Use „Asynchronous” for Non-Blocking și Use „Delayed” for Non-Blocking.

M-am gândit o clipă, despre ce e vorba în toată treaba asta?

Crede-mă, nu ești singurul. Aceste patru opțiuni vor lăsa probabil nedumerit chiar și un novice, darămite pe cineva care folosește WordPress de ani de zile. Acest articol prezintă direct către tine capcanele pe care le-am întâlnit și lecțiile pe care le-am învățat. Nu trebuie să consulți documentația; urmează doar instrucțiunile mele.

Care sunt mai exact aceste patru tipuri de încorporare?

Să vorbim mai întâi despre ce fel de personaj sunt aceste patru opțiuni.

Blocarea implicită este cea mai simplă abordare. Când browserul întâlnește un script, acesta se oprește, descarcă și execută scriptul complet, apoi continuă redarea paginii. Sună fiabil, nu? Dar compromisul este că încărcarea inițială a paginii va fi întârziată; utilizatorii vor trebui să aștepte ca scriptul să se termine înainte de a putea vedea ceva.

Utilizarea JavaScript pentru non-blocare este destul de interesantă. În loc să scrie direct etichete `<script>` pe pagină, mai întâi se generează un mic script, apoi se injectează dinamic scripturile necesare în pagină prin JavaScript după ce pagina rulează. În acest fel, pagina se poate randa mai întâi, iar scripturile se încarcă treptat. Sună grozav, nu? Cu toate acestea, problema este că acest proces dinamic de injectare poate perturba ordinea de execuție originală a scripturilor. Dacă unele scripturi de pe pagina dvs. se bazează foarte mult pe ordinea de execuție, pot apărea probleme.

Utilizarea atributului „asincron” pentru execuție neblocantă implică pur și simplu adăugarea atributului `async` la eticheta `<script>`. Scriptul se va descărca asincron în fundal și se va executa imediat după finalizare, fără ca pagina să îl aștepte. Cu toate acestea, dezavantajul este că ordinea de execuție este complet incontrolabilă; orice descărcare se execută prima, indiferent de ordinea specificată în cod.

Utilizarea atributului „delay” pentru execuția fără blocare se realizează prin adăugarea atributului `defer`. Scriptul va aștepta până când întreaga pagină a fost analizată înainte de a se executa și, în mod crucial, va menține ordinea originală în care l-ați scris. Acest lucru este destul de ușor de utilizat, deoarece nu blochează primul ecran și nici nu perturbă ordinea scriptului.

Pe care ar trebui să-l aleg?

Simplu spus, aceste patru opțiuni sunt ca o întrebare cu variante multiple de răspuns: vrei viteză sau vrei ordine?

Sugestia mea este următoarea:

Dacă site-ul dvs. web este mic, are puține scripturi și nu aveți cerințe extrem de mari pentru viteza de încărcare, utilizarea setării implicite (blocate) este cea mai ușoară opțiune. Deși este puțin mai lentă, nu va cauza probleme.

Dacă vrei să îmbunătățești viteza de redare pe primul ecran și scripturile tale nu au dependențe puternice precum „A trebuie să se execute înainte de B”, prioritizează utilizarea opțiunii „defer” pentru execuția fără blocare . Aceasta este aproape soluția ideală disponibilă în prezent, deoarece evită blocarea redării, menținând în același timp ordinea de execuție.

Dacă observați că unele funcții încă au probleme după ce încercați defer, luați în considerare utilizarea JavaScript pentru non-blocking . Această abordare este mai agresivă, dar compatibilitatea sa este puțin mai slabă.

Utilizarea opțiunii „async” pentru non-blocare este opțiunea pe care o recomand cel mai puțin. Deoarece ordinea de execuție este complet greșită, este ușor să se blocheze, cu excepția cazului în care ești absolut sigur că scripturile tale rulează independent.

Două mari capcane în care am căzut

Vorba e ieftină. Am notat două greșeli pe care le-am făcut; le poți verifica cu propria experiență ca să vezi dacă le poți evita.

Prima capcană: Temele WordPress personalizate nu pot fi previzualizate în timp real.

O vreme, când personalizam o temă, după ce apăsam butonul de salvare, previzualizarea nu se reîmprospăta. Făceam niște modificări, reîmprospătam pagina și tot era la fel.

După niște investigații, am descoperit că funcția de compresie a Minify era vinovată. Soluția este simplă:

Accesați setările generale ale pluginului W3 Total Cache , găsiți opțiunea „Compresie” și debifați-o. Apoi, faceți clic pe săgeata mică de sub „Salvare setări” în colțul din dreapta sus și selectați „ Salvare setări și ștergere memorie cache ”. Acest pas este crucial; fără a șterge memoria cache, veți vedea în continuare versiunea veche.

După ce ați terminat, reveniți la personalizarea temei, iar previzualizarea live va reveni la normal.

A doua problemă: Caseta de căutare a temei Astra nu răspunde când se dă clic pe ea.

Am întâmpinat această problemă acum ceva timp. Foloseam tema Astra și într-o zi am descoperit brusc că caseta de căutare nu răspundea indiferent cum apăsam pe ea. La început, am crezut că este o problemă cu tema în sine, dar mai târziu am descoperit că era cauzată de setările Minify ale W3TC.

Soluția este următoarea:

Accesați W3 Total Cache → Setări generale → Setări avansate de compresie → JS → Setări motor Minify → Setări regionale și schimbați tipul de încorporare la unul dintre aceste două:

1. Anterior, neblocarea se realiza folosind JavaScript.
2. După aceea, folosește JS pentru non-blocare

În mod similar, golirea memoriei cache și actualizarea paginii vor permite casetei de căutare să funcționeze corect.

Cât despre motivul pentru care au fost alese aceste două opțiuni în loc de altele, am făcut niște cercetări. Simplu spus, componentele front-end ale temei Astra sunt destul de sensibile la momentul execuției scriptului, iar anumite metode non-blocante pot cauza eșecul legării evenimentelor. Utilizarea modului „non-blocking with JS” asigură executarea scriptului numai după ce pagina s-a terminat de încărcat, evitând în același timp execuția dezordonată observată cu async.

Lista locurilor de vizitat

În final, iată o listă de verificare pe care o puteți urma direct:

Primul pas este să vă clarificați obiectivul. Doriți cea mai rapidă încărcare inițială a paginii sau prioritizați stabilitatea și funcționarea fără erori? Acest lucru va determina ce tip de încorporare ar trebui să utilizați.

Al doilea pas este să nu schimbi totul dintr-o dată. Mai întâi, găsește o pagină mai puțin importantă pentru a o testa, observ-o timp de o zi sau două și promov-o pe întregul site doar dacă ești sigur că nu există probleme.

În al treilea rând, goliți întotdeauna memoria cache după fiecare modificare. Mecanismul de cache al W3TC vă va împiedica să vedeți cele mai recente modificări, așa că pasul „goliți memoria cache și testați din nou” este absolut esențial.

În al patrulea rând, folosește instrumentele de dezvoltare ale browserului tău sau instrumente precum PageSpeed ​​​​Insights pentru a compara viteza de încărcare înainte și după. Lasă datele să vorbească de la sine, nu doar intuiția ta.

写在最后

Ca să fiu sincer, când am văzut prima dată această setare de tip încorporat, am fost uimit mult timp. Modul implicit de blocare părea prea lent, în timp ce modul asincron nu garanta ordinea operațiunilor, iar amânarea putea cauza probleme de compatibilitate. Nu eram sigur ce opțiune să aleg.

Dar mi-am dat seama mai târziu că este un compromis. Nu poți avea ambele opțiuni: cea mai rapidă și cea mai stabilă; trebuie întotdeauna să sacrifici una dintre ele. Din experiența mea, trebuie să folosești mai întâi defer, care este în prezent cea mai sigură soluție non-blocantă, și apoi să folosești un callback dacă apar probleme.

Dacă întâmpinați probleme similare sau dacă aveți în continuare alte probleme după ce ați urmat metoda mea, nu ezitați să discutați despre asta. Dezvoltarea de site-uri web se bazează pe încercări și erori; nimeni nu face excepție.

Mulțumesc că ai citit articolul meu. Pe data viitoare.