Всем привет.

Какое-то время пилил self-hosted чат в стиле Discord и наконец довёл до состояния, которым не стыдно поделиться. Бесплатный, открытый исходный код (MIT).

Зачем вообще: большинство self-hosted чатов требуют Docker, инстанс Postgres, очередь сообщений и полдня жизни до того, как увидишь экран входа. Мне хотелось, чтобы моё сообщество могло общаться, не завися от чужих серверов, и без необходимости быть админом-девопсом. Поэтому тут всё наоборот — только PHP и один файл SQLite. Если ваш хостинг тянет блог на WordPress, он потянет и это.

Что умеет: серверы, текстовые каналы и личные сообщения с редактированием и реакциями; голосовые комнаты и звонки по WebRTC с демонстрацией экрана; обмен файлами (картинки сжимаются автоматически, лента грузит лёгкие миниатюры); устанавливается как PWA на компьютер и телефон без магазинов приложений; несколько тем и 4 языка с переключением на лету; есть API мини-приложений (в комплекте демо 3D-шашек). Весь брендинг и лимиты живут в одном config.json — код трогать не нужно.

Что нужно на сервере: PHP 7.3+ (рекомендуется 8.1+), PDO SQLite, опционально GD для миниатюр, Apache или Nginx с HTTPS. Никакого Node, Composer, отдельной БД и сборки. Установка по сути: залить файлы → дать права на папку uploads → отредактировать конфиг → открыть в браузере.

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

Ссылки:

Исходники (MIT): https://github.com/MrZer0x0/trueCORD

Демо: https://morrowind.site
Демо: https://4tusa.site

Каждый год на рынке веб-разработки появляются десятки новых инструментов, фреймворков и конструкторов. Но для бизнеса вопрос выбора технологии для сайта остается открытым: с одной стороны — хочется быстро и недорого, с другой — не хочется через год упираться в технологический тупик, когда сайт тормозит, не позволяет внедрить нужную фичу или требует неподъемных вложений.

В 2026 году ситуация стала еще критичнее. Поисковые системы окончательно закрепили метрики Core Web Vitals (включая обновленный стандарт INP — Interaction to Next Paint) в качестве прямых факторов ранжирования. Скорость отклика интерфейса и стабильность отображения теперь напрямую влияют на позиции в выдаче и стоимость привлечения клиента. Пользователи привыкли к мгновенным реакциям приложений, а бизнес-задачи усложнились: глубокие интеграции с CRM и ERP, сложные калькуляторы, сквозная персонализация и омниканальные продажи.

На какой платформе строить сайт, чтобы он был быстрым, гибким, безопасным и не разорил компанию через пару лет?

Чаще всего предприниматели выбирают из трех привычных игроков — Tilda, WordPress или 1С-Битрикс. Их знают, о них пишут, они кажутся надежными. Но у каждого из этих решений есть жесткие границы, которые проявляются только при росте бизнеса. И именно в этот момент многие понимают, что дешевый старт обернулся дорогим переездом или полной переписью кода.

Мы — команда Big Panda, 13 лет на рынке Digital. В этой статье мы объективно разберем плюсы и минусы классических платформ, а затем познакомим вас с современным стандартом — Headless-архитектурой на базе Next.js и Strapi, а также расскажем, когда бизнес-логика требует проектирования кастомных решений. Вы узнаете, какой стек идеален для лендинга, какой — для интернет-магазина на десятки тысяч товаров, а какой — для масштабной экосистемы.

Обзор классических платформ

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

Tilda и облачные конструкторы

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

Преимущества:

• Скорость запуска — от 3 до 14 дней.

• Понятный интерфейс для нетехнических специалистов (концепция WYSIWYG — «что видишь, то и получаешь»).

• Встроенная инфраструктура — хостинг, автоматические SSL-сертификаты и базовая защита включены в платформу.

Ограничения:

• Ограниченное масштабирование. В Tilda есть базовые личные кабинеты, пошаговые формы и даже интеграция с 1С для небольших каталогов. Но как только вам потребуется кастомная логика (например, динамический расчет стоимости логистики в зависимости от габаритов товара или сложная система лояльности), стандартных блоков перестанет хватать, а сайт превратится в «лоскутное одеяло» из сторонних JavaScript-скриптов.

