Ynstellings foar de W3 Total Cache Minify-plugin: Hoe kieze jo it ynbêdingstype? Myn ûnderfining mei probleemoplossing en libbensreddend advys

Hawwe jo muoite om it juste ynbêdingstype te kiezen foar W3 Total Cache Minify? Dit artikel dielt de echte ûnderfining fan in webmaster en jout in stap-foar-stap hantlieding om it juste Minify-ynbêdingstype sekuer te selektearjen, wêrtroch jo websidestylproblemen en ladencrashes foarkomme kinne. It befettet ek in feilige opsetoplossing dy't sels begjinners maklik kinne tapasse.WordPress Fersnelle sûnder te crashen!

Ik wie in webside oan it optimalisearjen en doe't ik de Minify-ynstellingen yn W3 Total Cache iepene, wie ik folslein ferbjustere. It útklapmenu foar it ynbêde type hie fjouwer opsjes: Standert (Blokkearje), Brûk JS foar net-blokkearjen, Brûk "Asynchrone" foar net-blokkearjen, en Brûk "Fertrage" foar net-blokkearjen.

Ik haw der even oer neitocht, wêr giet dit allegear oer?

Fertrou my, jo binne net allinnich. Dizze fjouwer opsjes sille wierskynlik sels in begjinner yn 'e war litte, lit stean ien dy't WordPress al jierren brûkt. Dit artikel presintearret de falstrikken dy't ik tsjinkaam bin en de lessen dy't ik direkt leard haw. Jo hoege de dokumintaasje net te rieplachtsjen; folgje gewoan myn ynstruksjes.

Wat binne dizze fjouwer ynbêdingstypen krekt?

Litte wy earst prate oer hokker soarte karakter dizze fjouwer opsjes binne.

Standert (Blokkearre)Dit wurdt standertblokkering neamd. It is de meast ienfâldige oanpak: de browser stoppet as er in skript tsjinkomt, downloadt en fiert it folslein út, en giet dan troch mei it werjaan fan 'e side. Klinkt betrouber, toch? Mar de ôfwaging is dat jo earste sideladen blokkearre wurdt; brûkers moatte wachtsje oant it skript klear is foardat se wat kinne sjen.

JS brûke foar net-blokkearjenDit is aardich nijsgjirrich. Ynstee fan direkt `<script>` tags op 'e side te skriuwen, jout it earst in lyts skript út, en ynjektearret dan dynamysk de skripts dy't laden wurde moatte yn 'e side mei JavaScript nei't de side rint. Op dizze manier kin de side earst werjûn wurde, en kinne de skripts stadichoan laden wurde. Klinkt geweldich, toch? It probleem is lykwols dat dit dynamyske ynjeksjeproses de orizjinele útfieringsfolchoarder fan 'e skripts fersteure kin. As guon skripts op jo side sterk ôfhinklik binne fan 'e útfieringsfolchoarder, kinne problemen ûntstean.

Brûk "asynchrone" foar net-blokkearjendeDit hâldt yn dat it attribút `async` tafoege wurdt oan de `<script>` tag. It skript sil asynchrone downloade op 'e eftergrûn en direkt nei it downloaden útfiere, sûnder dat de side derop wachtet. It neidiel is lykwols dat de útfieringsfolchoarder folslein net te kontrolearjen is; hokker skript it earst foltôge wurdt mei downloaden, wurdt earst útfierd, nettsjinsteande de folchoarder dy't jo yn 'e koade oantsjutte hawwe.

"Fertraging" brûke foar net-blokkearjenDit is wat it tafoegjen fan it `defer` attribút betsjut. It skript sil wachtsje oant de hiele side parsearre is foardat it útfierd wurdt, en wichtich is dat it de orizjinele folchoarder behâldt wêryn jo it skreaun hawwe. Dit is frij brûkerfreonlik, om't it it earste skerm net blokkearret en de folchoarder ek net fersteurt.

Hokker moat ik kieze?

Om it simpel te sizzen, dizze fjouwer opsjes binne as in mearfâldige karfraach:Wolle jo snelheid of oarder?

Myn suggestje is dit:

As jo ​​webside lyts is, mar in pear skripts hat, en jo gjin ekstreem hege easken hawwe foar laadsnelheid, is it brûken fan de standertynstelling (blokkearre) de maklikste opsje. Hoewol it wat stadiger is, sil it gjin problemen feroarsaakje.

As jo ​​de snelheid fan it earste skerm ferbetterje wolle en jo skripts gjin sterke ôfhinklikheden hawwe lykas "A moat útfierd wurde foar B", prioritearje dan ..."Fertraging" brûke foar net-blokkearjen(útstelle). Dit is op it stuit hast de meast ideale oplossing, om't it de rendering net blokkearret en de folchoarder ek net fersteurt.

As jo ​​​​​​besykje útstel te dwaan en noch altyd fine dat guon funksjes problemen hawwe, beskôgje dan ...JS brûke foar net-blokkearjenDizze oplossing is radikaler, mar syn kompatibiliteit is wat minder.

Brûk "asynchrone" foar net-blokkearjende(async) is de opsje dy't ik it minst oanbefelje. Omdat de útfieringsfolchoarder folslein yn 'e war is, is it maklik om te crashen, útsein as jo der hielendal wis fan binne dat jo skripts allegear ûnôfhinklik rinne.

