Innstillinger for W3 Total Cache Minify-plugin: Hvordan velge innebyggingstype? Min feilsøkingserfaring og livreddende råd

Problemer med å velge riktig innebyggingstype for W3 Total Cache Minify? Denne artikkelen deler en webmasters praktiske erfaring og gir en trinnvis veiledning for å velge riktig Minify-innebyggingstype nøyaktig, unngå inkonsekvenser i nettstedsstil og innlastingskrasj. Den inkluderer også en idiotsikker oppsettløsning som selv nybegynnere enkelt kan bruke.WordPress Akselerer uten å krasje!

Jeg optimaliserte et nettsted, og da jeg åpnet Minify-innstillingene i W3 Total Cache, ble jeg fullstendig målløs. Nedtrekksmenyen for den innebygde typen hadde fire alternativer: Standard (blokkering), Bruk JS for ikke-blokkering, Bruk "Asynkron" for ikke-blokkering og Bruk "Forsinket" for ikke-blokkering.

Jeg tenkte over det et øyeblikk, hva handler alt dette om?

Stol på meg, du er ikke alene. Disse fire alternativene vil sannsynligvis forvirre selv en nybegynner, enn si noen som har brukt WordPress i årevis. Denne artikkelen presenterer fallgruvene jeg har støtt på og lærdommene jeg har lært, direkte til deg. Du trenger ikke å konsultere dokumentasjonen; bare følg instruksjonene mine.

Hva er egentlig disse fire innebyggingstypene?

La oss først snakke om hva slags karakter disse fire alternativene er.

Standard (blokk)Dette kalles standardblokkering. Det er den enkleste tilnærmingen: nettleseren stopper når den møter et skript, laster ned og kjører det fullstendig, og fortsetter deretter å gjengi siden. Høres pålitelig ut, ikke sant? Men ulempen er at den første sideinnlastingen din vil bli blokkert; brukerne må vente til skriptet er ferdig med å kjøre før de kan se noe.

Bruk av JS for ikke-blokkeringDette er ganske interessant. I stedet for å skrive `<script>`-tagger direkte på siden, sender den først ut et lite skript, og injiserer deretter dynamisk skriptene som må lastes inn på siden via JavaScript etter at siden kjører. På denne måten kan siden gjengis først, og skriptene kan lastes inn gradvis. Høres bra ut, ikke sant? Problemet er imidlertid at denne dynamiske injeksjonsprosessen kan forstyrre den opprinnelige utførelsesrekkefølgen til skriptene. Hvis noen skript på siden din er sterkt avhengige av utførelsesrekkefølgen, kan det oppstå problemer.

Bruk «asynkron» for ikke-blokkeringDette innebærer å legge til `async`-attributtet til `<script>`-taggen. Skriptet lastes ned asynkront i bakgrunnen og kjøres umiddelbart etter nedlasting, uten at siden venter på det. Ulempen er imidlertid at utførelsesrekkefølgen er fullstendig ukontrollerbar; det skriptet som fullfører nedlastingen først kjøres først, uavhengig av rekkefølgen du spesifiserte i koden.

Bruk av "forsinkelse" for ikke-blokkeringDette er hva det betyr å legge til `defer`-attributtet. Skriptet vil vente til hele siden er analysert før det kjøres, og viktigst av alt, det vil opprettholde den opprinnelige rekkefølgen du skrev det i. Dette er ganske brukervennlig, ettersom det verken blokkerer den første skjermen eller forstyrrer rekkefølgen.

Hvilken bør jeg velge?

Enkelt sagt, disse fire alternativene er som et flervalgsspørsmål:Vil du ha fart eller orden?

Mitt forslag er som følger:

Hvis nettstedet ditt er lite, har få skript, og du ikke har ekstremt høye krav til lastehastighet, er det enkleste alternativet å bruke standardinnstillingen (blokkert). Selv om den er litt tregere, vil den ikke forårsake noen problemer.

Hvis du vil forbedre hastigheten på første skjerm og skriptene dine ikke har sterke avhengigheter som "A må kjøres før B", prioriter ...Bruk av "forsinkelse" for ikke-blokkering(utsette). Dette er nesten den mest ideelle løsningen for øyeblikket, ettersom den verken blokkerer gjengivelsen eller forstyrrer rekkefølgen.

Hvis du prøver utsettelse og fortsatt finner ut at noen funksjoner har problemer, bør du vurdere ...Bruk av JS for ikke-blokkeringDenne løsningen er mer radikal, men kompatibiliteten er litt dårligere.

Bruk «asynkron» for ikke-blokkering(async) er alternativet jeg minst anbefaler. Fordi utførelsesrekkefølgen er fullstendig ødelagt, er det lett å krasje med mindre du er helt sikker på at skriptene dine kjører uavhengig av hverandre.

