Главная → Блог → Сайты → Веб-разработчик

Кто такой веб-разработчик и чем отличается от веб-дизайнера

Автор: Герман, основатель V³ Creative · Обновлено 18 августа 2026 · Чтение 11 мин · Тип: разбор

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

Кто такой веб-разработчик и что он делает руками

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

• Код в браузере. По формулировке MDN, клиентский код «в основном занят внешним видом и поведением отрисованной страницы»: выбор и стилизация элементов интерфейса, создание макетов, навигация, проверка заполнения форм. Это HTML, CSS и JavaScript.
• Код на сервере. Серверная часть «сводится к выбору того, какой контент вернуть браузеру в ответ на запрос»: проверить присланные данные, достать нужное из базы, отправить обратно. Языки разные — PHP, Python, Ruby, C#, JavaScript.
• Связка с внешними сервисами. Заявка уходит в почту и в CRM, оплата принимается платёжным сервисом, статистика пишется в счётчик. Всё это делает код.

Отсюда простое следствие, из-за которого чаще всего спорят на приёмке. MDN пишет прямо: «бо́льшая часть кода, обеспечивающего работу динамического сайта, должна выполняться на сервере». Макет в графическом редакторе — это изображение будущего сайта. Пока никто не написал код, кнопка не нажимается, форма не отправляется, а страницы не существует ни для посетителя, ни для поисковой системы.

Чем веб-разработчик отличается от веб-дизайнера?

Зоной ответственности. Дизайнер отвечает на вопрос «что человек поймёт и куда нажмёт», разработчик — на вопрос «работает ли это у него на телефоне и быстро ли открывается». Оба работают с одной и той же страницей, но принимают разные решения.

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

Что такое фронтенд и бэкенд простыми словами?

Фронтенд — всё, что выполняется в браузере посетителя. Бэкенд — всё, что выполняется на сервере до того, как браузер получит ответ. Граница проходит по месту, где выполняется код: сложность задачи её не определяет.

• Фронтенд — витрина, которая реагирует. Страница собралась, меню открылось, форма подсветила незаполненное поле, карточки перестроились под узкий экран. По MDN у клиентского кода почти нет доступа к операционной системе, поэтому всё серьёзное он передаёт дальше.
• Бэкенд — то, что происходит после отправки. Проверить данные, записать в базу, отправить письмо, вернуть страницу «спасибо». Серверный код, как формулирует MDN, имеет полный доступ к операционной системе сервера, и именно поэтому его пишут аккуратнее всего.
• Фулстек — один человек на обе стороны. Для сайта-визитки и небольшого корпоративного сайта это нормальная и частая конфигурация. Для магазина с оплатой и складом обычно нужны двое.

Практический смысл различия — в постановке задачи. «Хочу личный кабинет клиента» — это бэкенд, и считается он неделями. «Хочу, чтобы блок с ценами красиво выезжал» — это фронтенд, и счёт идёт на часы. Смешивать их в одном пункте задания не стоит: оценка получится бессмысленной.

Сколько людей нужно, чтобы сделать сайт?

Зависит от того, сколько из перечисленных работ вы отдаёте наружу. Работ шесть, и они есть в любом проекте, даже если их закрывает один исполнитель.

1. Постановка задачи. Кому сайт, что человек должен сделать на нём, чем вы отличаетесь от соседа по рынку. Это работа заказчика, её никто не сделает за вас.
2. Структура и тексты. Какие страницы нужны, что на них написано. Часто недооценивается и становится причиной срыва сроков: макет готов, наполнять нечем.
3. Дизайн. Макеты страниц, включая мобильные экраны.
4. Фронтенд. Сборка страниц в браузере, поведение, адаптация под экраны.
5. Бэкенд и интеграции. Формы, кабинет, оплата, связь с CRM.
6. Запуск и обслуживание. Домен, хостинг, сертификат, резервные копии, обновления.

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

Нужен ли разработчик, если сайт на конструкторе?

Для простого сайта — часто нет, и это честный ответ. Половина веба живёт на готовых системах: по данным Web Almanac 2024, на CMS работает 51% сайтов десктопной выборки, а на WordPress приходится свыше 35% мобильной. Это значит, что «разработчик» для малого бизнеса нередко означает человека, который умеет собрать и донастроить готовую систему. Писать всё с нуля для такой задачи не требуется.

