За пределами wp_enqueue: хирургическое управление ресурсами для высокопроизводительных сайтов

Многие плагины WordPress следуют путем наименьшего сопротивления. Они подключают свои CSS и JavaScript глобально, чтобы гарантировать, что их функции будут «просто работать» на каждой странице. Хотя такой подход безопасен для разработчика, он не идеален для производительности сайта. Каждый неиспользуемый байт JavaScript увеличивает время выполнения в браузере. Это негативно влияет на метрики Total Blocking Time (TBT) и Largest Contentful Paint (LCP).

В этом руководстве мы обсудим, как выйти за рамки базовой регистрации скриптов. Мы рассмотрим, как проверить внутреннюю очередь скриптов WordPress и целенаправленно удалить ресурсы, которые вашим посетителям на самом деле не нужны.

Начальный уровень: контекстная загрузка

Первая линия защиты — это обеспечение загрузки вашего собственного кода только тогда, когда это необходимо. Не забывайте, что хук wp_enqueue_scripts — это просто действие. Вы можете подцепить логику к вашим запросам на добавление в очередь, чтобы ограничить их использование определенными контекстами.

Использование условных тегов предотвращает загрузку скриптов там, где они не нужны. Например, если у вас есть ресурсоемкий скрипт, который выполняется только на определенной странице «Контакты», нет смысла загружать его везде.

add_action( 'wp_enqueue_scripts', function() {
    // Only load the heavy Map script on the Contact page
    if ( is_page( 'contact' ) ) {
        wp_enqueue_script( 'google-maps-api', 'https://maps.googleapis.com/...', array(), null, true );
    }
});

Использование функций is_page(), is_single() или даже has_block() позволяет реализовать загрузку «точно в срок». Это дает возможность поддерживать малый начальный вес страницы.

Заглянем внутрь глобальной переменной $wp_scripts

Реальное узкое место в производительности часто возникает из-за сторонних плагинов. Чтобы их остановить, сначала нужно определить их идентификаторы. Вы можете потратить много времени на рытье в исходных файлах плагинов, если вам это нравится, но, вероятно, быстрее просто взглянуть на внутреннее состояние менеджера скриптов WordPress.

WordPress использует класс WP_Scripts для управления очередью. В течение жизненного цикла страницы глобальная переменная $wp_scripts содержит все зарегистрированные и поставленные в очередь скрипты.

Выявление избыточности

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

Важно использовать хук wp_print_scripts. Этот хук срабатывает непосредственно перед тем, как WordPress начнет выводить скрипты в хэдере. Это гарантирует, что каждый плагин завершил свою логику постановки в очередь, а потому у вас будет полная картина финальной очереди.

Запуск в локальной или тестовой среде

Этот код следует запускать только в непроизводственной среде, например, на локальной установке или тестовом сайте.

• Локальный сайт против тестовой площадки: Хотя локальный сайт считается «безопасным», тестовая площадка часто предпочтительнее для этого аудита, поскольку она идеально отражает конфигурацию плагинов и состояние базы данных вашего продакшна.
• Почему не в продакшне? Фрагмент кода ниже выводит данные непосредственно в исходный HTML-код вашего сайта. На живом сайте это выглядит непрофессионально для посетителей и может раскрыть ваш конкретный набор плагинов злоумышленникам. Кроме того, запуск отладочной логики при каждой загрузке страницы создает ненужную нагрузку на производительность вашего сервера.

add_action( 'wp_print_scripts', function() {
    // Only run this if we are logged in as an admin to add an extra layer of privacy
    if ( ! current_user_can( 'manage_options' ) ) {
        return;
    }

    global $wp_scripts;

    // Check if the WP_Scripts class has enqueued handles [cite: 6]
    if ( ! empty( $wp_scripts->queue ) ) {
        // Output the enqueued handles to the browser's JavaScript console
        echo '<img src="data:image/gif;base64,R0lGODlhAQABAIAAAAAAAP///yH5BAEAAAAALAAAAAABAAEAAAIBRAA7" data-wp-preserve="%3Cscript%3Econsole.log(%22Delicious%20Brains%20Audit%20-%20Enqueued%20handles%3A%20'%20.%20implode(%20'%2C%20'%2C%20%24wp_scripts-%3Equeue%20)%20.%20'%22)%3B%3C%2Fscript%3E" data-mce-resize="false" data-mce-placeholder="1" class="mce-object" width="20" height="20" alt="&lt;script&gt;" title="&lt;script&gt;" />';
    }
});

Проверив свойство queue объекта $wp_scripts, вы можете найти точные строки, необходимые для указания конкретных ресурсов плагина.

Программное удаление из очереди: хирургический удар

После того, как вы определили целевые дескрипторы, вы можете использовать функцию wp_dequeue_script() для удаления требуемых ресурсов. Однако успех во многом зависит от приоритета.

В WordPress приоритеты хуков действуют как список ожидания, где более высокий номер выполняется позже. Поскольку большинство плагинов добавляют ресурсы в очередь с дефолтным приоритетом, равным 10, вам следует использовать хук wp_enqueue_scripts с гораздо большим числом (к примеру, 100), чтобы гарантировать, что ваша логика удаления будет выполняться после логики загрузки плагина.

Пример: Удаление лишнего кода из плагина

Предположим, плагин «Reviews» загружает на главной странице файл JavaScript размером 150 КБ. Если отзывы есть только на страницах товаров, вы можете удалить этот скрипт со всех остальных страниц.

add_action( 'wp_enqueue_scripts', function() {
    // If we are on the Home page, remove the Reviews asset
    if ( is_front_page() ) {
        wp_dequeue_script( 'plugin-reviews-js' );
        wp_dequeue_style( 'plugin-reviews-css' );
    }
}, 100 ); // High number = runs later

Для агрессивных плагинов, которые по-прежнему будут загружаться, можно использовать функцию wp_deregister_script(). Это более радикальный вариант, который полностью отвязывает дескриптор от исходного файла для конкретного запроса.

Ловушка зависимостей

Прежде чем отключать каждый скрипт, который вы видите, необходимо проверить наличие зависимостей. Функция wp_enqueue_script() позволяет определить список других скриптов, которые должны загрузиться первыми.

Вы нарушите функциональность сайта, если удалите из очереди скрипт, от которого зависят другие добавленные скрипты. Браузер выдаст ошибки «not defined» в консоли. Всегда проверяйте свойство registered в глобальной переменной $wp_scripts, чтобы увидеть массив зависимостей для конкретного дескриптора, прежде чем удалять его.

Источник: https://deliciousbrains.com