Чек-лист: как проверить работу фрилансера по верстке

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

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

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

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

Что входит в понятие «качественная верстка»: соответствие макету

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

Для проверки соответствия макету я использую расширение PerfectPixel - оно доступно для Chrome и Firefox и накладывает картинку макета поверх верстки в браузере с регулируемой прозрачностью. Загружаете PNG дизайн-макет, выравниваете по нулевой точке страницы и смотрите, где элементы расходятся - размеры блоков, положение заголовков, отступы. Разница в 1-3 пикселя между макетом и версткой - это нормальная погрешность, связанная с рендерингом шрифтов и не является браком.

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

Проверка адаптивности под мобильные устройства

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

За адаптацию верстки под разные размеры экрана отвечают media-запросы CSS - правила, которые меняют стили при определенной ширине окна. Проверить их работу можно прямо в браузере: открываете DevTools, включаете режим эмуляции устройства и растягиваете окно, наблюдая при изменении ширины окна, не наезжают ли элементы друг на друга и не съезжает ли текст за пределы контейнера. Важно тестировать в актуальной версии браузера - в старой версии картина может отличаться от того, что увидит реальный посетитель. Многие переходят на сайт по ссылке в социальных сетях прямо с телефона, поэтому мобильную версию проверяю в первую очередь.

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

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

Проверка кроссбраузерности

Один браузер никогда не показывает полной картины верстки. Chrome и Firefox используют разные движки рендеринга, и даже одна и та же CSS-конструкция иногда выглядит в них по-разному. Кроссбраузерное тестирование выявляет различия в отображении между браузерами, которые заказчик просто не увидит, открыв сайт только в одном.

Проверяйте макет минимум в 2-3 популярных браузерах: Chrome, Firefox и отдельно Safari. Это не формальность - у каждого браузера свой набор нюансов в обработке flexbox и grid - современных технологий CSS-верстки для расположения блоков на странице, а также шрифтов, и то, что идеально в Chrome, может съехать в Firefox.

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

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

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

Техническая чистота кода (HTML и CSS)

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

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

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

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

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

Проверка скорости загрузки страницы

Скорость загрузки - хороший косвенный индикатор качества верстки: тяжелые несжатые изображения, раздутый код и лишние скрипты почти всегда тянут сайт вниз. Инструмент Google PageSpeed Insights показывает оценку скорости загрузки страницы по шкале от 0 до 100 отдельно для мобильной версии и десктопа.

Помимо общей оценки, сервис считает метрики Core Web Vitals - это набор показателей от Google, которые оценивают удобство страницы для реального посетителя. Core Web Vitals включают метрики LCP (скорость отрисовки основного контента), CLS (стабильность верстки при загрузке, то есть насколько сильно элементы "прыгают") и INP (скорость отклика на действия пользователя).

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

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

Оценка Google PageSpeed выше 90 баллов считается признаком качественной оптимизации, но это ориентир, а не жесткая планка - для многих сайтов 70-80 баллов уже достаточный результат, если контент и функциональность важнее миллисекунд загрузки.

Как оформить замечания и довести работу до финала

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

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

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

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

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

Итог: чек-лист приёмки верстки

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

1. Сверка с макетом через инструмент наложения, а не на глаз
2. Проверка адаптива минимум на трёх точках - мобильный, планшет, десктоп
3. Просмотр в разных браузерах, включая Safari
4. Проверка кода через валидатор на явные ошибки разметки
5. Замер скорости загрузки и показателей Core Web Vitals
6. Клик по всем кнопкам, ссылкам и формам вручную
7. Финальная сверка результата с техническим заданием

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

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

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

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

Список литературы

1. Google for Developers - About PageSpeed Insights // developers.google.com
2. Google - Web Vitals // web.dev
3. Google for Developers - Improve your website with Web Vitals // developers.google.com
4. MDN Web Docs - материалы по адаптивной верстке и медиа-запросам
5. W3C - валидатор HTML и CSS как отраслевой стандарт проверки кода
6. HTML Academy - Кроссбраузерная вёрстка // Хабр, блог компании