Что такое веб-разработка: из чего состоит, как идёт по этапам и что проверить заказчику

Что такое веб-разработка

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

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

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

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

Чем фронтенд отличается от бэкенда?

Практикум в том же материале выделяет три направления. Фронтенд отвечает за внешнюю клиентскую часть и интерфейс ресурса, то есть за всё, что человек видит и нажимает. Бэкенд отвечает за внутреннюю серверную часть, которую обычный пользователь не видит. Фулстек объединяет оба направления.

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

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

Как разделение ролей работает на деле, показал маркетплейс Tokopedia. По данным web.dev, команда отрисовывала главный элемент страницы на сервере, предзагружала его и сжимала изображения. Итог: Tokopedia улучшила LCP на 55% и увеличила среднюю длительность сеанса на 23%. Такой результат потребовал согласованной работы обеих сторон: сервер отдавал готовую разметку, интерфейс подгружал остальное позже.

Как работает сайт: от запроса до страницы

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

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

Подробнее запрос описан в другом материале MDN. Клик по ссылке, заполнение формы или поиск заставляют браузер отправить на сервер запрос, а ответ содержит код статуса: успех, ресурс не найден, доступ запрещён. После получения HTML браузер отрисовывает страницу и, увидев ссылки на файлы JavaScript и CSS, делает отдельные запросы за каждым из них.

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

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

Из каких этапов состоит разработка сайта?

Практикум в том же материале описывает процесс в восемь шагов. Порядок может меняться, но состав работ у большинства проектов похож:

1. Планирование и анализ требований. Определяют цели и задачи проекта, функции, пожелания к дизайну и технические ограничения.
2. Структура и прототип. Выстраивают пользовательский путь и схему продукта, на основе которой делают прототип.
3. Дизайн. Дизайнеры детализируют прототип и создают визуальный образ с учётом фирменного стиля.
4. Фронтенд. Разработчики переводят макет в код и делают формы обратной связи, галереи, всплывающие окна и анимацию.
5. Бэкенд. Создают серверную часть, которая обрабатывает запросы, работает с базой данных и обеспечивает безопасность данных.
6. Тестирование и отладка. Проверяют, что функции работают, измеряют скорость и смотрят, как страница ведёт себя в разных браузерах и на разных устройствах.
7. Развёртывание. Готовый продукт запускают специальными инструментами, например Jenkins, и открывают доступ людям.
8. Поддержка. Команда обновляет контент, исправляет ошибки, повышает производительность и добавляет новые опции.

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

Тестирование заказчику стоит оговаривать отдельно. Практикум отмечает, что оно выявляет ошибки до того, как продукт попадёт к реальным пользователям. Запишите в договоре, какие браузеры, устройства и сценарии проверяют: покупку, отправку формы, личный кабинет. Тогда вопрос «а вы это проверяли?» получит ответ по списку.

Поддержка нужна потому, что проблемы часто видны только на живом трафике. Так было у индийского сервиса бронирования билетов redBus. По материалу web.dev, данные Real User Monitoring на 95-м процентиле показали иную картину, чем ждала команда. Разработчики дебаунсировали обработчик события scroll. При уменьшении выборки с 30 до 10 результатов INP снизился с 870-900 до 350-370. Продажи выросли на 7%.

Какие языки и технологии используют

Для фронтенда набор устоялся. Практикум называет HTML, CSS и JavaScript, а также фреймворки React, Angular и Vue.js. HTML создаёт структуру страницы, CSS отвечает за оформление, а JavaScript оживляет кнопки и формы. Знать эти слои полезно заказчику: так проще понять, почему правка текста занимает минуты, а новый калькулятор дни.

На бэкенде выбор шире. В том же материале сказано, что серверную часть можно писать практически на любом языке, а чаще всего применяют Python, C++, Java, JavaScript и Golang. Заказчику стоит смотреть на другое: найдётся ли специалист для поддержки проекта через несколько лет. Спросите подрядчика, на чём построен проект и сколько разработчиков с таким опытом на рынке.

Перед стартом работ задайте подрядчику несколько вопросов о технологиях:

• На каком языке и фреймворке написан серверный код и кто сможет его поддерживать?
• Какие готовые библиотеки и сторонние скрипты подключены к страницам?
• Где хранятся данные и как делают резервные копии?
• Как проект будут обновлять: вручную или автоматически, после каких проверок?
• Что останется у вас по договору: исходный код, доступы, документация?

