Как Smashing Magazine управляет контентом: переход с WordPress на JAMstack

Эта статья была любезно поддержана нашими дорогими друзьями из Netlify, универсальной платформы для автоматизации современных веб-проектов. Спасибо!

Каждый раз, когда разработчики говорят о WordPress, их доля рынка меняется. « 20% всех сайтов на WordPress! « 40% всех сайтов на WordPress! «Каким бы ни был процент, сообщение одно и то же: с точки зрения внедрения, WordPress ОГРОМНЫЙ.

Так почему же при таком внедрении сайт, использующий WordPress, рассматривает возможность перехода на JAMstack? В этой серии статей, состоящей из двух частей, мы расскажем, как выглядит реальная миграция WordPress, на примере того самого сайта, с которого вы сейчас читаете.

Мы поговорим о прибылях и убытках, о том, что мы хотели бы знать раньше, и о том, что нас удивило. А затем мы продолжим техническую демонстрацию одного из возможных путей миграции — не полностью с WordPress — но как вы можете обслуживать отделенный WordPress, чтобы вы могли получить лучшее из обоих миров: реализация WordPress JAMstack, которая дает вам все мощность их панели управления и функциональность, с лучшей производительностью и безопасностью.

Давайте копать!

Почему?

В 2015 году соучредитель Netlify Матиас Бильманн и основатель Smashing Виталий Фридман поговорили о делах. Когда архитектура JAMstack начала распространяться, Smashing стал больше интересоваться идеей стека. Виталий и Маркус (бывший управляющий директор Smashing) спросили Мэтта, что произойдет, если Smashing перейдет со своего традиционного сайта WordPress/LAMPstack на архитектуру JAMstack.

В качестве эксперимента Мэтт скопировал весь HTML-код из Smashing и разместил его на Netlify, статически доставляя контент из CDN. Результаты были впечатляющими — статическая версия в среднем более чем в шесть раз быстрее!

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

Поскольку вы обслуживаете через CDN, вы также можете распространять контент по всему миру — ближе к потенциальным посетителям. Нет центральной точки происхождения, что жизненно важно в случае любой онлайн-публикации, которая хочет быть быстрой для всех своих читателей.

Итак, сцена была готова. Smashing Magazine перешел на JAMstack — в частности, на Netlify как платформу. За 10 лет работы Smashing вырос из небольшого онлайн-издания в крупный блог WordPress, где продаются такие вещи, как книги, билеты на конференции и семинары.

С этого сайта было несколько штук:

• Блог WordPress
• Доска вакансий Rails
• Shopify магазин
• Еще одна CMS для сайта конференции

Когда Netlify впервые начал миграцию, сайт страдал от некоторых проблем с производительностью, отягощенных 20 тысячами комментариев и тысячами статей. Smashing также интересовался аутентификацией в рамках нового плана подписки, а также редизайном для более современного вида.

Надежность

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

Переход на Netlify позволил команде Smashing избежать ошибок при подключении к базе данных и не беспокоиться о простоях , даже когда статья имела огромный объем трафика. Почему? Потому что при обслуживании без сервера предварительно созданный контент не нужно создавать и обслуживать — он уже существует и готов к просмотру. На месте ничего не запрашивается, кроме всей статической страницы.

Обслуживание через CDN также позволило Smashing спать немного легче с точки зрения безопасности. wp-login.php долгое время был источником дыр в безопасности и векторов атак. Доступ к готовому контенту невозможен таким же образом, а дыры в безопасности не так распространены.

Инвалидация кеша

Smashing перебирал все плагины кэширования WordPress с разными результатами и множеством проблем. Виталий Фридман из Smashing упоминает:

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

Переход на Netlify позволил команде Smashing увидеть мгновенную недействительность кеша, а также обслуживать кешированный и производительный контент без дополнительных накладных расходов.

Когда вы развертываете сайт, файлы HTML размещаются в CDN Netlify. Он оптимизирован для высокой скорости попадания в кэш и быстрого получения первого байта, а также может мгновенно аннулировать все измененные HTML-файлы . Netlify также проверяет все ссылки на активы, такие как файлы CSS, изображения, шрифты или файлы JS, и обслуживает Smashing с кэширующими заголовками, которые кэшируют их навсегда. Снятие отпечатков пальцев гарантирует, что они уникальны, и что при обновлении новой версии вместо нее будет использоваться более новая версия.

Рабочий процесс

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

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

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

После того, как это было написано и преобразовано, оно было загружено в новый репозиторий в GitHub, и вместо него использовалась Netlify CMS. Что делает Netlify CMS уникальной, так это то, что она легкая и интегрирует редакторы контента в рабочий процесс Git — это означает, что она будет буквально извлекать и обслуживать файлы уценки из репозитория git, а не из базы данных. Кроме того, Netlify CMS не зависит от платформы и работает (почти) со всеми генераторами статических сайтов и сайтами, хранящимися в GitHub.

