web-quality-audit

작성자: addyosmani

성능, 접근성, SEO 및 모범 사례를 포괄하는 종합적인 웹 품질 감사입니다. "내 사이트 감사", "웹 품질 검토", "라이트하우스 감사 실행", "페이지 품질 확인", "내 웹사이트 최적화" 요청 시 사용하세요.

npx skills add https://github.com/addyosmani/web-quality-skills --skill web-quality-audit

Web quality audit

Comprehensive quality review that combines live browser evidence with source inspection. Covers Performance, Accessibility, SEO, Best Practices, and Agentic Browsing without treating an aggregate score as proof of quality.

Lighthouse 13+. The Performance category now uses shared Performance Insights across Lighthouse and the DevTools Performance panel (announcement). Follow current insight names and evidence. Do not require removed audit IDs or automatically recreate their recommendations; some were retired because they were noisy, inactionable, or easy to over-recommend.

How it works

  1. Establish the audit target: representative URLs, important states and journeys, public versus authenticated access, and mobile/desktop scope.
  2. If a page can run, read the measurement workflow and collect a minimal live baseline before searching the codebase broadly.
  3. Use runtime failures to localize source inspection. Keep measured findings separate from hypotheses found only in code.
  4. Categorize by user impact and confidence, then make or recommend specific fixes.
  5. Re-run equivalent automated checks and the affected manual flows. Report what is verified and what still needs field or human validation.

Tool routing

Use the best capability already available; do not block the audit on optional setup.

NeedPreferred routeFallback
Performance and Core Web VitalsRecord a browser performance trace and analyze focused insights; with Chrome DevTools MCP, use performance_start_trace then performance_analyze_insightLighthouse CLI or PageSpeed Insights lab data
Real-user performanceCrUX values included in current DevTools trace summariesPageSpeed Insights/CrUX Vis; direct CrUX API only when a key is already available or automation is requested
Accessibility, SEO, Best Practices, Agentic BrowsingRun a live Lighthouse audit; with Chrome DevTools MCP, use lighthouse_auditCategory-specific Lighthouse CLI audits plus manual checks
Rendered semantics and interactionInspect the accessibility tree and exercise the UI; with Chrome DevTools MCP, use take_snapshot and focused evaluate_scriptBrowser/manual testing
Source smoke testscripts/analyze.sh <path>Direct source inspection

Chrome DevTools MCP's lighthouse_audit intentionally excludes performance. Its navigation mode reloads the page; use snapshot mode when preserving the current authenticated or user-created state matters. The static analyzer is a fast smoke test, not a substitute for a rendered-page audit.

Audit categories

Performance

Core Web Vitals — Must pass for good page experience:

  • LCP (Largest Contentful Paint) < 2.5s. The largest visible element must render quickly. Optimize images, fonts, and server response time.
  • INP (Interaction to Next Paint) < 200ms. User interactions must feel instant. Reduce JavaScript execution time and break up long tasks.
  • CLS (Cumulative Layout Shift) < 0.1. Content must not jump around. Set explicit dimensions on images, embeds, and ads.

Resource Optimization:

  • Compress images. Use WebP/AVIF with fallbacks. Serve correctly sized images via srcset.
  • Minimize JavaScript. Remove unused code. Use code splitting. Defer non-critical scripts.
  • Optimize CSS. Extract critical CSS. Remove unused styles. Avoid @import.
  • Efficient fonts. Use font-display: swap. Preload critical fonts. Subset to needed characters.

Loading Strategy:

  • Preconnect to origins. Add <link rel="preconnect"> for third-party domains.
  • Preload critical assets. LCP images, fonts, and above-fold CSS.
  • Lazy load below-fold content. Images, iframes, and heavy components.
  • Cache effectively. Long cache TTLs for static assets. Immutable caching for hashed files.

Accessibility

Perceivable:

  • Text alternatives. Every <img> has meaningful alt text. Decorative images use alt="".
  • Color contrast. Minimum 4.5:1 for normal text, 3:1 for large text (WCAG AA).
  • Don't rely on color alone. Use icons, patterns, or text alongside color indicators.
  • Captions and transcripts. Video has captions. Audio has transcripts.