Разработчик становится нужен в четырёх ситуациях.

• Нестандартная логика. Расчёт стоимости, подбор по параметрам, личный кабинет, синхронизация со складом. Готовый шаблон это не закрывает.
• Скорость перестала устраивать. Набор плагинов замедлил сайт, и нужно разбираться, что именно грузится.
• Интеграция с чужой системой. CRM, платёжный сервис, поставщик данных.
• Сайт стал источником заявок. Когда простой на час стоит денег, нужен человек, который отвечает за работоспособность постоянно. «Мастер на разовую правку» эту роль не закрывает.

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

Что дать исполнителю до старта работ?

Три вещи, и ни одна из них не техническая. Разработчик не может угадать бизнес-задачу, а угадывать он будет обязательно — иначе просто не сможет принять ни одного решения.

1. Одна фраза про отличие. Марти Ньюмейер предлагает заполнить формулу «наш бренд представляет единственный ___, который ___» и дальше проверять по ней каждое решение: помогает оно или расфокусирует. Строка нужна и дизайнеру, и разработчику: она решает, что вынести на первый экран, а что убрать.
2. Список того, что человек должен сделать на сайте. Оставить заявку, скачать прайс, посчитать стоимость, записаться. Из этого списка вырастает и структура, и объём серверной работы.
3. Ограничения. Срок, бюджет, требования вашей CRM, фирменный стиль, если он есть.

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

Как принять работу и проверить её самому?

У качества страницы есть открытые числовые пороги, и заказчику не нужно уметь читать код, чтобы их проверить. Google публикует три метрики Core Web Vitals и значения, которые считаются хорошими: LCP не больше 2,5 секунды, INP не больше 200 миллисекунд, CLS не больше 0,1. Мерить их полагается по 75-му перцентилю загрузок страницы, отдельно для мобильных и десктопа. Разовый замер на своём ноутбуке этого не показывает.

• LCP — когда появилось главное. Время до отрисовки самого крупного элемента экрана. Порог: 2,5 секунды.
• INP — насколько живой отклик. Задержка между действием посетителя и ответом страницы. Порог: 200 миллисекунд.
• CLS — не прыгает ли вёрстка. Сдвиги содержимого при загрузке, из-за которых промахиваешься по кнопке. Порог: 0,1.

INP здесь важен ещё и как маркер компетентности. Эта метрика стала стабильной частью Core Web Vitals 12 марта 2024 года и заменила прежнюю FID, окончательно выведенную из употребления 9 сентября 2024 года. Если в отчёте подрядчика до сих пор фигурирует FID, отчёт устарел на два года.

Второй пункт приёмки — мобильная версия, и он жёстче, чем принято думать. Google завершил перевод на мобильного робота: после 5 июля 2024 года последние сайты обходятся только Googlebot Smartphone, а справка формулирует последствие прямо — «для индексирования используется только тот контент, который показан на мобильной версии сайта». Блок, который на телефоне свернули или спрятали, для поиска не существует.

У Яндекса требования сформулированы мягче, но проверяются так же бесплатно. Справка допускает три варианта — адаптивный дизайн на одном адресе, динамическую вёрстку и отдельный мобильный поддомен — и для адаптивного дизайна прямо требует метатег viewport. Проверить страницы можно инструментом «Проверка мобильных страниц» в Вебмастере. Как устроен адаптивный сайт и чем он отличается от отдельной мобильной версии, разобрано в статье адаптивный сайт.

Про скорость Яндекс своих числовых порогов не даёт: в справке сказано, что «скорость загрузки страниц сайта это один из важных показателей его качества», а анализировать её предлагается через отчёты Метрики. Поэтому числа в задание берут у Google, а у Яндекса — требование как таковое. И ещё один пункт, нулевой: сайт целиком открывается по защищённому протоколу. Google называет HTTPS положительным индикатором качества в поиске.

Наконец, полезно понимать планку рынка. По Web Almanac 2024 все три метрики Core Web Vitals проходили 43% сайтов на мобильных и 54% на десктопе. То есть требование «уложиться в пороги» выводит сайт в лучшую половину рынка.

