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

Форматы

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

Вам нужно использовать RSS 2 или Atom. Эти форматы имеют очень широкую поддержку. Среди других популярных форматов более старые стандарты RSS и JSON Feed или Microformats h-feed. Я буду избегать использовать их или менее популярные форматы, потому что их поддержка не так широка.

Если у вас ещё нет фида, то крайне рекомендую воспользоваться Atom. В его спецификации гораздо меньше неопределённостей, поэтому меньше вероятность проблем совместимости с широким ассортиментом клиентов. Кроме того, спецификация в целом проще и понятнее. Если у вас уже есть фид RSS 2, то причин для апгрейда почти нет.

Минимальный шаблон Atom представлен ниже. Все подробности можно узнать в спецификации. Если вам нужен пример, можете взглянуть на мой фид.

<?xml version="1.0" encoding="UTF-8"?>
<feed xmlns="http://www.w3.org/2005/Atom">
	<title>{{FEED_NAME}}</title>
	<id>{{HOMEPAGE_URL}}</id>
	<link rel="alternate" href="HOMEPAGE_URL"/>
	<link href="FEED_URL" rel="self"/>
	<updated>{{LAST_UPDATE_TIME in RFC3339 format}}</updated>
	<author>
		<name>{{AUTHOR_NAME}}</name>
	</author>
	<entry>
		<title>{{ENTRY.TITLE}}</title>
		<link rel="alternate" type="text/html" href="{{ENTRY.HTML_URL}}"/>
		<id>{{ENTRY.PERMALINK}}</id>
		<published>{{ENTRY.FIRST_POST_TIME in RFC3339 format}}</published>
		<updated>{{ENTRY.LAST_UPDATE_TIME in RFC3339 format}}</updated>
		<content type="html">{{ENTRY.HTML}}</content>
	</entry>
</feed>

Нет практически никаких причин для того, чтобы обеспечивать фиды в нескольких форматах. Если у вас есть Atom-фид, не нужно создавать ещё и RSS-фид.

Смена формата фида безопасна. Очень немногие ридеры будут сбиты с толку при переключении фида с Atom на RSS или наоборот. Это можно сделать изменением фида по тому же URL или перенаправлением на новый URL. (Необходимо только обновить тип контента, см. ниже.)

Тип контента

Правильно укажите заголовок Content-Type.

Atom: Content-Type: application/atom+xml
RSS: Content-Type: application/rss+xml
JSON Feed: Content-Type: application/feed+json

На практике используются и другие значения, но выше представлены стандартные значения, имеющие самую широкую поддержку.

Абсолютные URL

