W3 Total Cache Minify -laajennuksen asetukset: Kuinka valita upotustyyppi? Vianmäärityskokemukseni ja pelastusneuvoja

Onko sinulla vaikeuksia valita oikea upotustyyppi W3 Total Cache Minifyyn? Tässä artikkelissa jaetaan verkkovastaavan käytännön kokemuksia ja tarjotaan vaiheittainen opas oikean Minify-upotustyypin valitsemiseen tarkasti, välttäen verkkosivuston tyylin epäjohdonmukaisuuksia ja latauskaatumisia. Se sisältää myös virheettömän asennusratkaisun, jota jopa aloittelijat voivat helposti soveltaa.WordPress Kiihdytä törmäämättä!

Optimoin verkkosivustoa ja avattuani Minify-asetukset W3 Total Cachessa olin täysin ällistynyt. Upotetun tyypin alasvetovalikossa oli neljä vaihtoehtoa: Oletusarvo (Estä), Käytä JS:ää ei-estävälle, Käytä "Asynkronista" ei-estävälle ja Käytä "Viivästettyä" ei-estävälle.

Mietin hetken, mistä tässä kaikessa on kyse?

Luota minuun, et ole yksin. Nämä neljä vaihtoehtoa hämmentävät todennäköisesti jopa aloittelijaa, saati sitten jotakuta, joka on käyttänyt WordPressiä vuosia. Tässä artikkelissa esittelen kohtaamani sudenkuopat ja niistä oppimani läksyt suoraan. Sinun ei tarvitse tutustua dokumentaatioon; noudata vain ohjeitani.

Mitä nämä neljä upotustyyppiä tarkalleen ottaen ovat?

Puhutaanpa ensin siitä, millaisia ​​hahmoja nämä neljä vaihtoehtoa ovat.

Oletus (estetty)Tätä kutsutaan oletusarvoiseksi estämiseksi. Se on suoraviivaisin lähestymistapa: selain pysähtyy kohdatessaan komentosarjan, lataa ja suorittaa sen kokonaan ja jatkaa sitten sivun renderöintiä. Kuulostaa luotettavalta, eikö? Mutta kompromissina on, että alkuperäinen sivun lataus estetään; käyttäjien on odotettava komentosarjan suorituksen päättymistä ennen kuin he voivat nähdä mitään.

JS:n käyttö ei-estoonTämä on varsin mielenkiintoista. Sen sijaan, että sivulle kirjoitettaisiin suoraan `<script>`-tageja, se ensin tuottaa pienen komentosarjan ja sitten dynaamisesti injektoi sivulle ladattavat komentosarjat JavaScriptin kautta sivun suorittamisen jälkeen. Tällä tavoin sivu voidaan renderöidä ensin ja komentosarjat voivat latautua vähitellen. Kuulostaa hyvältä, eikö? Ongelmana on kuitenkin se, että tämä dynaaminen injektointiprosessi saattaa häiritä komentosarjojen alkuperäistä suoritusjärjestystä. Jos jotkin sivusi komentosarjat ovat vahvasti riippuvaisia ​​suoritusjärjestyksestä, ongelmia voi ilmetä.

Käytä "asynkronista" ei-estävälleTämä tarkoittaa `async`-attribuutin lisäämistä `<script>`-tagiin. Skripti latautuu asynkronisesti taustalla ja suoritetaan heti latauksen jälkeen ilman, että sivu odottaa sitä. Haittapuolena on kuitenkin se, että suoritusjärjestystä ei voi täysin hallita; se skripti, joka latautuu ensin, suoritetaan ensin riippumatta koodissa määrittämästäsi järjestyksestä.

Viiveen käyttäminen ei-estoonTätä tarkoittaa `defer`-attribuutin lisääminen. Skripti odottaa, kunnes koko sivu on jäsennetty ennen suorittamista, ja mikä tärkeintä, se säilyttää alkuperäisen kirjoitusjärjestyksen. Tämä on varsin käyttäjäystävällistä, koska se ei peitä ensimmäistä näyttöä eikä häiritse järjestystä.

Kumman minun pitäisi valita?

Yksinkertaisesti sanottuna nämä neljä vaihtoehtoa ovat kuin monivalintakysymys:Haluatko nopeutta vai järjestystä?

Ehdotukseni on seuraava:

Jos verkkosivustosi on pieni, siinä on vähän skriptejä, etkä aseta latausnopeudelle erittäin korkeita vaatimuksia, oletusasetuksen (estetty) käyttäminen on helpoin vaihtoehto. Vaikka se on hieman hitaampi, se ei aiheuta ongelmia.

Jos haluat parantaa ensimmäisen näytön nopeutta ja skripteilläsi ei ole vahvoja riippuvuuksia, kuten "A on suoritettava ennen B:tä", priorisoi...Viiveen käyttäminen ei-estoon(lykkää). Tämä on tällä hetkellä lähes ihanteellisin ratkaisu, koska se ei estä renderöintiä eikä häiritse järjestystä.

Jos yrität lykätä ja huomaat silti, että joissakin funktioissa on ongelmia, harkitse...JS:n käyttö ei-estoonTämä ratkaisu on radikaalimpi, mutta sen yhteensopivuus on hieman huonompi.

Käytä "asynkronista" ei-estävälle(async) on vaihtoehto, jota vähiten suosittelen. Koska suoritusjärjestys on täysin sekaisin, ohjelma kaatuu helposti, ellet ole täysin varma, että kaikki skriptisi toimivat itsenäisesti.

