W3 Total Cache Minify Plugin-instellings: Hoe om die inbeddingtipe te kies? My probleemoplossingservaring en lewensreddende advies

Sukkel jy om die regte inbeddingtipe vir W3 Total Cache Minify te kies? Hierdie artikel deel 'n webmeester se werklike ervaring en bied 'n stap-vir-stap gids om die regte Minify-inbeddingtipe akkuraat te kies, wat webwerfstyl-ongelukke en laai-ineenstortings vermy. Dit sluit ook 'n onfeilbare opsteloplossing in wat selfs beginners maklik kan toepas.WordPress Versnel sonder om te crash!

Ek was besig om 'n webwerf te optimaliseer en toe ek die Minify-instellings in W3 Total Cache oopmaak, was ek heeltemal verstom. Die aftreklys vir die ingebedde tipe het vier opsies gehad: Standaard (Blokkeer), Gebruik JS vir Nie-Blokkeer, Gebruik "Asynchroon" vir Nie-Blokkeer, en Gebruik "Vertraag" vir Nie-Blokkeer.

Ek het 'n oomblik daaroor gedink, waaroor gaan dit alles?

Glo my, jy is nie alleen nie. Hierdie vier opsies sal waarskynlik selfs 'n beginner verward laat, wat nog te sê iemand wat WordPress al jare lank gebruik. Hierdie artikel bied die slaggate wat ek teëgekom het en die lesse wat ek direk geleer het. Jy hoef nie die dokumentasie te raadpleeg nie; volg net my instruksies.

Wat presies is hierdie vier inbeddingstipes?

Kom ons praat eers oor watter soort karakter hierdie vier opsies is.

Standaard (Geblokkeer)Dit word Standaardblokkering genoem. Dis die eenvoudigste benadering: die blaaier stop wanneer dit 'n skrip teëkom, laai dit af en voer dit volledig uit, en gaan dan voort om die bladsy te lewer. Klink betroubaar, reg? Maar die kompromie is dat jou aanvanklike bladsylaai geblokkeer sal word; gebruikers sal moet wag totdat die skrip klaar loop voordat hulle enigiets kan sien.

Gebruik JS vir nie-blokkeringDit is nogal interessant. In plaas daarvan om `<script>`-etikette direk op die bladsy te skryf, gee dit eers 'n klein skrip uit, en spuit dan die skrifte wat gelaai moet word dinamies via JavaScript in die bladsy in nadat die bladsy loop. Op hierdie manier kan die bladsy eers weergegee word, en die skrifte kan geleidelik laai. Klink goed, reg? Die probleem is egter dat hierdie dinamiese inspuitproses die oorspronklike uitvoeringsvolgorde van die skrifte kan ontwrig. As sommige skrifte op jou bladsy sterk op die uitvoeringsvolgorde staatmaak, kan probleme ontstaan.

Gebruik "asynchrone" vir nie-blokkeringDit behels die byvoeging van die `async`-attribuut by die `<script>`-etiket. Die skrip sal asynchroon in die agtergrond aflaai en onmiddellik na aflaai uitgevoer word, sonder dat die bladsy daarvoor wag. Die nadeel is egter dat die uitvoeringsvolgorde heeltemal onbeheerbaar is; watter skrip ook al eerste klaar aflaai, word eerste uitgevoer, ongeag die volgorde wat jy in die kode gespesifiseer het.

Gebruik "vertraging" vir nie-blokkeringDit is wat die byvoeging van die `defer`-attribuut beteken. Die skrip sal wag totdat die hele bladsy ontleed is voordat dit uitgevoer word, en belangrik, dit sal die oorspronklike volgorde waarin jy dit geskryf het, handhaaf. Dit is redelik gebruikersvriendelik, aangesien dit nie die eerste skerm blokkeer of die volgorde ontwrig nie.

Watter een moet ek kies?

Eenvoudig gestel, hierdie vier opsies is soos 'n meervoudigekeusevraag:Wil jy spoed of orde hê?

My voorstel is soos volg:

As jou webwerf klein is, min skrifte het, en jy nie uiters hoë vereistes vir laaispoed het nie, is die gebruik van die verstek (geblokkeerde) instelling die maklikste opsie. Alhoewel dit 'n bietjie stadiger is, sal dit geen probleme veroorsaak nie.

As jy die spoed van die eerste skerm wil verbeter en jou skrifte nie sterk afhanklikhede soos "A moet voor B uitgevoer word" het nie, prioritiseer...Gebruik "vertraging" vir nie-blokkering(uitstel). Dit is tans amper die mees ideale oplossing, aangesien dit nie die lewering blokkeer of die volgorde ontwrig nie.

As jy probeer om uit te stel en steeds vind dat sommige funksies probleme ondervind, oorweeg dit dan...Gebruik JS vir nie-blokkeringHierdie oplossing is meer radikaal, maar die versoenbaarheid daarvan is effens erger.

Gebruik "asynchrone" vir nie-blokkering(async) is die opsie wat ek die minste aanbeveel. Omdat die uitvoeringsvolgorde heeltemal deurmekaar is, is dit maklik om te crash tensy jy absoluut seker is dat jou skripte almal onafhanklik loop.

