Нуждае ли се светът от поредната статия, сравняваща WordPress плъгини за кеширане? Не съм сигурен. И все пак, понякога съм толкова обсебен от някоя идея, че реших да седна и да инсталирам няколко тестови WordPress сайта и да добавя плъгини за кеширане.

Ако не друго, поне е забавно 🙂

Повечето статии по въпроса, на които съм попадал, са фокусирани върху подобрението на скоростта на зареждане на сайт, което се постига с този или онзи плъгин. Тъй като работя в уеб хостинг компания, моята гледна точка е малко по-различна. Нашата компания, ICDSoft, предлага споделени хостинг услуги и обикновено препоръчваме кеширащи плъгини на клиенти, които вече достигат лимитите на споделените си планове. По този начин, производителността на сайтовете им се повишава без да се променят системните ресурси, а в същото време клиентите ни спестяват пари, тъй като моментът, в който ще трябва да сменят плана си към по-мощен, се отлага във времето. От тази гледна точка, има голяма полза от WordPress плъгините за кеширане.

В тази статия ще се опитам да разгледам две неща – подобрението на скоростта на достъп от една страна и понижението на CPU потреблението от друга.

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

Изборът ми на плъгини за този тест може да Ви се стори малко странен.

Винаги съм си мислел колко по-добре би било ако даден WordPress сайт използва SQLite база данни вместо MySQL. Дори съществува плъгин, който прави това възможно. За съжаление, постигането на тази цел би било по-скоро бреме, тъй като базата на съществуващ сайт не може да бъде преобразувана от MySQL към SQLite – опцията е налична само при нова инсталация на WordPress. Все пак опитах с нов сайт и той наистина направо летеше. За съжаление, плъгинът няма нова версия от четири години насам и на практика няма никаква поддръжка, а да се използва подобен плъгин е прекалено рисковано. И така, какъв бе следващият най-добър вариант? Кеширащ плъгин, който запазва вече кешираната информация в SQLite база данни. Тук на дневен ред излиза сравнително неизвестният Yasakani Cache, който прави точно това.

Swift Performance Lite е безплатната версия на платения плъгин Swift Performance. Възторжените коментари от други потребители дори за безплатната версия привлякоха вниманието ми, затова реших да тествам на каква цена идва увеличението на скоростта.

WP Super Cache е утвърден инструмент, който се разработва от същата компания, създала WordPress – Automattic. Тъй като това е плъгинът, който по принцип препоръчваме на нашите клиенти, съвсем естествено избрах и него за този тест.

И така, за този тест имаме един новак (Swift Performance Lite), един ветеран (WP Super Cache) и една неизвестна (Yasakani).

Отворих четири хостинг акаунта на споделените ни сървъри, всеки от тях използващ Бизнес хостинг плана ни (100 GB дисково пространство и 5000 GB месечен трафик) – по един за всеки плъгин и един акаунт с WordPress сайт без никакво кеширане за сравнение. 

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

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

Наборът от инструменти WP-CLI и SSH достъп са налични безплатно и по подразбиране с всички хостинг планове, предлагани от ICDSoft, като по този начин можете лесно да смените адреса и всички линкове на даден WordPress сайт, ако искате да го преместите.

За да е по-точно измерването на CPU потреблението, направих следните неща предварително:

  • Спрях автоматичните ъпдейти на WordPress и планираните задачи (cron jobs) чрез добавянето на следните редове във файл wp-config.php:
    define( 'WP_AUTO_UPDATE_CORE', false ); 

    define('DISABLE_WP_CRON', 'true');
  • Основната планирана задача на WordPress минава на всеки час.
  • По време на теста не съм отварял таблото за управление на WordPress и внимавах да няма някой прозорец, в който да е отворено таблото, за да предотвратя изпълняването на admin-ajax.php.

Очаквах тестът да премине в две фази, но той реално премина в три:

Фаза 1: Използвах акаунта, създаден по подразбиране, за да тествам скоростта на сайта с всеки плъгин, използвайки два онлайн инструмента – GTmetrix и Pingdom. Няколко версии на PHP са налични на нашите сървъри, като пуснах общо три теста за всеки плъгин (по един със следните версии на PHP – 5.6, 7.1 и 7.2):

GTmetrix x (без кеширане + три кеширащи плъгина) x (три версии на PHP)
Pingdom x (без кеширане + три кеширащи плъгина) x (три версии на PHP)

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

Фаза 2: Следващата фаза беше посветена на тестването на CPU потреблението от всеки плъгин. Тествах и как то се влияе от смяната на PHP версията.

Използвах три от акаунтите, които бях отворил, да настроя всеки от трите плъгина, а в четвъртия бях оставил WordPress инсталация без кеширащ плъгин. Във всеки акаунт бях настроил конкретна версия на PHP за 24 часа (5.6, след това 7.1 и накрая 7.2).

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

Докато тествах, забелязах нещо странно – дневното CPU потребление за всеки акаунт беше ненормално високо въпреки употребата на кеширащи плъгини. Тогава забелязах странна заявка към:

wc-ajax=get_refreshed_fragments

Тя беше бавна и на всичкото отгоре не беше кеширана.

Демо съдържанието, което бях добавил, идваше с потребителска кошница от WooCommerce плъгина и горната заявка беше част от този плъгин.

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

В това ръководство можете да видите как да изключите определени страници от генерирането на подобни заявки. 

Ще намерите дори информация как да ограничите заявките единствено до страници, които са част от WooCommerce. Точно това направих и аз, а след това започнах тестовете отначало.

Фаза 3: Повторих тестовете с GTmetrix и Pingdom от Фаза 1 с вече оптимизираните WordPress сайтове.

Конфигуриране на плъгините

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

Yasakani Cache – според началната страница на този плъгин, той ще работи по-бързо ако всички php файлове се обработват от скрипт, който е част от плъгина. За целта, създадох файл .user.ini в WordPress папката и в него копирах следния ред, предложен от плъгина:

auto_prepend_file = "/home/yasakani/www/www/wp-content/yasakani-cache-exload.php"

Скриптът предлага и опция за намаляването на кода на WordPress страниците.

WP Super Cache – според собствените ни тестове през годините, този плъгин работи най-добре, когато е пусната опцията Expert mode. Плъгинът добавя набор от директиви в .htaccess файла на WordPress сайта, затова пуснах въпросната опция и се уверих, че директивите са добавени, където трябва.

Swift Performance Lite – когато активирате плъгина, ще минете през няколко стъпки за конфигуриране на различни опции.  Спрях gzip компресията, която плъгинът ползва, за да уеднаквя цялостната конфигурация на трите плъгина, тъй като останалите два не използват тази компресия след обработка на информацията.

Резултати от тестовете в WordPress

Ще започна с резултатите от тестовете от GTmetrix и Pingdom. Долните таблици показват скоростта на отваряне в секунди, измерена от двете онлайн услуги:

GTmetrix (с WooCommerce)

  Без кеширанеYasakaniWP Super CacheSP Lite
PHP 5.6Тест 1

2.300

2.500

1.700

2.800

 Тест 2

2.400

1.800

1.700

2.500

 Тест 3

2.400

1.800

2.600

1.700

Средно за PHP 5.6 

2.367

2.033

2.000

2.333

PHP 7.1Тест 1

2.500

1.700

1.700

2.200

 Тест 2

2.200

1.700

2.200

1.900

 Тест 3

2.200

2.400

2.200

1.700

Средно за PHP 7.1 

2.300

1.933

2.033

1.933

PHP 7.2Тест 1

2.300

2.800

1.600

1.700

 Тест 2

2.100

1.800

1.500

2.500

 Тест 3

2.200

1.700

2.700

1.700

Средно за PHP 7.2 

2.200

2.100

1.933

1.967

Средно за всички: 

2.289

2.022

1.989

