Как сделать вашу CMS более эффективной с помощью Fastly

Существует много терминов, которые пытаются различить подходы к проектированию CMS. Но почти любая CMS может получить пользу от использования на периферии (edge). Большинство CMS на практике работают одним из трех способов:

Монолитные или «традиционные» системы

Контент создается, управляется и презентуется в пределах одной системы, а пользователи обычно получают доступ к нему через веб-браузер.

Даже для таких монолитных систем кэширование на периферии может быть удачным решением. Например, очистка кэша на периферии при изменении контента и вариация в зависимости от состояния входа может повысить коэффициент попадания в кэш и уменьшить нагрузку на CMS (особенно если CMS старая и требует много ресурсов), при этом используя периферию только как кэш.

Отделение других функций от монолита — это хороший способ получить огромные преимущества в безопасности и производительности без необходимости значительных изменений архитектуры вашей CMS. Например, перенос на периферию блок-листов, правил фильтрации и нормализации запросов. Для более авторитетных сайтов неожиданно большое количество запросов приводит к перенаправлениям, поэтому перенос их на периферию также уменьшает нагрузку на источник.

Генераторы статических сайтов (SSG)

Это в основном реакция на проблемы производительности монолитных CMS. Генераторы статических сайтов предназначены для преобразования всего сохраненного контента в набор статических HTML, CSS и JavaScript, которые могут обслуживаться на таком вебхосте, как Amazon S3 или Google Cloud Storage. SSG также обычно используют разметку для создания контента и опираются на git для контроля версий. Но вам все равно нужно реализовать отдельный API для включения любых персонализированных элементов в конечный сайт.

SSG создают по сути «статический» веб-сайт, и хотя вы можете дополнять их API, все равно трудно достичь хорошего SEO — контроль доступа, в частности, может быть сложным. Периферия — это отличное место для решения этих проблем, перемещая персонализацию и частичный рендеринг, а также маршрутизацию, фильтрацию, блокировку списков, нормализацию и перенаправление (redirect).

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

Разделенные/Гибридные (API ориентированные)

Эти системы сосредоточены на предоставлении высококачественных API, которые могут быть использованы другими системами для отделения рендеринга и отображения контента от остальной части CMS. Это обычно позволяет избежать необходимости предварительно создавать весь сайт и позволяет легче поддерживать персонализацию, нативные приложения, физическую печать и другие медиаформаты отображения, а также часто обеспечивает богатый опыт редактирования контента.

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

Предварительная настройка конфигурации или авторизации

Когда вы получаете запрос на страницу, вы можете принять множество решений о тестировании, привилегиях доступа, идентичности и других аспектах. Есть несколько способов сделать это: для небольших объемов данных, которые редко меняются, самый быстрый способ их чтения — просто закодировать их в конфигурацию периферии. Тем не менее, более распространенным вариантом для служб VCL является использование периферийных словарей — простой способ поддерживать хранилище ключей-значений с сотнями или даже тысячами элементов, которые активно распределяются по периферии.

Если вам нужно обрабатывать большие объемы данных, которые часто меняются, или если каждый запрос требует уникальной конфигурации, рассмотрите возможность использования «запроса предварительного полета». Этот термин означает выполнение API-запроса до того, как основной запрос клиента будет отправлен на бэкэнд.

Очистка кеша при изменении контента

В большинстве случаев для кэширования контента на периферии существует только два оптимальных значения времени хранения (TTL): ноль или бесконечность (где «бесконечность» на практике часто означает «год»). Всегда могут быть исключения, но если вы управляете данными всего за несколько минут или час, почему бы не увеличить это время и не очистить их только при изменении?

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

Кроме того, вам не обязательно удалять только один элемент. С помощью одного вызова API вы можете очистить весь кеш вашего сайта («полная очистка»). Благодаря предварительному планированию, вы также можете очищать группы контента по тегам, например, все пола определенного автора или все страницы, которые содержат заголовок определенной статьи. Это позволяет удалить не только измененный контент, но и все ссылки на него.

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

CMS обычно предоставляют возможность предварительного рендеринга изображений разных размеров, но для максимальной гибкости стоит рассмотреть возможность выполнения этих задач на периферии. Это позволяет избежать обработки каждого изображения отдельно, что ускоряет процесс создания сайта. Благодаря интеллектуальной модификации Fastly, вам не нужно самостоятельно определять главную точку изображения-система автоматически определит ее и осуществит качественную проработку изображения для любого размера.