Вёрстка сайта: этапы, адаптив и требования к результату

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

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

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

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

Что такое вёрстка сайта

Вёрстка — это реализация дизайн-макета в браузере средствами выбранной технологии.

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

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

Вёрстка, веб-дизайн и разработка: в чём разница

Границы этапов зависят от процесса команды, но задачи у них разные.

Веб-дизайн

На этапе дизайна определяют структуру интерфейса, визуальную иерархию, композицию, типографику, цвета, графику и пользовательские сценарии.

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

Подробнее этот этап мы разбираем в статье «Веб-дизайн сайта: UX, UI, этапы и критерии оценки».

Вёрстка

На этапе вёрстки эти решения реализуют в браузере.

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

Разработка

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

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

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

Полный процесс создания сайта — от постановки задачи до запуска — разбираем отдельно в статье «Разработка сайта: от бизнес-задачи до запуска и развития».

Что подготовить до начала вёрстки

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

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

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

Для адаптива нужно понимать, как меняются основные композиции на узких экранах.

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

Если части решений нет, это не обязательно останавливает проект. Но до старта стоит определить, кто принимает недостающие дизайн-решения и как они согласовываются.

Почему недостаточно повторить макет «один в один»

Требование «сделать один в один как в Figma» понятно, но описывает задачу только частично.

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

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

Поэтому качество вёрстки стоит оценивать не только по совпадению отступов.

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

Работает ли интерфейс с реальным контентом. Длинные тексты не должны ломать карточки, а дополнительные элементы — разрушать сетку.

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

Реализованы ли состояния. Пользователь должен понимать, что произошло после нажатия, отправки формы или ошибки.

Такой подход точнее, чем сравнение готового сайта с одним скриншотом из Figma.

Адаптивная вёрстка и поведение сайта на разных экранах

Адаптивная вёрстка позволяет интерфейсу перестраиваться под доступное пространство.

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

Задача не сводится к трём отдельным версиям «компьютер — планшет — телефон».

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

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

Мобильная версия — не уменьшенный десктоп

На телефоне меняется не только ширина.

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

В проекте «Четыре горизонта» для мобильной версии отдельно адаптировали композиции и анимацию. Важно было сохранить концепцию сайта на небольшом экране, но не мешать навигации и основным действиям пользователя.

Интерактивные элементы и анимация

Современный макет часто содержит больше, чем статичные блоки.

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

До разработки полезно определить три вещи: что происходит, когда это происходит и что видит пользователь после действия.

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

С анимацией похожая ситуация. Дизайн может показать исходное и конечное состояния, но при реализации нужно определить длительность, последовательность, направление и условия запуска.

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

На первом экране сайта Эдс использовалась Lottie-анимация с исходным файлом около 50 МБ. Она замедляла загрузку, поэтому при переезде с Tilda на Taptop мы разделили её на отдельные JSON-файлы и изображения.

Требования к качеству вёрстки

Список используемых технологий сам по себе ничего не говорит о качестве результата. Для заказчика важнее, как работает готовый сайт.

Корректная структура

Для действий используют кнопки, для переходов — ссылки; полям форм задают понятные подписи, а заголовки выстраивают в последовательную структуру.

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

Адаптивность

Сайт должен нормально работать не только на размерах, показанных в дизайн-макете, но и между ними.

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

Работа в согласованных браузерах

Кроссбраузерность не означает абсолютное совпадение каждого пикселя.

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

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

Понятная система компонентов

Если после запуска сайт будет развиваться, новые страницы не должны каждый раз собираться с нуля.

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

Влияние вёрстки на скорость загрузки

Скорость сайта зависит не только от вёрстки. На неё также влияют сервер, CMS, аналитика, сторонние скрипты, видео и объём контента.

Но на этапе фронтенда можно избежать части проблем.

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

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

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

Если скорость критична для проекта, критерии проверки лучше согласовать до начала разработки, а не только после запуска.

Доступность сайта

Часть требований к доступности закладывается непосредственно при вёрстке.

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

Базовые принципы закреплены в WCAG 2.2 — рекомендациях W3C по доступности веб-контента.

Доступность сложно полностью добавить уже после сборки сайта: часть требований зависит от структуры интерфейса и способа реализации компонентов.

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

Этапы вёрстки сайта

Последовательность зависит от технологии, но логика работы обычно выглядит так.

1. Проверка макетов

Перед стартом разработчик смотрит структуру страниц, адаптивные состояния, повторяющиеся компоненты, графику, шрифты и интерактив.