• Отсутствие контроля над кодом и инфраструктурой. Сайт существует строго внутри экосистемы платформы. Вы не можете перенести его на собственный сервер или оптимизировать кеширование под специфические требования.

• Зависимость производительности от контента. Хотя сама Tilda использует CDN для отдачи статических файлов, обилие тяжелых анимаций, встроенных пикселей и сторонних виджетов быстро перегружает код. Тонко оптимизировать критический путь рендеринга здесь невозможно.

• SEO-потолок. Базовые мета-теги и микроразметка настраиваются легко, но получить полный контроль над структурой URL, серверными редиректами или сложными картами сайта для огромных проектов не получится.

• Стоимость владения. Актуальные тарифы (от 750–1250 рублей в месяц за один сайт и выше для бизнес-пакетов) при долгосрочном планировании на 3–5 лет сравнимы с разработкой независимого сайта, но при этом бизнес не получает цифровой актив в собственность.

Когда подходит: для одностраничных промо-сайтов, анонсов мероприятий, презентаций продуктов и MVP на этапе тестирования ниши.

WordPress

WordPress удерживает более 40% мирового рынка CMS. Благодаря развитой экосистеме плагинов и тем на нем собирают всё: от контентных медиа до интернет-магазинов (через WooCommerce).

Преимущества:

• Бесплатное ядро и колоссальный выбор готовых модулей.

• Огромное комьюнити: практически любая техническая задача или баг уже кем-то решены и описаны на форумах.

• Гибкое управление контентом благодаря встроенному редактору блоков Gutenberg и системе Custom Post Types.

Системные проблемы:

• Безопасность. Популярность WordPress делает его главной мишенью для автоматических сканеров уязвимостей. Более 90% взломов происходят через устаревшие или некачественные сторонние плагины. Платформа требует постоянного мониторинга, настройки фаерволов и регулярных обновлений.

• Проблема монолитной архитектуры и производительности. «Из коробки» WordPress генерирует страницы динамически: каждый запрос пользователя к серверу запускает цепочку SQL-запросов к базе данных и подгружает код всех активных плагинов. При росте каталога (от 5 000–10 000 товаров) без сложного многоуровневого кеширования, Redis и мощного хостинга сайт начинает ощутимо терять в скорости.

• «Конфликт обновлений». Обновление ядра или одного из плагинов может нарушить работу других модулей и временно сломать верстку или корзину, что требует постоянного контроля со стороны разработчика.

Когда оправдан: для корпоративных сайтов-визиток, крупных блогов, новостных порталов и небольших интернет-магазинов (до 2 000–3 000 товаров) при наличии грамотного администрирования.

1С-Битрикс

1С-Битрикс — российский индустриальный стандарт для e-commerce среднего и крупного масштаба. Его выбирают за готовую глубокую интеграцию с экосистемой «1С:Предприятие» (склады, остатки, цены, контрагенты) и соответствие требованиям законодательства (ФЗ-152, ФЗ-54).

Преимущества:

• Бесшовная синхронизация с 1С и торговыми маркетплейсами «из коробки».

• Богатый e-commerce функционал: скидки, наборы, корзины, кассы и встроенные маркетинговые инструменты.

• Высокий уровень безопасности и регулярный аудит уязвимостей ядра.

Ограничения:

• Финансовая нагрузка. Стоимость коммерческих лицензий для интернет-магазинов («Малый бизнес» и «Бизнес») варьируется от ~45 000 до 100 000 рублей, а Enterprise-версии начинаются от 500 000 рублей. Важно: правила продления жесткие — если вы не обновили лицензию в течение 30 дней после окончания ее срока, последующее продление обойдется в 100% от текущей стоимости, а не в 25%, как это было раньше.

• Требовательность к серверам. Платформа тяжелая. На стандартном виртуальном хостинге она работает медленно; необходима аренда производительных VPS/VDS или выделенных серверов, оптимизированных под Битрикс (стек BitrixEnv).

• Высокий порог входа для разработчиков. Внутренняя архитектура Битрикса специфична. Квалифицированные специалисты стоят дорого, а ошибки программистов, не знающих стандартов платформы (например, прямые запросы к БД в обход ORM), могут полностью заблокировать работу базы данных при пиковых нагрузках.

Когда разумен: для средних и крупных интернет-магазинов с выстроенным учетом в 1С, где автоматизация складских остатков и логистики приоритетнее легкости интерфейса, а компания готова инвестировать в постоянную техническую поддержку.

