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ë ngulitjes për W3 Total Cache Minify? Ky artikull ndan përvojën e një webmaster-i në botën reale dhe ofron një udhëzues hap pas hapi për të zgjedhur me saktësi llojin e duhur të ngulitjes 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, duke siguruar një përvojë të qetë dhe të shpejtë në WordPress !

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.

Bllokimi i parazgjedhur është qasja më e drejtpërdrejtë. Kur shfletuesi has një skript, ai e ndalon, e shkarkon dhe e ekzekuton plotësisht skriptin dhe më pas vazhdon ta paraqesë faqen. Tingëllon e besueshme, apo jo? Por kompromisi është se ngarkimi fillestar i faqes do të vonohet; përdoruesit do të duhet të presin që skripti të përfundojë së ekzekutuari përpara se të shohin diçka.

Përdorimi i JavaScript për mos-bllokim është mjaft interesant. 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 e nevojshme në faqe nëpërmjet JavaScript pasi faqja të jetë duke u ekzekutuar. Në këtë mënyrë, faqja mund të renderohet e para dhe skriptet ngarkohen gradualisht. Tingëllon shkëlqyeshëm, apo jo? Megjithatë, problemi është se ky proces injektimi dinamik 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ërdorimi i "asinkron" për ekzekutim jo-bllokues thjesht 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 përfundimit, pa e pritur faqja. Megjithatë, disavantazhi është se rendi i ekzekutimit është plotësisht i pakontrollueshëm; çdo shkarkim që kryhet i pari ekzekutohet, pavarësisht nga rendi që specifikoni në kod.

Përdorimi i "delay" për ekzekutim jo-bllokues arrihet duke shtuar atributin `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 në të cilin e keni shkruar. Kjo është mjaft miqësore për përdoruesit, pasi as nuk bllokon ekranin e parë dhe as nuk prish rendin e skriptit.

Cilin duhet të zgjedh?

Thënë thjesht, këto katër opsione janë si një pyetje me zgjedhje të shumëfishta: a dëshironi shpejtësi apo doni 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ërdorimit të "shtyrjes" për ekzekutim jo-bllokues . Kjo është pothuajse zgjidhja ideale që është aktualisht në dispozicion, pasi shmang bllokimin e renderimit duke ruajtur rendin e ekzekutimit.

Nëse vini re se disa funksione ende kanë probleme pasi të provoni shtyrjen, atëherë merrni në konsideratë përdorimin e JavaScript për mos-bllokim . Kjo qasje është më agresive, por përputhshmëria e saj është pak më e keqe.

Përdorimi i "async" për mos-bllokim ë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 ekzekutohen 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ë:

Shko te cilësimet e përgjithshme të plugin-it W3 Total Cache , gjej opsionin "Compression" dhe hiqe shenjën. Pastaj, kliko shigjetën e vogël poshtë "Save Settings" në këndin e sipërm të djathtë dhe zgjidh " Save Settings and Clear Cache ". Ky hap është thelbësor; pa pastruar cache-in, 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.