Cilësimet e Plugin-it W3 Total Cache Minify: Si të Zgjidhni Llojin e Embedding-ut? Përvoja Ime me Zgjidhjen e Problemeve dhe Këshilla Shpëtuese

Po keni vështirësi të zgjidhni llojin e duhur të ngulitur për W3 Total Cache Minify? Ky artikull ndan përvojën reale të një webmaster-i dhe ofron një udhëzues hap pas hapi për të zgjedhur me saktësi llojin e saktë të ngulitur Minify, duke shmangur gabimet në stilin e faqes së internetit dhe rrëzimet e ngarkimit. Ai gjithashtu përfshin një zgjidhje të pagabueshme konfigurimi që edhe fillestarët mund ta aplikojnë lehtësisht.WordPress Përshpejtoni pa u përplasur!

Po optimizoja një faqe interneti dhe kur hapa cilësimet e Minify në W3 Total Cache, mbeta plotësisht i habitur. Menuja zbritëse për llojin e ngulitur kishte katër opsione: Default (Block), Use JS for Non-Blocking, Use "Asyncronous" for Non-Blocking dhe Use "Delayed" for Non-Blocking.

Mendova për një moment, për çfarë bëhet fjalë në të gjitha këto?

Më beso, nuk je vetëm. Këto katër opsione ka të ngjarë të lënë të hutuar edhe një fillestar, e lëre më dikë që ka përdorur WordPress për vite me radhë. Ky artikull paraqet grackat që kam hasur dhe mësimet që kam nxjerrë drejtpërdrejt. Nuk keni nevojë të konsultoheni me dokumentacionin; thjesht ndiqni udhëzimet e mia.

Çfarë janë saktësisht këto katër lloje të nguliturash?

Le të flasim së pari për llojin e karakterit që përfaqësojnë këto katër opsione.

Parazgjedhur (I bllokuar)Kjo quhet bllokim i parazgjedhur. Është qasja më e drejtpërdrejtë: shfletuesi ndalet kur has një skript, e shkarkon dhe e ekzekuton atë plotësisht dhe më pas vazhdon ta paraqesë faqen. Tingëllon e besueshme, apo jo? Por kompromisi është se ngarkimi fillestar i faqes do të bllokohet; përdoruesit do të duhet të presin që skripti të përfundojë së ekzekutuari përpara se të shohin diçka.

Përdorimi i JS për mos-bllokimKjo është mjaft interesante. Në vend që të shkruajë drejtpërdrejt etiketat `<script>` në faqe, së pari prodhon një skript të vogël dhe më pas injekton dinamikisht skriptet që duhet të ngarkohen në faqe duke përdorur JavaScript pasi faqja të jetë duke u ekzekutuar. Në këtë mënyrë, faqja mund të renderohet e para dhe skriptet mund të ngarkohen gradualisht. Tingëllon shkëlqyeshëm, apo jo? Megjithatë, problemi është se ky proces dinamik injektimi mund të prishë rendin origjinal të ekzekutimit të skripteve. Nëse disa skripte në faqen tuaj mbështeten shumë në rendin e ekzekutimit, mund të lindin probleme.

Përdorni "asinkron" për jo-bllokuesKjo përfshin shtimin e atributit `async` në etiketën `<script>`. Skripti do të shkarkohet në mënyrë asinkrone në sfond dhe do të ekzekutohet menjëherë pas shkarkimit, pa e pritur faqja. Megjithatë, ana negative është se rendi i ekzekutimit është plotësisht i pakontrollueshëm; cilido skript që përfundon i pari shkarkimin ekzekutohet i pari, pavarësisht nga rendi që keni specifikuar në kod.

Përdorimi i "vonesës" për mos-bllokiminKjo është ajo që do të thotë shtimi i atributit `defer`. Skripti do të presë derisa të analizohet e gjithë faqja para se të ekzekutohet, dhe, më e rëndësishmja, do të ruajë rendin origjinal që e keni shkruar. Kjo është mjaft miqësore për përdoruesit, pasi as nuk bllokon ekranin e parë dhe as nuk e prish rendin.

Cilin duhet të zgjedh?

Thënë thjesht, këto katër opsione janë si një pyetje me zgjedhje të shumëfishtë:Dëshironi shpejtësi apo rregull?

Sugjerimi im është si më poshtë:

Nëse faqja juaj e internetit është e vogël, ka pak skripte dhe nuk keni kërkesa jashtëzakonisht të larta për shpejtësinë e ngarkimit, përdorimi i cilësimit të parazgjedhur (i bllokuar) është opsioni më i lehtë. Edhe pse është pak më i ngadaltë, nuk do të shkaktojë probleme.

Nëse doni të përmirësoni shpejtësinë e ekranit të parë dhe skriptet tuaja nuk kanë varësi të forta si "A duhet të ekzekutohet para B", jepni përparësi...Përdorimi i "vonesës" për mos-bllokimin(shtyj). Kjo është pothuajse zgjidhja më ideale për momentin, pasi as nuk bllokon renderimin dhe as nuk prish rendin.

Nëse provoni të shtyni dhe prapë zbuloni se disa funksione kanë probleme, atëherë merrni në konsideratë...Përdorimi i JS për mos-bllokimKjo zgjidhje është më radikale, por përputhshmëria e saj është pak më e keqe.

Përdorni "asinkron" për jo-bllokues(asinkron) është opsioni që unë rekomandoj më pak. Meqenëse rendi i ekzekutimit është krejtësisht i çrregullt, është e lehtë të rrëzohet nëse nuk jeni absolutisht të sigurt se skriptet tuaja po ekzekutohen të gjitha në mënyrë të pavarur.