Все URL в вашем фиде должны быть абсолютными. Хотя в спецификации Atom чётко объяснено, как резолвить относительные URL, их редко реализуют корректно. Чтобы ваш фид точно понимали все ридеры, используйте только абсолютные URL (начинающиеся с https://).

Это относится ко всем элементам <link>, summary и body постов (включённым в HTML).

Discovery

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

<link rel=alternate title="Blog Posts" type=application/atom+xml href="/feed.atom">

Если у вас несколько фидов, вы можете рекламировать их под соответствующими названиями.

<link rel=alternate title="Все посты" type=application/atom+xml href="/feed.atom">
<link rel=alternate title='Посты в категории "Social"' type=application/atom+xml href="/feeds/social.atom">
<link rel=alternate title="Комментарии к этому посту" type=application/atom+xml href="/post/hello-world/comments.atom">

Используйте правильный type для своего фида. Выше представлены примеры для Atom-фидов.

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

Можно проверить, что всё работает правильно, вставив URL своего веб-сайта в W3C Feed Validation Service. Если ссылки настроены верно, он должен распознать и валидировать ваш фид. Проверьте несколько разных страниц, чтобы убедиться в правильности работы discovery. Проверьте главную страницу, страницу со списком постов и страницу отдельного поста.

Если сложно изменить HTML, то можно использовать заголовок Link в HTTP-ответе. Однако его поддержка не очень широка. Для повышения совместимости предпочтительнее использовать HTML-теги <link>.

Link: /feed.atom; rel="alternate"; type="application/atom+xml"

Также стоит дополнять ссылку логотипом RSS

, чтобы её замечали пользователи без других индикаторов фидов.

HTTPS

HTTPS критически важен для безопасности и приватности в Интернете. Передача фидов через HTTPS обеспечивает приватность пользователей и гарантирует, что ваш фид не будет модифицирован злоумышленниками.

Ссылайтесь на все встроенные медиа (например, изображения) через HTTPS. Если HTTP-запросы запрещены, многие ридеры работают в защищённом контексте.
Передавайте фид через HTTPS.
Убедитесь, что ваша self link является HTTPS.
Перенаправляйте HTTP-запросы на HTTPS.
Подумайте об использовании Strict-Transport-Security.

Полный контент

В общем случае рекомендуется передавать в фиде полный контент постов. Это предпочтительно для большинства ридеров. У Atom есть элемент <summary> для предпочитающих его ридеров. Для RSS и Atom должен быть включён элемент <content> полной статьи.

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

Если ваш контент платный, то рассмотрите возможность позволить пользователям генерировать приватные ссылки, предоставляя токен аутентификации. Например, /feed.atom?user=peruserauthtoken. Также можно использовать простую аутентификацию вида https://fred:peruserauthtoken@blog.example/feed.atom, однако она поддерживается меньшим количеством ридеров, чем передача токена в пути URL или в строке запроса.

Entry ID

Entry ID — это основной способ идентификации разных записей фида. Если entry ID меняются или повторяются, то ридеры будут пропускать записи или получать дубликаты записей.

Никогда не меняйте Entry ID старых статей.
- Если вы меняете схему создания ID, убедитесь, что она применяется только к новым записям.
Никогда не используйте одинаковые Entry ID для разных статей.
Лучше использовать в качестве Entry ID постоянные ссылки на статьи.
Лучше сделать Entry ID глобально уникальными для всех существующих фидов.
- Некоторые ридеры объединяют фиды, уникальные ID гарантируют отсутствие проблем.
- Проще всего этого добиться, использовав URL контролируемого вами домена. Если это невозможно, то можете использовать UUID вида urn:uuid:f4a3ca5b-5799-44e8-aaaa-e40728f037d3.

Даты

И Atom, и RSS различают время публикации (время, когда запись впервые появилась в фиде) и время последнего обновления (последний раз, когда запись была изменена). Обрабатывайте их корректно.

Добавляйте время публикации.
Время публикации никогда не нужно изменять. Запись может быть опубликована только один раз.
Лучше, чтобы время публикации приблизительно совпадало с тем, когда запись появляется в фиде. Некоторые ридеры игнорируют записи, опубликованные в далёком прошлом. Крайне рекомендуется избегать того, чтобы записи отображались в фиде в порядке, отличном от того, который подразумевает время публикации.
Не указывайте время публикации в будущем. Если время публикации находится слишком далеко в будущем, многие ридеры игнорируют это как баг.
Время обновления должно быть больше или равно времени публикации. У новых записей они должны быть одинаковыми.
Время обновления должно меняться только при существенных обновлениях. Незначительное изменение форматирования или исправление опечаток, скорее всего, не стоят изменения времени последнего изменения. Большинство ридеров игнорирует время обновления, некоторые другие поднимают статью вверх как «обновлённую».

Стилизация

Свободно используйте в фиде CSS! Однако помните о том, что многие ридеры не используют движки современных браузеров и могут иметь ограничения рендеринга. Кроме того, многие ридеры очищают фиды, поэтому нестандартные элементы или собственные CSS могут быть частично или полностью вырезаны. Но пусть это вас не останавливает! Использование HTML и CSS может сильно повысить удобство для пользователей с хорошими ридерами. Воспользуйтесь следующими советами:

Посмотрите, что произойдёт, если не будут применяться CSS. Например, если вы указали background: black; color: white, но одно из двух правил будет вырезано, то текст окажется нечитаемым. В общем случае стоит вносить при помощи CSS небольшие изменения, а не существенные.
Лучше использовать встроенные атрибуты style CSS для разделения блоков <style>. Их совместимость выше.
Лучше использовать семантические элементы наподобие <p>, <h1>, <pre> и <code>, а не имитировать их стиль в <div> и <span>.
Не используйте JavaScript, его не поддерживает почти ни один ридер.
Обеспечьте возможность отката для тегов <audio>, <video> и <iframe>. Они поддерживаются нечасто.
Избегайте элементов форм и ввода. Их поддержка редка и несовместима.

К сожалению, здесь поможет только тестирование.

Self Link

Убедитесь, что self-link вашего фида правильна.

<link rel="self" href="https://kevincox.ca/feed.atom"/>

Это даёт следующие преимущества:

Позволяет перемещать фид. Некоторые ридеры обновляют URL фида, если получают постоянный редирект и цель редиректа содержит указывающую на себя self link.
Повышает попадание в кэш. Пользователи часто встречают незначительные вариации URL вашего фида. Например, http: вместо https:, /feed вместо /feed/, www.example.com вместо example.com, feed.atom?tracker=lookatme вместо ?category=rant&content=full или ?content=full&category=rant. Предоставляя канонизированную self link, вы можете объединить их, чтобы уменьшить вариативность и увеличить частоту попадания в кэш.
Это необходимо для WebSub (см. ниже).

Кэширование

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

Примеры заголовков кэша:

5 минут: Cache-Control: max-age=300
15  минут: Cache-Control: max-age=900
1 час: Cache-Control: max-age=3600

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

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

Условные запросы

Обеспечьте в своём фиде поддержку условных запросов. Это сделает опросы более эффективными и для вас, и для пользователей.

Возвращайте заголовок ETag и/или Last-Modified. При этом возвращайте ответ 304, если фид не изменился. Подробнее см. в HTTP conditional requests на MDN.

WebSub

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

Можно использовать публичный хаб или создать собственный. Стоит заметить, что хаб может изменять или инъектировать контент в ваш фид, так что убедитесь, что доверяете выбранному хабу.

Мне не удалось найти хороших общих инструкций, но на главной странице хаба Google есть базовые инструкции. Возможно, когда-нибудь я сам напишу руководство…

Доступ для ботов

Если вы используете какую-то технологию блокировки ботов, то отключите её (или снизьте её придирчивость) для фидов. Ведь их и должны потреблять боты! В противном случае у пользователей возникнут сложности с доступом к фиду и они не узнают о новом контенте.

Многие популярные сайты сталкиваются в этом вопросе с проблемами. Я уже писал об этом. Убедитесь, что вам не вредят параметры по умолчанию различных сервисов.

Категории

Категории — надёжный способ фильтрации тем фидов. Гораздо лучше дать пользователям возможность подписываться на одну категорию (или на все, кроме одной), чем потерять подписчика из-за того, что его раздражает часть вашего контента.

Для добавления категорий в Atom-фиды достаточно одного элемента. Например, этот пост имеет в моём фиде следующую разметку:

<category term="RSS"/>
<category term="Guide"/>

Для RSS 2 синтаксис лишь немного отличается:

<category>Rant</category>

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

Смена URL

Нужно максимально стремиться избегать смены URL фида. Но если это нужно сделать, то вот как поступить, чтобы не потерять слишком много подписчиков.

Сделайте фид доступным по новому URL в дополнение к старому URL.
Сделайте так, чтобы self link нового фида указывал на новый URL.
Если вы используете WebSub, то начинайте пинговать хаб для обоих URL после публикации.
Перенаправляйте старый URL на новый с помощью 308 Permanent Redirect.
Если вы используете WebSub, то нужно продолжать пинговать старый URL по крайней мере 3 месяца или в течение максимального срока действия подписки вашего хаба (в зависимости от того, какое из значений больше).

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

Производительность

Маленькие и локальные ри��еры фидов обычно используют простые частоты опроса, однако многие крупные сервисы применяют различные эвристики для того, чтобы определять, когда нужно проверять обновления вашего фида. Если вы не поддерживаете WebSub, то стоит нацелиться на то, чтобы отвечать на запросы фида за менее 1 секунды. Если ваш фид медленнее, особенно если он опрашивается медленнее, чем за 3 секунды, то есть вероятность, что опросы замедлят и ридеры будут получать обновления медленнее.

Приведённые ниже соображения не так важны. Их нужно учитывать, если вы создаёте продукт или генератор фидов, но, вероятно, они не стоят вашего внимания, если вы просто делаете фид для собственного блога.

Краткая информация

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

Пагинация

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

Пагинация очень проста. Достаточно добавить в фид следующую ссылку.

<link href="https://kevincox.ca/feed/2022-03-05.atom" rel="next"/>

Затем на последующие страницы также добавить ссылку prev. Разумеется, на последней странице не будет ссылки next.

<link href="https://kevincox.ca/feed.atom" rel="prev"/>
<link href="https://kevincox.ca/feed/2022-01-21.atom" rel="next"/>

При выборе размера страниц помните, что не все клиенты поддерживают пагинацию, поэтому не стоит слишком быстро перемещать новые записи с первой страницы. Я рекомендую следующее, но помните, что это обобщённые правила и их стоит применять рассудительно. Например, если вы публикуете посты по 20 раз в день, то вам, наверно, не стоит хранить в фиде 7 дней контента. Аналогично, если ваши посты состоят из одного-двух параграфов, то, вероятно, на первой странице может быть чуть больше записей.

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

Рекомендации по созданию RSS-фидов