Часть задач вообще не требует своего кода. Для небольших проектов подходит готовая система управления контентом или конструктор, и об их выборе подробно написано в справочнике про CMS. Индивидуальная разработка нужна, когда стандартных возможностей не хватает: сложные калькуляторы, личные кабинеты, интеграции с учётными системами.

Отдельная тема это нейросети. Практикум замечает, что фронтенд хорошо сочетается с ИИ-инструментами: они помогают создавать компоненты, формы, кнопки и адаптивные интерфейсы, но результат нужно уметь проверять. Совет начинающим в этом материале даёт Артём Стрельцов, старший разработчик в Яндексе:

В эпоху развития ИИ очень важно научиться думать своей головой.

Артём Стрельцов, старший разработчик в Яндексе, в материале Практикума

Как веб-разработка влияет на скорость и заявки?

Скорость и отзывчивость страницы измеряют по трём показателям. По описанию web.dev, LCP, который показывает скорость загрузки, должен укладываться в 2,5 секунды с начала загрузки страницы. Хороший INP, который отвечает за интерактивность, не превышает 200 миллисекунд. Хороший CLS, то есть визуальная стабильность, равен 0,1 или меньше. Цели достигаются, если их выполняют на 75-м процентиле загрузок страниц.

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

Связь скорости с деньгами показывают реальные проекты. В том же материале web.dev Vodafone в Италии улучшила LCP на 31% и получила рост продаж на 8%. Для этого команда отрисовывала критический HTML на сервере и сократила блокировку отрисовки скриптами. Авторы материала напоминают, что такой эффект надёжнее всего измерять A/B-тестом на стороне сервера, чтобы не списать рост на сезон или рекламу.

Другой пример из того же исследования: у redBus снижение CLS с 1,65 до 0 повысило рейтинг домена, а сокращение TTI с 8 до 4 с и TBT с 1200 до 700 мс способствовало росту мобильной конверсии на 80-100 процентов. Авторы подчёркивают, что культура производительности нужна и после правок, иначе показатели снова ухудшатся.

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

Что проверить владельцу, чтобы разработка не мешала поиску?

Начните с мобильной версии. В справке Яндекса сказано, что страницы должны открываться без горизонтальной прокрутки на устройствах от 320 пикселей, а технологии Flash, Silverlight и Applet на мобильных страницах использовать не стоит. Если у проекта отдельные адреса для телефона и компьютера, а версии между собой не связаны, обе могут оказаться в мобильной выдаче.

Следующий пункт касается файлов. Та же справка просит разрешить в robots.txt сканирование CSS и JavaScript, от которых зависит отображение страницы на мобильных, и требует, чтобы рабочие страницы отвечали кодом 200. Если разработчик закрыл эти файлы, робот увидит искажённую страницу.

Отдельно уточните, как собирается контент. В блоге Яндекса для вебмастеров указано, что большинство страниц не требует рендеринга и скачивается без JavaScript, а владельцы JS-проектов выбирают: сделать пререндер или SSR либо включить рендеринг в Вебмастере. Если робот исполняет скрипты, это может создавать дополнительную нагрузку на сервер, а доступ к вызываемым скриптам должен быть открыт. Подробнее о подходах рассказано в разборе про рендеринг и SSR.

Ещё одна ошибка касается рекламных блоков. В том же материале web.dev проект iCook улучшил CLS на 15% и увеличил доход от рекламы на 10%. Команда закрепила размеры рекламных мест в интерфейсе, чтобы страница не прыгала при загрузке баннера, и отложила некритический скрипт. Если на вашей странице блоки смещаются при загрузке, посетитель промахивается по кнопке.

Чтобы собрать проверки вместе, пройдитесь по короткому списку с разработчиком:

• Откройте проект на экране шириной 320 пикселей и убедитесь, что нет горизонтальной прокрутки.
• Сверьте LCP, INP и CLS с порогами web.dev на реальных данных.
• Посмотрите исходный код страницы и найдите в нём главный заголовок и основной текст.
• Проверьте, что robots.txt не закрывает CSS и JavaScript.
• Убедитесь, что рабочие страницы отвечают кодом 200.
• Заведите у подрядчика регламент проверок после каждого релиза.

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