Адаптивная вёрстка сайта: как проверить качество перед приёмкой

Приёмка вёрстки — момент, когда легче всего сэкономить деньги и время: пока финальный платёж не ушёл, у вас есть рычаг попросить исправления бесплатно. После оплаты то же самое становится «доработкой» с новым ценником. Мы много лет отдаём заказчикам готовую вёрстку сайта и знаем, какие проверки занимают 20–30 минут, но отсекают 90% типовых проблем — от съехавшего меню на iPhone до нечитаемого текста в Safari. Ниже — конкретный порядок действий без общих фраз про «удобство пользователей».

Зачем проверять вёрстку до оплаты, а не после

Разработчик тестирует вёрстку в первую очередь на своей машине, в своём браузере, на своём мониторе. Если исполнитель добросовестный, он прогонит сайт ещё по паре устройств — но полного покрытия «в одиночку» не бывает физически: экранов, версий браузеров и операционных систем слишком много. Проблема вскрывается там, где у заказчика реально живут посетители: старый Android, iPhone SE, монитор 1366×768, корпоративный Internet Explorer в бухгалтерии.

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

Брейкпоинты: какие контрольные точки проверять

Брейкпоинты — это ширины экрана, на которых меняется раскладка сайта. Стандартный минимальный набор для проверки:

• 320–375 px — маленький смартфон (iPhone SE, старые Android);
• 390–430 px — современный смартфон;
• 768 px — планшет в портретной ориентации;
• 1024–1280 px — планшет в альбомной ориентации и небольшой ноутбук;
• 1440–1920 px — десктоп и полноэкранный монитор.

Проверять нужно не только сами точки, но и промежутки между ними — потому что верстальщик обычно тестирует именно контрольные значения, а между ними макет может «ломаться»: элементы наезжают друг на друга, текст переносится некрасиво, кнопки съезжают за пределы блока. Практический приём: в DevTools браузера медленно тяните ширину окна от 320 до 1920 px, не отпуская мышь, и смотрите, где верстка визуально «дёргается» или ломается — это и есть проблемные зоны.

Отдельно проверьте горизонтальный скролл на мобильной версии. Он не должен появляться ни на одной странице — это первый признак того, что где-то элемент вылезает за пределы экрана (чаще всего виновата картинка без ограничения ширины или фиксированная ширина блока в пикселях).

Проверка на реальных устройствах, а не только в эмуляторе

Режим адаптивного дизайна в DevTools Chrome — это эмуляция размера экрана, а не полноценная имитация устройства. Он не покажет: как ведёт себя фиксированное меню при появлении клавиатуры на телефоне, как скроллится страница с эффектом инерции на iOS, корректно ли работают hover-эффекты на экране без курсора (на touch-устройствах наведения не существует физически, и если интерактивность завязана только на hover, часть функциональности окажется недоступной).

Что стоит сделать на реальных устройствах, если они у вас есть:

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

Если своего парка устройств нет, разумная альтернатива — облачные сервисы кроссбраузерного и кроссплатформенного тестирования (BrowserStack и аналоги) с бесплатным пробным периодом, либо просьба к 2–3 знакомым открыть сайт на их телефонах и прислать скриншот. Это не заменяет полноценный QA, но закрывает основные риски за 15 минут.

Кроссбраузерность: какие браузеры действительно нужно проверить

«Кроссбраузерность» на практике означает не «сайт открывается», а «сайт выглядит и работает одинаково». У браузеров разный рендеринг CSS-свойств, разная поддержка новых стандартов и разное поведение форм. Минимальный набор для проверки:

• Chrome — основной браузер большинства пользователей в России и мире, но на нём же чаще всего и разрабатывают, поэтому он реже показывает проблему;
• Safari — обязательно, отдельно на macOS и на iOS: это разные движки рендеринга по факту используемых версий, и именно в Safari чаще всего «плывут» flex-раскладки, sticky-элементы и анимации;
• Firefox — другой движок (Gecko), полезен для проверки, что верстальщик не использовал свойства, работающие только в Chromium;
• Яндекс Браузер — заметная доля рынка в РФ, основан на Chromium, но со своими нюансами (умная строка, встроенный переводчик могут искажать вёрстку);
• Edge — стандарт для многих корпоративных заказчиков, тоже на Chromium, но стоит проверить хотя бы один раз.

Честная оговорка: требовать одинаковый пиксель-в-пиксель вид в устаревших браузерах (Internet Explorer 11 и старше) — не имеет смысла в 2026 году, если только это прямо не прописано в ТЗ и не оправдано аудиторией заказчика (например, госструктуры с корпоративными ограничениями). Для таких случаев стоимость и сроки вёрстки обычно оговариваются отдельно — поддержка устаревших движков требует полифиллов и урезания части современной функциональности.

Скорость, семантика и другие технические критерии

Адаптив и кроссбраузерность — не всё, что стоит проверить до подписания акта. Ещё три вещи, которые проверяются быстро, но экономят деньги в будущем:

• Скорость загрузки. Прогоните сайт через Google PageSpeed Insights (бесплатно, результат за минуту) отдельно для мобильной и десктопной версии. Ориентир для нормальной вёрстки без сложных интеграций — 85–90+ баллов. Более низкий результат — повод спросить у исполнителя, почему, и попросить оптимизацию изображений (формат WebP), пока акт не подписан.
• Валидность кода. Проверка через валидатор W3C (validator.w3.org) показывает грубые ошибки разметки — незакрытые теги, дублирующиеся id, некорректную вложенность. Несколько предупреждений — норма, десятки ошибок — сигнал небрежной работы.
• Работа интерактивных элементов после ресайза. Слайдеры, модальные окна, аккордеоны и формы нужно проверить не только в исходном размере окна, но и после смены разрешения — некоторые скрипты инициализируются один раз при загрузке и «не замечают» изменение брейкпоинта.

Отдельно стоит открыть консоль браузера (F12 → Console) на каждой ключевой странице и посмотреть, нет ли красных ошибок JavaScript. Заказчику необязательно разбираться в коде, но само наличие ошибок в консоли — весомый аргумент попросить исправление до оплаты.

Чек-лист приёмки вёрстки перед оплатой

Короткий список, который можно пройти за 20–30 минут перед подписанием акта:

1. Вёрстка открыта на ширинах 320, 375, 768, 1024, 1440 px — раскладка не ломается, элементы не наезжают друг на друга.
2. Нет горизонтального скролла ни на одной странице в мобильной версии.
3. Сайт открыт хотя бы на одном реальном смартфоне (не только в эмуляторе браузера).
4. Форма заполнена с телефона — клавиатура не перекрывает поле ввода.
5. Сайт проверен в Chrome, Safari (обязательно, отдельно на iOS) и ещё в одном браузере — Firefox или Яндекс Браузере.
6. Меню, слайдеры, модальные окна и аккордеоны работают после изменения размера окна, а не только при первой загрузке.
7. PageSpeed Insights показывает 85+ баллов для мобильной версии главной страницы.
8. Консоль браузера (F12) не показывает красных ошибок JavaScript на ключевых страницах.
9. Валидатор W3C не выдаёт критических ошибок разметки.
10. Все ссылки, кнопки и формы кликабельны и доступны с тачскрина, а не только по hover-эффекту с мышью.

Практический вывод

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

Если своими силами проверить всё не успеваете — попросите исполнителя приложить к акту сдачи скриншоты PageSpeed Insights, валидатора W3C и вёрстки на нескольких брейкпоинтах: это нормальная практика, и добросовестный подрядчик такие материалы предоставит без сопротивления. Отказ показать эти артефакты до оплаты — сам по себе повод насторожиться и попросить дополнительное время на тестирование, прежде чем подписывать документы.