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

Мучите се да изаберете прави тип уграђивања за W3 Total Cache Minify? Овај чланак дели искуство вебмастера из стварног света и пружа водич корак по корак за прецизан избор исправног типа уграђивања Minify-а, избегавајући недоследности у стилу веб странице и падове приликом учитавања. Такође укључује решење за подешавање које чак и почетници могу лако да примене.WordPress Убрзајте без судара!

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

Размислио сам о томе на тренутак, о чему се све ово ради?

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

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

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

Подразумевано (блок)Ово се зове подразумевано блокирање. То је најједноставнији приступ: прегледач се зауставља када наиђе на скрипту, преузима је и потпуно је извршава, а затим наставља да приказује страницу. Звучи поуздано, зар не? Али компромис је у томе што ће почетно учитавање странице бити блокирано; корисници ће морати да сачекају да се скрипта заврши пре него што било шта виде.

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

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

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

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

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

Мој предлог је следећи:

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

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

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

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

Две велике замке у које сам упао

Прича је јефтина. Записао сам две грешке које сам направио; можете их упоредити са сопственим искуством да видите да ли их можете избећи.

Прва замка: Прилагођене WordPress теме не могу се прегледати у реалном времену.

Неко време, приликом прилагођавања теме, након клика на дугме „Сачувај“, преглед се није освежавао. Направио бих неке измене, освежио страницу, а она би и даље била иста.

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

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

Када завршите, вратите се на прилагођавање теме и преглед уживо ће се вратити у нормалу.

Други проблем: Поље за претрагу теме Астра не реагује када се кликне.

Наишао сам на овај проблем пре доста времена. Користио сам Астра тему и једног дана сам изненада открио да поље за претрагу не реагује без обзира како сам кликнуо на њега. У почетку сам мислио да је проблем са самом темом, али сам касније открио да је узрокован подешавањима Minify у W3TC-у.

Решење је следеће:

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

1. Раније се неблокирање постизало коришћењем Јаваскрипта.
2. Након тога, користите JS за неблокирање

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

Што се тиче разлога зашто су ове две опције изабране уместо других, мало сам истраживао. Једноставно речено, фронт-енд компоненте Астра теме су прилично осетљиве на време извршавања скрипте, а одређене методе које не блокирају могу проузроковати неуспех повезивања догађаја. Коришћење режима „неблокирање са JS“ осигурава да се скрипта извршава тек након што се страница заврши са учитавањем, избегавајући притом неуређено извршавање које се види код асинхроног режима.

Списак места која треба посетити

На крају, ево контролне листе коју можете директно пратити:

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

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

Треће, увек обришите кеш меморију након сваке измене. W3TC-ов механизам кеширања ће вас спречити да видите најновије измене, тако да је корак „обриши кеш меморију и поново тестирај“ апсолутно неопходан.

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

写在最后

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

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

Ако наиђете на сличне проблеме или ако и даље имате других проблема након што сте пратили моју методу, слободно разговарајте о томе. Развој веб сајтова се заснива на покушајима и грешкама; нико није изузетак.

Хвала вам што сте прочитали мој чланак. Видимо се следећи пут.