Оптимизация пагинации и бесконечного скролла для поисковиков

С точки зрения SEO понятно, что краулеру хорошо бы видеть SSR’ed html, однако иногда этого сложного достичь. На примере с nextjs парадигма фреймворка отдавать init shell html нужно asap и все, что зависит от Dynamic Api, к примеру доступ к headers, должно быть доставлено через Suspense.

И тут мы получаем кейс, если мне нужно отдавать контент в зависимости от региона (по ip), то я не могу заранее определить список позиций для выдачи. Соответственно бот получает немедленно static shell и скелетоны которые покажутся после гидрации через js.

Второе неудобство это сложность синхронизации серверного и клиентского стейта для infinity scroll, когда первая страница была показана с SSR и page2 кусок должен быть добавлен с помощью js.

Так вот вопрос - заявляется, что google bot эффективно индексирует даже простые react приложения без SSR. То есть индексация происходит после выполнения js. Это ложь?

Как настроить Server Side Rendering для индексации SPA приложений поисковиками

В 2026 показывать пример про next с getServerSideProps и pages router, ну такое

Организация импортов в React + TypeScript: настройка ESLint для порядка и чистоты кода

Порядок некоторых импортов, например таких, как scss важен (вы можете получить другой результат рендера).
Так же, без правила сортировки, каждый мейнтенер будет коммитить кучу конфликтов или просто мусорных изменений в порядке импортов, согласно его видения или видения его IDE

В Госдуме заявили, что Telegram не заблокируют до переноса каналов в Мах

Заполняете огромный слайс живых сообщений в LLM и получение удивительные данные и возможности

10 Принципов отказоустойчивости (с примерами на Javascript)

Честно сказать, ничего не могу сказать...
Да, вы совершенно правы. Я был рад прочитать ответ на мой комментарий. Пожалуйста, пишите ещё, я всегда рад ответить!

10 Принципов отказоустойчивости (с примерами на Javascript)

Даже не знаю пройдет ли этот комментарий тест Тьюринга :)

Ресайз изображений на лету с помощью Nginx и LuaJIT (OpenResty)

Смотря чего вам требуется достигнуть.
Можно настроить rate limit чтоб не долбили часто ngx_http_limit_req_module
Можно нормализовать экзотические размеры, типа 365x365 => 400x400
Можно ограничить с помощью ngx_http_secure_link_module
Ну или любую логику на lua добавить.

Ресайз изображений на лету с помощью Nginx и LuaJIT (OpenResty)

Не отдельный, архитектура остается типовой Nginx front + Nginx back. Фронт является балансировщиком, занимается кэшем и т.п. А бэк обслуживает само приложение + еще один upstream куда проксируются запросы ресайза.

Ресайз изображений на лету с помощью Nginx и LuaJIT (OpenResty)

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

Ресайз изображений на лету с помощью Nginx и LuaJIT (OpenResty)

Не вводит ли это в заблуждение и что вернет кэш другому клиенту?
Много решений для этого есть, например

background: image-set(
url('https://example.jpg?resize=400x400') 1x,
url('https://example.jpg?resize=800x800') 2x)

ну или media

Ресайз изображений на лету с помощью Nginx и LuaJIT (OpenResty)

Вы правы, в статье об этом упомянуто.

Ресайз изображений на лету с помощью Nginx и LuaJIT (OpenResty)

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