Днес WordPress използва 33% от интернет . Той е лесен за използване, много популярен и скоро няма да отидете никъде.

Но Wordpress може да бъде бавен. И така, как да го оптимизирате?

Има много статии за това как да оптимизирате WordPress. Всъщност самият WordPress предоставя здрав водач за това как да се оптимизира.

В повечето случаи тези статии и уроци обхващат доста основни и все пак полезни понятия. Такова е използването на приставки за кеширане, интеграция с мрежи за доставка на съдържание (CDN) и минимизиране на заявките. Въпреки че тези съвети са много ефективни и дори необходими, те не разглеждат основния проблем; Повечето бавни сайтове на Wordpress са резултат от лошо или неефективно кодиране.

Wordpress може да бъде бавен, но не е задължително. Tweet

Следователно, тази статия е предназначена основно за разработчици и Компании за разработчици на Wordpress някои насоки, които могат да ви помогнат да се справите с основните причини за много проблеми с производителността на WordPress.

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

Получаване на работни места

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

• Използване на функцията 'query_posts ()': Това е много ясен подход, но проблемът е, че той отменя заявката главница което може да причини неудобство. Например, това може да е проблем, ако искаме да определим в даден момент след получаване на публикации (като в рамките на „footer.php“) с какъв тип страница си имаме работа. Всъщност официалната документация съдържа препоръчителна бележка срещу използването на тази функция, тъй като ще трябва да извикате допълнителна функция, за да възстановите оригиналната заявка. Също така, подмяната на основната заявка ще има отрицателно въздействие върху времето за зареждане на страницата.

• Използване на функцията 'get_posts ()': Това работи почти като 'query_posts ()', но не променя основната заявка. От друга страна, ‘get_posts ()’ по подразбиране изпълнява заявката към ‘suppress_files’, параметърът е зададен на ‘true’. Това може да доведе до несъответствия, особено ако използваме филтри, свързани със заявки в нашия код, тъй като публикациите, които не очаквате на дадена страница, могат да бъдат върнати от тази функция.

• Използване на класа ‘WP_query’: Според мен това е най-добрият начин за извличане на публикациите от базата данни. Той не променя основната заявка и се изпълнява в стандартната си форма, точно както всяка друга заявка на WordPress.

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

Ограничаване на заявката

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

За целта използваме параметъра „публикации на страница“.

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

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

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

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

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

Ние обаче не се нуждаем от тази информация много често. Добавянето на тези два параметъра е да деактивира тези функции и да ускори нашата заявка:

$query = new WP_Query( array( 'ignore_sticky_posts' => true, 'no_found_rows' => true ) );

Изключване на публикации от заявка

Понякога искаме да изключим определени публикации от заявката. WordPress предлага приятен и ясен начин да направите това: с параметъра 'post__no_en'. Например:

