По-бърз WordPress Сайт

Оптимизацията на един WordPress сайт включва внимателен подбор на тема и плъгини, премахване на ненужните стилове и скриптове и компресиране на останалите ресурси, които се зареждат във frontend частта.

И на може би последно място – преместване на друг, по-надежден и бърз хост.

Та така, иматe сайт, направен на WordPress, но зарежда твърде бавно (повече от 2-3 секунди) и губите посетители и потенциални клиенти?

Не сте сами. Отворете който и да е уебмастърски форум, група, или пък платформа за фрийленсърски услуги като UpWork.com, Freelancer.com. Лесно ще забележите множество постове в духа на:

• „Как да си забързам WordPress сайта?“
• „WooCommerce магазинът ми е много бавен!“
• „Търся WordPress гуру да ми оптимизира сайта“

На същите места ще видите и доста отговори и съвети от разни „специалисти“. Най-често срещаните препоръки представляват вариации на следните:

Смени хоста, lol!

WordPress става само за блогове.

Най-добре звънни на нашето момче да ти направи къстъм сайт!

Абе сложи истински софтуер за магазин като Opencart. WordPress е направено за блог и е тромаво.

Плъгин за кеширане сложил ли си?

Как нема да бави, ве батко, ти виждал ли си какъв спагети код е вътре?!

Намери PHP експерт да види какви заявки към базата данни се генерират и да ги оптимизира…

Предполагам поне една част звучат познато, ако сте се сблъсквали с така често срещания проблем „бавен WordPress“?

Приятната „новина“ е, че горните „диагнози“ нямат почти нищо общо с реалността и можете да постигнете желания бързозареждащ WordPress сайт дори и без кой знае какви техническа подготовка или големи финансови инвестиции.

Но първо едно важно уточнение:

WordPress е бърз, дори много бърз…

… сам по себе си.

Точно защото използва „остаряла“ и проста архитектура, той е много по-производителен от CMS с еквивалентна функционалност, но базиран на някоя от модерните PHP frameworks като Symfony, Zend (Laminas) или Laravel.

Това, което го прави „бавен“ са нещата, които се поставят върху базовата WordPress инсталация, а именно:

• изображения
• тема
• плъгини

Предупреждение!

Няма да задълбаваме в технически детайли, а ще го караме по-целенасочено и ще обобщаваме без да се отплесваме много-много. Потърсете помощта на разработчик, ако останалата част на ръководството ви се види сложна и неразбираема!

Освен това, няма да се занимаваме с кеширащи плъгини! Фокусираме се върху аспектите на оптимизацията, които имат най-голямо практическо влияние върху бързодействието, а за тях кеширащите плъгини няма да помогнат особено, каквито и приказки да са ви разказвали за Лека Нощ.

И тъй, започваме…

Избор на тема и плъгини

Ако тепърва ще изграждате сайт, добре е най-напред да си съставите списък с всички основни функции, които ще предлага на потребителите. А под него може да добавите и някои желани, но незадължителни опции.

Тема

Ако бързодействието ви е приоритет, най-добре да си избиете от главата идеята за визуално претрупан сайт с огромни и детайлни изображения, както и с изумителни ефекти и анимации. Или пък всички възможни опции за настройка на външния вид в админ панела.

Това на практика изключва всички теми в ThemeForest.net.

Ясно е, че за една огромна част от уебмастърите това е основното място за шопинг на темичка за новия сайт, но стандартите на тоя marketplace, а и очакванията на потребителите му, са довели до напълването му с меганатоварени, универсални продукти, всеки от които се опитва да задоволи всички възможни нужди, които би могъл да има клиентът („one theme fits them all“).

Което пък води до т.нар. bloat – раздута функционалност, голяма част от която не се използва, но въпреки това гълта сървърни ресурси и затлачва браузърите на посетителите на сайта. Особено на мобилните устройства.

Същото се отнася и за builder-ите от рода на Elementor и Divi. И двата генерират неприятно количество допълнителен markup и зареждат тежки stylesheet и JavaScript файлове на всяка страница, независимо дали има нужда от тях на конкретното място.

Предвид горното и ако скоростта на зареждане е приоритет, най-целесъобразно би било да се спрете на лека и семпла тема, която да доработвате при нужда. Или тема с конкретно предназначение и оптимизирана за конкретна цел, т.е. такава която не предлага всевъзможни опции за къстъмизация и не се опитва да бъде едновременно блогинг + онлайн магазин + портфолио тема.

