Практика «Performance» и «Accessibility»

Две песочницы для багов, которые обычно не видны на глаз: /practice/perf и /practice/a11y. Здесь нужны инструменты браузера. Практика по производительности входит в бесплатную часть платформы, по доступности — в сопровождении.

Performance — /practice/perf

Два тренажёра.

Медленная страница

/practice/perf/slow-page — страница, нагруженная типичными проблемами производительности: 200 тяжёлых картинок без ленивой загрузки, синхронный цикл на миллион итераций, «прыгающая» вёрстка, лишний встроенный CSS, document.write. Задача — найти проблемы в DevTools и ответить на вопросы под страницей: что тормозит и что чинить первым.

Метрики Core Web Vitals

/practice/perf/vitals — смоделированные значения LCP, FID, CLS и TTFB. Для каждой метрики нужно поставить оценку «good / needs improvement / poor» и решить, что чинить первым. Пороги: LCP 2,5 / 4 с, CLS 0,1 / 0,25, FID 100 / 300 мс, TTFB 0,8 / 1,8 с.

Что искать

• Долгий TTFB (Time To First Byte) — медленный сервер или тяжёлая серверная отрисовка.
• CLS (Cumulative Layout Shift) — элементы сдвигаются при загрузке: у <img> нет width и height, шрифты подгружаются и перерисовывают текст.
• LCP (Largest Contentful Paint) — крупное изображение или блок появляется поздно.
• Долгие задачи в JS, которые блокируют основной поток.
• Лишние сетевые запросы — дубликаты, неиспользуемые ресурсы.
• Тяжёлые ресурсы — большие картинки, несжатые файлы.

Инструменты

• Lighthouse (DevTools → Lighthouse) — запустите проверку в режиме Performance и прочитайте отчёт.
• Вкладка Performance — запишите профиль и найдите долгие функции.
• Вкладка Network с замедлением «Slow 4G» — посмотрите, как страница ведёт себя на медленной сети.
• Вкладка Coverage — какая доля JS реально используется.

Accessibility — /practice/a11y

Плохая страница

/practice/a11y/bad-page — страница, собранная из нарушений доступности: <div> вместо кнопок, поля без подписей, серый текст на белом, модальное окно, из которого не выйти клавиатурой, ссылки «click here». Такие баги не видны глазами, но мешают людям со скринридерами и тем, кто пользуется только клавиатурой.

Под страницей — чек-лист. Среди пунктов есть ложные: стилистические особенности, которые нарушением доступности не являются. Зачёт — от 8 настоящих находок и не больше одной ошибки.

Тренажёр по axe DevTools пока в разработке.

Что искать

• Нет <label> у полей формы.
• Кнопки без текста — только иконка, без aria-label.
• Пустой или бессмысленный alt у <img>.
• Низкий контраст — например, текст #888 на белом.
• Невидимый фокус — outline: none без замены.
• Кнопки, недоступные с клавиатуры — <div onclick> без tabindex и обработки клавиш.
• Ловушка фокуса — из модального окна нельзя выйти клавишей Tab или Esc.
• Нарушенная иерархия заголовков — после <h1> сразу <h4>.

Инструменты

• Lighthouse → Accessibility — автоматически находит многие базовые проблемы.
• axe DevTools (расширение для Chrome и Firefox) — находит больше, чем Lighthouse.
• Клавиша Tab по всей странице — где фокус пропадает, где застревает.
• Скринридер:
  • macOS: VoiceOver (Cmd + F5);
  • Windows: NVDA (бесплатный);
  • ChromeOS: ChromeVox.
• Проверка контраста — в DevTools: выберите элемент, нажмите на образец цвета в стилях, там показан коэффициент контраста.

Совет для обеих практик

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

Что дальше

• Практика bug-hunt — функциональные баги и баги интерфейса
• Виджет «Bug-checklist»
• Практика «DevTools-квесты»