Оптимізація WordPress: як прискорити сайт і покращити SEO

Привіт:) У цій статті розгляну способи, інструменти та власні спостереження оптимізації WordPress для, які використовую у своїй роботі для покращення швидкодії роботи сайту та вищих балів PageSpeed.

Розгляну кожен спосіб та інструмент детально.

Оптимізація зображень

Часто на клієнтських сайтах зустрічаються розмір файлів зображень від 400 Кб і до 3 Мб. Зазвичай така ситуація виникає через невірний вибір формату графічного файлу, а також розмірами самого зображення. Наприклад, складна фотографія може мати розміри 4000х3000 пікселів. Зазвичай для комфортного її відображення достатньо ширини у 1200 пікселів.

Мої подальші дії з оптимізації зображень залежать від кількості неоптимізованих файлів зображень.

Якщо їх до 30 штук:

• завантажую їх локально;
• пропорційно зменшую розмір фотографії (наприклад, за допомогою GIMP);
• конвертую у формат WebP;
• оптимізую файл без втрати якості (наприклад, tinypng.com, imagecompressor.com або Caesium Image Compressor);
• на сторінках сайту замінюю на новий файл.

Якщо більше 30:

• завантажую локально;
• пакетно оптимізую без втрати якості (tinypng.com, imagecompressor.com);
• завантажую із перезаписом у відповідний каталог сайту.

Якщо картинок більше тисячі (та/або періодично додаються нові на сайт):

• встановлюю та налаштовую WordPress-плагін, який оптимізує та зменшує розмір вже завантажених файлів зображень та автоматично застосовує цю процедуру для тих, які будуть завантажені у майбутньому. Наприклад, Converter for Media – Optimize images (або WebP Express). Особливістю цих плагінів є автоматичне конвертування у формат WebP та підміна на цей формат файлу у коді користувацької частини сайту. Підміна застосовується лише у тому випадку, якщо у новому форматі WebP розмір файлу зображення буде меншим за оригінальний.

Видалення зображень що не використовуються

Така робота проводиться для зменшення дискового простору. Цю задачу вирішую окремим плагіном Media Cleaner. Він коректно видаляє лише ті фото, які не прикріплені до жодного посту.

Оновлення ядра WordPress, тем і плагінів

Регулярне оновлення ядра WordPress, тем і плагінів безпосередньо впливає на швидкість роботи сайту, оскільки нові версії часто містять оптимізації продуктивності та виправлення неефективного коду. Розробники прибирають зайві SQL-запити, оптимізують роботу з кешем і адаптують код під сучасні версії PHP. Оновлення теми дозволяє позбутися застарілих підходів до підключення CSS і JavaScript, які блокують рендеринг сторінки. Актуальні плагіни краще взаємодіють між собою та з ядром WordPress, зменшуючи конфлікти й зайві навантаження. Крім того, нові версії зазвичай краще працюють із OPcache, Object Cache та серверним кешуванням. У підсумку сайт обробляє запити швидше, стабільніше тримає навантаження і показує кращі результати в PageSpeed та Core Web Vitals.

Вимкнення зайвих плагінів і тем

Часто на клієнтських сайтах помічаю використання зайвих плагінів (див. Скільки плагінів можна встановити на WordPress). Наприклад, плагін, який не використовується взагалі або був застосований всього лише один раз.

Також вимикаю зайві теми. Залишаю лише активну та одну із стандартних тем WordPress. Останню рекомендується залишати у випадку, якщо в активній темі виникне критична помилка, та система автоматично увімкне тему за замовчуванням.

Перехід на нову версію PHP

Часто клієнтські WordPress сайти працюють на застарілих версіях PHP. У цьому випадку на хостингу оновлюю до останньої, яка працює швидше за рахунок багатьох оптимізацій, поліпшення обробки типів і кешування.

Перехід на LiteSpeed Web Server

LiteSpeed Web Server дає WordPress ключову перевагу за рахунок серверного Page Cache, який віддає готовий HTML без запуску PHP і ядра CMS. Це суттєво зменшує TTFB і навантаження на сервер, особливо на сайтах з високим трафіком або WooCommerce. На відміну від PHP-кеш-плагінів, LSCache працює на рівні веб-сервера і тісно інтегрований з хуками WordPress. LiteSpeed підтримує HTTP/3, QUIC, Brotli та сучасні версії PHP "з коробки", без складних налаштувань. У результаті продуктивність WordPress визначається якістю теми й плагінів, а не обмеженнями серверної інфраструктури.