Twee groot slaggate waarin ek geval het

Praat is goedkoop. Ek het twee foute neergeskryf wat ek gemaak het; jy kan dit teen jou eie ervaring vergelyk om te sien of jy dit kan vermy.

Die eerste valkuil: Pasgemaakte WordPress-temas kan nie intyds voorbeskou word nie.

Vir 'n rukkie, wanneer ek 'n tema aangepas het, wou die voorskou nie verfris nadat ek op stoor geklik het nie. Ek sou 'n paar veranderinge maak, die bladsy verfris, en dit sou steeds dieselfde wees.

Na 'n bietjie ondersoek het ek ontdek dat Minify se kompressiefunksie die oorsaak was. Die oplossing is eenvoudig:

Kry toegang tot die W3 Total Cache-inprop常规设置,opdaag"kompressie"Ontmerk daardie opsie. Klik dan op die klein pyltjie onder "Stoor instellings" in die regter boonste hoek en kies "...".Stoor instellings en maak kas skoonHierdie stap is van kritieke belang; as jy nie die kasgeheue skoonmaak nie, sal jy steeds die ou weergawe sien.

Nadat jy klaar is, gaan terug na tema-aanpassing, en die regstreekse voorskou sal weer normaal wees.

Die tweede probleem: Die Astra-tema-soekkassie reageer nie wanneer daarop geklik word nie.

Ek het hierdie probleem 'n geruime tyd gelede teëgekom. Ek het die Astra-tema gebruik, en eendag het ek skielik gevind dat die soekkassie nie reageer nie, maak nie saak hoe ek daarop klik nie. Aanvanklik het ek gedink dit was 'n probleem met die tema self, maar later het ek ontdek dat dit veroorsaak is deur W3TC se Minify-instellings.

Die oplossing is soos volg:

Gaan na W3 Total Cache → Algemene instellings → Gevorderde kompressie-instellings → JS → Minify Engine Settings → Locale Settings, en verander die inbeddingtipe na een van hierdie twee:

1. Voorheen is nie-blokkering bereik met behulp van JavaScript.
2. Gebruik daarna JS vir nie-blokkering

Net so sal die soekkassie behoorlik werk as jy die kasgeheue skoonmaak en die bladsy verfris.

Wat betref hoekom hierdie twee opsies gekies is in plaas van ander, het ek 'n bietjie navorsing gedoen. Eenvoudig gestel, die Astra-tema se voorste komponente is nogal sensitief vir die tydsberekening van skripuitvoering, en sekere nie-blokkerende metodes kan veroorsaak dat gebeurtenisbinding misluk. Deur die "nie-blokkerende met JS"-modus te gebruik, word verseker dat die skrip eers uitgevoer word nadat die bladsy klaar gelaai het, terwyl die wanordelike uitvoering wat met asinkronisasie gesien word, vermy word.

Lys van plekke om te besoek

Laastens, hier is 'n kontrolelys wat jy direk kan volg:

Die eerste stap is om jou doelwit te verduidelik. Wil jy die vinnigste aanvanklike bladsylaai hê, of prioritiseer jy stabiliteit en foutvrye werking? Dit sal bepaal watter inbeddingtipe jy moet gebruik.

Die tweede stap is om nie alles op een slag te verander nie. Vind eers 'n minder belangrike bladsy om dit te toets, observeer dit vir 'n dag of twee, en bevorder dit slegs na die hele webwerf as jy seker is dat daar geen probleme is nie.

Derdens, maak altyd die kas skoon na elke wysiging. W3TC se kasmeganisme sal verhoed dat jy die nuutste veranderinge sien, daarom is die "maak kas skoon en toets weer"-stap absoluut noodsaaklik.

Vierdens, gebruik jou blaaier se ontwikkelaarsnutsgoed of gereedskap soos PageSpeed ​​Insights om die laaispoed voor en na te vergelyk. Laat die data vir homself spreek, nie net jou ingewing nie.

Skryf aan die einde

Om eerlik te wees, toe ek hierdie ingebedde tipe-instelling die eerste keer gesien het, was ek lank verstom. Die standaardblokkeringsmodus het te stadig gelyk, terwyl die asynchrone modus nie die volgorde gewaarborg het nie, en uitstel kan versoenbaarheidsprobleme veroorsaak. Ek was onseker oor watter opsie om te kies.

Maar ek het later besef dis 'n kompromie. Jy kan nie beide die vinnigste en die mees stabiele hê nie; jy moet altyd een opoffer. My ervaring is om eers defer te gebruik, wat tans die veiligste nie-blokkerende oplossing is, en dan 'n terugroep te gebruik as probleme ontstaan.

Indien jy soortgelyke probleme ondervind, of indien jy steeds ander probleme ondervind nadat jy my metode gevolg het, voel vry om dit te bespreek. Webwerf-ontwikkeling gaan alles oor probeer en tref; niemand is 'n uitsondering nie.

Dankie dat jy my artikel gelees het. Sien jou volgende keer.