To store fallgruver jeg falt i

Snakk er billig. Jeg har skrevet ned to feil jeg gjorde; du kan sjekke dem mot din egen erfaring for å se om du kan unngå dem.

Den første fallgruven: Tilpassede WordPress-temaer kan ikke forhåndsvises i sanntid.

En stund, når jeg tilpasset et tema, ville ikke forhåndsvisningen lastes inn på nytt etter å ha klikket på lagre. Jeg gjorde noen endringer, lastet inn siden på nytt, og det var fortsatt det samme.

Etter litt undersøkelser oppdaget jeg at Minifys komprimeringsfunksjon var synderen. Løsningen er enkel:

Få tilgang til W3 Total Cache-pluginen常规设置,skru opp"kompresjon"Fjern merket for det alternativet. Klikk deretter på den lille pilen under «Lagre innstillinger» øverst til høyre og velg «...»Lagre innstillinger og tøm hurtigbufferenDette trinnet er avgjørende. Hvis du ikke tømmer hurtigbufferen, vil du fortsatt se den gamle versjonen.

Når du er ferdig, gå tilbake til tilpasning av temaet, og forhåndsvisningen vil være tilbake til normalen.

Det andre problemet: Astra-temaets søkeboks svarer ikke når du klikker på den.

Jeg opplevde dette problemet for en god stund siden. Jeg brukte Astra-temaet, og en dag oppdaget jeg plutselig at søkeboksen ikke svarte uansett hvordan jeg klikket på den. Først trodde jeg det var et problem med selve temaet, men senere oppdaget jeg at det var forårsaket av W3TCs Minify-innstillinger.

Løsningen er som følger:

Gå til W3 Total Cache → Generelle innstillinger → Avanserte komprimeringsinnstillinger → JS → Minify Engine-innstillinger → Lokale innstillinger, og endre innebyggingstypen til en av disse to:

1. Tidligere ble ikke-blokkering oppnådd ved hjelp av JavaScript.
2. Bruk deretter JS for ikke-blokkering

På samme måte vil det å tømme hurtigbufferen og oppdatere siden gjøre at søkefeltet fungerer som det skal.

Når det gjelder hvorfor disse to alternativene ble valgt i stedet for andre, har jeg gjort litt research. Enkelt sagt er Astra-temaets front-end-komponenter ganske følsomme for tidspunktet for skriptkjøring, og visse ikke-blokkerende metoder kan føre til at hendelsesbinding mislykkes. Bruk av modusen "ikke-blokkerende med JS" sikrer at skriptet bare kjøres etter at siden er ferdig lastet, samtidig som man unngår den uordnede kjøringen som ses med asynkron.

Liste over steder som skal besøkes

Til slutt, her er en sjekkliste du kan følge direkte:

Det første trinnet er å avklare målet ditt. Ønsker du den raskeste innlastingen av siden, eller prioriterer du stabilitet og feilfri drift? Dette vil avgjøre hvilken innebyggingstype du bør bruke.

Det andre trinnet er å ikke endre alt på én gang. Finn først en mindre viktig side å teste, observer den i en dag eller to, og promoter den bare til hele nettstedet hvis du er sikker på at det ikke er noen problemer.

For det tredje, tøm alltid hurtigbufferen etter hver endring. W3TCs hurtigbuffermekanisme vil hindre deg i å se de siste endringene, så trinnet «tøm hurtigbufferen og test på nytt» er helt avgjørende.

For det fjerde, bruk nettleserens utviklerverktøy eller verktøy som PageSpeed ​​Insights for å sammenligne lastehastigheten før og etter. La dataene tale for seg selv, ikke bare magefølelsen din.

Skriv på slutten

For å være ærlig, da jeg først så denne innstillingen for innebygd type, ble jeg lamslått lenge. Standard blokkeringsmodus virket for treg, mens asynkron modus ikke garanterte rekkefølgen på operasjonene, og utsettelse kunne forårsake kompatibilitetsproblemer. Jeg var usikker på hvilket alternativ jeg skulle velge.

Men jeg innså senere at det er en avveining. Du kan ikke ha både den raskeste og den mest stabile; du må alltid ofre den ene. Min erfaring er å bruke defer først, som for øyeblikket er den sikreste ikke-blokkerende løsningen, og deretter bruke en tilbakeringing hvis det oppstår problemer.

Hvis du støter på lignende problemer, eller hvis du fortsatt har andre problemer etter å ha fulgt metoden min, er det bare å diskutere det. Nettstedsutvikling handler om prøving og feiling; ingen er et unntak.

Takk for at du leste artikkelen min. Vi sees neste gang.