Збільшення ліміту оперативної пам'яті для роботи адмін-частини

Зазвичай ефективно якщо:

• на сайті багато публікацій та/або з ними працює декілька авторів;
• встановлені конструктори сайтів (наприклад, Elementor);
• плагін WooCommerce.

Серед вбудованих функцій WordPress є можливість змінювати ліміти оперативної пам'яті (RAM) для адміністративної та користувацької частин сайту.

Щоб збільшити ліміт RAM для роботи адмін-частини у файлі wp-config.php достатньо додати рядок

define( 'WP_MAX_MEMORY_LIMIT', '512M' );

// або

define( 'WP_MAX_MEMORY_LIMIT', '1024M' );

Оптимізація бази даних

Для оптимізації бази даних WordPress зазвичай застосовую декілька методів.

1. Заміна у базі даних типу таблиць із MyISAM на InnoDB (це дозволяє також, наприклад, плагін WP-Optimize).
2. Додавання індексів до таблиць бази даних. Наприклад, до таблиць, які додає плагін WooCommerce. Наприклад, плагін Index WP MySQL For Speed. Також Оптимізація бази даних WordPress: додавання індексів до користувацьких таблиць.
3. Очищення бази даних від надлишкових даних (тимчасові опції транзієнти, ревізії, метаполя що не використовуються).
4. Видалення непотрібних таблиць. Наприклад, таких, які залишилися після видалення якогось плагіну. Виявлення та коректне видалення таких таблиць дозволяє плагін WP-Optimize. Якщо є сумнівні таблиці, які не видаляє вказаний плагін, то після введення назви такої таблиці у Google-пошуку, є можливість визначити який саме плагін їх створив.

Вимкнення зберігання у базі даних ревізій постів та сторінок

Вимкнення зберігання ревізій постів і сторінок у WordPress — це обмеження або повна заборона збереження проміжних версій контенту в базі даних. За замовчуванням WordPress створює ревізію майже після кожного автозбереження або редагування, що з часом призводить до роздування таблиць wp_posts. Це збільшує обсяг бази даних, уповільнює SQL-запити та негативно впливає на продуктивність сайту, особливо на великих проєктах. Вимкнення або лімітування ревізій зменшує навантаження на базу даних і прискорює роботу адмінки та фронтенду. Така оптимізація є доцільною для продакшн-сайтів, де не потрібна історія правок кожного запису.

Щоб вимкнути ревізії:

1. У файл wp-config.php додайте рядок

/* Вимкнення автозберігання на 1 рік */
define( 'AUTOSAVE_INTERVAL', 60*60*60*24*365 );

2. У файлі functions.php вставте код

/**
 * Вимкнення ревізій
 */
if ( ! function_exists( 'mp_revisions_to_keep' ) ) {
	add_filter( 'wp_revisions_to_keep', 'mp_revisions_to_keep' );
	function mp_revisions_to_keep( $revisions ) {
		return 0;
	}
}

/**
 * Заборона автозберігання у браузері
 */
if ( ! function_exists( 'mp_disable_autosave' ) ) {
	add_action( 'wp_print_scripts', 'mp_disable_autosave' );
	add_action( 'admin_init', 'mp_disable_autosave' );
	function mp_disable_autosave() {
		wp_deregister_script( 'autosave' );
	}
}

/**
 * Заборона автозберігання у редакторі Gutenberg
 */
if ( ! function_exists( 'mp_change_gutenberg_autosave_interval' ) ) {
	add_filter( 'block_editor_settings_all', 'mp_change_gutenberg_autosave_interval', 10, 2 );
	function mp_change_gutenberg_autosave_interval( $editor_settings, $post ) {
		$editor_settings['autosaveInterval'] = 604800;

		return $editor_settings;
	}
}

Під'єднання зовнішніх JavaScript- та CSS-бібліотек локально