Dy gracka të mëdha në të cilat rashë

Të folurit është i lirë. Kam shkruar dy gabime që kam bërë; mund t’i krahasoni me përvojën tuaj për të parë nëse mund t’i shmangni.

Gracka e parë: Temat e personalizuara të WordPress nuk mund të shihen paraprakisht në kohë reale.

Për njëfarë kohe, gjatë personalizimit të një teme, pasi klikoja butonin "Ruaj", pamja paraprake nuk rifreskohej. Bëja disa ndryshime, rifreskoja faqen dhe ajo mbetej përsëri e njëjtë.

Pas disa hetimeve, zbulova se funksioni i kompresimit të Minify ishte fajtori. Zgjidhja është e thjeshtë:

Qasuni në shtojcën W3 Total Cache常规设置,ngrite"kompresim"Hiq shenjën e zgjedhjes së këtij opsioni. Pastaj kliko shigjetën e vogël poshtë "Ruaj Cilësimet" në këndin e sipërm të djathtë dhe zgjidh "..."Ruaj cilësimet dhe pastro memorien e përkohshmeKy hap është thelbësor; nëse nuk e pastroni memorien e përkohshme, do ta shihni ende versionin e vjetër.

Pasi të keni mbaruar, kthehuni te personalizimi i temës dhe pamja paraprake e drejtpërdrejtë do të kthehet në normalitet.

Problemi i dytë: Kutia e kërkimit të temës Astra nuk përgjigjet kur klikohet.

E hasa këtë problem mjaft kohë më parë. Po përdorja temën Astra dhe një ditë papritmas zbulova se kutia e kërkimit nuk po përgjigjej pavarësisht se si e klikova. Në fillim mendova se ishte një problem me vetë temën, por më vonë zbulova se ishte shkaktuar nga cilësimet e Minify të W3TC.

Zgjidhja është si më poshtë:

Shko te W3 Total Cache → Cilësimet e Përgjithshme → Cilësimet e Kompresionit të Avancuar → JS → Cilësimet e Motorrit të Minify → Cilësimet e Vendndodhjes dhe ndrysho llojin e ngulitjes në një nga këto dy:

1. Më parë, mos-bllokimi arrihej duke përdorur JavaScript.
2. Më pas, përdorni JS për mos-bllokimin

Në mënyrë të ngjashme, pastrimi i memorjes së përkohshme dhe rifreskimi i faqes do të lejojë që kutia e kërkimit të funksionojë siç duhet.

Sa i përket zgjedhjes së këtyre dy opsioneve në vend të të tjerave, kam bërë disa kërkime. Thënë thjesht, komponentët e front-end të temës Astra janë mjaft të ndjeshëm ndaj kohës së ekzekutimit të skriptit, dhe disa metoda jo-bllokuese mund të shkaktojnë dështimin e lidhjes së ngjarjeve. Përdorimi i modalitetit "jo-bllokues me JS" siguron që skripti të ekzekutohet vetëm pasi faqja të ketë mbaruar ngarkimin, duke shmangur ekzekutimin e çrregullt që shihet me async.

Lista e vendeve që duhen vizituar

Së fundmi, ja një listë kontrolli që mund ta ndiqni drejtpërdrejt:

Hapi i parë është të sqaroni qëllimin tuaj. A dëshironi ngarkimin fillestar më të shpejtë të faqes, apo i jepni përparësi stabilitetit dhe funksionimit pa gabime? Kjo do të përcaktojë se cilin lloj integrimi duhet të përdorni.

Hapi i dytë nuk është të ndryshosh gjithçka menjëherë. Së pari, gjej një faqe më pak të rëndësishme për ta testuar, vëzhgoje për një ose dy ditë dhe promovoje atë në të gjithë faqen vetëm nëse je i sigurt se nuk ka probleme.

Së treti, gjithmonë pastroni memorien e përkohshme pas çdo modifikimi. Mekanizmi i ruajtjes në memorien e përkohshme i W3TC do t'ju pengojë të shihni ndryshimet më të fundit, kështu që hapi "pastroni memorien e përkohshme dhe testoni përsëri" është absolutisht thelbësor.

Së katërti, përdorni mjetet e zhvilluesit të shfletuesit tuaj ose mjete si PageSpeed ​​​​Insights për të krahasuar shpejtësinë e ngarkimit para dhe pas. Le të flasin vetë të dhënat, jo vetëm ndjesia juaj intuitive.

shkruani në fund

Të them të drejtën, kur e pashë për herë të parë këtë cilësim të tipit të integruar, mbeta i habitur për një kohë të gjatë. Modaliteti i bllokimit parazgjedhur më dukej shumë i ngadaltë, ndërsa modaliteti asinkron nuk garantonte rendin dhe shtyrja mund të shkaktonte probleme me pajtueshmërinë. Isha i pasigurt se cilin opsion të zgjidhja.

Por më vonë e kuptova se është një kompromis. Nuk mund të kesh edhe më të shpejtën edhe më të qëndrueshmen; gjithmonë duhet të sakrifikosh njërën. Përvoja ime është që së pari të përdor shtyrjen, e cila aktualisht është zgjidhja më e sigurt pa bllokim, dhe pastaj të përdor një thirrje mbrapsht nëse lindin probleme.

Nëse hasni probleme të ngjashme, ose nëse keni ende probleme të tjera pasi keni ndjekur metodën time, mos ngurroni ta diskutoni. Zhvillimi i faqes së internetit ka të bëjë tërësisht me provën dhe gabimin; askush nuk bën përjashtim.

Faleminderit që lexuat artikullin tim. Shihemi herën tjetër.