Як вимкнути стилі Gutenberg у WordPress та прибрати зайвий CSS

Редактор Gutenberg давно став стандартною частиною WordPress. Разом з ним система включає CSS та інші ресурси, необхідні для коректного відображення блоків: кнопок, колонок, галерей, цитат, зображень та інших елементів.

Проблема постає на сайтах, де Gutenberg практично не використовується. Наприклад, сторінки можуть бути повністю побудовані на Elementor, Bricks, WPBakery або власної теми, а записи можна редагувати через Classic Editor. У такому разі частина ресурсів WordPress може виявитися непотрібною.

Вимкнення зайвих стилів дозволяє зменшити кількість CSS на сторінці і зробити вихідний код трохи чистішим. Але виконувати таку оптимізацію потрібно обережно: деякі системні стилі дійсно потрібні блокам WordPress.

Коротка відповідь: щоб вимкнути стандартні стилі Gutenberg на фронтенді WordPress, можна видалити wp-block-library, wp-block-library-theme і за необхідності classic-theme-styles через wp_dequeue_style(). Проте безпечніше спершу перевірити, чи використовуються блоки Gutenberg на сайті. Для змішаних сайтів краще включити завантаження CSS блоків тільки на вимогу, а не повністю відключати бібліотеку.

Які стилі Gutenberg завантажує WordPress

WordPress реєструє та підключає кілька груп CSS, пов'язаних із системою блоків. Основний із них — стиль з ідентифікатором:

wp-block-library

Він містить основні правила оформлення стандартних блоків WordPress.

Крім нього, залежно від теми, конфігурації та версії WordPress можуть траплятися:

• wp-block-library-theme;
• classic-theme-styles;
• global-styles;
• CSS окремих блоків;
• inline-стилі, сформовані системою Global Styles;
• стилі, створені на підставі theme.json.

Сам WordPress використовує wp-block-library як загальну бібліотеку стилів блоків Якщо увімкнено роздільне завантаження ресурсів Core-блоків, замість одного великого файлу WordPress може підключати окремі таблиці стилів лише для необхідних блоків.

Тому перед оптимізацією важливо розуміти різницю між двома підходами:

повністю видалити Gutenberg CSS або залишити Gutenberg, але змусити WordPress завантажувати стилі більш вибірково.

У більшості сучасних проектів другий варіант безпечніший.

Навіщо відключати CSS Gutenberg

Основна причина – оптимізація фронтенду.

Якщо сайт взагалі не використовує стандартні блоки WordPress, завантаження CSS для Button, Columns, Gallery, Quote та інших блоків не приносить практичної користі.

Видалення непотрібних ресурсів потенційно дозволяє:

• зменшити обсяг завантажуваного CSS;
• скоротити кількість запитів;
• зменшити кількість CSS, що не використовується;
• зробити HTML-код сторінки чистішим;
• трохи прискорити обробку CSS браузером;
• покращити результати аудиту PageSpeed ​​Insights та Lighthouse.

Однак очікувати величезного приросту швидкості тільки від видалення Gutenberg CSS не варто.

На реальному WordPress-сайті набагато більший вплив часто мають зображення, шрифти, JavaScript, плагіни, сторонні віджети, аналітика, реклама та CSS самого шаблону.

Відключення Gutenberg CSS – це скоріше один із етапів комплексної оптимізації.

Спосіб №1. Повністю вимкнути основні стилі Gutenberg

Якщо ви впевнені, що стандартні блоки WordPress ніде на фронтенді не використовуються, можна видалити основні таблиці стилів.

Додати наступний код в functions.php дочірньої теми:

function my_remove_gutenberg_block_styles() {
    wp_dequeue_style( 'wp-block-library' );
    wp_dequeue_style( 'wp-block-library-theme' );
}
add_action( 'wp_enqueue_scripts', 'my_remove_gutenberg_block_styles', 100 );

Функція wp_dequeue_style() є стандартною функцією WordPress і призначена для видалення раніше поставленої таблиці стилів.

пріоритет 100 використовується для того, щоб функція виконувалася досить пізно після того, як WordPress і тема встигли додати відповідні CSS в чергу.

Куди вставляти код

Є кілька варіантів:

1. functions.php дочірньої теми;
2. власний невеликий плагін;
3. MU-plugin;
4. спеціалізований плагін для PHP-сніппетів.

Для постійної технічної оптимізації краще власний плагін або MU-plugin. Тоді зміна теми не призведе до зникнення оптимізації.

Не рекомендується змінювати functions.php батьківської темиоскільки зміни можуть бути втрачені після її оновлення.

Спосіб №2. Вимкнути classic-theme-styles.css

Для класичних тем WordPress може підключати:

classic-theme-styles

Ці стилі з'явилися для забезпечення зворотної сумісності деяких блоків Core в класичних темах.

Якщо блоки WordPress на фронтенді взагалі не використовуються, файл також можна забрати:

function my_remove_classic_theme_styles() {
wp_dequeue_style( 'classic-theme-styles' );
}
add_action( 'wp_enqueue_scripts', 'my_remove_classic_theme_styles', 100 );

Особливо важливо не відключати цей ресурс наосліп.

WordPress використовує Classic Theme Styles, зокрема, для сумісності блоків Button та File у класичних темах. Тому після вимкнення обов'язково перевірте зовнішній вигляд кнопок та посилань на файли.

Спосіб №3. Об'єднати вимкнення стилів в одну функцію

Якщо Gutenberg на фронтенді взагалі не використовується, код можна зробити компактніше:

function my_disable_unused_block_css() {

    wp_dequeue_style( 'wp-block-library' );
    wp_dequeue_style( 'wp-block-library-theme' );
    wp_dequeue_style( 'classic-theme-styles' );

}
add_action( 'wp_enqueue_scripts', 'my_disable_unused_block_css', 100 );

Це простий варіант для сайтів, повністю збудованих без Core-блоків.

Наприклад, такий підхід може бути доречним для старого корпоративного сайту Classic Editor або проекту з власною системою шаблонів.

Але для сучасного сайту, де Gutenberg використовується хоча б іноді, є цікавіше рішення.

Спосіб №4. Завантажувати CSS Gutenberg тільки там, де він потрібний

Це один із найважливіших моментів, який варто враховувати при оптимізації сучасних версій WordPress.

WordPress вміє розділяти CSS стандартних блоків замість підключення загальної бібліотеки стилів.

Для цього існує фільтр:

add_filter( 'should_load_separate_core_block_assets', '__return_true' );

При такому режимі Core-блоки можуть використовувати окремі таблиці стилів замість єдиного wp-block-library.

Це принципово відрізняється від повного відключення Gutenberg CSS.

Якщо на сторінці є потрібний блок, WordPress отримує можливість завантажити потрібні для нього стилі. Якщо блоку немає, ресурс не потрібен.

Такий підхід є особливо цікавим для сайтів, де Gutenberg використовується частково.

Наприклад:

• записи створюються в Gutenberg;
• головна сторінка зроблена в Elementor;
• деякі посадкові сторінки використовують Core-блоки;
• решту сторінок побудовано власними шаблонами.

Замість повного видалення CSS можна дозволити WordPress завантажувати ресурси більш вибірково.

Завантаження стилів блоків на вимогу у сучасних версіях WordPress

У сучасних версіях WordPress механізм оптимізації став ще більш гнучким.

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

should_load_block_assets_on_demand

Його можна використовувати наступним чином:

add_filter( 'should_load_block_assets_on_demand', '__return_true' );

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

Це особливо корисно для великих сайтів із безліччю зареєстрованих блоків.

Важливо розуміти, що should_load_separate_core_block_assets відноситься перш за все до розділення CSS стандартних Core-блоків, тоді як should_load_block_assets_on_demand відповідає за завантаження ресурсів блоків за фактом їхнього рендерингу.

Для нових проектів розумно спочатку розглянути ці механізми і лише потім переходити до агресивного wp_dequeue_style().

Спосіб №5. Вимкнути Global Styles

WordPress може додавати до сторінки стилі, пов'язані з Global Styles.

Їх можна побачити у вихідному HTML приблизно як:

<style id="global-styles-inline-css">
...
</style>

Якщо проект взагалі не використовує цю систему, трапляється такий варіант оптимізації:

function my_remove_global_styles() {
    wp_dequeue_style( 'global-styles' );
}
add_action( 'wp_enqueue_scripts', 'my_remove_global_styles', 100 );

Але тут потрібно значно більше обережності.

Global Styles тісно пов'язані з theme.json, налаштування блоків, кольорів, типографіки, spacing та інші можливості сучасних тем WordPress.

Якщо використовується блокова тема або активно застосовується theme.jsonБездумно відключати Global Styles не слід.

Що робити з SVG-фільтрами Duotone

Gutenberg підтримує ефект Duotone для зображень. Для роботи WordPress може додавати SVG-фільтри.

На сайті, який абсолютно не використовує відповідних можливостей Gutenberg, такий код іноді також видаляють.

Наприклад:

function my_remove_wp_duotone_filters() {
    remove_action( 'wp_body_open', 'wp_global_styles_render_svg_filters' );
    remove_action( 'wp_footer', 'wp_global_styles_render_svg_filters' );
}
add_action( 'wp_enqueue_scripts', 'my_remove_wp_duotone_filters', 100 );

Однак подібні сніпети особливо важливо перевіряти на актуальній версії WordPress.

Внутрішні механізми Global Styles та Duotone змінювалися разом із розвитком Gutenberg. Тому оптимізацію, знайдену кілька років тому у блозі чи на форумі, не можна автоматично вважати універсальною для будь-якої сучасної версії WordPress.

Чи потрібно відключати сам Gutenberg

Ні.

Вимкнення CSS Gutenberg та відключення редактора Gutenberg — різні операції.

Можна залишити Block Editor в адміністративній панелі та оптимізувати лише ресурси фронтенду.

Але якщо для певного типу записів Gutenberg справді не потрібний, WordPress дозволяє відключити Block Editor окремо.

Наприклад:

function my_disable_gutenberg_for_post_types( $use_block_editor, $post_type ) {

    $disabled_post_types = array(
        'page',
        'product'
    );

    if ( in_array( $post_type, $disabled_post_types, true ) ) {
        return false;
    }

    return $use_block_editor;
}

add_filter(
    'use_block_editor_for_post_type',
    'my_disable_gutenberg_for_post_types',
    10,
    2
);

Так можна, наприклад, залишити Gutenberg для звичайних записів, але вимкнути його для сторінок або певного Custom Post Type.

Це корисніше, ніж глобально відключати редактор, якщо веб-сайт використовує змішану архітектуру.

Як вимкнути пошук блоків у Block Directory

Є ще одна функція Gutenberg, яка не стосується безпосередньо CSS, але може бути зайвою.

Block Directory дозволяє шукати додаткові блоки безпосередньо із редактора WordPress.

Якщо така можливість редакторам сайту не потрібна, її можна вимкнути:

function my_disable_block_directory_assets() {
    remove_action(
        'enqueue_block_editor_assets',
        'wp_enqueue_editor_block_directory_assets'
    );
}
add_action( 'init', 'my_disable_block_directory_assets' );

Такий варіант може бути корисним на корпоративних проектах, де набір дозволених плагінів та блоків контролює розробник чи адміністратор.

Який варіант вибрати

Вибір залежить від архітектури веб-сайту.

Головний принцип тут простий:

не відключайте ресурс тільки тому, що PageSpeed ​​Insights позначає частину CSS як невикористовувану. Спочатку визначте, якою функціональністю належить цей CSS.

Чому після видалення wp-block-library може «поїхати» дизайн

Розглянемо типову ситуацію.

Ви відключили:
wp_dequeue_style( 'wp-block-library' );

Головна сторінка працює ідеально.

Через кілька днів ви відкриваєте стару статтю та виявляєте, що галерея виглядає неправильно, кнопка втратила оформлення або колонки змінили розташування.

Причина проста: цей конкретний запис містить Core-блок.

Наприклад:

<div class="wp-block-columns">

або:

<div class="wp-block-buttons">

CSS було видалено глобально, тому HTML блок зберігся, але частина стандартного оформлення зникла.

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

Як перевірити, чи використовуються Gutenberg-блоки

Перед зміною functions.php відкрийте кілька типових сторінок сайту та вивчіть HTML.

Шукайте класи:

wp-block-

Наприклад:

wp-block-image
wp-block-gallery
wp-block-columns
wp-block-button
wp-block-group
wp-block-cover
wp-block-quote

Якщо вони є, повністю видаляти CSS Gutenberg ризиковано.

Але одного перегляду головної сторінки недостатньо.

Перевірити бажано:

• головну;
• звичайну сторінку;
• запис блогу;
• архів;
• результати пошуку;
• сторінку товару WooCommerce;
• кошик;
• оформлення замовлення;
• сторінку 404;
• старі публікації.

Особливу увагу приділіть старому контенту. Сайт міг перейти на Elementor кілька років тому, але сотні старих записів все ще можуть містити блоки Gutenberg.

Як перевірити результат після оптимізації

Після додавання коду очистіть:

1. кеш WordPress;
2. кеш оптимізуючий плагін;
3. серверний кеш;
4. CDN/Cloudflare;
5. кеш-браузер.

Потім відкрийте Chrome DevTools → Network і виберіть CSS- фільтр.

Перевірте наявність:

wp-block-library
wp-block-library-theme
classic-theme-styles

Додатково відкрийте вихідний код сторінки та знайдіть:

global-styles

Якщо потрібного ресурсу більше немає, сніпет спрацював.

Але технічна перевірка – лише половина роботи.

Після неї необхідно візуально перевірити сторінки на desktop та mobile.

Що перевірити в PageSpeed ​​Insights

До внесення змін бажано провести тест, зберегти показники, а потім повторити вимір.

Звертайте увагу насамперед на:

• First Contentful Paint;
• Largest Contentful Paint;
• Total Blocking Time;
• обсяг переданого CSS;
• кількість запитів;
• рекомендації щодо скорочення CSS, що не використовується.

При цьому один тест PageSpeed ​​не можна вважати підтвердженням прискорення.

Результати Lighthouse можуть змінюватись між запусками. Краще провести кілька вимірів до і після оптимізації та порівняти загальну тенденцію.

Чому не варто копіювати старі сніпети без перевірки

Gutenberg розвивається дуже швидко.

Рішення, опубліковане для WordPress 5.x або ранніх WordPress 6.x, може бути технічно робочим, але не оптимальним.

Зокрема, WordPress поступово розвиває:

• роздільні CSS Core-блоки;
• завантаження block assets на вимогу;
• theme.json;
• Global Styles;
• Style Engine;
• Block Supports API;
• окремі frontend-ресурси блоків.

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

Відключення Gutenberg CSS в Elementor, Bricks та інших конструкторах

Наявність page builder'а ще не означає, що wp-block-library можна автоматично видалити.

Наприклад, сайт може використовувати Elementor для сторінок, але Gutenberg для запису блогу.

У такому разі глобальний:

wp_dequeue_style( 'wp-block-library' );

може призвести до проблем саме у статтях.

Більш розумна архітектура:

Page Builder → мінімум Gutenberg CSS

Gutenberg Posts → необхідні стилі блоків

Тобто оптимізація повинна враховувати тип сторінки та контент, що фактично використовується.

Чи можна відключати стилі лише на певних сторінках

Так. Це часто безпечніше від глобального відключення.

Наприклад:

function my_conditional_gutenberg_css_cleanup() {

    if ( is_page_template( 'templates/landing.php' ) ) {
        wp_dequeue_style( 'wp-block-library' );
        wp_dequeue_style( 'wp-block-library-theme' );
        wp_dequeue_style( 'classic-theme-styles' );
    }

}
add_action( 'wp_enqueue_scripts', 'my_conditional_gutenberg_css_cleanup', 100 );

Тепер оптимізація застосовується лише до конкретного шаблону.

Аналогічно можна використовувати умови:

is_front_page()
is_home()
is_page()
is_single()
is_singular()
is_post_type_archive()

Для складних проектів саме умовна оптимізація часто дає найкращий баланс між продуктивністю та сумісністю.

functions.php чи окремий плагін?

Для швидкого тесту можна використовувати functions.php дочірньої теми.

Для робочого сайту найкраще розглянути site-specific plugin.

Найпростіший варіант:

<php
/**
 * Plugin Name: Site Performance Tweaks
 * Description: Custom frontend performance optimizations.
 * Version: 1.0
 */