Headless-архитектура: Next.js + Strapi

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

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

Что это дает бизнесу:

• Омниканальность: бэкенд становится единым источником данных (Single Source of Truth). Один раз заполнив карточку товара, вы можете мгновенно транслировать её на сайт, в мобильное приложение, Telegram-бот или на экраны офлайн-терминалов.

• Абсолютная скорость: пользовательская часть не нагружает базу данных тяжелыми запросами при каждом клике. Она получает чистые данные по API и мгновенно перерисовывает интерфейс.

• Безопасность: панель управления и база данных скрыты от внешнего мира за сервером приложений. Злоумышленник, зашедший на сайт, видит только фронтенд-оболочку, у него нет прямой точки входа для взлома CMS.

Next.js — стандарт высокопроизводительного фронтенда

Next.js — это фреймворк на базе библиотеки React, который стал мировым стандартом для создания быстрых веб-приложений. Его главное преимущество — гибкое управление рендерингом страниц:

• Server-Side Rendering (SSR): страница собирается на сервере за доли секунды и отдается в браузер уже в виде готового HTML. Роботы Яндекса и Google мгновенно индексируют контент, а пользователь сразу видит текст и графику.

• Static Site Generation (SSG) и ISR (Incremental Static Regeneration): страницы, которые редко меняются (о компании, контакты, статьи), компилируются в статичные файлы один раз. Они загружаются со скоростью света и не создают нагрузки на сервер. При этом технология ISR позволяет незаметно обновлять отдельные страницы (например, изменить цену в одной карточке товара) без перезапуска всего сайта.

• Встроенная оптимизация медиа: Next.js автоматически сжимает изображения, конвертирует их в современные форматы (WebP/AVIF) и адаптирует под размеры экрана пользователя, экономя до 70% трафика.

Для бизнеса это означает гарантированное попадание в «зеленую зону» Core Web Vitals, улучшение поведенческих факторов и, как следствие, рост органического SEO-трафика.

Strapi — современная система управления контентом

Strapi — это ведущая Open-Source Headless CMS. Она отвечает за бэкенд-часть: предоставляет удобную административную панель для контент-менеджеров и автоматически формирует REST или GraphQL API для разработчиков.

• Чистый интерфейс: В отличие от перегруженной админки Битрикса или хаотичной структуры WordPress с сотнями плагинов, в Strapi менеджер видит только те поля и таблицы, которые спроектированы под его задачи.

• Гибкое моделирование: Можно за полчаса настроить любую структуру данных — от простых текстовых страниц до сложных многоуровневых каталогов с системой фильтрации.

• Готовая инфраструктура: Из коробки доступны роли пользователей, интернационализация (мультиязычность) и медиабиблиотека.

Стоит быть объективными: контент-менеджерам, привыкшим к Tilda, потребуется короткий период адаптации, так как здесь нет прямого визуального редактирования на самой странице сайта. Но этот шаг компенсируется строгим порядком в данных и отсутствием риска случайно «развалить» дизайн или верстку сайта при изменении текста.

Сравнение подходов: экономика и эффективность

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

По скорости запуска бесспорным лидером остаются Tilda и облачные конструкторы — проект можно развернуть за считаные дни. WordPress занимает среднюю позицию: на сборку сайта уходят недели. 1С-Битрикс и Headless-решения (Next.js + Strapi) требуют больше всего времени — месяцы на проектирование и разработку.

Стоимость разработки распределяется предсказуемо: дешевле всего обходится Tilda, затем с небольшим удорожанием идёт WordPress. 1С-Битрикс и кастомный Headless-стек попадают в категорию дорогих решений из-за сложности внедрения и необходимости привлекать высококвалифицированных специалистов.

По производительности разница становится заметнее. Tilda показывает хорошую скорость только на простых страницах, но при усложнении структуры начинает проседать. WordPress требует постоянной ручной настройки кеширования и оптимизации, чтобы держать приемлемый уровень. 1С-Битрикс также нуждается в мощном VPS-хостинге и тонкой настройке окружения. И только Headless-архитектура на Next.js обеспечивает максимальную производительность, гарантируя попадание в «зелёную зону» Core Web Vitals без компромиссов.

