W3 Total Cache Minify pluginaren ezarpenak: Nola aukeratu txertatze mota? Nire arazoak konpontzeko esperientzia eta bizitza salbatzeko aholkuak

Zailtasunak dituzu W3 Total Cache Minify-rako txertatze mota egokia aukeratzeko? Artikulu honek webmaster baten benetako esperientzia partekatzen du eta urratsez urrats gida bat eskaintzen du Minify txertatze mota egokia zehaztasunez hautatzeko, webgunearen estiloko akatsak eta kargatzeko matxurak saihestuz. Gainera, hasiberriek ere erraz aplika dezaketen konfigurazio irtenbide seguru bat ere barne hartzen du, WordPress esperientzia leun eta azkarra bermatuz !

Webgune bat optimizatzen ari nintzen eta W3 Total Cache-n Minify ezarpenak ireki nituenean, guztiz txundituta geratu nintzen. Txertatutako motaren goitibeherako menuan lau aukera zeuden: Lehenetsia (Blokeatua), Erabili JS blokeatzailerik ez izateko, Erabili "Asinkronoa" blokeatzailerik ez izateko eta Erabili "Atzeratua" blokeatzailerik ez izateko.

Une batez pentsatu nuen, zertaz ote da hau guztia?

Sinets iezadazu, ez zaude bakarrik. Lau aukera hauek ziurrenik hasiberri bat ere nahastuta utziko dute, are gutxiago WordPress urteetan erabili duen norbait. Artikulu honek aurkitu ditudan arazoak eta ikasi ditudan lezioak aurkezten dizkizu, zuzenean zuri. Ez duzu dokumentazioa kontsultatu beharrik; jarraitu nire argibideak.

Zeintzuk dira zehazki lau txertatze mota hauek?

Lehenik eta behin, lau aukera hauek zer nolako pertsonaia diren azalduko dugu.

Blokeo lehenetsia da modurik errazena. Nabigatzaileak script bat aurkitzen duenean, gelditu, deskargatu eta erabat exekutatzen du, eta gero orrialdea errendatzen jarraitzen du. Fidagarria dirudi, ezta? Baina alde txarra da hasierako orrialdearen karga atzeratu egingo dela; erabiltzaileek script-a exekutatzen amaitu arte itxaron beharko dute ezer ikusi aurretik.

JavaScript erabiltzea blokeorik gabe erabiltzea nahiko interesgarria da. `<script>` etiketak zuzenean orrialdean idatzi beharrean, lehenik script txiki bat sortzen du, eta gero beharrezko scriptak dinamikoki txertatzen ditu orrialdean JavaScript bidez, orrialdea exekutatzen ari den ondoren. Horrela, orrialdea lehenik errendatu daiteke, eta scriptak pixkanaka kargatzen dira. Oso ondo dirudi, ezta? Hala ere, arazoa da injekzio prozesu dinamiko honek scripten jatorrizko exekuzio ordena eten dezakeela. Zure orrialdeko script batzuk exekuzio ordenan oinarritzen badira neurri handi batean, arazoak sor daitezke.

"Asinkronoa" erabiltzea exekuzio ez-blokeatzailerako `async` atributua `<script>` etiketari gehitzea besterik ez da. Script-a asinkronoki deskargatuko da atzeko planoan eta amaitutakoan berehala exekutatuko da, orrialdeak itxaron gabe. Hala ere, desabantaila da exekuzio-ordena guztiz kontrolaezina dela; deskargatzen den lehenengo edozer gauza exekutatzen da, kodean zehaztutako ordena edozein dela ere.

"Atzerapena" erabiltzea exekuzio ez-blokeatzailerako `defer` atributua gehituz lortzen da. Script-ak orrialde osoa aztertu arte itxarongo du exekutatu aurretik, eta, funtsean, idatzi zenuen jatorrizko ordena mantenduko du. Hau nahiko erabilerraza da, ez baitu lehen pantaila blokeatzen ezta script-aren ordena eteten ere.

Zein aukeratu beharko nuke?

Laburbilduz, lau aukera hauek galdera anitzeko baten antzekoak dira: abiadura nahi duzu ala ordena?

Nire iradokizuna honako hau da:

Zure webgunea txikia bada, script gutxi baditu eta kargatzeko abiadurari dagokionez eskakizun oso altuak ez badituzu, lehenetsitako ezarpena (blokeatua) erabiltzea da aukerarik errazena. Apur bat motelagoa den arren, ez du arazorik sortuko.

Lehenengo pantailako abiadura hobetu nahi baduzu eta zure gidoiek ez badute "A B baino lehen exekutatu behar da" bezalako mendekotasun sendorik, lehentasuna eman "atzeratu" erabiltzeari exekuzio ez-blokeatzailerako . Hau da gaur egun eskuragarri dagoen irtenbide ia aproposa, errendatzea blokeatzea saihesten baitu exekuzio-ordena mantenduz.

Atzerapena probatu ondoren funtzio batzuek arazoak izaten jarraitzen badute, kontuan hartu JavaScript erabiltzea blokeatze-ezintasunerako . Ikuspegi hau oldarkorragoa da, baina bere bateragarritasuna apur bat okerragoa da.

Blokeorik ez izateko "async" erabiltzea da gutxien gomendatzen dudan aukera. Exekuzio-ordena guztiz nahasita dagoenez, erraza da kraskatzea, zure script-ak modu independentean exekutatzen direla guztiz ziur ez bazaude behintzat.