Operable:

  • Keyboard accessible. All functionality available via keyboard. No keyboard traps.
  • Focus visible. Clear focus indicators on all interactive elements.
  • Skip links. Provide "Skip to main content" for keyboard users.
  • Sufficient time. Users can extend time limits. No auto-advancing content without controls.

Understandable:

  • Page language. Set lang attribute on <html>.
  • Consistent navigation. Same navigation structure across pages.
  • Error identification. Form errors clearly described and associated with fields.
  • Labels and instructions. All form inputs have associated labels.

Robust:

  • Valid HTML. No duplicate IDs. Properly nested elements.
  • ARIA used correctly. Prefer native elements. ARIA roles match behavior.
  • Name, role, value. Interactive elements have accessible names and correct roles.

SEO

Crawlability:

  • Valid robots.txt. Doesn't block important resources.
  • XML sitemap. Lists all important pages. Submitted to Search Console.
  • Canonical URLs. Prevent duplicate content issues.
  • No noindex on important pages. Check meta robots and headers.

On-Page SEO:

  • Unique title tags. Make each title descriptive and concise; display truncation varies by device and result type.
  • Meta descriptions. Write useful, page-specific summaries; search engines may choose a different snippet.
  • Heading hierarchy. The primary heading is descriptive and the structure is logical; do not fail valid HTML solely for using more than one <h1>.
  • Descriptive link text. Not "click here" or "read more".

Technical SEO:

  • Mobile-friendly. Responsive design. Tap targets ≥ 48px.
  • HTTPS. Secure connection required.
  • Page experience signals. Use field Core Web Vitals as evidence, without promising a ranking change.
  • Structured data. JSON-LD for rich snippets (Article, Product, FAQ, etc.).

Best practices

Security:

  • HTTPS everywhere. No mixed content. HSTS enabled.
  • No vulnerable libraries. Keep dependencies updated.
  • CSP headers. Content Security Policy to prevent XSS.
  • No exposed source maps. In production builds.

Modern Standards:

  • No deprecated APIs. Replace document.write, synchronous XHR, etc.
  • Valid doctype. Use <!DOCTYPE html>.
  • Charset declared. <meta charset="UTF-8"> as first element in <head>.
  • No browser errors. Clean console. No CORS issues.

UX Patterns:

  • No intrusive interstitials. Especially on mobile.
  • Clear permission requests. Only ask when needed, with context.
  • No misleading buttons. Buttons do what they say.

Agentic browsing

Use the Lighthouse Agentic Browsing results as technical signals for how well assistants can understand and interact with the rendered page.

  • Accessible interaction surface. Semantic HTML, labels, names, roles, and states must expose meaningful controls in the accessibility tree.
  • WebMCP integrations are valid when present. Review registered tools, schemas, and form coverage; do not add WebMCP solely to raise an audit score.
  • llms.txt is optional. A valid file may help compatible tools discover curated content, but a Lighthouse pass does not prove that search or AI products will ingest, rank, or cite it.
  • Keep this category separate from SEO claims. Agentic browsability is not evidence of search ranking or AI visibility.

Severity levels

LevelDescriptionAction
CriticalSecurity vulnerabilities, complete failuresFix immediately
HighCore Web Vitals failures, major a11y barriersFix before launch
MediumPerformance opportunities, SEO improvementsFix within sprint
LowMinor optimizations, code qualityFix when convenient

Audit output format

When performing an audit, structure findings as:

## Audit results

### Evidence
| Signal | Scope/conditions | Result | Source |
|--------|------------------|--------|--------|
| LCP | URL, phone, p75/28 days | 3.1s (needs improvement) | CrUX |
| Accessibility | URL, mobile navigation | 92 | Lighthouse |

### Critical issues (X found)
- **[Category]** Issue description. File: `path/to/file.js:123`
  - **Impact:** Why this matters
  - **Evidence:** Measured failure, runtime observation, or source hypothesis
  - **Fix:** Specific code change or recommendation

