Переориентация современной издательской платформы
Почти 66%[1] всех веб-сайтов в Интернете сегодня работают на той или иной форме системы управления контентом. Большинство из них тесно связывают свои проблемы с отображением страниц с поставщиками данных и редакторскими инструментами. Это невероятно сложно масштабировать осмысленным и эффективным способом.
Почему масштаб?
Масштабирование — это реакция на повышенный спрос на услугу или услуги. У современной публикации могут быть внезапные всплески трафика, которые превышают вашу базовую читательскую аудиторию. Сколько раз вы читали вирусную историю только для того, чтобы перейти к исходному материалу и обнаружить, что сайт отключен из-за спроса?
Масштабирование позволяет быстрее и без перерыва охватить больше людей за счет увеличения ресурсов, необходимых для этого, или оптимизации процессов приложений для увеличения или уменьшения масштаба в зависимости от потребностей.
Традиционная CMS представляет собой монолитное приложение, тесно связанные компоненты, огромные требования к обработке и кэшированию; которые обеспечивают очень небольшую отдачу, кроме обслуживания страниц.
Мы хотели использовать эту потраченную впустую мощность, вернуть ее и лучше использовать в других местах нашей платформы, используя ее для обработки изображений или кодирования видео.
Разделяй и властвуй
Изучая неэффективность нашего процесса разработки, стало ясно, что наличие тесно связанной системы рендеринга с нашей бизнес-логикой и поставщиками данных означало значимые изменения в рендеринге страниц и контенте, требующие гораздо большего, чем следовало бы.
Мы решили дать команде фронтенда возможность работать быстро, использовать существующие инструменты в своем наборе инструментов и избавиться от раздувания.
Интерфейсному инженеру не нужно разбираться в докере, бродяге или настраивать приложение, прежде чем приступить к работе.
Отделение рендеринга контента от наших поставщиков данных и остальных редакционных инструментов было единственным способом добиться этого.
Генерация статического контента становится все более популярной, и существует множество таких фреймворков, как Jekyll, MetalSmith и Hugo. Использование MetalSmith казалось нам легкой задачей, поскольку мы хотели поддерживать технологический стек FE (JS/HTML/CSS[Sass, SCSS]), который можно было бы легко построить с помощью нашего сервера непрерывной интеграции, используя nodeJS и gulp.
Генерация статического контента имеет смысл по нескольким причинам:
- После того, как вы накопите ресурсы своей страницы, вы уменьшите задолженность по обработке и сможете разгрузить ее на CDN для быстрой доставки*
- Вписывается во внешний рабочий процесс
- Не требует настройки среды — HTML/JS/CSS может работать везде
*Как и в любом бизнесе, работающем в Интернете, крайне важно избегать простоев, а возможность размещать статический контент в сети CDN снижает количество единых точек отказа и обеспечивает значительный прирост производительности
*Мы также можем удалить любую инфраструктуру, используемую для обслуживания контента, и использовать ее для других более сложных и интересных задач
Разрыв мертвой хватки между рендерингом, хранением и редактированием контента дает возможность использовать не только многопользовательскую систему (множество публикаций из одной кодовой базы/API), но теперь мы можем более эффективно использовать наши ресурсы обработки.
Дополнительным побочным эффектом использования SCG является возможность пересматривать контент, сверхурочные изменения в макете, таблицах стилей или JS не требуют полной сборки сайта. Мы можем постоянно обновлять каждую из наших публикаций, и в худшем случае мы обновляем контент всего за пару дней, если у нас плохой выпуск кода — удобно, когда у вас более 80 000 статей на платформе.
Кэширование ресурсов может быть бессрочным, пользователи будут получать более быструю осмысленную визуализацию сайта быстрее, поскольку обновления ресурсов создают версию с уникальным хэшем, сохраняя большую часть ресурсов сайта в кеше браузера.
Команда внутренних инженеров теперь также может сосредоточиться на создании инструментов и API-интерфейсов, которые могут отображать контент, предоставлять ресурсы поиска и изображений, которые можно легко масштабировать, и предоставлять наш контент не только для Интернета, но и для других платформ.
Наша команда по интеграции может полностью состоять из внутренних инженеров, в то время как наша команда по внешнему интерфейсу и приложениям может сосредоточиться на обеспечении невероятных возможностей для наших читателей.
В результате кэширование также стало проще поддерживать, и мы смогли предсказать, где может потребоваться дополнительное укрепление.
Создайте невероятный опыт
Google, Apple и Facebook вложили значительные средства в технологии, которые ускоряют загрузку страниц и отображение контента в Интернете.
Google AMP и Facebook Instant Articles ориентированы на практически мгновенное представление контента читателям. Читатели не хотят ждать, они не лояльны и найдут то, что хотят, в другом месте.
Мы хотели создать невероятно быстрый интерфейс не только для мобильных устройств, но и для компьютеров и других устройств.
Установка запроса и бюджета ресурсов позволила нам снова сосредоточиться на том, что должно быть доставлено, чтобы кто-то мог прочитать наш контент. Изображения, значки, шрифты и другие ресурсы, не необходимые для чтения, удаляются из начальной загрузки. Таблицы стилей и JavaScript называются асинхронными или неблокирующими.
Мы сократили начальное время загрузки с 3 секунд до ~ 500 мс в среднем на 100 000 запросов в секунду.
Внедрив более строгое кэширование на клиенте, управление версиями и хеширование ресурсов с длинным TTL кеша, мы улучшили «скорость восприятия» загрузки нашей статьи и, как следствие, увеличили среднюю продолжительность сеанса на 30%, снизив показатель отказов на 15%.
Подпишитесь на нашу публикацию, чтобы узнать больше
