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

У нас в веб аппке есть страницы подкастов. Если кто-то делится подкастом из приложения, ссылка открывается в браузере, если у получателя не установлен Metacast.

Пример такой страницы: https://metacast.app/podcast/metacast-behind-the-scenes/N52SWYpt

Данные подтягиваются с бэкенда. Сначала тащим информацию о подкасте, потом 30 последних эпизодов. В идеальном сценарии это занимает меньше секунды, но если бэкенд «холодный», то может занять и 5+ секунд.

Это — извечная проблема serverless. Когда бэкенд не используется (нет запросов), ты за него не платишь. Но это так же значит, что на облаке контейнер, в котором исполняются функции типа AWS Lambda или Google Cloud Functions, «спит» и при запросе его нужно быстренько выкатить, принять запрос и ответить.

Это называется cold start. Когда контейнер не спит, запросы выполняются очень быстро. В таком случае говорят, что контейнер тёплый.

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

Но вот что мы обнаружили. Когда страницу нужно переадресовать, так как она «переехала» (у подкаста поменялся заголовок и, как следствие, URL), то вместо кода 301 или 308, который говорит Гуглу, что нужно смотреть по другому адресу, в ответ возвращается код 200, что значит ОК. А переадресация потом происходит в браузере.

Более того, нас начал долбить бот OpenAI. Десятки тысяч запросов на несуществующие страницы! У них был какой-то баг 🤷‍♂️

Вместо того, чтобы дать им в ответ код 404 (не найдено), мы все равно возвращали 200, в итоге они продолжали отправлять запросы на страницы, которые они считали существующими.

И здесь встала дилемма.

Чтобы показывать лоадеры, сервер должен вернуть код 200. Он еще не знает нужно ли переадресовать страницу или данные не найдены, так как данные ещё не получены с бэкенда. Вся суть лоадера — в том, чтобы скрасить ожидание… а чтобы браузер показал лоадер, он должен получить в ответ 200 ОК.

Мы посмотрели вариант с тем, чтобы показывать лоадеры только живым пользователям, а ботам не показывать, но это не работает в сочетании с кэшированием страниц в Next.js. А кэш нужен, чтобы было быстрее, дешевле и чтобы не загружать бэкенд.

В итоге встал вопрос. Что важнее — показывать пользователям лоадеры (хороший UX) или оптимизация под поисковики (SEO).

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

Так хотелось и рыбку съесть и тортик, но не вышло. Пришлось принимать прагматичное решение в ущерб пользователю из-за технической имплементации.

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