Разбира се, при наличие на съответния бюджет, оптималният вариант би бил да наемете професионалист да направи тема конкретно за вашите нужди и в която няма да има нищо излишно.

Плъгини

Имате подготвен списък (или ясна идея в главата си) с нужните функционалности, които трябва поддържа сайтът, нали?

Такъв списък ще ви помогне в избора на плъгини и ще ви предпази от инсталиране на излишни неща и залитания от сорта на „А, гледай какъв красив слайдер има на тоя сайт – чакай да видя как да си сложа и аз такъв…“

Предварително тестване на сървърното натоварване

Независимо дали подготвяте нов сайт или целите подобряване на скоростта на вече съществуващ, бих ви препоръчал да тествате всеки един плъгин и всяка една тема на локалния си компютър.

Целта е да добием представа за допълнителното натоварване на сървъра (backend), което причинява конкретният плъгин (или тема).

Какво имам предвид:

1) Използвате (инсталирате на компютъра си) софтуер като WAMP или XAMPP за емулация на сървърна среда – уеб сървър, сървър за база данни, както и скриптов език (PHP).

2) Инсталирате WordPress.

3) Включвате debug режим като във файла wp-config.php проверявате за наличието на ред:

define( 'WP_DEBUG', true );

(добавяте, ако липсва или го редактирате, ако трябва)

4) Добавяте плъгин, наречен Debogger и го активирате. Не обръщайте внимание, че не е ъпдейтван от 10 години.

5) Отваряте frontend частта на WordPress инсталацията (това, което ще виждат потребителите, а не админ панела!). Най-долу ще видите следното инфо, генерирано от Debogger:

Запишете си или запомнете числовите стойности. Това ви е „сървърното“ натоварване на голата WordPress инсталация.

Вече можете да започнете да инсталирате желаните теми и плъгини – един по един.

След всяка инсталация на плъгин/тема, презареждате фронтенда и поглеждате долу числата. С колко са се повишили?

Пример: ако най-напред инсталирате и активирате WooCommerce, ще видите, че броят на заявките (queries) към базата данни се е УДВОИЛ, както и времето за генериране на страницата.

Не се съсредоточавайте върху конкретните стойности, а по-скоро гледайте на тях като на относително (процентно) увеличение.

Идеята на цялото упражнение е да добиете ясна представа доколко ще натовари сървъра конкретния набор от плъгини + тема.

Излишно е да казвам, че ако забележите брутално увеличение на Debogger стойностите след активиране на някой плъгин, ще е добре да потърсите допълнителна информация за него, като например мнения от други потребители. Може да се наложи да се огледате за алтернативен, по-лек плъгин.

Естествено, в някои случаи няма да има алтернатива, понеже въпросният тежък плъгин добавя ключова за проекта ви функционалност и няма как да се лишите от него. В такива случаи ще трябва да се стремите да „орежете“ от останалите плъгини.

Дотук с backend (сървър) оптимизирането. Поне на тоя етап.

Не се вманиачавайте в оптимизирането на сървъра!

Освен в някои крайни случаи или наложени ограничения от самия хост, много по-голям ефект върху скоростта на един сайт има тежестта на frontend-а, т.е. това, което зареждат в браузъра си посетителите на сайта.

Следващата част от оптимизацията предполага, че вече сте инсталирали сайта на хостинг сървъра си (не на локалния компютър).

Измерване на настоящата скорост

Първото нещо, което следва да направим, ако имаме усещането, че сайтът не зарежда задоволително бързо, е да използваме някой инструмент за диагностика.

Може би най-добрият е GTMetrix. Просто пействате адреса на сайта си и натискате бутона. Изчаквате докато генерира репорта и поглеждате какво е положението…

Първо, до голяма степен може да игнорирате двата Performance Scores: PageSpeed и YSlow. Много по-важни са:

• Fully Loaded Time – за колко секунди зарежда началната страница
• Total Page Size – общата тежест на страницата в килобайт
• Requests – броят HTTP заявки, които прави браузърът към сървъра.

Ето един примерен резултат от произволен сайт, където положението е плашещо:

Обърнете внимание на времето за зареждане – 20 секунди. Кой би чакал 20 секунди докато му зареди уеб страница?!

Размерът на страницата донякъде обяснява нещата – потребителите трябва да чакат източването на цели 10 мегабайта.

Броят заявки в случая е висок, но не прекалено.

След това цъкнете по-долу на таб „Waterfall“ и сложете курсора върху най-горния ред. Ще изскочи popup с допълнително инфо. Обърнете внимание на стойността на Waiting (лилавото):

