Справочник на статиите
Затруднявате се да изберете правилния тип вграждане за W3 Total Cache Minify? Тази статия споделя реалния опит на уеб администратор и предоставя подробно ръководство за точен избор на правилния тип вграждане Minify, като избягвате проблеми със стила на уебсайта и сривове при зареждане. Също така включва безупречно решение за настройка, което дори начинаещите могат лесно да прилагат, осигурявайки гладко и бързо WordPress изживяване!
Оптимизирах уебсайт и когато отворих настройките за Minify в W3 Total Cache, бях напълно изумен. Падащото меню за вградения тип имаше четири опции: По подразбиране (Блокиране), Използване на JS за неблокиране, Използване на „Асинхронно“ за неблокиране и Използване на „Забавено“ за неблокиране.
Замислих се за момент, за какво е всичко това?
Повярвайте ми, не сте сами. Тези четири опции вероятно ще озадачат дори начинаещ, камо ли някой, който използва WordPress от години. Тази статия представя капаните, с които се сблъсках, и уроците, които научих, директно на вас. Не е необходимо да се консултирате с документацията; просто следвайте инструкциите ми.
Какви точно са тези четири типа вграждане?
Нека първо поговорим за това какъв характер представляват тези четири варианта.
Блокирането по подразбиране е най-лесният подход. Когато браузърът срещне скрипт, той спира, изтегля и изпълнява скрипта напълно, след което продължава да рендира страницата. Звучи надеждно, нали? Но компромисът е, че първоначалното зареждане на страницата ще се забави; потребителите ще трябва да чакат скриптът да приключи, преди да видят нещо.
Използването на JavaScript за неблокиране е доста интересно. Вместо директно да се пишат тагове `<script>` на страницата, той първо извежда малък скрипт и след това динамично инжектира необходимите скриптове в страницата чрез JavaScript, след като страницата се изпълни. По този начин страницата може първо да се рендира, а скриптовете се зареждат постепенно. Звучи страхотно, нали? Проблемът обаче е, че този динамичен процес на инжектиране може да наруши оригиналния ред на изпълнение на скриптовете. Ако някои скриптове на вашата страница силно разчитат на реда на изпълнение, може да възникнат проблеми.
Използването на „асинхронно“ за неблокиращо изпълнение просто включва добавяне на атрибута `async` към тага `<script>`. Скриптът ще се изтегля асинхронно във фонов режим и ще се изпълнява веднага след завършване, без страницата да го чака. Недостатъкът обаче е, че редът на изпълнение е напълно неконтролируем; каквото и да се изтегли първо, се изпълнява, независимо от реда, който посочвате в кода.
Използването на „delay“ за неблокиращо изпълнение се постига чрез добавяне на атрибута `defer`. Скриптът ще изчака, докато цялата страница бъде анализирана, преди да се изпълни, и най-важното е, че ще запази оригиналния ред, в който сте го написали. Това е доста удобно за потребителя, тъй като нито блокира първия екран, нито нарушава реда на скрипта.
Кой да избера?
Казано по-просто, тези четири варианта са като въпрос с избираем отговор: искате ли скорост или искате ред?
Моето предложение е следното:
Ако уебсайтът ви е малък, има малко скриптове и нямате изключително високи изисквания за скорост на зареждане, използването на настройката по подразбиране (блокирано) е най-лесният вариант. Въпреки че е малко по-бавно, няма да причини проблеми.
Ако искате да подобрите скоростта на извеждане на първия екран и вашите скриптове нямат силни зависимости като „A трябва да се изпълни преди B“, дайте приоритет на използването на „defer“ за неблокиращо изпълнение . Това е почти идеалното решение, налично в момента, тъй като избягва блокирането на рендирането, като същевременно запазва реда на изпълнение.
Ако установите, че някои функции все още имат проблеми след опит с defer, помислете за използване на JavaScript за неблокиране . Този подход е по-агресивен, но съвместимостта му е малко по-лоша.
Използването на „async“ за неблокиране е опцията, която най-малко препоръчвам. Тъй като редът на изпълнение е напълно объркан, е лесно да се стигне до срив, освен ако не сте абсолютно сигурни, че скриптовете ви се изпълняват независимо.
Два големи капана, в които попаднах
Приказките са евтини. Записах две грешки, които направих; можете да ги сравните със собствения си опит, за да видите дали можете да ги избегнете.
Първият капан: Персонализираните теми за WordPress не могат да бъдат визуализирани в реално време.
За известно време, когато персонализирах тема, след щракване върху „Запазване“, визуализацията не се обновяваше. Правех някои промени, обновявах страницата и тя все още си беше същата.
След известно проучване открих, че виновникът е функцията за компресия на Minify. Решението е просто:
Отидете в общите настройки на плъгина W3 Total Cache , намерете опцията „Компресия“ и я махнете отметката. След това щракнете върху малката стрелка под „Запазване на настройките“ в горния десен ъгъл и изберете „ Запазване на настройките и изчистване на кеша “. Тази стъпка е изключително важна; без да изчистите кеша, все още ще виждате старата версия.
След като приключите, върнете се към персонализирането на темата и прегледът на живо ще се върне към нормалното.
Вторият проблем: Полето за търсене на темата Astra не реагира при щракване.
Сблъсках се с този проблем преди доста време. Използвах темата Astra и един ден изведнъж открих, че полето за търсене не реагира, независимо как щракнах върху него. Първоначално си помислих, че проблемът е в самата тема, но по-късно открих, че е причинен от настройките за Minify на W3TC.
Решението е следното:
Отидете на W3 Total Cache → Общи настройки → Разширени настройки за компресия → JS → Настройки на двигателя за минимизиране → Настройки за локализация и променете типа на вграждане на един от тези два:
- Преди това, неблокирането се постигаше с помощта на JavaScript.
- След това използвайте JS за неблокиране
По подобен начин, изчистването на кеша и обновяването на страницата ще позволи на полето за търсене да работи правилно.
Що се отнася до това защо тези две опции бяха избрани вместо други, направих известно проучване. Казано по-просто, компонентите на предния край на темата Astra са доста чувствителни към времето на изпълнение на скрипта и някои неблокиращи методи могат да доведат до неуспех при обвързване на събития. Използването на режима „неблокиране с JS“ гарантира, че скриптът се изпълнява само след като страницата е завършила зареждането, като същевременно се избягва неподреденото изпълнение, наблюдавано при async.
Списък с места за посещение
Накрая, ето контролен списък, който можете да следвате директно:
Първата стъпка е да изясните целта си. Искате ли най-бързото първоначално зареждане на страницата или давате приоритет на стабилността и безгрешната работа? Това ще определи кой тип вграждане трябва да използвате.
Втората стъпка не е да променяте всичко наведнъж. Първо, намерете по-маловажна страница, за да я тествате, наблюдавайте я ден-два и я популяризирайте в целия сайт само ако сте сигурни, че няма проблеми.
Трето, винаги изчиствайте кеша след всяка промяна. Механизмът за кеширане на W3TC ще ви попречи да видите последните промени, така че стъпката „изчистване на кеша и тестване отново“ е абсолютно задължителна.
Четвърто, използвайте инструментите за разработчици на вашия браузър или инструменти като PageSpeed Insights, за да сравните скоростта на зареждане преди и след това. Нека данните говорят сами за себе си, а не само интуицията ви.
Пишете в края
Честно казано, когато за първи път видях тази вградена настройка за тип, дълго време бях изумен. Режимът на блокиране по подразбиране ми се стори твърде бавен, докато асинхронният режим не гарантираше реда на операциите, а отлагането можеше да причини проблеми със съвместимостта. Не бях сигурен коя опция да избера.
Но по-късно осъзнах, че това е компромис. Не можеш да имаш едновременно най-бързия и най-стабилния; винаги трябва да жертваш едното. Моят опит е първо да използвам defer, което в момента е най-безопасното неблокиращо решение, и след това да използвам обратно извикване, ако възникнат проблеми.
Ако срещнете подобни проблеми или ако все още имате други трудности, след като сте следвали моя метод, не се колебайте да ги обсъдите. Разработването на уебсайтове е изцяло въпрос на проба и грешка; никой не е изключение.
Благодаря ви, че прочетохте статията ми. Ще се видим следващия път.
Надявам се, че статията „Настройки на плъгина W3 Total Cache Minify: Как да избера типа вграждане? Моите капани и съвети за спасяване на живота“, споделена в блога на Чен Вейлианг ( https://www.chenweiliang.com/ ), ще ви бъде полезна.
Чувствайте се свободни да споделите линка към тази статия: https://www.chenweiliang.com/cwl-34003.html