Прискорюємо адмінку WordPress – відключаємо агресивну перевірку оновлень

Це, на мій погляд, обов’язкова фітча для всіх сайтів на WordPress, як кажуть – маст хев. Чому? Тому що перевірка оновлень має йти фоном і ніяк інакше, за дуже рідкісним винятком! Давайте розберемося до чого.

Як повністю відключити авто-оновлення для ядра, тим, плагінів, читайте в окремій статті: Авто-оновлення WordPress .

Причина гальм у адмінці

Думаю кожен, хто більш-менш пов’язаний з WordPress, помічав періодичні гальма при заході на будь-яку сторінку адмінки: в консоль адмінки, на сторінку плагінів або тим (тут особливо!). Ці гальма трапляються періодично: то повільно, то швидко.

Відбувається так через перевірки WordPress про нові версії: ядра, плагіни, теми та переклади.

Справа в тому, що для перевірки нових версій при генерації сторінки PHP надсилає HTTP запит, а точніше 3 запити: ядро, теми, плагіни. Якщо є платні плагіни, то на кожен плагін зазвичай є ще один свій запит. При HTTP запиті в PHP генерація сторінки зависає, поки кожен запит не отримає результат, а на кожен запит йде в середньому 0,3 – 1 секунда. Ось і виходить, що сторінка висне на 2-4 секунди.

Частота цих перевірок на різних сторінках адмінки така:

  • На сторінці Консоль Обновления– раз на хвилину.
  • На сторінці Плагиныабо Внешний вид > Темы– раз на годину.
  • На будь-якій сторінці в адмінці – раз на 12 годин (двічі на день).

Крім того, ці перевірки спрацьовують під час події admin_init , а значить при AJAX запитах. Незважаючи на те, що це відбувається раз на пів дня, все ж таки неприємно коли хтось буде ловити AJAX запит із затримкою в 3 секунди… Крім того, така поведінка для AJAX запитів працює і у фронтенді, а це вже зовсім недобре. .

Фронт та адмінка

У фронті всі перевірки висять на кроні і від спрацьовують у фоновому режимі. Коли користувач заходить на сайт, WP запускає крон (з певною періодичністю), причому робить це без затримок (фоном). Якщо в крон-задачі настав час перевірки, то вона відбувається… У фронті все гаразд і нічого не гальмує.

В адмінці відбувається “агресивна перевірка” не тлом, а прямий при генерації сторінки. Зроблено так для того, щоб при заході в адмінку ми одразу в меню бачили, що є оновлення. Якби була фонова перевірка, то щоб побачити наявність оновлень, нам потрібно було б зайти на сторінку ще раз. Якщо порівнювати цей мінус із гальмами, я однозначно вибираю його!

Гальма та об’єктне кешування

Якщо на сайті встановлено плагін об’єктного кешування, то ситуація з гальмами лише посилюється. Тому що коли використовується об’єктне кешування, то немає жодних часових опцій у базі даних – все пишеться в кеш, і варто очистити цей кеш, очищається все, включаючи дані про останню перевірку нових версій: ядра, плагінів, тем та перекладів.

Таким чином варто очистити об’єктний кеш і ми обов’язково ловимо 3-х секундну затримку на будь-якій сторінці адмінки. У процесі розробки часом часто доводиться очищати об’єктний кеш і щоразу після очищення сторінка вантажиться по 3-4 секундиshout

Рішення (відключаємо гальма)

Щоб позбавитися гальм, але при цьому не відключати перевірку оновлень зовсім. Вставте наступний код у файл теми functions.php , чи куди ви там вставляєте такі коди…

Цей код повністю відключає агресивну перевірку оновлень в адмінці. Але не торкається перевірки оновлень по крону. Також, якщо потрібно перевірити наявність нових версій прямо зараз, то заходимо на сторінку Консоль > Обновления– там агресивна перевірка не відключається і спрацьовує кожну хвилину.

Ось так все й має працювати, на мій погляд, із коробки. Але WP щось занадто «послужив» з оновленнями… Можливо, це змінять у майбутньому, хоча я сумніваюся… Ну а поки:

/**
 * Відключаємо примусову перевірку нових версій WP, плагінів та теми в адмінці,
 * щоб вона не гальмувала, коли довго не заходив і зайшов...
 * Усі перевірки відбуватимуться непомітно через крон або при заході на сторінку: "Консоль > Оновлення".
 *
 * @see https://wp-doc.com/filecode/wp-includes/update.php
 * @author Kama (https://wp-doc.com)
 * @version 1.1
 */
if( is_admin() ){
	// відключимо перевірку оновлень за будь-якого заходу в адмінку...
	remove_action( 'admin_init', '_maybe_update_core' );
	remove_action( 'admin_init', '_maybe_update_plugins' );
	remove_action( 'admin_init', '_maybe_update_themes');

	// відключимо перевірку оновлень під час заходу на спеціальну сторінку в адмінці...
	remove_action( 'load-plugins.php', 'wp_update_plugins');
	remove_action( 'load-themes.php', 'wp_update_themes');

	// залишимо примусову перевірку під час заходу на сторінку оновлень...
	//remove_action( 'load-update-core.php', 'wp_update_plugins');
	//remove_action( 'load-update-core.php', 'wp_update_themes');

	// внутрішня сторінка адмінки "Update/Install Plugin" або "Update/Install Theme" - залишимо не заважає...
	//remove_action( 'load-update.php', 'wp_update_plugins');
	//remove_action( 'load-update.php', 'wp_update_themes');

	// подія крона не чіпаємо, через нього перевірятиметься наявність оновлень - тут все чудово!
	//remove_action( 'wp_version_check', 'wp_version_check');
	//remove_action( 'wp_update_plugins', 'wp_update_plugins');
	//remove_action( 'wp_update_themes', 'wp_update_themes');

	/**
	 * відключимо перевірку необхідності оновити браузер в консолі - ми завжди користуємося топовими браузерами!
	 * ця перевірка відбувається раз на тиждень...
	 * @see https://wp-doc.com/function/wp_check_browser_version
	 */
	add_filter( 'pre_site_transient_browser_'. md5( $_SERVER['HTTP_USER_AGENT'] ), '__return_empty_array' );
}

Плагін

За кодом цієї статті було створено плагін: Disable Aggressive Updates .

Залишити коментар

Ваша e-mail адреса не оприлюднюватиметься. Обов’язкові поля позначені *