Agordoj de la kromprogramo W3 Total Cache Minify: Kiel elekti la enkorpigan tipon? Mia sperto pri problemsolvado kaj vivsavaj konsiloj

Ĉu vi malfacile elektas la ĝustan enkorpigan tipon por W3 Total Cache Minify? Ĉi tiu artikolo dividas la realmondan sperton de retejestro kaj provizas paŝon post paŝa gvidilo por precize elekti la ĝustan Minify-enkorpigan tipon, evitante retejajn stilajn malkonsekvencojn kaj ŝarĝajn kraŝojn. Ĝi ankaŭ inkluzivas neerarigeblan agordan solvon, kiun eĉ komencantoj povas facile apliki.WordPress Akcelu sen kraŝi!

Mi optimumigis retejon kaj kiam mi malfermis la agordojn de Minify en W3 Total Cache, mi estis tute ŝokita. La falmenuo por la enigita tipo havis kvar opciojn: Defaŭlta (Bloka), Uzi JS por Ne-Bloka, Uzi "Asinkrona" por Ne-Bloka, kaj Uzi "Malfrua" por Ne-Bloka.

Mi pripensis ĝin momenton, pri kio temas ĉio ĉi?

Kredu min, vi ne estas sola. Ĉi tiuj kvar ebloj verŝajne lasos eĉ novulon konfuzita, des malpli iun, kiu uzas WordPress dum jaroj. Ĉi tiu artikolo prezentas la kaptilojn, kiujn mi renkontis, kaj la lecionojn, kiujn mi lernis, rekte al vi. Vi ne bezonas konsulti la dokumentaron; nur sekvu miajn instrukciojn.

Kio precize estas ĉi tiuj kvar enkorpigaj tipoj?

Ni unue parolu pri kia karaktero estas ĉi tiuj kvar opcioj.

Defaŭlto (bloko)Ĉi tio nomiĝas Defaŭlta blokado. Ĝi estas la plej simpla aliro: la retumilo haltas kiam ĝi renkontas skripton, elŝutas kaj efektivigas ĝin tute, kaj poste daŭre bildigas la paĝon. Ŝajnas fidinde, ĉu ne? Sed la kompromiso estas, ke via komenca paĝŝarĝo estos blokita; uzantoj devos atendi ĝis la skripto finiĝos antaŭ ol ili povos vidi ion ajn.

Uzante JS por ne-blokadoĈi tio estas sufiĉe interesa. Anstataŭ rekte skribi etikedojn `<script>` sur la paĝon, ĝi unue eligas malgrandan skripton, kaj poste dinamike injektas la skriptojn, kiuj bezonas esti ŝarĝitaj en la paĝon per JavaScript post kiam la paĝo funkcias. Tiel, la paĝo povas esti unue bildigita, kaj la skriptoj povas ŝarĝiĝi iom post iom. Sonas bonege, ĉu ne? Tamen, la problemo estas, ke ĉi tiu dinamika injektoprocezo povus interrompi la originalan plenumordon de la skriptoj. Se iuj skriptoj sur via paĝo forte dependas de la plenumordo, problemoj povas ekesti.

Uzu "nesinkronan" por ne-blokadoTio implicas aldoni la atributon `async` al la etikedo `<script>`. La skripto elŝutiĝos nesinkrone en la fono kaj efektiviĝos tuj post la elŝuto, sen ke la paĝo atendu ĝin. Tamen, la malavantaĝo estas, ke la ekzekut-ordo estas tute nekontrolebla; kiu ajn skripto unue finas elŝuti, efektiviĝas unue, sendepende de la ordo, kiun vi specifis en la kodo.

Uzante "prokraston" por ne-blokadoJen kion signifas aldoni la atributon `defer`. La skripto atendos ĝis la tuta paĝo estos analizita antaŭ ol ĝi estos ekzekutita, kaj grave, ĝi konservos la originalan ordon, kiun vi skribis. Ĉi tio estas sufiĉe uzanto-amika, ĉar ĝi nek blokas la unuan ekranon nek interrompas la ordon.

Kiun mi elektu?

Simple dirite, ĉi tiuj kvar opcioj estas kiel plurelekta demando:Ĉu vi volas rapidecon aŭ ordon?

Mia sugesto estas jena:

Se via retejo estas malgranda, havas malmultajn skriptojn, kaj vi ne havas ekstreme altajn postulojn pri ŝarĝrapido, uzi la defaŭltan (blokitan) agordon estas la plej facila opcio. Kvankam ĝi estas iom pli malrapida, ĝi ne kaŭzos problemojn.

Se vi volas plibonigi la rapidecon sur la unua ekrano kaj viaj skriptoj ne havas fortajn dependecojn kiel "A devas ekzekutiĝi antaŭ B", prioritatigu...Uzante "prokraston" por ne-blokado(prokrasti). Ĉi tio estas preskaŭ la plej ideala solvo nuntempe, ĉar ĝi nek blokas la bildigon nek interrompas la ordon.

Se vi provas "prokrasti" kaj ankoraŭ trovas, ke iuj funkcioj havas problemojn, tiam konsideru...Uzante JS por ne-blokadoĈi tiu solvo estas pli radikala, sed ĝia kongrueco estas iomete pli malbona.