2.078

Не знам защо, но резултатите от GTmetrix изглеждаха доста непостоянни. Разликата между две зареждания на сайта с един и същ плъгин и една и съща версия на PHP достигаше до 900 милисекунди, а това беше странно.

Очаквано, резултатите без кеширащ плъгин бяха по-бавни, но не чак толкова. Победителят в този тест бе WP Super Cache, макар че разликата между усреднения резултат за трите плъгина беше в рамките на 100 милисекунди.

Едно нещо веднага ми се наби на очи – със Swift Performance Lite, кешираните страници бяха предварително обработени значително от плъгина.

Докато размерът на страницата и броят заявки към други страници бяха в общи линии стандартни, страницата, доставена от SP Lite беше осезаемо по-малка като размер, а заявките за доставянето ѝ бяха намалели драстично – от 46 (48) на 14!

Следва таблицата с резултати от Pingdom.

Pingdom (с WooCommerce)

  Без кеширанеYasakaniWP Super CacheSP Lite
PHP 5.6Тест 1

2.800

1.660

1.440

1.310

 Тест 2

2.750

1.640

1.250

1.260

 Тест 3

2.940

2.050

1.410

1.060

Средно за PHP 5.6 

2.830

1.783

1.367

1.210

PHP 7.1Тест 1

2.690

1.540

1.530

1.170

 Тест 2

1.950

1.420

1.430

1.160

 Тест 3

2.150

1.890

1.480

1.160

Средно за PHP 7.1 

2.263

1.617

1.480

1.163

PHP 7.2Тест 1

2.570

1.810

1.320

1.200

 Тест 2

2.760

1.790

1.220

1.280

 Тест 3

2.480

1.760

1.490

1.600

Средно за PHP 7.2 

2.603

1.787

1.343

1.360

Средно за всички: 

2.566

1.729

1.397

1.244

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

Докато зареждането на почти всички некеширани страници отнемаше над две секунди, всички кеширани страници освен една имаха време за зареждане под две секунди. Сериозната оптимизация от Swift Performance Lite си казваше думата – страниците зареждаха два пъти по-бързо от некешираните страници. WP Super Cache беше на второ място с малка разлика, а Yasakani на трето, но все пак с доста добър резултат.

Броят тестове с всяка версия на PHP не беше достатъчен за статистически представителен резултат, но въпреки това и двете групи тестове (с GTmetrix и Pingdom) показват, че смяната на версията от 5.6 на 7.1 има сериозно отражение върху скоростта.

Както бях споменал по-горе, като цяло WooCommerce страницата зареждаше доста бавно дори и кеширана. След като открих и спрях ajax заявките, скоростта на зареждане се повиши значително.

Можете да видите резултатите от новите тестове отдолу:

GTmetrix (Без WooCommerce)

  Без кеширанеYasakaniWP Super CacheSP Lite
PHP 5.6Тест 1

1.900

1.300

1.200

1.200

 Тест 2

2.400

1.300

1.200

1.200

 Тест 3

2.100

1.300

1.200

1.300

Средно за PHP 5.6 

2.133

1.300

1.200

1.233

PHP 7.1Тест 1

1.900

1.300

1.200

1.200

 Тест 2

1.900

1.300

1.300

1.300

 Тест 3

1.800

1.200

1.200

1.200

Средно за PHP 7.1 

1.867

1.267

1.233

1.233

PHP 7.2Тест 1

1.800

1.300

1.200

1.300

 Тест 2

1.800

1.300

1.200

1.500

 Тест 3

1.800

1.300

1.400

1.300

Средно за PHP 7.2 

1.800

1.300

1.267

1.367

Средно за всички: 

1.933

1.289

1.233

1.278

Pingdom (Без WooCommerce)

  Без кеширанеYasakaniWP Super CacheSP Lite
PHP 5.6Тест 1

1.820

1.160

1.060

0.945

 Тест 2

1.830

1.160

1.250

0.887

 Тест 3

2.540