Тези 328 милисекунди са времето, което е отнело на сървъра да „сглоби“ страницата и да започне да я изпраща към браузъра. Това на практика ви е backend performance-ът – нещото, което тествахме с Debogger по-рано. Зависи от това дали се сервира кеширана страница или тепърва се генерира от PHP (скриптовия език) и MySQL (сървъра за бази данни). Ако тепърва се генерира, зависи най-вече от броя и от сложността на заявките (queries) към базата данни, както и от големината на самата база данни.

Ето пример за друг уебсайт, който видимо има нужда от смяна на хостинга:

Това са 583 милисекунди, или повече от половин секунда преди въобще да започне даунлоуда на страницата. При положение, че е препоръчително да се стремим към по-малко от 1 секунда за ПЪЛНО зареждане на страницата в браузъра, това изглежда като прекалено дълго забавяне от страна на сървъра.

Идеалната стойност на този показател е нещо под 200-250 ms. Ако е доста повече, вероятно е добра идея да преместите сайта на елитен (и нескъп) WordPress хост като SiteGround.

В случая имаме 328 ms чакане, което не е чак толкова зле и следва да си извадим заключението, че забавянето идва основно от фронтенда (картинки, stylesheets, JavaScripts, шрифтове).

За сравнение – в повечето случаи трябва да гоните по-малко от 2-3 секунди за зареждане. Една огромна част от посетителите на сайта няма да чакат повече, а просто ще го затворят преди да е заредил.

Освен това забравете Гугъл да ранкне сайта ви нагоре в SERP, съответно едва ли ще получите кой знае какъв органичен трафик. Вече е обявено, че скоростта на зареждане ще стане дори още по-голям фактор при оценяването на сайтовете от търсачките!

Дотук ясно, сега е време да видим…

Кое точно по фронтенда затормозява браузъра?

Точен и детайлен отговор на това можем да получим, като загледаме по-надолу същия таб Waterfall на резултата от GTMetrix. Там са изредени всеки един от въпросните 64 външни файла, генериращу съответните 64 HTTP заявки.

Интересуват ни най-големите (и проблемни) файлове, затова цъкаме на заглавието на колонката Size, за да ни ги подреди по размер и да покаже най-големите горе:

В случая, най-горе виждаме доста на брой и ОГРОМНИ като обем .jpg и .png файлове, т.е. картинки.

Сивата част на лентичката отдясно на всеки ресурс (файл) показва колко време е отнело на браузъра да свали всеки от тях. Разбираемо, виждаме доста дълги сиви сегменти. Ако сложим курсора върху първия, ще покаже цели 8.9 СЕКУНДИ.

Ако ви е станало интересно, може да отделите известно време да прегледате и останалите файлове, за да си изградите по-добра представа за типовете файлове, големината им и колко време отнема техният даунлоуд.

Диагнозата е що-годе поставена, време е да се захванем с подобряване на ситуацията или с…

Оптимизиране на WordPress сайта

В случая установихме, че оптимизацията на бекенд частта не е приоритет и не е спешно да се засилваме да сменяме хостинга или нещо от сорта. Затова се фокусираме върху:

Олекотяване на фронтенда

Общо взето, имаме да свършим следните неща:

1. Намалим размера на показваните картинки като ги изрежем и/или компресираме и/или конвертираме в по-подходящ формат.
2. Махнем стайлшийтовете и скриптовете от страниците, където не се използват.

Най-напред бих се замислил дали въобще има нужда от всяка една от големите изображения.

Ако отворим разглеждания сайт, ще видим, че те са използвани като слайдове в слайдер елемент. Това означава, че чакаме зареждането на поне няколко от тях без каквато и да била визуална „полза“, просто защото така или иначе в началото ще видим само първия, а останалите ще останат скрити.

С две думи, помислете дали не можете да минете и без слайдер на сайта си.

Ако сте се решили да разкарате някоя и друга не толкова важна картинка – чудесно. Следващата стъпка е да видим дали можем да компресираме тези, от които не искате да се лишите.

Компресиране

Пак ще използваме за пример същия сайт – виждаме че най-голямата картинка е 966 килобайта. Още първосигнално това изглежда прекалено много.

Най-лесно е да използваме онлайн инструмент като CompressJPEG. Качваме примерната картинка (966 KB) и получаваме компресиран вариант от само… 402 KB. Това е повече от 2 пъти по-малко!

Още една хубава новина е, че ако внимателно сравните компресираната и некомпресираната версия, едва ли ще забележите каквато и да било разлика в качеството (аз поне не успях).

Формат на изображенията