В то время Сара Суэйдан работала в Smashing внештатным разработчиком внешнего интерфейса над их редизайном. Она создала библиотеку компонентов для создания архитектуры внешнего интерфейса и отметила, насколько проще было работать с ней, поскольку она работала непосредственно в git, даже при работе с CMS.

«Все, что я отправил в репозиторий, напрямую применяется к библиотеке шаблонов, а это означает, что вам не нужно поддерживать два разных набора компонентов... такая непрерывность была великолепной! Все, что мне нужно сделать, это написать HTML, CSS и JavaScript и отправить их в репозиторий, и все заработает как по волшебству. Рабочий процесс был фантастическим».

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

Вот почему в следующем уроке мы познакомим вас с безголовой моделью , в которой вы по-прежнему сможете пользоваться преимуществами панели инструментов WordPress для создателей контента, но использовать WordPress через API, а разработка будет опираться на рабочий процесс, ориентированный на git, который легко для разработчиков, чтобы поддерживать, а также. Следите за обновлениями!

Выбор фреймворка

В первоначальном прототипе, созданном Мэттом Бильманном, он написал все на минимальном Preact в паре с Хьюго, так как был очень сосредоточен на производительности. Он просто использовал реквизит и сделал все очень легким. Когда он передал проект на сопровождение разработчику Smashing, Илье Пухальскому, он обнаружил, что в Preact не хватает некоторых функций, которых им не хватало для подключения к экосистеме React. В конце концов, преимущества Redux и других библиотек перевесили стоимость.

Размышляя сейчас, Мэтт говорит, что он бы использовал Vue, который в то время не имел достаточной доли рынка (клянусь, я не подталкивал его к этому). Я задал очевидный вопрос: почему не Svelte? Поскольку люди, ориентированные на производительность, склонны тянуться к этой библиотеке. Он упомянул, что у Svelte пока нет такой экосистемы, как у Vue.

Когда Мэтт размышляет о том, стал бы он по-прежнему использовать Hugo, он говорит, что любит Hugo, но особенно в этом проекте он нашел трудным то, что в нем не было достаточной системы плагинов — создания баннеров и прочего. что природа не была достаточно программируемой с Хьюго, и ему нужно было вводить сценарии, чтобы выполнить это. Эти сценарии, как правило, замедляли процесс сборки. Тем не менее, мы по-прежнему используем Hugo для нашего собственного сайта netlify.com, и нам это нравится — это предостережение особенно важно для нужд сайта Smashing, в частности.

Если бы он мог сделать это снова, он мог бы выбрать либо Eleventy, у которого есть богатые возможности с точки зрения создания плагинов и других расширяемых скриптов. Или, если бы он использовал Vue, Nuxt предложил бы ему некоторые хорошие возможности плагинов, позволяя быть хорошим выбором для этой платформы, предлагая рендеринг на стороне сервера, маршрутизацию и статическую генерацию.

Создание больших сайтов

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

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

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

Что сделал Netlify, так это создал большую папку /production-articles , которая содержала большую часть многих тысяч статей, которые они уже размещали. Затем создал отдельный рабочий каталог с именем content/articles , куда можно было помещать статьи, которые активно создавались и редактировались.

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

Одним из недостатков этого подхода является то, что он по-прежнему требует запуска всей сборки, что замедляет процесс. В небольшой публикации это, вероятно, будет иметь меньшее значение, но в масштабе Smashing это действительно замедляет процесс публикации.

API с открытым исходным кодом

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

• GoTell
  API и инструмент сборки для обработки большого количества комментариев.
• Перейти
  Небольшой API на основе Go для сайтов электронной коммерции, который обрабатывает заказы и платежи.
• GoTrue
  Небольшой API с открытым исходным кодом, написанный на Golang, который может действовать как автономная служба API для обработки регистрации пользователей и аутентификации для проектов. Он основан на OAuth2 и JWT и будет обрабатывать регистрацию пользователей, аутентификацию и пользовательские данные.

Каждая из этих частей требовала миграции и собственных уникальных факторов, и хотя они выходят за рамки этой статьи, все они описаны в бесплатной книге, написанной в соавторстве с Мэттом, под названием « Современная веб-разработка на JAMstack ». Мы также сделаем несколько глубоких погружений, подобных этому, — с полезными примерами — в поиске и аутентификации в последующих сообщениях.

Заключение

Миграция прошла гладко. Сокрушительно? Э… все прошло хорошо. Smashing не наказывался из-за его собственного успеха — когда появлялась популярная статья, они могли последовательно отображать контент, больше не отказываясь от больших нагрузок. Наряду с этим переход на инфраструктуру JAMstack повысил производительность и безопасность.

Маркус Сейферт, бывший генеральный директор Smashing Magazine, отметил:

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

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