Отдайте нам ваши статьи

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

В этой статье Борис Ребров, руководитель разработки клиентской части медиапроектов, рассматривает один из шагов в этом направлении — ”нативные” статьи, которыми, вслед за Facebook, с его Instant Articles, обзавелся Google (AMP), а недавно и Telegram.

Суть вопроса проста и понятна: сервис, в том или ином виде, получает контент у издателя и, вместо перехода по ссылке на сайт, показывает пользователю статью у себя, при этом оптимизировав время загрузки и переформатировав ее под свое окружение. Технически все тоже достаточно просто. Основной момент тут заключается в том, что и для ускорения загрузки, и для того, чтобы иметь возможность видоизменять материалы, нужно уметь приводить данные от разных издателей к единому виду. Давайте более подробно рассмотрим, как коллеги подошли к решению этой задачи.

AMP Project

Начнем с инициативы Google, потому что AMP стал первым форматом, доступным всем издателям. Кроме того, ребята предлагают наиболее жизнеспособную концепцию.

Подробное описание проекта присутствует по ссылке выше. Если коротко — это набор достаточно строгих требований, предъявляемых к коду страницы, направленных на оптимизацию скорости ее работы и независимость от контекста отображения. Одно из требований — использование стандартных компонентов из общего репозитория проекта. Весь код проекта выложен в open source, так что сторонние разработчики могут предлагать свои реализации компонентов, патчи и фиксы в уже существующие. Чтобы Google или другой сервис нашли ваши документы и ассоциировали их с обычными веб-страницами, достаточно добавить теги с перекрестными ссылками:

<link rel=”amphtml” /> //на страницах сайта
<link rel=”canonical” /> //на amp-версиях страниц

Таким образом, AMP-страницы существуют в привычном окружении, используют стандартные для веба технологии и библиотеку компонентов, поддерживаемую сообществом, могут использоваться сторонними сервисами. Что может быть лучше?

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

Нам, в Медиапроектах Mail.Ru Group, было очень просто поддержать AMP на страницах наших материалов. Статьи уже давно хранятся у нас в виде структуры и шаблонизируются перед выдачей клиенту. И мы просто добавили для них еще одно представление.

Facebook Instant Articles

Разработчики из Facebook тоже решили не изобретать ещё один язык разметки и используют в своём решении HTML5. И так же, как и Google, они налагают на его формат свои требования. Однако тут html используется, скорее, для представления структуры материала, на выходе приложение покажет свой UI, а не тот html, который вы ему передали. Количество поддерживаемых компонентов тут несколько меньше чем в AMP, но есть возможность встраивать сторонние виджеты, в том числе и напрямую с вашего сайта (однако в разметке они фигурируют как iframe, соответственно, у виджета должен иметься выделенный url). Тестирование формата началось в далеком 2015 году, и AMP, в какой-то степени, стал ответом на его внедрение.

У Facebook, в отличие от Google, нет краулеров, обходящих все страницы вашего сайта. Поэтому передавать разметку статей им приходится явно, публикуя RSS-ленту с ней или посредством API (работа с которым уже поддерживается в некоторых популярных CMS).

В итоге мы получаем еще один формат представления. Хотя Facebook и декларирует возможность преобразования InA в AMP и даже поддерживает такое преобразование в рамках своего SDK, рабочим такой вариант можно назвать только условно.

Что ж, два формата — так два. Как я уже писал выше, мы шаблонизируем статьи перед отображением, поэтому с реализацией проблем также не возникло.

Telegram Instant View

Сам формат отображения материалов непосредственно в интерфейсе мессенджера появился достаточно давно. Но совсем недавно команда Telegram дала сообществу возможность создавать шаблоны для любых площадок и даже запустила конкурс с немалым призовым фондом. Первой реакцией было восклицание “Ох, ещё один формат! Сколько можно?!”. Но потом выяснилось что все ещё хуже. Серьёзно. Ребята оставили шаблонизацию на своей стороне, что неплохо, но данные для неё они, внезапно, решили получать, разбирая код “обычных” веб-страниц. Шаблон Instant View — это, фактически, набор инструкций XPath, указывающих, где в html лежат те или иные части материала, и некоторое количество логики, описанной самобытным синтаксисом. Невалидная верстка? Редизайн? Нет, не слышали. То есть мы имеем два этапа шаблонизации, и работоспособность второго зависит от результатов первого, который, в отличие от тех же InA, не стандартизирован. На мой взгляд, это чудовищный антипаттерн. Хоть в школе показывай “как не надо”. Хотя, теоретически, объем шаблонов, созданных сообществом в рамках конкурса, может быть достаточен, чтобы обучить на нем нейросеть и автоматизировать процесс поиска данных в верстке.

Мы реализацию пробного шаблона для Instant View отдали на аутсорс и ждём, пока закончится конкурс.

Резюмируя, скажу, что все ещё только начинается. Сервисы, “владеющие” трафиком, продолжат тянуть одеяло на себя. Остаётся надеяться что многим хватит дальновидности выбрать путь, проторенный Google, не плодить новые форматы, более плотно работать с издателями и сообществом. Хотя, насколько известно, коллеги из Яндекс уже запилили свой велосипед. Больше форматов богу форматов!