### High priority (X found)
...

### Summary
- Performance: measured status and X findings
- Accessibility: automated status, X findings, manual checks pending/passed
- SEO: X findings
- Best Practices: X findings
- Agentic Browsing: X findings or not available

### Recommended priority
1. First fix this because...
2. Then address...
3. Finally optimize...

### Verification
- Re-run results under the same conditions
- Manual checks completed
- Field validation still pending

Quick checklist

Before every deploy

  • Core Web Vitals passing
  • No accessibility errors (axe/Lighthouse)
  • No console errors
  • HTTPS working
  • Meta tags present

Weekly review

  • Check Search Console for issues
  • Review Core Web Vitals trends
  • Update dependencies
  • Test with screen reader

Monthly deep dive

  • Full Lighthouse audit
  • Performance profiling
  • Accessibility audit with real users
  • SEO keyword review

References

For detailed guidelines on specific areas:

addyosmani의 다른 스킬

accessibility
addyosmani
WCAG 2.2 지침에 따라 웹 접근성을 감사하고 개선합니다. "접근성 개선", "a11y 감사", "WCAG 준수", "스크린 리더 지원", "키보드 탐색", "접근 가능하게 만들기"와 같은 요청이 있을 때 사용하세요.
developmenttestingcode-review
seo
addyosmani
검색 엔진 가시성과 순위를 최적화합니다. "SEO 개선", "검색 최적화", "메타 태그 수정", "구조화된 데이터 추가", "사이트맵 최적화", 또는 "검색 엔진 최적화"를 요청받을 때 사용하세요.
marketingresearchdevelopment
performance
addyosmani
웹 성능을 최적화하여 더 빠른 로딩과 더 나은 사용자 경험을 제공합니다. "사이트 속도 높이기", "성능 최적화", "로딩 시간 줄이기", "느린 로딩 수정", "페이지 속도 개선", "성능 감사" 요청 시 사용하세요.
developmenttesting
code-review-and-quality
addyosmani
다축 코드 리뷰를 수행합니다. 변경 사항을 병합하기 전에 사용하세요. 자신, 다른 에이전트 또는 사람이 작성한 코드를 검토할 때 사용하세요. 코드가 메인 브랜치에 들어가기 전에 여러 차원에서 코드 품질을 평가해야 할 때 사용하세요.
developmentcode-review
frontend-ui-engineering
addyosmani
프로덕션 품질의 접근 가능하고 반응형 사용자 인터페이스를 구축합니다. 인터페이스나 페이지를 만들거나 수정할 때, 컴포넌트를 생성할 때, 레이아웃을 구현할 때, WCAG 접근성 요구사항을 충족할 때, 상태를 관리할 때, 또는 결과물이 AI 생성물처럼 보이지 않고 프로덕션 품질처럼 보여야 할 때 사용하세요.
developmentdesign
security-and-hardening
addyosmani
코드를 취약점으로부터 강화합니다. 사용자 입력, 인증, 데이터 저장소 또는 외부 통합을 처리할 때 사용하세요. 신뢰할 수 없는 데이터를 받거나, 사용자 세션을 관리하거나, 타사 서비스와 상호작용하는 모든 기능을 구축할 때 사용하세요.
spec-driven-development
addyosmani
코딩 전에 명세를 작성합니다. 새 프로젝트, 기능 또는 중요한 변경을 시작할 때 아직 명세가 없는 경우 사용합니다. 요구사항이 불명확하거나, 모호하거나, 막연한 아이디어로만 존재할 때 사용합니다.
developmentdocumentproject-management
performance-optimization
addyosmani
프론트엔드, 백엔드, 쿼리, 데이터베이스 전반에 걸쳐 애플리케이션 성능을 최적화합니다. 성능 요구사항이 있거나, 성능 저하가 의심되거나, Core Web Vitals나 로드 시간 개선이 필요하거나, N+1 쿼리 패턴을 수정해야 하거나, 프로파일링에서 병목 현상이 발견된 경우 사용하세요.
developmentdatabasedata-analysis