Frontend разработка

• Вёрстка и компонентный UI по дизайн-системе
• Клиентская логика: формы, валидация, мультистеп-квизы
• Загрузка данных с API без блокировки первого экрана
• Оптимизация бандла: code splitting, lazy routes
• Доступность и работа с клавиатуры
• Согласование с backend по контрактам API и кодам ошибок

Где проходит граница с вёрсткой

Вёрстальщик сдаёт статику; frontend-разработчик подключает данные, состояние, маршрутизацию и интеграции. На практике роли смешиваются: один специалист делает и BEM, и Vue-компонент. Важно в ТЗ зафиксировать, нужен ли SSR/SSG для SEO, или достаточно CSR с пререндером ключевых страниц. Чистый SPA без серверного рендера для сайта услуг с органикой — риск пустого HTML для бота, если не компенсировать пререндером или гибридом.

Стеки для коммерческих проектов

WordPress + кастомные блоки, Next.js/Nuxt для контентных платформ, Astro для преимущественно статических сайтов с островками интерактива — типичные выборы 2026 года. Выбор не «какой модный», а какой команда сможет сопровождать и что требует интеграция: личный кабинет, realtime, сложный каталог. Для лендинга с формой часто избыточен React; для личного кабинета с историей заказов — оправдан.

1. Оценить, какой HTML видит краулер без выполнения JS
2. Согласовать формат ошибок API для форм (поле, код, сообщение)
3. Заложить состояния загрузки и пустых списков в UI
4. Продумать деградацию, если API недоступен

Формы и конверсия

Frontend отвечает за UX формы: inline-валидация, понятные сообщения, сохранение введённого при ошибке сервера, маски телефона без ломания вставки из буфера. Отправка — fetch/XHR на backend или сервис форм; важно не светить секреты в клиенте. UTM и client_id аналитики пробрасывают скрытыми полями или заголовками по согласованию с маркетингом.

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

• Анализ бандла: какие библиотеки тянут лишние килобайты
• Динамический import для админских и редких виджетов
• Предзагрузка шрифтов только используемых начертаний
• Измерение INP на реальных страницах с формами и фильтрами

Тестирование и релизы

Минимум — регрессия ключевых сценариев вручную и автотесты на критичную логику (калькулятор, корзина). Storybook или аналог помогает жить компонентам отдельно от CMS. Feature flags на фронте редко нужны малому бизнесу, но staging-окружение с тем же API — обязательно. Версионируйте API, чтобы фронт и бэк не релизились в жёсткой связке без предупреждения.

Документация для заказчика

Краткое описание: какие виджеты на каких страницах, откуда берутся данные, кто меняет тексты в CMS, а что только через разработчика. Это снижает стоимость сопровождения и ускоряет онбординг нового подрядчика.

Безопасность на клиенте

Frontend не заменяет серверную валидацию, но обязан не усугублять риски: экранировать пользовательский вывод при вставке в DOM, не использовать eval, осторожно с innerHTML для контента из API. XSS на странице с формой заявки — прямой путь к потере доверия и блокировкам. Content Security Policy настраивается на сервере, но фронт должен знать, какие домены скриптов и iframe разрешены.

• Санитизация HTML в комментариях и отзывах, если они рендерятся на клиенте
• Защита от повторной отправки формы и CSRF-токены с backend
• Не хранить PII в localStorage без необходимости
• Обновлять зависимости с известными CVE

На стыке с backend согласуйте формат дат, чисел и валют — фронт не должен «угадывать», как сервер отдаёт десятичный разделитель. Для мультиязычности заложите переключатель с сохранением пути или query-параметра и проверьте длину строк в навигации на всех языках до релиза.