Artikkelihakemisto
Onko sinulla vaikeuksia valita oikea upotustyyppi W3 Total Cache Minifyyn? Tässä artikkelissa jaetaan web-vastaavan käytännön kokemuksia ja tarjotaan vaiheittainen opas oikean Minify-upotustyypin valitsemiseen tarkasti, välttäen verkkosivuston tyyliongelmia ja latauskaatumisia. Se sisältää myös virheettömän asennusratkaisun, jota jopa aloittelijat voivat helposti soveltaa, mikä varmistaa sujuvan ja nopean WordPress- kokemuksen!
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.
Oletusarvoinen esto on suoraviivaisin lähestymistapa. Kun selain kohtaa komentosarjan, se pysähtyy, lataa ja suorittaa sen kokonaan ja jatkaa sitten sivun renderöintiä. Kuulostaa luotettavalta, eikö? Mutta kompromissina on, että sivun alkuperäinen lataus viivästyy; käyttäjien on odotettava komentosarjan suorituksen päättymistä ennen kuin he näkevät mitään.
JavaScriptin käyttö ei-esto-ominaisuuksien saavuttamiseksi on varsin mielenkiintoista. Sen sijaan, että sivulle kirjoitettaisiin suoraan `<script>`-tageja, se ensin tuottaa pienen komentosarjan ja sitten dynaamisesti lisää tarvittavat komentosarjat sivulle JavaScriptin kautta sivun suorittamisen jälkeen. Tällä tavoin sivu voi renderöidä ensin ja komentosarjat latautuvat vähitellen. Kuulostaa hyvältä, eikö? Ongelmana on kuitenkin se, että tämä dynaaminen injektointiprosessi voi häiritä komentosarjojen alkuperäistä suoritusjärjestystä. Jos jotkin sivusi komentosarjat ovat vahvasti riippuvaisia suoritusjärjestyksestä, ongelmia voi ilmetä.
"Asynkronisen" suorittamisen käyttäminen ei-estävään suoritukseen tarkoittaa yksinkertaisesti `async`-attribuutin lisäämistä `<script>`-tagiin. Skripti latautuu asynkronisesti taustalla ja suoritetaan välittömästi valmistuttuaan ilman, että sivun tarvitsee odottaa sitä. Haittapuolena on kuitenkin se, että suoritusjärjestystä ei voi hallita; ensin latautuneet tiedostot suoritetaan riippumatta koodissa määrittämästäsi järjestyksestä.
"Delay"-attribuutin käyttäminen estämättömässä suorituksessa saavutetaan lisäämällä `defer`-attribuutti. 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 estä ensimmäistä näyttöä eikä häiritse skriptin 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 "defer"-ominaisuutta estämättömään suoritukseen . Tämä on lähes ihanteellinen tällä hetkellä saatavilla oleva ratkaisu, koska se välttää renderöinnin estämisen säilyttäen samalla suoritusjärjestyksen.
Jos huomaat, että joillakin funktioilla on edelleen ongelmia lykkäämisen kokeilemisen jälkeen, harkitse JavaScriptin käyttöä estämättömänä . Tämä lähestymistapa on aggressiivisempi, mutta sen yhteensopivuus on hieman huonompi.
"Async"-ominaisuuden käyttäminen estottoman toiminnan yhteydessä on vähiten suosittelemani vaihtoehto. Koska suoritusjärjestys on täysin sekaisin, ohjelma kaatuu helposti, ellet ole täysin varma, että 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:
Siirry W3 Total Cache -laajennuksen yleisiin asetuksiin , etsi "Pakkaus" -vaihtoehto ja poista sen valinta. Napsauta sitten pientä nuolta "Tallenna asetukset" -kohdan alapuolella oikeassa yläkulmassa ja valitse " Tallenna asetukset ja tyhjennä välimuisti ". Tämä vaihe on ratkaisevan tärkeä; tyhjentämättä 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:
- Aiemmin estottomuus saavutettiin JavaScriptillä.
- 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.
Toivon, että Chen Weiliangin blogissa ( https://www.chenweiliang.com/ ) jaetusta artikkelista "W3 Total Cache Minify -laajennuksen asetukset: Kuinka valita upotustyyppi? Ongelmani ja pelastusneuvojani" on sinulle hyötyä.
Voit vapaasti jakaa tämän artikkelin linkin: https://www.chenweiliang.com/cwl-34003.html