Kaksi isoa sudenkuoppaa, joihin sorruin

Puhuminen on halpaa. Olen kirjoittanut muistiin kaksi tekemääni virhettä; voit verrata niitä omiin kokemuksiisi ja nähdä, voitko välttää ne.

Ensimmäinen sudenkuoppa: Mukautettuja WordPress-teemoja ei voi esikatsella reaaliajassa.

Jonkin aikaa teemaa muokatessa esikatselu ei päivittynyt tallennuspainikkeen napsauttamisen jälkeen. Tein joitakin muutoksia, päivitin sivun, ja se oli silti sama.

Tutkittuani asiaa huomasin, että Minifyn pakkausfunktio oli syyllinen. Ratkaisu on yksinkertainen:

Käytä W3 Total Cache -laajennusta常规设置,käänny esiin"puristus"Poista valinta kyseisestä vaihtoehdosta. Napsauta sitten oikeassa yläkulmassa olevaa pientä nuolta "Tallenna asetukset" -kohdan alapuolella ja valitse "..."Tallenna asetukset ja tyhjennä välimuistiTämä vaihe on ratkaisevan tärkeä; jos et tyhjennä välimuistia, näet edelleen vanhan version.

Kun olet valmis, palaa teeman mukauttamiseen, niin live-esikatselu palautuu normaaliksi.

Toinen ongelma: Astra-teeman hakukenttä ei vastaa napsautettaessa.

Kohtasin tämän ongelman jonkin aikaa sitten. Käytin Astra-teemaa, ja eräänä päivänä huomasin yhtäkkiä, että hakukenttä ei vastannut, vaikka kuinka klikkasin sitä. Aluksi luulin, että ongelma johtui itse teemasta, mutta myöhemmin huomasin, että sen aiheuttivat W3TC:n Minify-asetukset.

Ratkaisu on seuraava:

Siirry kohtaan W3 Total Cache → Yleiset asetukset → Lisäasetukset pakkauksessa → JS → Minify Engine -asetukset → Kieliasetukset ja muuta upotustyypiksi jompikumpi näistä kahdesta:

1. Aiemmin estottomuus saavutettiin JavaScriptillä.
2. Käytä sen jälkeen JS:ää estottomana

Samoin välimuistin tyhjentäminen ja sivun päivittäminen mahdollistaa hakukentän oikean toiminnan.

Olen tehnyt jonkin verran tutkimusta siihen, miksi juuri nämä kaksi vaihtoehtoa valittiin. Yksinkertaisesti sanottuna Astra-teeman käyttöliittymäkomponentit ovat melko herkkiä skriptien suorituksen ajoitukselle, ja tietyt estämättömät menetelmät voivat aiheuttaa tapahtumasidonnan epäonnistumisen. "Ei-estävä JS:n kanssa" -tilan käyttäminen varmistaa, että skripti suoritetaan vasta sivun latautumisen jälkeen, välttäen samalla asynkronisen tilan aiheuttaman epäjärjestyneen suorituksen.

Luettelo paikoista, joissa kannattaa vierailla

Lopuksi tässä on tarkistuslista, jota voit seurata suoraan:

Ensimmäinen askel on tavoitteesi selventäminen. Haluatko nopeimman sivun alkulatauksen vai priorisoitko vakautta ja virheetöntä toimintaa? Tämä määrää, mitä upotustyyppiä sinun tulisi käyttää.

Toinen vaihe ei ole muuttaa kaikkea kerralla. Etsi ensin vähemmän tärkeä sivu testattavaksi, tarkkaile sitä päivän tai kaksi ja mainosta se koko sivustolle vain, jos olet varma, ettei ongelmia ole.

Kolmanneksi, tyhjennä välimuisti aina jokaisen muokkauksen jälkeen. W3TC:n välimuistimekanismi estää sinua näkemästä uusimpia muutoksia, joten "tyhjennä välimuisti ja testaa uudelleen" -vaihe on ehdottoman tärkeä.

Neljänneksi, käytä selaimesi kehitystyökaluja tai työkaluja, kuten PageSpeed ​​​​Insightsia, vertaillaksesi latausnopeutta ennen ja jälkeen. Anna datan puhua puolestaan, äläkä vain mutu-tuntumaasi.

Kirjoita lopussa

Rehellisesti sanottuna, kun näin tämän upotetun tyyppiasetuksen ensimmäisen kerran, olin pitkään ällistynyt. Oletusarvoinen estotila tuntui liian hitaalta, kun taas asynkroninen tila ei taannut järjestystä, ja lykkääminen saattoi aiheuttaa yhteensopivuusongelmia. Olin epävarma siitä, minkä vaihtoehdon valitsisin.

Mutta myöhemmin tajusin, että kyse on kompromissista. Ei voi olla sekä nopeinta että vakainta; aina on uhrattava toinen. Kokemukseni mukaan kannattaa ensin käyttää lykkäämistä, joka on tällä hetkellä turvallisin estämätön ratkaisu, ja sitten käyttää takaisinkutsua, jos ongelmia ilmenee.

Jos kohtaat samanlaisia ​​ongelmia tai jos sinulla on edelleen muita ongelmia menetelmääni seurattuasi, keskustele niistä rohkeasti. Verkkosivustojen kehittäminen on ennen kaikkea kokeilua ja erehdystä; kukaan ei ole poikkeus.

Kiitos, että luit artikkelini. Nähdään taas ensi kerralla.