Вопрос безопасности тоже разделяет платформы. Tilda как закрытая SaaS-система предлагает высокий уровень защиты «из коробки». 1С-Битрикс также находится в зелёной зоне благодаря регулярным аудитам ядра. WordPress, напротив, несёт самые высокие риски из-за уязвимостей сторонних плагинов и требует постоянного мониторинга. Headless-решения выходят на первое место по безопасности, поскольку панель управления и база данных скрыты от внешнего мира, а фронтенд работает изолированно.

Наконец, по глубине интеграций и сложности бизнес-логики платформы располагаются так: Tilda подходит только для базовых сценариев, WordPress позволяет подключать средние по сложности модули, 1С-Битрикс даёт глубокую интеграцию прежде всего с собственными продуктами, а Headless-архитектура открывает безграничные возможности через гибкие API-интерфейсы.

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

Когда готовых CMS мало: переход к специализированной архитектуре

Strapi и Next.js идеально закрывают задачи 80% контентных проектов и классического e-commerce. Но существуют бизнес-сценарии, где стандартная архитектура коробочных CMS начинает ограничивать развитие, и требуется переход к кастомному проектированию бэкенда:

• Сложная e-commerce логика: Если в вашем интернет-магазине планируется каталог на 100 000+ товаров со сложной матрицей динамического ценообразования (разные цены для разных типов оптовиков, привязка к курсам валют, остаткам на региональных складах и индивидуальным скидкам), стандартную CMS придется переписать настолько глубоко, что она потеряет свои преимущества. В таких случаях фронтенд на Next.js сочетают со специализированными Headless-commerce движками (например, Medusa.js, Saleor) или кастомными микросервисами.

• Уникальные бизнес-процессы (SaaS, Маркетплейсы, Порталы): Платформы бронирования, HR-сервисы, B2B-кабинеты с тендерными механиками — эти продукты оперируют специфическими сущностями и связями. Разрабатывать их логику с нуля на базе легковесных фреймворков (Node.js, Go, Python) эффективнее и безопаснее, чем пытаться «втиснуть» их в рамки полей обычной CMS.

• Повышенные требования к ИБ и регуляторике: Финтех-сервисы, медицинские платформы или проекты с жесткими корпоративными требованиями к шифрованию, логированию действий и изоляции баз данных создаются по кастомным архитектурным паттернам.

В наших проектах мы придерживаемся прагматичного подхода: мы не предлагаем «кастом ради кастома». Если структуру проекта можно эффективно и надежно реализовать на связке Next.js + Strapi, мы используем этот проверенный стек, экономя бюджет клиента. Если мы видим, что бизнес-логика уникальна — проектируется индивидуальная микросервисная архитектура бэкенда.

Как выбрать стек под вашу задачу в 2026 году

• Лендинг, MVP, промо-страница продукта: Однозначно Tilda. Это быстро, экономически оправдано и позволяет маркетологам гибко управлять контентом без привлечения разработчиков.

• Корпоративный сайт, медиа-портал, новостник: Если бюджет ограничен — WordPress. Если в приоритете ультимативная скорость, высокая безопасность и уникальный дизайн с прицелом на SEO-лидерство — Next.js + Strapi.

• Интернет-магазин до 3 000 – 5 000 товаров: Для быстрого старта с небольшим бюджетом — WordPress + WooCommerce. Для технологичного, быстрого и масштабируемого проекта — Next.js + Strapi / Headless фреймворки.

• Крупный ритейл с жесткой привязкой к инфраструктуре 1С: 1С-Битрикс (желательно с вынесением фронтенда в Headless-режим, если критически важна скорость интерфейса).

• SaaS, Личные кабинеты, Сложные сервисы и Маркетплейсы: Классические CMS здесь противопоказаны. Оптимальный стек — Next.js на фронтенде и кастомная микросервисная архитектура (Node.js / Go / Python) на бэкенде.

Выводы

Платформы вроде Tilda, WordPress и Битрикс — это жизнеспособные рабочие инструменты. Вопрос не в том, какая платформа «лучше в абсолюте», а в том, решает ли она задачи вашего бизнеса на выбранном горизонте планирования.

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

Расследование идёт через разговоры с тремя жителями — солдатом Михаилом, женой Анной и старухой Еленой; ты ловишь, кто себе противоречит и кто отводит глаза, и записываешь в дневник. Говорить можно двумя способами: готовыми вопросами или — подключив бесплатный ключ нейросети — спрашивать о чём угодно своими словами. В живом разговоре персонаж иногда проговаривается, выдаёт деталь, которой нет в готовых ветках, и она влияет на твоё финальное обвинение.