Періодично помічаю, що у темах JS-бібліотеки (наприклад, (jQuery, AOS, Swiper, Fancybox та ін.) викликаються із зовнішніх ресурсів. А тому під'єдную їх локально. Для цього використовую WordPress-функції wp_enqueue_style() та wp_enqueue_script().

Перенесення виклику скриптів JavaScript ближче до </body>

Перенесення виклику JavaScript-скриптів ближче до HTML-тегу </body> дозволяє браузеру спочатку завантажити й відрендерити HTML-розмітку без блокування. Це зменшує час до першого відображення контенту (FCP) і покращує сприйняття швидкості сайту користувачем. У WordPress такий підхід особливо актуальний, оскільки багато плагінів під'єднують скрипти глобально та синхронно. Завантаження JS після основного контенту знижує ризик затримок у відображенні сторінки та блокування DOM. Додатково це позитивно впливає на Core Web Vitals і загальну оцінку PageSpeed. Така оптимізація є базовою практикою для продакшн-сайтів із високими вимогами до продуктивності.

Наступний код спрацьовує для скриптів активних тем та плагінів, які були додані за допомогою WordPress-функції wp_enqueue_script().

/**
 * Перенесення JS-скриптів ближче до HTML-тегу </body>
 */
add_action( 'wp_enqueue_scripts', function() {
    if ( ! is_admin() ) {
        remove_action( 'wp_head', 'wp_print_scripts' );
        remove_action( 'wp_head', 'wp_print_head_scripts', 9 );
        remove_action( 'wp_head', 'wp_enqueue_scripts', 1 );

        add_action( 'wp_footer', 'wp_print_scripts', 5 );
        add_action( 'wp_footer', 'wp_enqueue_scripts', 5 );
        add_action( 'wp_footer', 'wp_print_head_scripts', 5 );
    }
}, 0 );

/**
 * Додавання атрибуту defer
 */
add_filter( 'script_loader_tag', function( $tag, $handle, $src ) {
    if ( is_admin() ) {
        return $tag;
    }

    // Пропустити бібліотеку jQuery, щоб не зламати плагіни/тему
    if ( $handle === 'jquery-core' || $handle === 'jquery-migrate' || $handle === 'highlightjs' ) {
        return $tag;
    }

    // Додати defer
    return '<script src="' . esc_url( $src ) . '" defer></script>';
}, 10, 3 );

Під'єднання зовнішніх шрифтів локально

Часто у темах розробники викликають шрифти із зовнішніх ресурсів. Наприклад, із fonts.googleapis.com. А тому завантажую файли шрифтів локально та під'єдную їх у темі.

У випадку якщо це зробити неможливо, до виклику зовнішнього шрифту додаю GET-параметр display=swap:

<link href="https://fonts.googleapis.com/css?family=Roboto:100,400&display=swap" rel="stylesheet">

Вимкнення функціоналу плагінів на сторінках сайту, де вони не задіюються

Для кожного плагіну — це окремий код у файлі functions.php.

Contact Form 7

Таке рішення оправдано, якщо, наприклад, форма виводиться лише одній сторінці — Контакти.

Щоб не задіювати функціонал плагіну Contact Form 7 на сторінках сайту, де він не потрібен:

/** 
 * Вимкнення функціоналу Contact Form 7 на сайті, де він не потрібен
 */
require_once( ABSPATH . 'wp-admin/includes/plugin.php' );
if ( is_plugin_active( 'contact-form-7/wp-contact-form-7.php' ) ) {
	add_action( 'wp_print_styles', 'mp_deregister_cf7_styles', 100 );
	add_action( 'wp_print_scripts', 'mp_deregister_cf7_scripts', 100 );
}
function mp_deregister_cf7_styles() {
	if ( ! is_page( get_theme_mod( "header_contacts") ) ) {
		wp_deregister_style( 'contact-form-7' );
	}
}
function mp_deregister_cf7_scripts() {
	if ( ! is_page( get_theme_mod( "header_contacts") ) ) {
		wp_deregister_script( 'contact-form-7' );
	}
}

WooCommerce

Часто на сайті інтернет-магазину, окрім розділу з товарами, є статичні сторінки та/або публікації блогу. На них не потрібен функціонал Кошика, а тому його можна вимкнути.

/**
 * Вимкнення WooCommerce на сайті, де він не потрібен
 */
add_action( 'wp_enqueue_scripts', function() {
    // Якщо WooCommerce не активний — нічого не робимо
    if ( ! class_exists( 'WooCommerce' ) ) {
        return;
    }

    // Якщо це будь-яка WooCommerce-сторінка — нічого не вимикаємо
    if (
        is_woocommerce()
        || is_cart()
        || is_checkout()
        || is_account_page()
        || wp_doing_ajax()
        || wp_doing_rest()
    ) {
        return;
    }

    /**
     * 1. Вимикаємо ВСІ стандартні стилі WooCommerce
     * (найбезпечніший спосіб, рекомендований самою Woo)
     */
    add_filter( 'woocommerce_enqueue_styles', '__return_empty_array' );

    /**
     * 2. Вимикаємо cart-fragments
     * (єдиний скрипт, який Woo тягне глобально)
     */
    wp_dequeue_script( 'wc-cart-fragments' );

}, 20 );