function site_performance_remove_unused_block_css() {

    wp_dequeue_style( 'wp-block-library' );
    wp_dequeue_style( 'wp-block-library-theme' );
    wp_dequeue_style( 'classic-theme-styles' );

}

add_action(
    'wp_enqueue_scripts',
    'site_performance_remove_unused_block_css',
    100
);

Так оптимізація залежить від активної теми і зникне за її заміні.

типові помилки

1. Видалити всі стилі відразу

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

Найкраще відключати їх по одному.

2. Не перевіряти старі записи

На головній Gutenberg може бути відсутнім, а в статтях за останні п'ять років активно використовуватися.

3. Вимикати Global Styles у block theme

Це може порушити кольори, розміри, spacing та інші параметри дизайну.

4. Редагувати батьківську тему

Після оновлення зміни зникнуть.

5. Перевіряти лише desktop

CSS деяких блоків є особливо важливим для адаптивного відображення.

6. Орієнтуватися виключно на PageSpeed

Мета оптимізації – прискорити сайт без порушення функціональності, а не просто отримати максимальний бал Lighthouse.

Рекомендований алгоритм оптимізації

Насправді краще використовувати таку послідовність.

Крок 1. Визначте, чи використовуються Gutenberg-блоки на фронтенді.

Крок 2. Перевірте Network у DevTools та встановіть, які CSS дійсно завантажуються.

Крок 3. Якщо Gutenberg ніде не використовується, протестуйте повне відключення Block Library CSS.

Крок 4. Якщо Gutenberg використовується частково, спочатку протестуйте separate/on-demand block assets.

Крок 5. Не видаляйте Global Styles без перевірки theme.json та можливостей активної теми.

Крок 6. Очистіть усі рівні кешу.

Крок 7. Перевірте основні шаблони сайту та старі публікації.

Крок 8. Проведіть кілька тестів продуктивності до та після змін.

Такий підхід набагато надійніший за ідеї «видалити весь CSS Gutenberg однією функцією».

Питання та відповіді

Відключення стилів вбудованих блоків Gutenberg може бути корисною частиною оптимізації WordPress, особливо для сайтів на Classic Editor, власних шаблонах або page builder'ах, де Core-блоки взагалі не використовуються.

Найпростіший варіант – видалити:

wp-block-library
wp-block-library-theme
classic-theme-styles

через wp_dequeue_style().

Але повне видалення CSS - не завжди найкращий сучасний підхід.

Якщо Gutenberg використовується хоча б на частині сайту, правильніше розглянути роздільне завантаження Core Block CSS та механізм завантаження ресурсів блоків на вимогу. WordPress здатний підключати стилі набагато вибірковіше, що дозволяє одночасно зберегти сумісність Gutenberg і зменшити обсяг непотрібних ресурсів.

Тому оптимальна стратегія має такий вигляд:

не Gutenberg → відключаємо непотрібний CSS;

частково Gutenberg → завантажуємо ресурси на вимогу;

block theme/theme.json → не відключаємо Global Styles без детального тестування.

Після будь-яких змін обов'язково очищайте кеш та перевіряйте не лише головну сторінку, а й записи, архіви, мобільну версію, WooCommerce та старий контент.

Джерела

1. DoubleNeed - 5 Lightweight Code Snippets to Disable Gutenberg Block CSS & Unused Features.
2. WordPress Developer Resources - wp_dequeue_style().
3. WordPress Developer Resources - wp_should_load_separate_core_block_assets().
4. WordPress Developer Resources - should_load_separate_core_block_assets.
5. WordPress Developer Resources - wp_should_load_block_assets_on_demand().
6. WordPress Developer Resources - should_load_block_assets_on_demand.
7. WordPress Developer Resources - wp_enqueue_block_style().
8. WordPress Block Editor Handbook Global Settings & Styles (theme.json).
9. WordPress Block Editor Handbook Styles in the Editor.
10. WordPress.org Documentation - Styles overview.

Олексій Шевченко

редактор wpcafe

Вивчає сайтобудування з 2008 року. Практикуючий вебмайстер, що спеціалізується на створенні сайтів WordPress. Задати питання Олексію можна на https://profiles.wordpress.org/wpthemeus/