Как вы знаете, WordPress 5 представил новый интерфейс редактора (для тех, кто еще не решил явно отключить его ), и отзывы пользователей были в основном нормальные, несмотря на спорный график выпуска и решение решить множество проблем с доступностью и производительностью в последующих выпусках.
Проблема заключается в производительности интерфейса , и, честно говоря, Gutenberg на самом деле не виноват.
Предыстория
Gutenberg — «блочный» редактор. Каждый фрагмент контента в записи является блоком. Абзацы, изображения, заголовки … все обычные вещи, которые вы добавляете в контент, — это блок.
И это открывает перед пользователями мир возможностей по мере необходимости активировать новые типы блоков.
Нужна контактная форма на вашей странице контактов? Для этого есть блок .
Нужна галерея изображений? Для этого есть блок .
Нужна куча полезных блоков в одном плагине? Для этого есть библиотека блоков.
Теперь, чтобы удовлетворить ваши потребности в создании того типа контента, который вы хотите, вы можете установить несколько блочных плагинов одновременно с уже используемыми плагинами. Не говоря уже о риске просто наличия слишком большого количества активных плагинов, сосредоточимся на более серьезной проблеме.
Водопады
При тестировании производительности сайта, разработчики часто делают анализ водопада. Это диаграмма каждого ресурса, который требуется сайту для полной загрузки, и время, которое потребовалось для загрузки каждого из этих ресурсов. Это хорошее визуальное представление веса страницы.
Каждый загружаемый ресурс, используемый вашей страницей, представлен на графике строкой. Каждая строка имеет цветную линию (крайняя справа), которая указывает, когда ресурс начал загрузку, и сколько времени это заняло. Очевидно, что большие файлы с более медленных серверов будут занимать больше времени, тогда как небольшие файлы с быстрых серверов (например, CDN) будут занимать меньше времени.
Помимо определения местоположения ресурсов, которые загружаются медленно (из-за размера или скорости сервера), водопад показывает еще одну полезную метрику: какие ресурсы блокируют загрузку других ресурсов и, в конечном счете, блокируют отображение страницы.
Несмотря на то, что существует несколько типов блокирующих ресурсов, для целей этой статьи мы сосредоточимся на наиболее актуальном из них — таблицах стилей (CSS).
Блокирующие таблицы стилей
Поскольку в настоящее время нет способа предотвратить блокировку таблиц стилей при визуализации страницы, мы в основном просто должны были принять, что наши таблицы стилей задерживали рендеринг страницы, пока они все не скачались.
По сути, пока весь CSS не будет загружен, ничто на странице не будет отображаться.
Поэтому мы придумали маленькие хитрости, чтобы помочь решить эту проблему, например, минимизировать CSS, объединить весь CSS в одну таблицу стилей (где это возможно) и в значительной степени полагаться на кэширование в браузере. Когда у вас есть полный контроль над вашим сайтом, это не страшные варианты.
Но расширяемая CMS усложнит ситуацию. Ваша тема загружает немного CSS, плагины загружают CSS, ядро WordPress загружает немного CSS.
Нет ничего удивительного в том, что сайт WordPress загружает более 10 таблиц стилей, и это будет только усугубляться тем, что блокам Gutenberg требуется собственный CSS для правильной визуализации на фронтенде.
Что еще хуже, эти таблицы стилей загружаются независимо от того, нужны ли они. Если страница не использует определенный блок, плагин блока все равно, вероятно, загрузит CSS для этого блока.
Но даже если плагин блока знал, что страница использует блок, и загружал CSS только тогда, когда блок использовался на странице, у нас все еще есть проблема! Когда вы регистрируете и ставите в очередь таблицу стилей в WordPress ( правильный путь ), она будет выводиться в <head>.
Проблема в том, что теперь таблица стилей, предназначенная для блока, который используется в нижней части страницы, блокирует отображение заголовка сайта, меню, заголовка записи и т. д.
Почему блок, расположенный значительно ниже области видимости, должен влиять на отображение заголовка сайта?
Добавим модульности
Здравый смысл говорит нам, что нужно использовать как можно меньше CSS-файлов. Каждый HTTP-запрос включает некоторую задержку в сети, и, следовательно, уменьшение количества запросов означает меньше времени, пока весь наш CSS не будет загружен и страница не будет готова к визуализации.
В конце концов, если каждый файл CSS загружается в <head>и блокирует рендеринг всей страницы, то почему бы вам не объединить весь ваш CSS в один файл, один HTTP-запрос?
Примечание: хотя вы можете утверждать, что модульность ваших CSS-файлов обеспечивает более эффективную возможность очистки кэша, а HTTP2 допускает асинхронную загрузку CSS, задержка все еще остается проблемой, поэтому для производительности все же лучше объединить CSS.
Но пару месяцев назад Джейсон Коэн поделился интересной ссылкой с инженерами WP Engine. Выдержка:
из-за недавних изменений в Chrome (версия 69) и поведения, уже присутствующего в Firefox и IE / Edge,
<link rel="stylesheet" />s будет блокировать только рендеринг последующего контента, а не всей страницы.CSS Wizardry
Если все таблицы стилей связаны между собой <head>, эта новая информация меняет немного. Он все еще блокирует все после ссылки … каждый визуальный элемент на вашем сайте.
Но что, если мы разделим CSS на несколько файлов, каждый из которых соответствует фрагменту контента, который требует стилизации. И вместо того, чтобы связать их все в <head>, эти CSS-файлы будут вызваны только непосредственно перед тем, как будет представлен контент, для которого они были разработаны.
Он по-прежнему блокирует рендеринг, как и традиционный метод, но поскольку мы вызываем CSS-файл в <body> прямо перед тем, как контент, для которого он предназначен, мы не блокируем рендеринг контента до этой точки в исходном коде.
Практическим результатом этого является то, что теперь мы можем постепенно отображать наши страницы, эффективно добавляя стили на страницу по мере их появления.CSS Wizardry
Другими словами, мы подключаем стили на страницу по мере необходимости .
Это также имеет дополнительное преимущество, заключающееся в стратегической блокировке рендеринга любого контента, для которого еще не загружен соответствующий CSS.
Время до первого рендера
Так почему же это важно? Потому что скорость страницы (фактическое время загрузки всего сайта) и воспринимаемая скорость страницы (время, которое пользователь думает, что ваш сайт загружен) — это очень разные вещи.
И оказывается, что пользователям все равно, сколько времени фактически занимает загрузка вашего сайта. Они не смотрят на водопад, они смотрят на экран.
Все, что мы можем сделать для сокращения времени, которое пользователь ждет до появления первого контента — это выигрыш для удержания посетителей. Пользователи не видят футер при первой загрузке страницы. А поскольку все больше и больше трафика поступает с мобильных устройств, то при первом обращении к странице количество видимого контента еще уменьшается.
Это представляет большую возможность! Мы можем уменьшить время первого рендеринга и отложить рендеринг элементов дальше вниз по экрану до тех пор, пока их соответствующие CSS не будут загружены.
Блоки
Не так-то просто. WordPress очень точно описывает, как он хочет, чтобы вы загружали свои CSS-файлы.
В настоящее время есть возможность зарегистрировать таблицу стилей с помощью одной функции, а другая функция подключает ее (она также выполняет регистрацию, но вообще нужно зарегистрировать стиль и подключить его отдельно).
Когда вы ставите эти стили в очередь, каждая ссылка на таблицу стилей выводится в <head>. Каждая таблица стилей зарегистрирована с уникальным дескриптором, поэтому одна и та же ссылка на таблицу стилей может быть вызвана не более одного раза.
Что если бы мы могли регистрировать таблицы стилей таким же образом, но вместо того, чтобы ставить их в очередь для вывода в <head>, мы могли бы вызвать функцию вручную, которая выдаст ссылку на таблицу стилей (с любыми зависимостями) непосредственно перед блоком. После отображения ссылки менеджер таблиц стилей WordPress может убедиться, что она не будет отображаться снова.
Как оказалось, так можно сделать!
Вот краткое доказательство и суть концепции. Оно использует блок CTA из Atomic Blocks в качестве примера, но, очевидно, рабочий код будет выглядеть немного иначе.
// this snippet requires PHP 5.3+
add_action( 'wp_enqueue_scripts', function() {
wp_register_style( 'atomic-blocks/ab-cta', '/path/to/atomic-blocks/css/ab-cta.css', array(), '1.0.0' );
} );
add_filter( 'render_block', function( $block_content, $block ) {
if ( 'atomic-blocks/ab-cta' === $block['blockName'] ) {
ob_start();
wp_print_styles( $block['blockName'] );
$block_content = ob_get_clean() . $block_content;
}
return $block_content;
} );По сути, вы регистрируете модульный CSS, как обычно. Затем, используя фильтр render_block, вы можете вывести ссылку на таблицу стилей «как раз вовремя», чтобы контент получил CSS для стилизации, прежде чем он будет отображен, но CSS не блокирует отображение чего-либо.
Используя wp_register_style()и wp_print_styles(), мы работаем в существующем загрузчике стилей WordPress и получаем все его преимущества. Но не ставя в очередь стили и вместо того, чтобы выводить их непосредственно там, где мы хотим, мы можем выводить ссылки стилей непосредственно перед тем блоком, который они стилизуют, и только если этот блок фактически используется. Да, мы должны использовать буферизацию вывода, но это иногда неизбежно, и в этом случае оно того стоит.
Темы
Этот метод не ограничен блоками. Целые темы могут быть построены таким образом. Вместо основной таблицы стилей, которая стилизует все, используйте отдельные таблицы стилей для каждого раздела вашего сайта и выводите ссылку на таблицу стилей непосредственно перед разделом, в котором она стилизуется.
Вас когда-нибудь беспокоило, что темы WordPress загружают CSS для раздела комментариев на страницах с отключенными комментариями, или в архивах, или на домашней странице?
Подключая таблицу стилей только тогда, когда это необходимо, вы загружаете CSS только для тех разделов, которые действительно существуют на странице. Это может значительно уменьшить общий вес страницы, в дополнение к сокращению времени первого отображения, упомянутого ранее.
Плагины
Плагины имеют те же возможности, что и темы и блоки.
Это действительно не сложно. Просто зарегистрируйте свою таблицу стилей, как обычно, а затем используйте wp_print_styles()для вывода CSS как часть любой функции рендеринга, которую использует ваш плагин. Если ваш плагин предоставляет виджет, то убедитесь, что стили виджета получают вывод при визуализации виджета … не ставьте таблицу стилей в очередь, как вы привыкли!
Так в чем же подвох?
В настоящее время этот метод работает во всех основных браузерах, кроме Safari. Он не ломается или что-то еще, он просто обрабатывает каждую связанную таблицу стилей, как если бы она была в <head>. То есть каждая связанная таблица стилей является блокировкой рендеринга для всей страницы.
Так что, в основном, в Safari мы получаем тот же результат, что и в случае, если бы мы вообще не реализовали этот метод.
Конечно, используя этот метод, вы можете пожертвовать некоторой производительностью в Safari (пока они не исправят все), не объединяя весь ваш CSS в один файл, а имея таблицу стилей для каждого основного раздела или типа контента и связывая ее только тогда, когда раздел или тип контента фактически используется, вы также получаете некоторую производительность, уменьшая общий вес страницы.
Одна из возможных проблем заключается в том, что на страницах, где мы на самом деле не уменьшаем общий вес страницы — на странице, которая использует много разделов, блоков и т. д., — мы могли бы технически увеличить общее время загрузки страницы, используя наш метод загрузки таблицы стилей.
