Благодаря недавно улучшенному Cache API и добавлению BigPipe, Drupal 8 работает быстрее, чем когда-либо. Давайте разберемся в этих нововведениях.
Модуль внутреннего кэширования страниц
Теперь он включен по умолчанию, новый основной модуль с именем Internal Page Cache кэширует страницы для анонимных пользователей. Страницы, запрошенные анонимными пользователями, сохраняются и используются повторно, что повышает производительность сайта.
Единственный настраиваемый параметр внутреннего кэша страниц - это «максимальный возраст кэша страниц», который задает значение максимального возраста в заголовках Cache-Control, выводимых Drupal 8. Установите значение max-age таким, как часто вы обновляете страницу. Если ваш сайт получает большое количество трафика, установите максимальное значение max-age. Чем выше max-age, тем больше информации будет кэшироваться и использоваться повторно.
Кэширование внешнего интерфейса использует значение max-age и обслуживает кэшированную копию до истечения срока ее действия. Чтобы отключить кэширование Drupal в целях разработки, установите для параметра «Page cache maximum age» значение «Нет кэширования». Единственное значение, которое отключает кэширование Drupal 8, это «no caching».
Этот модуль предполагает, что страницы идентичны для всех анонимных пользователей. Поэтому, если ваш сайт содержит персонализированный контент, можно отключить модуль внутреннего кэширования страниц. В противном случае Javascript и Ajax будут обрабатывать персонализацию на внешнем интерфейсе.
Альтернатива: модуль динамического кэширования страниц
Кроме того, вы можете использовать динамический кэш страниц. Динамический кэш кэширует страницы за исключением персонализированных разделов. Следовательно, это полезно как для анонимных, так и для аутентифицированных пользователей. Динамический кэш страниц использует контексты кэша - декларативный способ создания вариаций контекста всех элементов, которые должны быть кэшированы.
Эти динамические разделы помечены плейсхолдерами в Drupal 8 Render API, которые называются авто-заполнением. Когда плейсхолдер установлен, Drupal откладывает рендеринг массива визуализации до самого последнего момента. Вся страница с авто-заполнением кэшируется с помощью Dynamic Page Cache, и Drupal продолжает отображать фрагменты кэша для этих динамических частей.
Использование Cache API
Для разработчиков, работающих на Drupal 8, кэширование является обязательным моментом. Поэтому важно изучить и понять основы Cache API.
Drupal кэширование контекстов
Контексты кэша аналогичны HTTP-заголовку Vary. Он определяет контекст, участвующий в кэшировании массива рендеринга. Контексты кэша представлены в виде наборов строк. Примеры кэшированных контекстов:
• languages (vary by all language types: interface, content, …)
• languages:language_interface (vary by interface language)
• user.roles (vary by user’s role)
• url (vary by the entire url)
• url.path.is_front (vary by the front page)
Теги кэша
Теги кэша показывают, от каких данных зависит кэш в Drupal. Подобно контекстам кэша, теги кэша представлены наборами строк. Кэш будет признан недействительным, если кэш теги совпадают.
Например:
• user:10 (invalidates the cache when User entity 10 changes)
• node:8 (invalidates the cache when Node entity 8 changes)
Max-age кэша
Max-age кэша – это то количество секунд, в течение которых элемент кэша действителен. Как правило, вам не нужно устанавливать max-age, поэтому будет достаточно использовать значение по умолчанию (Cache :: PERMANENT).
Отладка кэшируемых ответов
Вы можете отлаживать кэшируемые ответы, установив для параметра http.response.debug_cacheability_headers значение true в вашем services.yml. Чтобы изменение вступило в силу, контейнер должен быть перезапущен. Это заставит Drupal отправлять соответствующие заголовки X-Drupal-Cache-Tags и X-Drupal-Cache-Contexts для кэширования тегов и контекстов.
Использование контекстов кэша и тэгов кэша
Use \Drupal\node\Entity\Node;
/** * Implements hook_preprocess_block(). */
function mymodule_preprocess_block(&$variables) {
if ($variables['elements']['#id'] == 'search_promo') {
// Unique cache per search query string.
$variables['#cache']['contexts'] = ['url.query_args:search']; // Depends on content from a node entity.
$node = Node::load($variables['promo_nid']);
$variables['#cache']['tags'] = [$node->getCacheTags(];
}
}
Допустим, у нас есть блок промо-контента, который будет отображать различный контент в зависимости от результата поиска. Строка запроса «поиск» определяет контекст кэша блока. Кэширование блока будет варьироваться в строке запроса «search», отсюда и url.query_args:search. Теги кэша указывают, что кэшированный блок должен быть признан недействительным при обновлении содержимого сущности узла, куда загружается блок.
Обычно кэш-теги имеют вид <entity type ID>:<entity ID> или config: <configuration name>, вы не должны обращаться к ним напрямую. Можно обратиться с помощью ::getCacheTags() метода, например $node->getCacheTags(), $user->getCacheTags(), $view->getCacheTags() и т.д.
Чтобы очистить кэш, используйте Drupal \ Core \ Cache \ Cache;
Cache :: invalidateTags ($ node-> getCacheTags ());
Каковы доступные контексты кэша?
Быстрый способ найти список контекстов кэша, который вы можете использовать, - это поиск в файлах * .services.yml шаблона «cache_context. *».
Переменная {{content}} в шаблоне
Вы должны отобразить переменную {{content}}, чтобы теги кэша гарантированно попали в кэш страниц. Если {{content}} не отображать, можно получить не кэшируемую страницу.
Итак, убедитесь, что ваш шаблон содержит:
{{content}}
Или, если вы хотите визуализировать некоторые поля отдельно:
{{content|without('field_coauthor', 'field_more_link')}}
Подсказки:
- Избегайте случайной сортировки. Произвольная сортировка в представлениях или коде приведет к невозможности кэширования страницы.
- Вся логика проверки доступа теперь должна возвращать объекты AccessResultInterface, что позволяет использовать метаданные для кэширования. Если вы реализуете какую-либо форму доступа или изменяете существующие хуки доступа, убедитесь, что вы возвращаете что-то из этого:
• return AccessResult :: enabled ();
• return AccessResult :: forbidden ();
• return AccessResult :: neutral (); // По умолчанию, если все условия не выполнены.
BigPipe
BigPipe стал стабильным с Drupal 8.3. Это метод, изобретенный в Facebook, который определяет его как способ «разбивать веб-страницы на маленькие порции, называемые портлетами, и направлять их через несколько этапов выполнения на веб-серверах и в браузерах».
Как это устроено:
- Во время рендеринга персонализированные части превращаются в плейсхолдеры.
- По умолчанию Drupal 8 использует стратегию Single Flush (она же «традиционная») для замены плейсхолдеров. т.е. мы не отправляем ответ, пока не заменим все плейсхолдеры.
- Модуль BigPipe это новая стратегия, которая позволяет нам сначала очистить начальную страницу, а затем передать замену для плейсхолдеров.
- Это приводит к значительному улучшению внешнего вида / воспринимаемой производительности.
Поскольку содержимое загружается с помощью BigPipe, есть один важный нюанс: нужно убедиться, что загрузка страницы не будет зрительной. Самый простой способ удостовериться в этом - отображать содержимое BigPipe в отдельном пространстве на странице, что помогает избежать переполнение контентом. Кроме того, вы можете применить патч «Предварительный просмотр интерфейса» или добавить анимацию загрузки перед этим контентом.
Добавить комментарий