Честно про ИИ: часть прозы и арта сделаны с ИИ-ассистом, а живой диалог — это вообще нейросеть. Прятать глупо: половина интереса в том, можно ли расколоть собеседника, который отвечает вживую. Арт — в духе Васнецова, мрачные полнокадровые сцены; музыка — настоящие записи 1910-х.

Бесплатно, без регистрации и установки, прямо в браузере — в том числе с телефона, на русском и английском:

https://wormwood.games/ru?utm_source=pikabu&utm_medium=p...

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

Что-то вроде портфолио. Образование, карьера, навыки.

Легкий понт

Свой сайт бывает только у серьезных людей. А ты как раз такой.

Как сделать?

Идём в нейронку. Будем делать сайт на 1 страницу.

1. Спрашиваем нейронку, а что надо указать на сайте крутому специалисту по ремонту электрики?

2. Закидываем ей списком или файлом инфу. Цены, расклады, обучение, курсы и личную страницу из ТГ. Грузим фотки.

3. Просим сделать дизайн.

4. Если дизайн понравился, просим сделать сам сайт и запихнуть в архив.

5. Идём на хостинг. Я пользую бегет, не реклама. Можешь спросить у знакомого айтишника.

6. Выбираем имя сайта.

7. Подключаем. Ума не надо точно. Всё по инструкции.

Хостинг можно попросить у айтишника бесплатно, можно купить за 2-3к рублей в год. Имя сайт от 200р в год.

Комментатор, я тебе сайт сделал за пару минут суммарно. Чатгпт. Ссылка здесь.

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

Основная идея: софт должен запускаться в один клик, работать без интернета внутри локалки, иметь всеядный предпросмотр файлов прямо в браузере и не требовать от пользователя установки Питона или настройки окружения.

После нескольких итераций проект дорос до версии 1.6, и я хочу поделиться тем, как устроена утилита изнутри и с какими техническими проблемами пришлось столкнуться.

Что под капотом и как это работает

Бэкенд написан на Python + Flask, а фронтенд работает на чистом JS. Процесс использования максимально упрощен:

1. Запускается один исполняемый файл FlashStash.exe.

2. Программа сама определяет локальный IP-адрес компьютера, поднимает сервер и автоматически открывает веб-интерфейс в браузере хоста.

3. Чтобы подключить смартфон или другой ПК к общему пространству, нужно просто ввести в адресную строку браузера IP-адрес, который отображается в консоли сервера.

4. При этом для каждого загруженного файла в интерфейсе генерируется отдельный QR-код — это позволяет мгновенно скачивать конкретные файлы на телефон через камеру, не вбивая ссылки вручную.

Проект собран как Zero-Dependency Portable Build. Внутри архива лежит скомпилированный .exe файл со своей иконкой и встроенное портативное ядро Python. То есть утилиту можно закинуть на абсолютно «голую» Windows (желательно прямо на Рабочий стол), кликнуть, и всё сразу заведётся.

Как развивался проект: от костылей к нормальной архитектуре

В процессе разработки вылезло несколько неочевидных проблем, которые пришлось оперативно закрывать.

1. Борьба с «одноразовой» безопасностью

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

В версии 1.6 я переписал эту логику. Теперь все хэндлы, пароли файлов и история текстового буфера обмена намертво пишутся в локальные JSON-файлы. Данные идеально выдерживают перезапуск сервера и не нагружают систему лишними тяжелыми СУБД.

2. Закрытие уязвимости Path Traversal

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

Продвинутый пользователь в локальной сети мог провернуть атаку Path Traversal, отправив запрос вида ../, выйти за пределы папки обмена и стянуть системные файлы с хост-машины. Чтобы это исправить, я внедрил жесткую фильтрацию и санитаризацию входных путей через os.path.basename. Теперь бэкенд отсекает любые попытки побега из папки shared_files.

3. Всеядный предпросмотр (All-in-One)

Мне не хотелось, чтобы пользователь скачивал файл только ради того, чтобы узнать, что внутри. Поэтому фронтенд получил встроенные плееры для аудио и видео, просмотрщик картинок и текстовых документов. Из интересного — добавил просмотрщик архивов: структура файлов внутри .zip и .rar отображается прямо на веб-странице до скачивания самого архива.