Twa grutte falstrikken dêr't ik yn fallen bin

Praten is goedkeap. Ik haw twa flaters opskreaun dy't ik makke haw; jo kinne se kontrolearje mei jo eigen ûnderfining om te sjen oft jo se foarkomme kinne.

De earste falstrik: Oanpaste WordPress-tema's kinne net yn realtime foarôf besjoen wurde.

In skoftke, by it oanpassen fan in tema, nei it klikken op bewarje, woe de foarbyld net ferfarskje. Ik makke wat feroarings, ferfarske de side, en it soe noch itselde wêze.

Nei wat ûndersyk ûntduts ik dat de kompresjefunksje fan Minify de skuldige wie. De oplossing is ienfâldich:

Tagong ta de W3 Total Cache-plugin常规设置, opkomme"kompresje"Skeakelje dy opsje út. Klik dan op it lytse pylkje ûnder "Ynstellings bewarje" yn 'e rjochter boppeste hoeke en selektearje "..."Ynstellings bewarje en cache wiskjeDizze stap is krúsjaal; as jo de cache net wiskje, sille jo noch altyd de âlde ferzje sjen.

As jo ​​klear binne, gean werom nei it oanpassen fan tema, en de live foarbyld sil werom wêze nei normaal.

It twadde probleem: It sykfak fan it Astra-tema reagearret net as derop klikt wurdt.

Ik bin dit probleem al in skoft lyn tsjinkommen. Ik brûkte it Astra-tema, en op in dei fûn ik ynienen dat it sykfak net reagearre, nettsjinsteande hoe't ik derop klikte. Earst tocht ik dat it in probleem wie mei it tema sels, mar letter ûntduts ik dat it feroarsake waard troch de Minify-ynstellingen fan W3TC.

De oplossing is as folget:

Gean nei W3 Total Cache → Algemiene ynstellings → Avansearre kompresje-ynstellings → JS → Minify Engine-ynstellings → Lokale ynstellings, en feroarje it ynbêdingstype nei ien fan dizze twa:

1. Earder waard net-blokkearjen berikt mei JavaScript.
2. Brûk dêrnei JS foar net-blokkearjen

Op deselde wize sil it wiskjen fan 'e cache en it ferfarskjen fan 'e pagina it sykfak goed wurkje litte.

Wat de redenen oanbelanget wêrom't dizze twa opsjes keazen binne ynstee fan oaren, haw ik wat ûndersyk dien. Simpelwei sein, de front-end-komponinten fan it Astra-tema binne frij gefoelich foar de timing fan skriptútfiering, en bepaalde net-blokkearjende metoaden kinne feroarsaakje dat evenemintbinding mislearret. It brûken fan de modus "net-blokkearjend mei JS" soarget derfoar dat it skript allinich útfierd wurdt nei't de pagina klear is mei laden, wylst de ûnregelmjittige útfiering dy't sjoen wurdt mei async foarkommen wurdt.

List fan plakken om te besykjen

Ta beslút, hjir is in checklist dy't jo direkt folgje kinne:

De earste stap is om jo doel te ferdúdlikjen. Wolle jo de rapste earste sidelading, of jouwe jo prioriteit oan stabiliteit en flaterfrije operaasje? Dit sil bepale hokker ynbêdingstype jo brûke moatte.

De twadde stap is om net alles tagelyk te feroarjen. Earst, fyn in minder wichtige side om it te testen, observearje it in dei of twa, en promovearje it allinich op 'e hiele side as jo der wis fan binne dat der gjin problemen binne.

Tredde, meitsje altyd de cache leech nei elke wiziging. It cache-meganisme fan W3TC sil foarkomme dat jo de lêste feroarings sjogge, dus de stap "leegje de cache leech en test opnij" is absolút essensjeel.

Fjirder, brûk de ûntwikkelderstools fan jo browser of ark lykas PageSpeed ​​Insights om de laadsnelheid foar en nei te fergelykjen. Lit de gegevens foar himsels sprekke, net allinich jo gefoel.

Skriuw oan 'e ein

Om earlik te wêzen, doe't ik dizze ynbêde type-ynstelling foar it earst seach, wie ik lange tiid ferbjustere. De standert blokkearmodus like te stadich, wylst de asynchrone modus de folchoarder net garandearre, en útstel koe kompatibiliteitsproblemen feroarsaakje. Ik wie net wis hokker opsje ik kieze moast.

Mar letter realisearre ik my dat it in ôfwaging is. Jo kinne net sawol de rapste as de stabilste hawwe; jo moatte altyd ien opofferje. Myn ûnderfining is om earst defer te brûken, wat op it stuit de feilichste net-blokkearjende oplossing is, en dan in callback te brûken as der problemen ûntsteane.

As jo ​​ferlykbere problemen tsjinkomme, of as jo noch oare problemen hawwe nei it folgjen fan myn metoade, fiel jo frij om it te besprekken. Websideûntwikkeling giet allegear oer proef en flater; nimmen is in útsûndering.

Tankewol foar it lêzen fan myn artikel. Oant de folgjende kear.