Поставки на додатокот W3 Total Cache Minify: Како да го изберете типот на вградување? Моето искуство со решавање проблеми и совети за спасување на живот

Се мачите да го изберете вистинскиот тип на вградување за W3 Total Cache Minify? Оваа статија го споделува искуството на вебмастерот од реалниот свет и обезбедува чекор-по-чекор водич за прецизно избирање на точниот тип на вградување на Minify, избегнувајќи недоследности во стилот на веб-страницата и падови при вчитување. Исто така, вклучува и сигурно решение за поставување што дури и почетниците можат лесно да го применат.WordPress Забрзајте без да се судрите!

Оптимизирав веб-страница и кога ги отворив поставките за Minify во W3 Total Cache, бев целосно зачуден. Паѓачкото мени за вградениот тип имаше четири опции: Стандардно (Блокирање), Користи JS за неблокирање, Користи „Асинхроно“ за неблокирање и Користи „Одложено“ за неблокирање.

Размислував за момент, за што се работи сето ова?

Верувајте ми, не сте сами. Овие четири опции веројатно ќе го остават збунет дури и почетникот, а камоли некој што го користи WordPress со години. Оваа статија ги претставува стапиците со кои се соочив и лекциите што ги научив директно. Не треба да ја консултирате документацијата; само следете ги моите упатства.

Што точно се овие четири типа на вградување?

Ајде прво да разговараме за тоа каков карактер се овие четири опции.

Стандардно (Блокирано)Ова се нарекува стандардно блокирање. Тоа е наједноставниот пристап: прелистувачот запира кога ќе наиде на скрипта, ја презема и ја извршува целосно, а потоа продолжува да ја прикажува страницата. Звучи сигурно, нели? Но, компромисот е што првичното вчитување на страницата ќе биде блокирано; корисниците ќе мора да почекаат скриптата да заврши со извршување пред да можат да видат нешто.

Користење на JS за неблокирањеОва е доста интересно. Наместо директно да пишува ознаки `<script>` на страницата, прво се прикажува мала скрипта, а потоа динамички се инјектираат скриптите што треба да се вчитаат во страницата преку JavaScript откако страницата ќе се изврши. На овој начин, страницата може прва да се рендерира, а скриптите можат постепено да се вчитуваат. Звучи одлично, нели? Сепак, проблемот е што овој динамичен процес на инјектирање може да го наруши оригиналниот редослед на извршување на скриптите. Ако некои скрипти на вашата страница во голема мера зависат од редоследот на извршување, може да се појават проблеми.

Користете „асинхроно“ за неблокирачкиОва вклучува додавање на атрибутот `async` на ознаката `<script>`. Скриптата ќе се преземе асинхроно во позадина и ќе се изврши веднаш по преземањето, без страницата да чека на неа. Сепак, недостатокот е што редоследот на извршување е целосно неконтролиран; која скрипта прва ќе заврши со преземањето, се извршува прва, без оглед на редоследот што сте го навеле во кодот.

Користење на „одложување“ за неблокирањеОва е она што значи додавањето на атрибутот `defer`. Скриптата ќе почека додека целата страница не се анализира пред да се изврши, и што е важно, ќе го задржи оригиналниот редослед што сте го напишале. Ова е доста лесно за користење, бидејќи ниту го блокира првиот екран ниту го нарушува редоследот.

Кој треба да го изберам?

Едноставно кажано, овие четири опции се како прашање со повеќекратен избор:Дали сакате брзина или ред?

Мојот предлог е овој:

Ако вашата веб-страница е мала, има малку скрипти и немате екстремно високи барања за брзина на вчитување, користењето на стандардната (блокирана) поставка е најлесната опција. Иако е малку побавно, нема да предизвика никакви проблеми.

Ако сакате да ја подобрите брзината на првиот екран и вашите скрипти немаат силни зависности како „А мора да се изврши пред Б“, дајте им приоритет...Користење на „одложување“ за неблокирање(одложување). Ова е речиси најидеалното решение во моментов, бидејќи ниту го блокира рендерирањето ниту го нарушува редоследот.

Ако се обидете со одложување и сè уште откриете дека некои функции имаат проблеми, тогаш размислете...Користење на JS за неблокирањеОва решение е порадикално, но неговата компатибилност е малку полоша.

Користете „асинхроно“ за неблокирачки(async) е опцијата што најмалку ја препорачувам. Бидејќи редоследот на извршување е целосно погрешен, лесно е да се сруши освен ако не сте апсолутно сигурни дека сите ваши скрипти работат независно.

