Artikelgids
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, wat 'n gladde en vinnige WordPress- ervaring verseker !
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.
Standaardblokkering is die eenvoudigste benadering. Wanneer die blaaier 'n skrip teëkom, stop dit, laai dit af en voer die skrip volledig uit, en gaan dan voort om die bladsy te lewer. Klink betroubaar, reg? Maar die kompromie is dat jou aanvanklike bladsylaai vertraag sal word; gebruikers sal moet wag totdat die skrip klaar loop voordat hulle enigiets kan sien.
Dit is nogal interessant om JavaScript te gebruik vir nie-blokkering . In plaas daarvan om `<script>`-etikette direk op die bladsy te skryf, word eers 'n klein skrip uitgevoer en dan word die nodige skripte dinamies via JavaScript in die bladsy ingespuit nadat die bladsy loop. Op hierdie manier kan die bladsy eers weergegee word, en die skripte laai geleidelik. Klink goed, reg? Die probleem is egter dat hierdie dinamiese inspuitproses die oorspronklike uitvoeringsvolgorde van die skripte kan ontwrig. As sommige skripte op jou bladsy sterk op die uitvoeringsvolgorde staatmaak, kan probleme ontstaan.
Die gebruik van "asynchrone" vir nie-blokkerende uitvoering behels eenvoudig die byvoeging van die `async`-attribuut by die `<script>`-etiket. Die skrip sal asynchronies in die agtergrond aflaai en onmiddellik na voltooiing uitvoer, sonder dat die bladsy daarvoor wag. Die nadeel is egter dat die uitvoeringsvolgorde heeltemal onbeheerbaar is; wat ook al eerste afgelaai word, word uitgevoer, ongeag die volgorde wat jy in die kode spesifiseer.
Die gebruik van "delay" vir nie-blokkerende uitvoering word bereik deur die `defer`-attribuut by te voeg. Die skrip sal wag totdat die hele bladsy ontleed is voordat dit uitgevoer word, en van kardinale belang, dit sal die oorspronklike volgorde waarin jy dit geskryf het, handhaaf. Dit is redelik gebruikersvriendelik, aangesien dit nie die eerste skerm blokkeer of die skrip se volgorde ontwrig nie.
Watter een moet ek kies?
Eenvoudig gestel, hierdie vier opsies is soos 'n meerkeusevraag: wil jy spoed hê, of wil jy die volgorde 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 skripte nie sterk afhanklikhede soos "A moet voor B uitgevoer word" het nie, prioritiseer die gebruik van "uitstel" vir nie-blokkerende uitvoering . Dit is amper die ideale oplossing wat tans beskikbaar is, aangesien dit blokkering van lewering vermy terwyl die volgorde van uitvoering gehandhaaf word.
Indien jy vind dat sommige funksies steeds probleme ondervind nadat jy defer probeer het, oorweeg dit om JavaScript vir nie-blokkering te gebruik . Hierdie benadering is meer aggressief, maar die versoenbaarheid daarvan is effens swakker.
Die gebruik van "async" vir nie-blokkering 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 skrifte 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:
Gaan na die algemene instellings van die W3 Total Cache-inprop , vind die "Kompressie" -opsie en ontmerk dit. Klik dan op die klein pyltjie onder "Stoor instellings" in die regter boonste hoek en kies " Stoor instellings en maak kas skoon ". Hierdie stap is noodsaaklik; sonder om die kas skoon te maak, 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:
- Voorheen is nie-blokkering bereik met behulp van JavaScript.
- 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.
Ek hoop dat die artikel "W3 Total Cache Minify Plugin Settings: How to Choose the Embedding Type? My Falls and Lifesaving Advice" wat op Chen Weiliang se blog ( https://www.chenweiliang.com/ ) gedeel is, vir jou nuttig sal wees.
Deel gerus die skakel na hierdie artikel: https://www.chenweiliang.com/cwl-34003.html