Ако се окаже, че в сайта ви има картинки с разширение .png, препоръчително е да се уверите, че това е оптималният формат за всяка една от тях.

.PNG се използва за изображения с прозрачни области, като например лога и фавикони. Повечето снимки с това разширение обикновено са прекалено големи и най-вероятно би било удачно да бъдат конвертирани в .JPG посредством инструмент като PNG2JPG.

Но внимавайте! В някои случаи .PNG е по-оптималния вариант, с по-малък размер от .JPG. Това обикновено се среща при снимки с малък брой цветове, предимно текст, схеми с прави линии и разни такива…

Преоразмеряване на изображенията

Следващото нещо е да се уверим, че картинките в сайта ни не са с излишно големи ширина и височина. Поглеждаме пак същата примерна картинка и виждаме, че е 2500х1200 пиксела, а на страницата е ограничена до 1176х564 пиксела.

Това донякъде има смисъл ако искаме изображението да изглежда идеално на Retina или други дисплеи със scale ratio над 1.0. Понеже Ретина е с ratio 2.0, може да намерим за целесъобразно да използваме ДВОЙНО по-голям размер.

В нашия случай това би означавало да умножим 1176 х 2 = 2352 и 564 х 2 = 1128, за да получим размера, които ни трябва – 2352х1128. Това е съвсем малко по-малко от реалния размер 2500х1200, но можем да спестим някой и друг килобайт ако все пак я понамалим.

Най-лесно можем да преоразмерим картинка в WordPress като отворим Media – Library (Файлове – Библиотека) и я намерим там. Цъкаме отгоре и след това върху бутона долу „Редакция“.

Горе вдясно можете да въведете новите размери и след това да натиснете „Преоразмеряване“.

Готови сте с картинките? Чудесно, в много случаи това би оказало драматично подобрение в скоростта на сайта, точно защото обикновено изображенията утежняват с най-много фронтенд частта.

Следващите стъпки са по-сложни и предполагат по-задълбочени познания по WordPress, затова може би е добра идея да потърсите помощта на професионален програмист.

За да си спестите време в обяснения какво точно искате, може просто да му покажете това ръководство.

Премахване на stylesheets и scripts от страниците, където не се използват

Добре написаните плъгини и теми се стремят да зареждат собствените си ресурси – файлове със стилове и скриптове, САМО на местата, където реално се използват.

За съжаление, горното е по-скоро изключение, отколкото правило. Дори суперпопулярни теми и плъгини, написани от авторитетни автори и компании, най-често си зареждат външните файлове глобално и в резултат товарят всяка една страница, която отвори потребителят.

Какво можете да направите по въпроса?

Най-лесно е да използвате плъгина Asset CleanUp: Page Speed Booster. Чрез него можете да изключите който решите ресурс от която и да е страница или пост в WordPress сайта.

Използването му е лесно – след активацията му, в админ частта на всяка страница или пост долу ще видите допълнителни секции (metaboxes), съдържащи списък с всички външни файловете, които се зареждат на въпросната страница/пост. Плюс опцията да ги изключите.

Сложното тук е как да разберете кое е безопасно да махнете и изключването на кое би счупило страницата…

Както предупредих по-горе, това е по-скоро работа за специалист.

Всяка тема и всеки плъгин добавят най-различни неща, така че е трудно да дам универсална рецепта или дори общи насоки. Опитен WordPress разработчик би прегледал кои файлове се зареждат от кои плъгини, а след това би проучил къде всеки от плъгините добавя своята функционалност.

Например, един quiz плъгин не би трябвало да зарежда своите скриптове и стилове на други места освен на страниците (или постовете) където са изобразени въпросните куизове.

Излишно е да се споменава, че изчистването на ненужните ресурси е от особена важност за НАЧАЛНАТА страница (homepage) на един сайт, понеже за повечето уебсайтове това е най-посещавания адрес (URL).

Разбира се, компетентен програмист може да свърши цялата тази работа и без помощта на въпросния плъгин, но по тоя начин му предоставяте готов и удобен интерфейс, което със сигурност ще му спести време, а на вас – пари.

Ако нямате нужния опит, но все пак решите да се пробвате и да покликате, ТЕСТВАЙТЕ усърдно, за да се уверите , че всичко работи нормално след творческата ви интервенция!

Финал

Да не забравите след като чинно и старателно сте преминали през горните стъпки, да тествате наново в GTMetrix? Да се надяваме, че новият резултат ще е далеч по-удовлетворителен. Ако не е – връщате се в началото и повтаряте, като гледате да не пропуснете нещо този път…