Uzu "nesinkronan" por ne-blokado(asynchron) estas la opcio, kiun mi malplej rekomendas. Ĉar la ekzekut-ordo estas tute fuŝita, estas facile kraŝi krom se vi estas absolute certa, ke viaj skriptoj ĉiuj funkcias sendepende.

Du grandajn kaptilojn, en kiujn mi falis

Babilado estas malmultekosta. Mi skribis du erarojn, kiujn mi faris; vi povas kompari ilin kun via propra sperto por vidi, ĉu vi povas eviti ilin.

La unua kaptilo: Propraj WordPress-temoj ne povas esti antaŭrigardataj en reala tempo.

Dum kelka tempo, agordante temon, post alklako de konservi, la antaŭrigardo ne refreŝiĝis. Mi faris kelkajn ŝanĝojn, refreŝigis la paĝon, kaj ĝi restis sama.

Post iom da esplorado, mi malkovris, ke la kunprema funkcio de Minify estis la kulpulo. La solvo estas simpla:

Aliru la kromprogramon W3 Total Cache常规设置,aperu"kunpremo"Malmarku tiun opcion. Poste alklaku la malgrandan sagon sub "Konservi Agordojn" en la supra dekstra angulo kaj elektu "..."Konservi agordojn kaj malplenigi la kaŝmemoronĈi tiu paŝo estas decida; se vi ne malplenigas la kaŝmemoron, vi ankoraŭ vidos la malnovan version.

Post kiam vi finos, revenu al tema personigo, kaj la antaŭrigardo denove estos normala.

La dua problemo: La serĉkesto de la temo Astra ne respondas kiam oni alklakas ĝin.

Mi renkontis ĉi tiun problemon antaŭ iom da tempo. Mi uzis la temon Astra, kaj unu tagon mi subite trovis, ke la serĉkesto ne respondis, kiom ajn mi alklakis ĝin. Komence, mi pensis, ke temas pri problemo kun la temo mem, sed poste mi malkovris, ke ĝin kaŭzis la agordoj Minify de W3TC.

La solvo estas jena:

Iru al W3 Total Cache → Ĝeneralaj Agordoj → Altnivelaj Kunpremaj Agordoj → JS → Minify Engine Agordoj → Lokaj Agordoj, kaj ŝanĝu la enkorpigan tipon al unu el ĉi tiuj du:

1. Antaŭe, ne-blokado estis atingita per JavaScript.
2. Poste, uzu JS por ne-blokado

Simile, malplenigi la kaŝmemoron kaj refreŝigi la paĝon permesos al la serĉkesto funkcii ĝuste.

Pri kial ĉi tiuj du opcioj estis elektitaj anstataŭ aliaj, mi faris iom da esplorado. Simple dirite, la front-end-komponantoj de la Astra temo estas tre sentemaj al la tempigo de skripta ekzekuto, kaj certaj ne-blokaj metodoj povas kaŭzi malsukceson de okazaĵa ligado. Uzi la reĝimon "ne-bloka per JS" certigas, ke la skripto ekzekutas nur post kiam la paĝo finŝarĝiĝis, evitante la malordan ekzekuton vidatan kun asinkrona.

Listo de vizitotaj lokoj

Fine, jen kontrollisto, kiun vi povas rekte sekvi:

La unua paŝo estas klarigi vian celon. Ĉu vi volas la plej rapidan komencan paĝŝarĝon, aŭ ĉu vi prioritatigas stabilecon kaj seneraran funkciadon? Tio determinos, kiun enkorpigan tipon vi devus uzi.

La dua paŝo estas ne ŝanĝi ĉion samtempe. Unue, trovu malpli gravan paĝon por testi ĝin, observu ĝin dum tago aŭ du, kaj nur reklamu ĝin al la tuta retejo se vi certas, ke ne estas problemoj.

Trie, ĉiam malplenigu la kaŝmemoron post ĉiu modifo. La kaŝmemora mekanismo de W3TC malhelpos vin vidi la plej novajn ŝanĝojn, do la paŝo "malplenigu la kaŝmemoron kaj testu denove" estas absolute esenca.

Kvare, uzu la programistajn ilojn de via retumilo aŭ ilojn kiel PageSpeed ​​​​Insights por kompari la ŝarĝrapidon antaŭ kaj post. Lasu la datumojn paroli por si mem, ne nur vian intuicion.

Skribu ĉe la fino

Verdire, kiam mi unue vidis ĉi tiun agordon de enigita tipo, mi longe restis ŝokita. La defaŭlta blokreĝimo ŝajnis tro malrapida, dum nesinkrona reĝimo ne garantiis la ordon de operacioj, kaj prokrasto povus kaŭzi kongruecajn problemojn. Mi ne estis certa pri kiu opcio elekti.

Sed mi poste komprenis, ke temas pri kompromiso. Oni ne povas havi kaj la plej rapidan kaj la plej stabilan; oni ĉiam devas oferi unu el ili. Mia sperto estas uzi unue "default", kiu nuntempe estas la plej sekura ne-bloka solvo, kaj poste uzi "callback" se problemoj ekestas.

Se vi renkontas similajn problemojn, aŭ se vi ankoraŭ havas aliajn problemojn post sekvado de mia metodo, bonvolu diskuti ĝin. Reteja disvolviĝo temas pri provoj kaj eraroj; neniu estas escepto.

Dankon pro legado de mia artikolo. Ĝis revido.