1.260

1.170

0.979

Средно за PHP 5.6 

2.063

1.193

1.160

0.937

PHP 7.1Тест 1

1.660

1.390

1.150

0.908

 Тест 2

2.270

1.220

1.050

1.010

 Тест 3

2.320

1.090

0.943

1.120

Средно за PHP 7.1 

2.083

1.233

1.048

1.013

PHP 7.2Тест 1

1.590

1.190

1.090

1.250

 Тест 2

1.600

1.150

0.962

0.907

 Тест 3

2.230

1.190

1.130

0.821

Средно за PHP 7.2 

1.807

1.177

1.061

0.993

Средно за всички: 

1.984

1.201

1.089

0.981

Този път, дори некешираните страници често зареждаха за по-малко от две секунди.

Резултатите от GTmetrix отново са доста близки, като победителят е WP Super Cache. С него, средното време за зареждане намалява с около 36%. Резултатите от другите два плъгина обаче са с до 60 милисекунди разлика, така че няма осезаема разлика между тях.

Резултатите от Pingdom са доста различни и победителят от тестовете с този инструмент е доста по-ясен. Според него, най-голямо увеличение на скоростта на WordPress сайта се постига със Swift Performance Lite (50.51% по-бързо зареждане). WP Super Cache е втори с 45% по-добра скорост, а Yakasani Cache е трети с 39% подобрение.

Влияние на WordPress плъгините за кеширане върху CPU потреблението

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

19.12.2018: PHP 5.6

20.12.2018: PHP 7.1

21.12..2018: PHP 7.2

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

Тъй като контролният акаунт не използва никакво кеширане, той показва разликата в потреблението, която е единствено в резултат от смяната на PHP версията. Първата графика показва потреблението по часове след два и половина дни:

Само последните две колонки от таблицата с усредненото дневно потребление са приложими, тъй като за предишните дни потреблението е много по-високо заради ajax заявката, генерирана от WooCommerce.

Повече от ясно се вижда в графиката по часове кога е сменена PHP версията от 5.6 на 7.1, тъй като CPU потреблението рязко спада с около 25%. Няма съществена разлика при смяната на версията на 7.2 след това.

Отдолу можете да видите дневната статистика след края на теста:

Началната дата е отбелязана и дневното потребление за този ден е 41 CPU минути, но то пада на 32 CPU минути след смяната на версията на 7.1. Потреблението е без промяна с PHP версия 7.2. С други думи, освен ако не използвате WordPress тема и/или плъгин, несъвместими с PHP 7.х, няма никакъв смисъл да използвате PHP 5.6. Дори и тогава би било по-добре да видите дали и как можете да ги направите съвместими с по-нова PHP версия. Все пак, WordPress.org препоръчва на собствениците на сайтове да използват версия 7.2.

Yasakani Cache

Същият тест с Yasakani Cache показа, че дори и по-скромен плъгин може значително да подобри CPU потреблението. Резултатите показват, че няма значителна разлика по часове независимо от смяната на PHP версията:

Дневното потребление е 7 CPU минути за всеки от дните на теста. Сравнете този резултат с 41/32 минути без кеширащ плъгин и ползата от употребата на Yasakani Cache ще Ви стане ясна веднага.

WP Super Cache

WP Super Cache е с подобно поведение – без съществена разлика по часове, но CPU потреблението е дори по-ниско – около 5 CPU минути с PHP 5.6 и 4 CPU минути с PHP 7.1 и PHP 7.2.

Swift Performance Lite

SP Lite плъгинът генерира най-интересната CPU графика. Въпреки, че страниците, обработени от този плъгин, зареждат впечатляващо бързо, няма почти никаква промяна в CPU потреблението с PHP 5.6. Предполагам, че това се дължи на по-интензивната работа на плъгина при обработката на страниците. Както споменах по-рано, по-високата скорост на зареждане идва за сметка на повече обработка на съдържанието от страна на плъгина. Преглеждайки изходния код бих казал, че някои картинки и шрифтове се интегрират директно в кешираните страници. Това намалява броя заявки, генерирани от тези страници, но е за сметка на по-интензивна обработка от страна на плъгина, което на свой ред повишава CPU потреблението.