Наведение порядка: Wipe_All_Data

Поскольку Питон при работе создаёт скрытый кэш (__pycache__), а папка shared_files постепенно забивается реальными файлами, перед заливкой проекта на GitHub или передачей папки другу её нужно как-то чистить. Сам запущенный Питон свои процессы и кэш удалить не может (Windows выдаёт Access Denied).

Для этого я написал отдельный служебный батник Wipe_All_Data.bat на английском (чтобы кодовая база репозитория выглядела аккуратно). Он делает три вещи:

1. Жестко тушит активные процессы сервера через taskkill.

2. Под ноль вычищает папки с файлами, паролями и текстами.

3. Сканирует дерево директорий и сносит весь кэш компилятора Питона, сжимая вес папки до исходного минимума.

Итоги

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

👉 https://github.com/arxbyte/FlashStash/releases/tag/v1.6

Буду рад конструктивной критике в комментариях. Пишите, каких фич вам не хватает в локальных файлообменниках и как бы вы улучшили текущую архитектуру.

Минусы:

• Долгая первая загрузка (Time to Interactive)Долгая первая загрузка (Time to Interactive)

• Плохо для SEO — боты видят пустой HTML

• Требует хорошего интернета у пользователя

Главная проблема CSR — поисковые боты. Googlebot умеет выполнять JavaScript, но делает это с задержкой и не всегда корректно. Яндекс справляется хуже. В итоге страницы индексируются медленнее и хуже.

Когда CSR — правильный выбор:

•  Дашборды и админки за авторизацией — SEO не нужен

•  SPA с богатой интерактивностью: редакторы, конструкторы, таблицы

•  Внутренние инструменты компании

•  Приложения, где пользователь авторизован и контент персональный

SSR — Server-Side Rendering

При каждом запросе сервер генерирует готовый HTML с данными и отдаёт его браузеру. Пользователь сразу видит контент — не надо ждать, пока выполнится JavaScript.

Плюсы:

• Отличный SEO — боты видят готовый HTML

• Актуальные данные на каждый запрос

Минусы:

• Нагрузка на сервер при каждом запросе

• Медленнее навигация, чем CSR

• Нужен сервер — хостинг дороже

SSR — лучший выбор для SEO-важных страниц. Поисковик получает готовый HTML с контентом, мета-тегами и структурированными данными. Индексация быстрее и надёжнее, чем при CSR.

Когда SSR — правильный выбор:

•  Интернет-магазины — карточки товаров должны индексироваться

•  Новостные сайты и блоги с часто меняющимся контентом

•  Страницы с персонализированным контентом (лента, рекомендации)

•  Любые публичные страницы, где важен SEO и актуальность данных

SSG — Static Site Generation

HTML генерируется один раз — во время сборки проекта. Готовые файлы раздаются с CDN без участия сервера. Это самый быстрый способ доставить контент пользователю.

Плюсы:

• Максимальная скорость

• Отличный SEO

• Дешёвый хостинг — просто файлы

• Высокая надёжность — нет сервера

Минусы:

• Данные могут быть устаревшими

• Долгая сборка при большом числе страниц

• Не подходит для часто меняющихся данных

Когда SSG — правильный выбор:

•  Лендинги и маркетинговые сайты

•  Документация и справочники

•  Блоги и портфолио

•  Сайты, где контент меняется редко или по расписанию

Главное про SEO

SEO — это часто решающий фактор при выборе рендеринга. Вот простое правило:

•  Страница публичная и должна находиться в поиске → SSR или SSG

•  Страница за авторизацией или контент персональный → CSR

•  Контент меняется часто → SSR

•  Контент меняется редко → SSG

Отдельно про Core Web Vitals — Google учитывает LCP, FID и CLS в ранжировании. SSG и SSR дают лучшие показатели, чем CSR по умолчанию, но и CSR можно оптимизировать через lazy loading, code splitting и prefetching.

Хорошая новость: Next.js позволяет миксовать все подходы в одном проекте. Лендинг — SSG, карточка товара — SSR, личный кабинет — CSR. Именно поэтому он стал стандартом индустрии.

Больше материалов про разработку и запуск своих продуктов — в Telegram-канале @deep_in_prod