На этом этапе фиксируют недостающие состояния и вопросы к дизайну.

2. Подготовка структуры проекта

Определяют повторяющиеся компоненты, сетки, типографику, общие стили и логику страниц.

Для многостраничного сайта особенно важно не собирать каждый экран как независимый макет.

3. Вёрстка основных страниц и компонентов

Сначала реализуют базовые элементы и характерные страницы, после чего используют эту систему в остальных разделах.

Так проще сохранять единое поведение интерфейса и вносить системные изменения.

4. Адаптив

Композицию проверяют на разных ширинах, уточняют перестроение блоков, изображения, размеры текста, меню и формы.

Если дизайн не учитывает какой-то промежуточный сценарий, решение согласуют в процессе.

5. Интерактив и анимация

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

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

6. Тестирование и исправления

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

В качестве дополнительной технической проверки можно использовать инструменты W3C, например Nu HTML Checker. Автоматическая проверка помогает найти часть технических ошибок, но не заменяет ручное тестирование интерфейса.

7. Передача вёрстки и подключение к сайту

После проверки результат передают на следующий этап разработки или размещают в рабочей среде.

Подключение к CMS, серверной части, внешним сервисам и публикация сайта выполняются, если эти работы включены в проект.

Если сайт собирается внутри no-code-платформы, отдельной передачи HTML может вообще не быть: страницы, контент и настройки остаются внутри самой системы.

Проверка вёрстки перед запуском

Проверять сайт лучше не только сравнением с Figma.

Пройти основные сценарии

Нужно открыть меню, перейти между страницами, отправить формы, проверить ссылки, состояния ошибок и результат успешных действий.

Формы, интеграции и другие функции проверяют в пределах согласованного состава проекта.

Проверить разные размеры экрана

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

Именно на промежуточных ширинах часто появляются слишком узкие колонки, странные переносы заголовков, наложение элементов или незапланированные отступы.

Использовать реальный контент

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

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

Посмотреть сайт на настоящем телефоне

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

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

Сравнить с дизайном

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

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

Что получает заказчик после вёрстки

Результат зависит от технологии и согласованного состава проекта.

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

Если сайт работает внутри CMS или no-code-платформы, нужно передать проект под управление заказчика и предоставить необходимые права доступа.

Перед закрытием работ стоит проверить:

• у заказчика есть доступ к проекту и необходимым сервисам

• переданы согласованные исходники и материалы

• понятно, где находится актуальная версия проекта

• формы и интеграции работают в пределах согласованного объёма работ

• страницы и адаптивные состояния протестированы

• известные ограничения зафиксированы

• определён порядок дальнейшей поддержки, если она входит в договорённости

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

От чего зависят сроки и стоимость

Количество страниц влияет на объём работы, но оценивать вёрстку только по этому показателю неправильно.

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

На объём работы влияют:

• сложность дизайн-макетов

• количество уникальных компонентов

• наличие адаптивных версий

• интерактив и анимация

• количество форм и состояний

• качество исходников

• требования к тестированию

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

• подключение CMS и интеграций, если они входят в проект

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

Что проверить в предложении подрядчика

Перед началом работы стоит уточнить:

1. Какие страницы и состояния входят в оценку?

2. Кто отвечает за недостающие адаптивные решения?

3. Какие браузеры и устройства входят в тестирование?

4. Какие формы и интерактивные элементы нужно реализовать?

5. Какой объём анимации входит в проект?

6. Входит ли оптимизация изображений и других тяжёлых материалов?

7. Входят ли подключение CMS, программирование и интеграции?

8. Как проходит тестирование и приёмка?

9. Какие исходники, доступы и файлы получает заказчик?

10. Что входит в поддержку после запуска?

Так проще сравнивать предложения по реальному составу работ, а не только по итоговой цене.

Вёрстка и разработка сайтов в Эдс

Вёрстку мы рассматриваем как один из этапов создания сайта. До реализации проверяем макеты, адаптивные сценарии, состояния интерфейса и повторяющиеся компоненты.

Если проект требует дизайна, анимации, программирования, CMS или интеграций, эти задачи фиксируем отдельно в составе разработки. Так до начала работ понятно, что именно входит в проект и какой результат получит заказчик.

Подробнее рассказываем о нашем подходе в направлении «Сайты».

Нужен сайт по готовому дизайн-макету или разработка проекта целиком? Покажите макеты и расскажите, как сайт должен работать после запуска. Определим состав работ и задачи, которые нужно решить до публикации.

Обсудить проект