$posts_to_exclude = array( 1, 2, 3 ); $posts_per_page = 10; $query = new WP_Query( array( 'posts_per_page' => $posts_per_page, 'post__not_in' => $posts_to_exclude ) ); for ( $i = 0; $i posts ); $i++ ) { //do stuff with $query->posts[ $i ] }

Но макар това да е съвсем просто, то не е оптимално, защото генерира вътрешно подзаявка. Особено при големи инсталации това може да доведе до бавен отговор. По-бързо е да се позволи обработката да се извършва от интерпретатора на PHP с няколко прости модификации:

$posts_to_exclude = array( 1, 2, 3 ); $posts_per_page = 10; $query = new WP_Query( array( 'posts_per_page' => $posts_per_page + count( $posts_to_exclude ) ) ); for ( $i = 0; $i posts ) && $i posts[ $i ]->ID, $posts_to_exclude ) ) { //do stuff with $query->posts[ $i ] } }

Какво направих тук

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

Как

Първо, премахнах параметъра 'post__no_en' от заявката.

Тъй като заявката може да ни донесе някои публикации, които не искаме като резултат, увеличих параметъра „posts_per_page. По този начин мога да гарантирам, че дори да имам нежелани публикации в моя отговор, бих искал да имам в поставете там най-малко '$ posts_per_page желан'.

Така че, когато търся публикациите и обработвам само тези, които не са в масива „$ posts_para_exclude“.

Избягвайте сложна параметризация

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

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

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

Възползвайте се максимално от опциите на Wordpress.

Настроики API на WordPress WordPress предоставят редица инструменти за лесно зареждане или запазване на данни. Те са полезни за обработка на малки парчета информация, тъй като други механизми, които WordPress предлага (като публикации или таксономии) са твърде сложни.

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

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

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

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

// functions.php add_action( 'save_post', function ( $post_id ) { // For simplicity, we do not include all the required validation before saving // the meta key: checking nonces, checking post type and status, checking // it is not a revision or an autosaving, etc. update_post_meta( $post_id, 'is_breaking_news', ! empty ( $_POST['is_breaking_news'] ) ); } ); // front-page.php $query = new WP_Query( array( 'posts_per_page' => 1, 'meta_key' => 'is_breaking_news' ) ); $breaking_news = $query->posts[0] ?: NULL;

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

// functions.php add_action( 'save_post', function ( $post_id ) { // Same comment for post validation if ( ! empty ( $_POST['is_breaking_news'] ) ) update_option( 'breaking_news_id', $post_id ); } ); // front-page.php if ( $breaking_news_id = get_option( 'breaking_news_id' ) ) $breaking_news = get_post( $breaking_news_id ); else $breaking_news = NULL;

Функционалността варира леко от пример до пример.

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

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

Но тъй като сигурно искаме по една новина да мига, това няма да е проблем.

И в крайна сметка сме променили тежка заявка за база данни (използвайки „WP_QUERY“ с мета ключове) в проста и ясна заявка („get_post ()“ повикване), което е по-добър и по-ефективен подход.

Можем също така да направим малка промяна и да използваме преходни процеси вместо опции.

Преходните процеси работят по подобен начин, но ни позволяват да посочим времето на изтичане.

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

// functions.php add_action( 'save_post', function ( $post_id ) { // Same comment for post validation // Let's say we want that breaking news for one hour // (3600 = # of seconds in an hour). if ( ! empty ( $_POST['is_breaking_news'] ) ) set_transient( 'breaking_news_id', $post_id, 3600 ); } ); // front-page.php if ( $breaking_news_id = get_transient( 'breaking_news_id' ) ) $breaking_news = get_post( $breaking_news_id ); else $breaking_news = NULL;

Активирайте постоянен кеш

WordPress първоначално има механизъм за кеширане обект .

Опциите например се кешират с помощта на този механизъм.

Но по подразбиране кешът не е постоянен, което означава, че живее само по време на една заявка. Всички данни се кешират за по-бърз достъп, но са достъпни само по време на тази заявка.

Поддръжката на постоянен кеш изисква инсталирането на приставка за постоянен кеш.

Някои плъгини за кеш на пълна страница идват с включен постоянен плъгин за кеш (например W3 Total Cache), но други не, и ние трябва да го инсталираме отделно.

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

Може да се запитате: „Ако това е чудесна функция на WordPress, защо не е активирана по подразбиране?“

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

Ако искаме да хостваме разпределен сървър на нашия сайт, например, трябва да използваме външна кеш система (като Memcached сървър ), но ако нашият уебсайт се намира на един сървър, бихме могли да спестим пари и просто да използваме кеш файловата система.

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

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

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

AJAXing Най-бързият начин

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

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

Причината за това е, че за да използваме тези механизми, ние сме длъжни да отправим заявка за публикуване до файл, намиращ се в папката “wp-admin”. Повечето (ако не всички) приставки на Wordpress нямат нито пълен кеш на страница, нито кеш за заявки, нито обаждания на файловия мениджър.

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

След това можем да анализираме резултатите чрез JavaScript в браузъра.

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

Унищожете представата, че WordPress е бавен

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

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

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

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