Bi hutsune handitan erori nintzen

Hitz egitea merkea da. Egin ditudan bi akats idatzi ditut; zure esperientziarekin alderatu ditzakezu ea saihestu ditzakezun ikusteko.

Lehenengo tranpa: WordPress gai pertsonalizatuak ezin dira denbora errealean aurreikusi.

Denbora batez, gai bat pertsonalizatzean, gorde botoian klik egin ondoren, aurrebista ez zen freskatzen. Aldaketa batzuk egiten nituen, orria freskatzen nuen, eta berdin jarraitzen zuen.

Ikerketa batzuk egin ondoren, Minify-ren konpresio funtzioa zela erruduna aurkitu nuen. Irtenbidea erraza da:

Joan W3 Total Cache pluginaren ezarpen orokorretara , bilatu "Konpresioa" aukera eta desmarkatu. Ondoren, egin klik goiko eskuineko izkinan dagoen "Gorde ezarpenak" azpiko gezi txikian eta hautatu " Gorde ezarpenak eta garbitu cachea ". Urrats hau ezinbestekoa da; cachea garbitu gabe, bertsio zaharra ikusten jarraituko duzu.

Amaitutakoan, itzuli gaiaren pertsonalizaziora, eta zuzeneko aurrebista normaltasunera itzuliko da.

Bigarren arazoa: Astra gaiaren bilaketa-koadroak ez du erantzuten klik egitean.

Duela denbora dezente arazo hau izan nuen. Astra gaia erabiltzen ari nintzen, eta egun batean bat-batean konturatu nintzen bilaketa-koadroak ez zuela erantzuten, klik egin arren. Hasieran, gaiaren beraren arazoa zela pentsatu nuen, baina geroago W3TC-ren Minify ezarpenek eragiten zutela aurkitu nuen.

Irtenbidea honako hau da:

Joan W3 Total Cache → Ezarpen Orokorrak → Konpresio Ezarpen Aurreratuak → JS → Minify Engine Ezarpenak → Tokiko Ezarpenak atalera, eta aldatu txertatze mota bi hauetako batera:

1. Aurretik, blokeorik ez egitea JavaScript erabiliz lortzen zen.
2. Ondoren, erabili JS blokeatzerik ez izateko

Era berean, cachea garbitu eta orria freskatzeak bilaketa-koadroa behar bezala funtzionatzea ahalbidetuko du.

Zergatik aukeratu diren bi aukera hauek beste batzuen ordez jakiteko, ikerketa batzuk egin ditut. Laburbilduz, Astra gaiaren aurrealdeko osagaiak oso sentikorrak dira script-aren exekuzio-denborarekiko, eta blokeatzen ez duten metodo batzuek gertaeren lotura huts egitea eragin dezakete. "JS-rekin blokeatzen ez dena" modua erabiltzeak ziurtatzen du script-a orrialdea kargatu ondoren bakarrik exekutatuko dela, async-ekin ikusten den exekuzio desordenatua saihestuz.

Bisitatu beharreko lekuen zerrenda

Azkenik, hona hemen zuzenean jarrai dezakezun kontrol-zerrenda bat:

Lehen urratsa zure helburua argitzea da. Hasierako orrialdea azkarren kargatzea nahi duzu, edo egonkortasuna eta akatsik gabeko funtzionamendua lehenesten dituzu? Horrek zehaztuko du zein txertatze mota erabili behar duzun.

Bigarren urratsa ez da dena batera aldatzea. Lehenik eta behin, aurkitu garrantzi gutxiagoko orrialde bat probatzeko, behatu egun bat edo biz, eta sustatu gune osora arazorik ez dagoela ziur bazaude bakarrik.

Hirugarrenik, garbitu beti cachea aldaketa bakoitzaren ondoren. W3TC-ren cache mekanismoak azken aldaketak ikustea eragotziko dizu, beraz, "garbitu cachea eta probatu berriro" urratsa guztiz ezinbestekoa da.

Laugarrenik, erabili zure arakatzailearen garatzaile tresnak edo PageSpeed ​​​​Insights bezalako tresnak kargatzeko abiadura alderatzeko aurretik eta ondoren. Utzi datuek berez hitz egiten, ez zure intuizioak bakarrik.

Idatzi amaieran

Egia esan, txertatutako mota-ezarpen hau lehen aldiz ikusi nuenean, denbora luzez harrituta geratu nintzen. Blokeatzeko modu lehenetsia motelegia iruditzen zitzaidan, modu asinkronoak ez zuen eragiketen ordena bermatzen, eta atzeratzeak bateragarritasun arazoak sor zitzakeen. Zalantzarik gabe nengoen zein aukera aukeratu.

Baina geroago konturatu nintzen truke bat dela. Ezin dituzu azkarrena eta egonkorrena aldi berean izan; beti bat sakrifikatu behar duzu. Nire esperientziak dio lehenik deferr erabiltzea, hau da, gaur egun blokeatzen ez duen irtenbiderik seguruena, eta gero arazoak sortzen badira atzera-dei bat erabiltzea.

Antzeko arazoekin topo egiten baduzu, edo nire metodoa jarraitu ondoren beste arazo batzuk badituzu oraindik, lasai eztabaidatu. Webguneen garapena proba eta akatsen kontua da; inor ez da salbuespena.

Eskerrik asko nire artikulua irakurtzeagatik. Hurrengoan arte.