Что такое фронтенд и бэкенд простыми словами: как устроен сайт
Что такое фронтенд? Это всё, что посетитель видит и нажимает на сайте: страницы, кнопки, формы, меню, фильтры каталога. Бэкенд — то, что происходит «за стеной»: сервер принимает заявку, проверяет её, сохраняет в базу, считает цену, передаёт данные в CRM и 1С. Вместе фронтенд и бэкенд и составляют разработку сайта, и заказчику полезно понимать эту границу: от неё зависят смета, состав команды, сроки и то, к кому идти, когда «ничего не работает».
Фронтенд и бэкенд простыми словами: аналогия с рестораном
Представьте ресторан. Зал — это фронтенд: интерьер, меню, официант, который принимает заказ и приносит блюдо. Кухня — это бэкенд: склад продуктов (база данных), повара (бизнес-логика), рецепты и правила (что можно готовить, по какой цене, кому положена скидка). Гость на кухню не заходит, но если там бардак, никакой интерьер не спасёт. Заказы из зала на кухню передаются через окно выдачи по чётким правилам — в разработке это API.
Что такое фронтенд: из чего состоит клиентская часть сайта
Код фронтенда скачивается в браузер посетителя и работает на его устройстве, поэтому его можно увидеть: правый клик на странице → «Просмотреть код».
Три базовых языка
- HTML — структура страницы: заголовки, абзацы, кнопки, поля формы, таблицы.
- CSS — внешний вид: цвета, шрифты, отступы, сетка, анимации, адаптация под разные экраны.
- JavaScript (часто TypeScript — JavaScript со строгой типизацией) — поведение: реакция на клики, проверка полей, фильтры без перезагрузки, отправка данных на сервер.
Фреймворки: React, Vue, Next.js
React и Vue позволяют собирать страницу из повторно используемых компонентов — карточка товара, форма, модальное окно описываются один раз и применяются везде. Next.js (на базе React) и Nuxt (на базе Vue) добавляют серверную отрисовку: страница приходит в браузер уже собранной, что важно для скорости и SEO — поисковые роботы получают готовый HTML.
За что отвечает фронтенд, кроме «красоты»
- Адаптивность — сайт корректно выглядит на экранах от 360 px до широких мониторов. У многих коммерческих сайтов с телефонов приходит больше половины посетителей.
- Скорость — Google оценивает её метриками Core Web Vitals: LCP (загрузка основного контента, норма до 2,5 с), INP (отклик на действие, до 200 мс), CLS (смещение вёрстки, до 0,1). Тяжёлые картинки и лишние скрипты — фронтенд-проблемы.
- Доступность — сайтом можно пользоваться с клавиатуры, с экранным диктором, при слабом зрении: контраст, подписи к полям, alt у изображений.
- Первичная проверка ввода — подсказать, что телефон введён не полностью, до отправки на сервер.
Вёрстка — часть фронтенда: перевод макета дизайнера в HTML/CSS. Если дизайн уже готов, её можно выделить в отдельную задачу — вёрстку по макету, а логику подключить позже.
Что такое бэкенд: сервер, база данных и бизнес-логика
Бэкенд работает на сервере (своём, VPS или облачном). Пользователь его код не видит и не может изменить — поэтому всё важное (цены, права доступа, скидки, проверка оплаты) должно решаться именно здесь.
Из чего состоит бэкенд
- База данных — где хранятся товары, заказы, пользователи, заявки. Чаще всего MySQL или PostgreSQL, для кэша и очередей — Redis.
- Бизнес-логика — правила компании в виде кода: расчёт стоимости доставки, оптовые цены для B2B-клиента, статусы заказа, резервирование остатков.
- Авторизация и права — вход в личный кабинет, роли (клиент, менеджер, администратор), защита данных. Для персональных данных граждан РФ действует 152-ФЗ, и это тоже зона бэкенда.
- Интеграции — обмен с 1С, CRM (Битрикс24, amoCRM), платёжными сервисами (ЮKassa, СБП), доставкой (СДЭК), почтой, SMS, Telegram.
- Админка — интерфейс, через который менеджер правит контент и видит заказы. Её экраны — тоже фронтенд, но только для сотрудников.
На чём пишут бэкенд
Чаще всего — на PHP (1С-Битрикс, WordPress, Laravel, Yii), Node.js (удобно, когда фронтенд на React/Next.js: один язык в команде), Python/Django (сервисы вокруг данных и машинного обучения) и Go (высоконагруженные сервисы). Когда выбирать CMS, а когда фреймворк, — в статье на чём пишут сайты.
Фронтенд и бэкенд: разница в одной таблице
| Фронтенд | Бэкенд | |
|---|---|---|
| Где работает | В браузере пользователя | На сервере |
| Что делает | Показывает интерфейс, реагирует на действия, отправляет запросы | Хранит данные, считает, проверяет права, связывает с 1С, CRM, оплатой |
| Технологии | HTML, CSS, JavaScript/TypeScript, React, Vue, Next.js | PHP (Laravel, Битрикс), Node.js, Python (Django), Go; MySQL, PostgreSQL, Redis |
| Чем опасна ошибка | Сайт «разъехался» на телефоне, кнопка не нажимается, страница грузится 6 секунд — теряются конверсия и позиции | Заявки не сохраняются, неверные цены, утечка персональных данных, заказ не ушёл в 1С — прямые деньги и юридические риски |
| Как заметить | Видно глазами, часто только на части устройств или браузеров | Часто не видно: сайт «работает», а данные теряются молча |
Как фронтенд и бэкенд общаются через API: путь заявки от кнопки до CRM
Фронтенд и бэкенд — отдельные программы, которые обмениваются сообщениями по HTTP. Фронтенд отправляет запрос, бэкенд отвечает — обычно в формате JSON — и сообщает код статуса: 2xx — всё хорошо, 4xx — ошибка в запросе (не заполнено обязательное поле, нет доступа), 5xx — сбой на сервере. Набор таких запросов с описанием форматов и есть API; подробнее — в статье что такое API простыми словами. Проследим на примере обычной заявки «Перезвоните мне».
- Фронтенд. Посетитель вводит имя и телефон. Скрипт проверяет маску телефона и отметку о согласии на обработку персональных данных, блокирует кнопку от повторного нажатия.
- Фронтенд. Данные вместе с UTM-метками и идентификатором Яндекс Метрики упаковываются в запрос и уходят на сервер через API.
- Бэкенд. Сервер заново проверяет данные — проверке в браузере доверять нельзя, её легко обойти. Отсекает спам (капча, лимит запросов с одного IP).
- Бэкенд. Заявка сохраняется в базу данных сайта — это страховка: даже если CRM недоступна, лид не потеряется.
- Бэкенд. Через API CRM (Битрикс24, amoCRM) создаётся лид или сделка с источником и UTM. Если CRM ответила ошибкой — заявка ставится в очередь на повторную отправку, а ответственному уходит уведомление.
- Бэкенд. Параллельно отправляются письмо менеджеру, сообщение в Telegram и событие-конверсия в Метрику.
- Фронтенд. Получив от сервера успешный ответ (код 200), интерфейс показывает «Спасибо, перезвоним в течение 15 минут». При ошибке — понятное сообщение и телефон, а не вечный «спиннер».
Шаги 3–6 посетитель не видит, но именно там теряется большинство заявок: истёк токен CRM, поменялось обязательное поле в воронке, упал почтовый сервер. Настройка обмена с учётными системами — отдельная работа, её часто выделяют в задачу интеграции с 1С и CRM.
Как разделение на фронт и бэк влияет на смету и сроки
В смете разработки фронтенд и бэкенд обычно идут отдельными блоками — и это удобно заказчику: видно, за что платите. Типичная картина:
- Промо-сайт или лендинг — основная трудоёмкость во фронтенде (дизайн, вёрстка, анимации), бэкенд минимален: форма и простая админка.
- Интернет-магазин на CMS — бэкенд во многом «из коробки», но растёт на интеграциях: выгрузка из 1С, оплата, доставка.
- Личный кабинет, B2B-портал, сервис — бэкенд становится основной частью: роли, расчёты, статусы, API для мобильного приложения. Это уже разработка веб-приложения, а не сайта.
Число экранов плохо предсказывает бюджет: две похожие страницы «Оформление заказа» отличаются по трудоёмкости в разы, если за одной — отправка письма, а за другой — резерв остатков в 1С, расчёт доставки и частичная оплата. Для ориентира: разработка веб-приложения у нас — от 900 000 ₽, доработки по почасовой ставке — 2 500 ₽/час; итог зависит от логики и интеграций. Чем веб-приложение отличается от сайта по составу работ — в статье веб-приложение или сайт.
Роли в команде: фронтенд, бэкенд, fullstack, DevOps
Фронтенд-разработчик отвечает за интерфейс, вёрстку, скорость и работу с API; бэкенд-разработчик — за базу данных, логику, интеграции и безопасность; DevOps-инженер — за сервер, выкладку обновлений, резервные копии и мониторинг. Fullstack-разработчик ведёт обе стороны и выгоден на MVP и небольших проектах, но на крупных одного человека обычно не хватает по глубине.
Где искать причину бага: во фронтенде или бэкенде
Точная диагностика — работа разработчика, но по простым признакам заказчик может сразу направить задачу нужному человеку.
| Симптом | Скорее всего | Как проверить |
|---|---|---|
| На телефоне съехали блоки, на компьютере всё нормально | Фронтенд | Открыть в другом браузере и на другом устройстве |
| Кнопка не реагирует, ничего не происходит | Фронтенд (ошибка скрипта) | Консоль браузера (F12 → Console): красные ошибки |
| Форма показала ошибку или «висит» после отправки | Бэкенд или связь с ним | F12 → Network: запрос вернул код 500 или не вернулся вообще |
| «Спасибо» показалось, а заявки в CRM нет | Бэкенд, интеграция | Есть ли заявка в админке сайта; журнал отправок в CRM |
| Неверная цена или остаток, у всех пользователей одинаково | Бэкенд или данные из 1С | Сравнить с 1С и временем последней выгрузки |
| После правки в админке на сайте ничего не поменялось | Кэш (сервер, CDN или браузер) | Открыть в режиме инкогнито |
Сообщая о баге, прикладывайте ссылку, время по МСК, устройство и браузер, скриншот и — если есть — скриншот вкладки Network.
Headless CMS и раздельный фронтенд: когда это оправдано
В классической CMS (1С-Битрикс, WordPress) фронтенд и бэкенд живут в одной системе: движок сам формирует HTML-страницы по шаблонам. В headless-подходе CMS или бэкенд только отдают данные по API (Strapi, Directus, Payload или своя разработка), а фронтенд — отдельное приложение, чаще на Next.js или Nuxt.
Такой подход оправдан, когда:
- одни данные нужны сайту, мобильному приложению, Telegram Mini App и партнёрам;
- критичны скорость интерфейса и Core Web Vitals, а шаблоны CMS упираются в потолок;
- интерфейс сложный, почти как у приложения: конфигураторы, калькуляторы, кабинеты;
- фронтенд и бэкенд развивают разные команды с независимыми релизами.
Для корпоративного сайта или магазина, которому хватает возможностей CMS, это лишнее: два приложения, два развёртывания и двойная поддержка.
Типичные ошибки заказчика
- Оценивать работу по картинке. Красивый интерфейс принят, а через месяц выясняется, что заказы не уходят в 1С. Приёмка должна включать сценарии, а не только внешний вид.
- Считать бэкенд «само заработает». Интеграции, права и обработка ошибок — отдельные строки ТЗ; если их там нет, их нет и в смете.
- Разные подрядчики на фронт и бэк без описанного API. Каждый уверен, что проблема на стороне другого, а сроки и бюджет растут.
- Логика только во фронтенде. Скидка или цена, которую считает браузер, подменяется за минуту. Проверка должна дублироваться на сервере.
- Нет доступа к серверу и репозиторию. Код бэкенда живёт у подрядчика — и при смене исполнителя проект приходится восстанавливать. Если проект достался в наследство, начните с аудита и доработки текущего сайта, а не с переписывания.
Что проверить при приёмке сайта: чек-лист
- Сайт корректно работает на телефоне, планшете и компьютере в Chrome, Safari и Яндекс Браузере.
- Основные страницы проходят Core Web Vitals в PageSpeed Insights на мобильных.
- Каждая форма доходит до конечной точки: админка сайта, CRM, почта, Telegram — проверено тестовой заявкой.
- При недоступной CRM заявка не теряется: сохраняется и отправляется повторно.
- Цены, скидки и права доступа проверяются на сервере, а не только в браузере.
- Обмен с 1С, оплата и доставка проверены на тестовых и реальных сценариях, включая возврат и отмену.
- Отдельное согласие на обработку персональных данных и политика конфиденциальности на месте, а первичная запись и хранение персональных данных ведутся в базах на территории РФ (ч. 5 ст. 18 152-ФЗ).
- У вас есть доступы к хостингу, домену, репозиторию с кодом и админке, а также описание API и схема интеграций.
- Настроены резервные копии и мониторинг доступности, известно, кто получает уведомления о сбоях.
- Цели Метрики срабатывают на реальные отправки, а не на клик по кнопке.
Итог: зачем заказчику понимать фронтенд и бэкенд
Фронтенд — это то, как сайт выглядит и откликается, бэкенд — то, как он обрабатывает данные и зарабатывает деньги. Одно без другого не работает: быстрый интерфейс бесполезен, если заявки теряются, а надёжная логика не продаёт, если форма не открывается на телефоне. Понимая эту границу, проще читать смету, ставить задачи, искать причину бага и принимать работу по сценариям, а не по скриншотам.