Две големи стапици во кои паднав

Разговорот е евтин. Запишав две грешки што ги направив; можете да ги споредите со вашето сопствено искуство за да видите дали можете да ги избегнете.

Првата стапица: Прилагодените WordPress теми не можат да се прегледаат во реално време.

Некое време, при прилагодување на тема, откако ќе кликнев на „Зачувај“, прегледот не се освежуваше. Правев некои промени, ја освежував страницата и сè уште беше иста.

По некое истражување, открив дека функцијата за компресија на Minify е виновникот. Решението е едноставно:

Пристапете до приклучокот W3 Total Cache常规设置, свртете се„компресија“Отштиклирајте ја таа опција. Потоа кликнете на малата стрелка под „Зачувај поставки“ во горниот десен агол и изберете „...“Зачувајте ги поставките и исчистете ја кеш-меморијатаОвој чекор е клучен; ако не го исчистите кешот, сè уште ќе ја гледате старата верзија.

Откако ќе завршите, вратете се на прилагодување на темата и прегледот во живо ќе се врати во нормала.

Вториот проблем: Полето за пребарување на темата Astra не реагира кога ќе се кликне.

Се соочив со овој проблем пред доста време. Ја користев темата Astra и еден ден одеднаш открив дека полето за пребарување не реагира без разлика колку кликнав на него. На почетокот мислев дека е проблем со самата тема, но подоцна открив дека е предизвикан од поставките за Minify на W3TC.

Решението е како што следува:

Одете во W3 Total Cache → General Settings → Advanced Compression Settings → JS → Minify Engine Settings → Locale Settings и променете го типот на вградување на еден од овие два:

1. Претходно, неблокирањето се постигнуваше со употреба на JavaScript.
2. После тоа, користете JS за неблокирање

Слично на тоа, чистењето на кешот и освежувањето на страницата ќе овозможи полето за пребарување да работи правилно.

Што се однесува до тоа зошто беа избрани овие две опции наместо другите, направив малку истражување. Едноставно кажано, front-end компонентите на темата Astra се доста чувствителни на времето на извршување на скриптата, а одредени методи што не блокираат можат да предизвикаат неуспех во врзувањето на настаните. Користењето на режимот „неблокирање со JS“ гарантира дека скриптата ќе се изврши само откако страницата ќе заврши со вчитувањето, избегнувајќи го нередовното извршување што се гледа кај async.

Список на места што треба да се посетат

Конечно, еве листа за проверка што можете директно да ја следите:

Првиот чекор е да ја разјасните вашата цел. Дали сакате најбрзо вчитување на почетната страница или давате приоритет на стабилноста и работењето без грешки? Ова ќе одреди кој тип на вградување треба да го користите.

Вториот чекор не е да менувате сè одеднаш. Прво, пронајдете помалку важна страница за да ја тестирате, набљудувајте ја еден или два дена и промовирајте ја на целата страница само ако сте сигурни дека нема проблеми.

Трето, секогаш исчистете го кешот по секоја модификација. Механизмот за кеширање на W3TC ќе ве спречи да ги видите најновите промени, па затоа чекорот „исчисти го кешот и тестирај повторно“ е апсолутно неопходен.

Четврто, користете ги алатките за развивачи на вашиот прелистувач или алатки како PageSpeed ​​​​Insights за да ја споредите брзината на вчитување пред и потоа. Дозволете податоците да зборуваат сами за себе, а не само вашата интуиција.

Напиши на крајот

Да бидам искрен, кога првпат го видов ова поставување за вграден тип, долго време бев запрепастен. Стандардниот режим на блокирање ми изгледаше премногу бавен, додека асинхрониот режим не го гарантираше редоследот, а одложувањето може да предизвика проблеми со компатибилноста. Не бев сигурен која опција да ја изберам.

Но подоцна сфатив дека е компромис. Не можете да ги имате и најбрзиот и најстабилниот; секогаш мора да жртвувате едно. Моето искуство е прво да се користи одложување, што во моментов е најбезбедното решение без блокирање, а потоа да се користи повратен повик доколку се појават проблеми.

Доколку наидете на слични проблеми или доколку сè уште имате други проблеми откако ќе го следите мојот метод, слободно разговарајте за тоа. Развојот на веб-страници е базиран на обиди и грешки; никој не е исклучок.

Ви благодарам што ја прочитавте мојата статија. Се гледаме следниот пат.