web-quality-audit

Web quality audit — это workflow Addy Osmani для системной проверки веб-проекта по четырём направлениям: Performance, Accessibility, SEO и Best Practices. Источник описывает аудит как проверку более чем 150 критериев, поэтому карточка подходит для повторяемого quality review сайта, а не только для поиска одной медленной страницы. Результат должен быть оформлен по уровням Critical, High, Medium и Low: для каждого замечания фиксируются категория, влияние и конкретное исправление. Критические проблемы требуют немедленного внимания, серьёзные барьеры доступности и провалы Core Web Vitals следует устранить до запуска, а средние и низкие улучшения можно планировать по спринтам. В performance-части skill выделяет Core Web Vitals и базовые причины потерь скорости. Для Largest Contentful Paint указан ориентир менее 2,5 секунды, для Interaction to Next Paint — менее 200 миллисекунд, для Cumulative Layout Shift — менее 0,1. Эти значения служат критериями проверки, а не обещанием результата для любого проекта. Источник предлагает искать независимые последовательные ожидания, лишний JavaScript и неиспользуемые стили, оптимизировать изображения до WebP или AVIF с fallback, корректно выбирать размер через srcset, задавать размеры для изображений и встраиваемых элементов, использовать font-display: swap и lazy loading для содержимого ниже первого экрана. Для критических LCP-изображений, шрифтов и CSS рассматриваются preload, а для внешних доменов — preconnect. Долгий серверный ответ, тяжёлый bundle и неудачное кеширование относятся к разным причинам и требуют отдельной проверки. Accessibility-раздел охватывает воспринимаемость, управление с клавиатуры, понятность и совместимость с технологиями доступа. Среди проверяемых условий названы meaningful alt у информативных изображений, пустой alt для декоративных, контраст не менее 4,5:1 для обычного текста и 3:1 для крупного, отсутствие зависимости только от цвета, подписи и расшифровки для видео и аудио. Интерактивные элементы должны работать с клавиатуры, иметь видимый focus и не создавать keyboard trap; интерфейс должен давать пользователю достаточно времени и содержать skip link. Дополнительно проверяются lang у HTML, связанные с полями labels и понятные сообщения об ошибках. Валидная разметка, уникальные id и корректное применение ARIA относятся к robust-части проверки, но ARIA не должен подменять нативные элементы там, где их достаточно. SEO-направление проверяет crawlability и содержание страницы: robots.txt, XML sitemap, canonical, отсутствие noindex на важных URL, уникальность title, релевантность основного ключа, иерархию заголовков с одним H1, описательные тексты ссылок и JSON-LD. Техническая часть включает HTTPS, mobile-friendly поведение, размеры touch targets не менее 48 пикселей, отсутствие mixed content, устаревших API, document.write, synchronous XHR, небезопасных библиотек и открытых source maps. Best Practices также подразумевают CSP и чистую консоль без browser или CORS ошибок. Это набор проверяемых сигналов: он не заменяет полноценный pentest, ручное тестирование реальными пользователями или анализ бизнес-метрик. Важное ограничение связано с версией Lighthouse. Источник отмечает, что в Lighthouse 13 старые performance-аудиты могли быть объединены в Performance Insight Audits: First Meaningful Paint, No Document Write, Uses Passive Event Listeners и Uses Rel Preload больше нельзя механически ожидать как отдельные поля. Аналогично проверки layout shifts и изображений группируются в cls-culprits-insight и image-delivery-insight. Старый JSON следует понимать как более широкий набор сигналов, а не как противоречие новой форме отчёта. Практический цикл — выполнить аудит до deploy, еженедельно сверять Search Console, Core Web Vitals и зависимости, а раз в месяц повторять полный Lighthouse-проход и отдельную проверку доступности. Skill формирует приоритеты и рекомендации, но не применяет исправления автоматически и не доказывает production-готовность без запуска в реальном окружении.