Проверка веб-дизайна в браузере

Зачем это изучать

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

Проверено: 23 августа 2026 года.

Frontend нельзя завершать по чтению JSX, шаблона или CSS. Официальные материалы OpenAI рекомендуют отрендерить результат, проверить layout, clipping, spacing, пропавший контент и визуальную согласованность, а затем исправить найденное.

Пирамида UI-проверки

Уровень	Что ловит	Пример доказательства
Static	синтаксис, типы, запрещённые patterns	lint, typecheck, build
Component	состояния и локальные interaction	stories, component tests
Accessibility automation	часть нарушений семантики и контраста	axe/эквивалентный отчёт
Browser/E2E	реальный пользовательский поток	Playwright trace и assertions
Visual regression	неожиданные изменения рендера	утверждённый screenshot diff
Manual	иерархия, focus, смысл, motion, удобство	протокол прохода и screenshots
Field	опыт реальных устройств и сетей	RUM/Core Web Vitals

Ни один уровень не заменяет остальные. Playwright отдельно предупреждает, что автоматические accessibility-тесты находят только часть проблем; нужны ручная оценка и inclusive user testing.

Матрица browser-check

До реализации определите риск-профиль проекта. Минимальный baseline:

• 320 px, типичный mobile, tablet и широкий desktop;
• основной поддерживаемый browser и хотя бы один альтернативный engine для критичного публичного пути;
• light/dark, если обе темы существуют;
• 200% zoom и увеличенный размер текста;
• prefers-reduced-motion: reduce;
• клавиатура: Tab, Shift+Tab, Enter, Space, Escape и стрелки по модели widget;
• loading, empty, error, success, disabled, offline/slow response по риску;
• длинный текст, другая локаль и отсутствующее изображение.

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

Функциональный browser-тест

Проверяйте наблюдаемый пользовательский исход, а не внутренний CSS-класс:

Дано: новый пользователь на /pricing, viewport 390 × 844.
Когда: выбирает тариф, открывает форму и исправляет ошибку email.
Тогда: focus приходит к ошибке, данные не теряются, CTA доступен,
успех подтверждён понятным сообщением и следующим шагом.

Используйте locators по роли и доступному имени. Это делает тест ближе к пользовательскому восприятию и одновременно выявляет проблемы семантики. Изолируйте тесты, контролируйте данные и не маскируйте flakiness произвольными таймаутами.

Visual regression

Снимайте только стабильные, значимые состояния. Для воспроизводимости зафиксируйте browser, OS/container, viewport, fonts, locale, theme, test data и motion. Playwright отмечает, что рендер зависит от среды; baseline и сравнение должны выполняться в одинаковых условиях.

Хороший процесс:

1. сгенерировать baseline из утверждённого интерфейса;
2. получать actual, expected и diff для изменившегося состояния;
3. просматривать diff человеком;
4. исправить регрессию или осознанно утвердить новый baseline;
5. хранить baseline рядом с тестом или в управляемом сервисе.

Pixel diff ловит изменение, но не решает, стало ли лучше. Не подменяйте им дизайн-review.

Accessibility gate

Автоматически проверяйте хотя бы ключевые страницы и интерактивные состояния. Вручную проходите:

• landmark и heading structure;
• полный сценарий клавиатурой;
• видимость, порядок и возврат focus;
• объявления ошибок, загрузки и status messages;
• осмысленность labels, link text и alt;
• reflow, zoom, high contrast и reduced motion;
• сложные widgets по WAI-ARIA APG.

WCAG 2.2 оценивает полную страницу, включая responsive-варианты. Успешный scan одного desktop-состояния не является заявлением о соответствии.

Performance gate

Для публичных страниц сохраняйте ориентиры Core Web Vitals: LCP ≤ 2,5 с, INP ≤ 200 мс, CLS ≤ 0,1 на 75-м перцентиле, отдельно для mobile и desktop. Лабораторная проверка полезна до публикации; полевые данные показывают опыт реальных пользователей.

Codex должен искать причину, а не снижать threshold. Частые источники:

• hero/media без responsive-размеров и приоритета;
• web fonts, блокирующие первый рендер;
• JavaScript и hydration сверх нужд первого экрана;
• изображения и embed без зарезервированной геометрии;
• тяжёлая анимация и обработчики, блокирующие interaction;
• third-party scripts без бюджета и владельца.

Evidence-пакет завершённой задачи

- маршруты и состояния, которые проверены;
- viewport/browser/theme/locale;
- команды test/lint/typecheck/build;
- browser/E2E result и trace при сбое;
- accessibility automation + ручной keyboard/focus-check;
- screenshots или visual diff;
- performance result и происхождение данных;
- известные ограничения и непроверенные сценарии.

Финальное решение принимайте по чек-листу review.