Интересното е, че горното важи единствено за PHP 5.6. CPU потреблението спадна веднага след смяната на PHP версията на 7.1, което ме навежда на мисълта, че може би плъгинът не е оптимизиран добре за работа с версия 5.6. Отдолу можете да видите графиката на почасовото потребление – откроява се резкият спад в 00:00 на 20.12.2018:

Както изглежда, CPU потреблението на WordPress сайта със Swift Performance Lite зависи директно от PHP версията, която се използва. След смяната на версията на 7.2, потреблението падна още повече:

PHP 5.6: 46 минути

PHP 7.1: 7 минути

PHP 7.2: 5 минути

Честно казано, бях малко изненадан от тези резултати, тъй като статистиките с PHP 5.6 ми се струваха донякъде ненормални и ме караха да си мисля, че може би съм пропуснал нещо. Затова реших да върна версията на PHP на 5.6 на 23-ти декември и CPU потреблението веднага скочи. Вече бях сигурен, че всичко е както трябва и че явно плъгинът така работи.

Заключение

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

Трябва да решите и какво Ви е по-важно – по-висока скорост на зареждане, оптимизиране на потреблението на системни ресурси, или и двете неща по равно.

Swift Performance Lite предлага най-висока скорост на зареждане на страниците от трите тествани плъгина. Те зареждат по-бързо от кешираните от другите два плъгина страници, но това има своята цена. Тестовете, които проведох, бяха със сравнително малък сайт, като зареждах само главната страница. Ако имате голям сайт с няколко стотин или няколко хиляди страници, тяхното кеширане ще доведе до голямо увеличение на системните ресурси, от които се нуждае сайтът, за да работи. Ако използвате споделен хостинг план, можете да тествате плъгина стига да имате по-малък сайт и потреблението Ви не приближава горната граница на системните ресурси, с които идва планът ви. И все пак, плъгинът има доста опции, които можете да настроите, така че може би има начин да намерите златната среда между скорост и потребление на системни ресурси.

WP Super Cache и Yasakani Cache без никакви изненади увеличават скоростта, с която се отваря сайта.

И двата осигуряват добра производителност на сайта, но WP Super Cache е по-бърз и по-ефективен от Yasakani. Това може би се дължи на Expert mode опцията, която разчита на mod_rewrite директивите. Yasakani доставя страниците, осланяйки се на PHP и SQLite, което е неизбежно по-бавният вариант в сравнение с mod_rewrite

Като предимство на Yasakani бих отбелязал, че намалява кода на кешираните страници и преподрежда JavaScript файловете, които се зареждат, което от своя страна намалява цялостния размер на страниците. Въпреки това, този плъгин е най-бавният от всички.

Така че ако искате да забързате сайта си, но в същото време да намалите натоварването на сървъра, логичният избор измежду тези два плъгина би бил WP Super Cache. Yasakani Cache също повишава производителността, но ако трябва да съм честен, не се сещам за причина да го предпочетете в този случай. Разбира се, нищо не пречи да го използвате, за да подкрепите екипа, който го разработва, а сайтът Ви няма да загуби нищо от това.

Този тест не претендира да е подробен и всеобхватен, тъй като има много други плъгини, които можете да използвате – както безплатни, така и платени. Ако имате желание, можете да пробвате популярни плъгини като W3 Total Cache, WP Rocket, Comet Cache и т.н., да видите доколко всеки от тях повишава производителността на Вашия сайт и да прецените кой би Ви свършил най-добра работа.

От Support 58

Avatar
Author

ICDSoft е българска компания с дългогодишен опит в хостинг индустрията. Държим на качество и честност в предоставяните услуги, а екипът ни от професионалисти е винаги готов да Ви помогне при нужда.