Что заказчик обязан получить на руки?

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

• Домен на ваше имя. Регистрация оформляется на компанию или на владельца, не на подрядчика.
• Доступ к хостингу. Аккаунт ваш, разработчику выдаётся отдельный доступ, который можно отозвать.
• Исходники и код. Макеты в исходном формате и репозиторий с кодом. Технологии веба открыты: по формулировке MDN, они «не обременены патентами и лицензиями», ни одна компания их не контролирует, и «любой может бесплатно написать код и сделать сайт». Значит, зависимость от конкретного исполнителя создаётся только закрытыми доступами.
• Доступы к счётчикам и панелям. Метрика, Вебмастер, Search Console заводятся на вас.
• Инструкция на страницу. Где что лежит, как обновить текст, кому писать при сбое.

Отдельно обсудите резервные копии: кто их делает, куда складывает и как быстро восстанавливает сайт. Проверять эту договорённость лучше не в день аварии.

Из чего складывается цена работы веб-разработчика?

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

1. Сколько уникальных экранов. Десять страниц из одного шаблона дешевле трёх страниц с разной логикой.
2. Есть ли серверная часть. Форма заявки — это часы. Кабинет с ролями и оплатой — недели, потому что появляются данные, доступы и ответственность за них.
3. Какой стек выбран. Модный набор инструментов не бесплатен: его дороже поддерживать и сложнее передать другому исполнителю. Полезная отрезвляющая цифра из Web Almanac 2024: самая распространённая библиотека веба — jQuery, она встречается на 74% мобильных страниц, а React — на 10%.

С весом связана и скорость. Медианный объём JavaScript на странице в 2024 году вырос на 14% и составил 558 килобайт на мобильных, а медианный вес страницы в октябре 2024 года — 2 311 килобайт на мобильных. Каждая добавленная библиотека оплачивается дважды: в смете и в секундах загрузки. Поэтому вопрос «зачем нам этот инструмент» задаётся до начала работ. После провала по LCP он обходится дороже.

По каким признакам видно сильного исполнителя?

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

• Начинает с задачи. Первый вопрос сильного исполнителя — что должно происходить после запуска и как вы поймёте, что сайт работает.
• Сам называет числа приёмки. Скорость, отклик, стабильность вёрстки, мобильная проверка. Если критериев не предложил он, их предлагаете вы.
• Думает про то, что сломается. MDN описывает принцип прогрессивного улучшения: базовый набор содержимого и функций доступен максимальному числу пользователей, а лучший опыт получают те, у кого современный браузер. На практике это значит, что заявка должна отправляться даже там, где отвалились скрипты.
• Помнит про доступность. Доступность, по определению MDN, — «практика делать ваши сайты пригодными для использования как можно большим числом людей», и закладывать её нужно с начала проекта: в конце она прикручивается плохо и дорого.

Эти же признаки работают и при выборе студии целиком: как проверить исполнителя до подписания договора, разобрано в материале как выбрать дизайн-студию.

Какие ошибки повторяются при найме разработчика?

Ошибки однотипные, и все они совершаются до начала работ, а вылезают на приёмке или через год.

• Задача поставлена картинкой. «Хочу как у них» без объяснения, что человек должен сделать на сайте. Исполнитель повторит внешний вид и не повторит смысл.
• Мобильные экраны никто не рисовал. Дизайнер сдал десктоп, разработчик собрал телефон по своему усмотрению, претензии предъявить некому.
• Критерии приёмки не названы. Без чисел спор сводится к «мне кажется, медленно», и выигрывает тот, кто громче.
• Домен и хостинг на подрядчике. Через год смена исполнителя превращается в переговоры о выкупе собственного сайта.
• Оплата целиком вперёд. Разбивка на этапы — нормальная практика: каждый этап заканчивается тем, что можно посмотреть и принять.
• Никто не отвечает за сайт после запуска. Обновления, сертификат, резервные копии не делаются сами. Договоритесь об этом до запуска.

Собрать сайт вместе с дизайном и разработкой одной командой можно у нас: состав работ и порядок этапов описаны на странице услуги создание сайтов.

Частые вопросы

Читайте также

Герман

Основатель V³ Creative. Веду проекты сам — от разбора до финального макета.