Artikola Adresaro
Ĉ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 misfunkciojn kaj ŝarĝajn kraŝojn. Ĝi ankaŭ inkluzivas neerarigeblan agordan solvon, kiun eĉ komencantoj povas facile apliki, certigante glatan kaj rapidan WordPress- sperton!
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ŭlta blokado estas la plej simpla maniero. Kiam la retumilo renkontas skripton, ĝi haltas, elŝutas kaj plene ekzekutas la skripton, kaj poste daŭre bildigas la paĝon. Ŝajnas fidinde, ĉu ne? Sed la malavantaĝo estas, ke via komenca paĝŝarĝo estos prokrastita; uzantoj devos atendi, ke la skripto finu sian funkciadon antaŭ ol ili povos vidi ion ajn.
Uzi JavaScript por ne-blokado estas sufiĉe interesa. Anstataŭ rekte skribi la etikedojn `<script>` sur la paĝon, ĝi unue eligas malgrandan skripton, kaj poste dinamike injektas la necesajn skriptojn en la paĝon per JavaScript post kiam la paĝo funkcias. Tiel, la paĝo povas unue bildiĝi, kaj la skriptoj ŝarĝiĝas iom post iom. Sonas bonege, ĉu ne? Tamen, la problemo estas, ke ĉi tiu dinamika injektoprocezo povas interrompi la originalan plenumordon de la skriptoj. Se iuj skriptoj sur via paĝo forte dependas de la plenumordo, problemoj povas ekesti.
Uzi "asynchronous" por ne-bloka ekzekuto simple implicas aldoni la atributon `async` al la etikedo `<script>`. La skripto elŝutiĝos asinkrone en la fono kaj ekzekutiĝos tuj post kompletigo, sen ke la paĝo atendus ĝin. Tamen, la malavantaĝo estas, ke la ekzekut-ordo estas tute nekontrolebla; kio ajn elŝutiĝas unue ekzekutiĝas, sendepende de la ordo, kiun vi specifas en la kodo.
Uzi "delay" por ne-bloka ekzekuto atingiĝas per aldono de la atributo `defer`. La skripto atendos ĝis la tuta paĝo estos analizita antaŭ ol ekzekutiĝi, kaj grave, ĝi konservos la originalan ordon en kiu vi skribis ĝin. Ĉi tio estas sufiĉe uzanto-amika, ĉar ĝi nek blokas la unuan ekranon nek interrompas la ordon de la skripto.
Kiun mi elektu?
Simple dirite, ĉi tiuj kvar opcioj estas kiel plurelekta demando: ĉu vi volas rapidecon, aŭ ĉu vi volas la 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 de la unua ekrano kaj viaj skriptoj ne havas fortajn dependecojn kiel "A devas ekzekutiĝi antaŭ B", prioritatigu la uzon de "prokrasti" por ne-bloka ekzekuto . Ĉi tio estas preskaŭ la ideala solvo nuntempe havebla, ĉar ĝi evitas blokan bildigon dum ĝi konservas la ordon de ekzekuto.
Se vi trovas, ke iuj funkcioj ankoraŭ havas problemojn post provado de prokrasti, tiam konsideru uzi JavaScript por ne-blokado . Ĉi tiu aliro estas pli agresema, sed ĝia kongrueco estas iomete pli malbona.
Uzi "asynchron" por ne-blokado 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 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:
Iru al la ĝeneralaj agordoj de la kromaĵo W3 Total Cache , trovu la opcion "Kunpremo" kaj malmarku ĝin. Poste, alklaku la malgrandan sagon sub "Konservi Agordojn" en la supra dekstra angulo kaj elektu " Konservi Agordojn kaj Malplenigi Kaŝmemoron ". Ĉi tiu paŝo estas decida; sen malplenigi 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:
- Antaŭe, ne-blokado estis atingita per JavaScript.
- 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.
Mi esperas, ke la artikolo "W3 Total Cache Minify Plugin Settings: How to Choose the Embedding Type? My Pitfalls and Lifesaving Advice" (Agordoj de la kromaĵo W3 Total Cache Minify: Kiel elekti la enkorpigan tipon? Miaj kaptiloj kaj vivsavaj konsiloj) dividita en la blogo de Chen Weiliang ( https://www.chenweiliang.com/ ) estos utila por vi.
Bonvolu kunhavigi la ligilon al ĉi tiu artikolo: https://www.chenweiliang.com/cwl-34003.html