
Web Quality Audit
- 18.2k installs
- 2.5k repo stars
- Updated June 14, 2026
- addyosmani/web-quality-skills
Web Quality Audit is a skill for comprehensive quality reviews covering performance, accessibility, SEO, and best practices via Lighthouse v13.
About
Comprehensive web quality audit covering performance, accessibility, SEO, and best practices. Based on Google Lighthouse v13, covers 150+ checks including Core Web Vitals (LCP, INP, CLS), WCAG compliance, crawlability, on-page SEO, structured data, security, and modern standards. Categorizes findings by severity (Critical to Low) with actionable fixes. Use when asked to audit site quality, review web performance, optimize for ranking factors, or prepare for launch.
- 150+ quality checks across performance, accessibility, SEO, and best practices
- Core Web Vitals validation (LCP, INP, CLS)
- Structured severity levels and actionable recommendations
Web Quality Audit by the numbers
- 18,158 all-time installs (skills.sh)
- +1,317 installs in the week ending Jul 28, 2026 (Skillselion tracking)
- Ranked #20 of 1,382 Code Review & Quality skills by installs in the Skillselion catalog
- Security screen: LOW risk (skills.sh audit)
- Data as of Jul 28, 2026 (Skillselion catalog sync)
web-quality-audit capabilities & compatibility
- Capabilities
- performance audit · accessibility audit · seo audit · security audit · best practices check
- Use cases
- frontend · seo · testing
What web-quality-audit says it does
Minimum 4.5:1 for normal text, 3:1 for large text (WCAG AA)
npx skills add https://github.com/addyosmani/web-quality-skills --skill web-quality-auditAdd your badge
Show developers this skill is listed on Skillselion. Paste this into your README.
| Installs | 18.2k |
|---|---|
| repo stars | ★ 2.5k |
| Security audit | 3 / 3 scanners passed |
| Last updated | June 14, 2026 |
| Repository | addyosmani/web-quality-skills ↗ |
What it does
Audit website quality across performance, accessibility, SEO, and best practices to identify and prioritize improvements before launch.
Who is it for?
frontend developers, QA engineers, SEO specialists
Skip if: Teams that need live browser runtime profiling or authenticated page crawling instead of static HTML analysis.
When should I use this skill?
auditing site quality, reviewing web performance, checking accessibility, optimizing for search, preparing for launch
What you get
Prioritized audit findings with severity levels and actionable fixes organized by category
- Structured JSON findings report
- Human-readable stderr audit logs
By the numbers
- 150+ Lighthouse checks
- 4 audit categories (Performance 40%, Accessibility 30%, SEO 15%, Best Practices 15%)
- severity levels from Critical to Low
Files
Web quality audit
Comprehensive quality review based on Google Lighthouse audits. Covers Performance, Accessibility, SEO, and Best Practices across 150+ checks.
Lighthouse v13 note (Oct 2025+). Lighthouse has migrated the Performance category from per-opportunity audits to Performance Insight Audits (announcement). Several individual audit names this skill historically referenced — First Meaningful Paint, No Document Write, Uses Passive Event Listeners, Uses Rel Preload — have been removed or merged. The underlying advice is unchanged and still applies; only the report format moved. The CLS-related audits ("layout shifts", "non-composited animations", "unsized images") are now consolidated into a singlecls-culprits-insight, and image audits are merged intoimage-delivery-insight. Treat older Lighthouse JSON output as a superset, not a contradiction.
How it works
1. Analyze the provided code/project for quality issues 2. Categorize findings by severity (Critical, High, Medium, Low) 3. Provide specific, actionable recommendations 4. Include code examples for fixes
Audit categories
Performance (40% of typical issues)
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 (30% of typical issues)
Perceivable:
- Text alternatives. Every
<img>has meaningfulalttext. Decorative images usealt="". - 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
langattribute 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 (15% of typical issues)
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. 50-60 characters. Primary keyword included.
- Meta descriptions. 150-160 characters. Compelling and unique.
- Heading hierarchy. Single
<h1>. Logical heading structure. - Descriptive link text. Not "click here" or "read more".
Technical SEO:
- Mobile-friendly. Responsive design. Tap targets ≥ 48px.
- HTTPS. Secure connection required.
- Fast loading. Performance directly impacts ranking.
- Structured data. JSON-LD for rich snippets (Article, Product, FAQ, etc.).
Best practices (15% of typical issues)
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.
Severity levels
| Level | Description | Action |
|---|---|---|
| Critical | Security vulnerabilities, complete failures | Fix immediately |
| High | Core Web Vitals failures, major a11y barriers | Fix before launch |
| Medium | Performance opportunities, SEO improvements | Fix within sprint |
| Low | Minor optimizations, code quality | Fix when convenient |
Audit output format
When performing an audit, structure findings as:
## Audit results
### Critical issues (X found)
- **[Category]** Issue description. File: `path/to/file.js:123`
- **Impact:** Why this matters
- **Fix:** Specific code change or recommendation
### High priority (X found)
...
### Summary
- Performance: X issues (Y critical)
- Accessibility: X issues (Y critical)
- SEO: X issues
- Best Practices: X issues
### Recommended priority
1. First fix this because...
2. Then address...
3. Finally optimize...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:
- Performance Optimization
- Core Web Vitals
- Accessibility
- SEO
- Best Practices
#!/bin/bash
# Read-only HTML quality analyzer (v2). No filesystem mutations.
# stderr = human logs, stdout = structured JSON.
set -euo pipefail
MAX_FINDINGS=100
MAX_PER_CATEGORY_PER_FILE=20 # cap per high-volume check per file so one category can't fill MAX_FINDINGS
fail() {
local type="$1" msg="$2" suggestion="$3"
if command -v jq >/dev/null 2>&1; then
jq -n \
--arg type "$type" \
--arg msg "$msg" \
--arg suggestion "$suggestion" \
'{success: false, error: {type: $type, message: $msg, retryable: false, suggestion: $suggestion}}'
else
printf '{"success":false,"error":{"type":"%s","message":"%s","suggestion":"%s","retryable":false}}\n' \
"$type" "$msg" "$suggestion"
fi
exit 1
}
command -v jq >/dev/null 2>&1 || \
fail "missing_dependency" "jq is required for safe JSON output" "Install: brew install jq"
[ $# -ge 1 ] || fail "invalid_input" "No target provided" "Usage: $0 <file_or_directory>"
TARGET="$1"
[ -e "$TARGET" ] || fail "invalid_input" "Target not found: $TARGET" "Pass an existing file or directory path"
ISSUES=()
WARNINGS=()
analyze_html() {
local file="$1"
echo "Analyzing: $file" >&2
grep -qi "<!doctype html>" "$file" || ISSUES+=("$file:0: Missing HTML5 doctype")
grep -qi 'charset.*utf-8' "$file" || WARNINGS+=("$file:0: Missing or non-UTF-8 charset")
grep -qi 'name="viewport"' "$file" || ISSUES+=("$file:0: Missing viewport meta tag")
grep -qi '<html[^>]*lang=' "$file" || ISSUES+=("$file:0: Missing lang attribute on <html>")
grep -qi '<title>' "$file" || ISSUES+=("$file:0: Missing <title> tag")
# <img> without alt — two-pass replaces broken PCRE lookahead
local alt_count=0
while IFS=: read -r ln tag; do
if grep -qE 'alt=' <<<"$tag"; then continue; fi
if [ "$alt_count" -ge "$MAX_PER_CATEGORY_PER_FILE" ]; then
WARNINGS+=("$file:0: <img>-without-alt findings truncated (>${MAX_PER_CATEGORY_PER_FILE} in this file)")
break
fi
WARNINGS+=("$file:$ln: <img> without alt attribute")
alt_count=$((alt_count + 1))
done < <(grep -noE '<img[^>]*>' "$file" || true)
# Non-HTTPS URLs with line numbers
local http_count=0
while IFS=: read -r ln _; do
if [ "$http_count" -ge "$MAX_PER_CATEGORY_PER_FILE" ]; then
WARNINGS+=("$file:0: Non-HTTPS URL findings truncated (>${MAX_PER_CATEGORY_PER_FILE} in this file)")
break
fi
WARNINGS+=("$file:$ln: Non-HTTPS URL")
http_count=$((http_count + 1))
done < <(grep -noE 'http://[^"'\''[:space:]>]*' "$file" || true)
}
# Process substitution keeps arrays in main shell (fixes v1 subshell bug)
if [ -d "$TARGET" ]; then
while IFS= read -r -d '' file; do
analyze_html "$file"
done < <(find "$TARGET" \( -name "*.html" -o -name "*.htm" \) -print0)
elif [ -f "$TARGET" ]; then
analyze_html "$TARGET"
else
fail "invalid_input" "Target is not a regular file or directory: $TARGET" "Pass a path to an .html/.htm file or a directory"
fi
issue_total=${#ISSUES[@]}
warning_total=${#WARNINGS[@]}
to_json_array() {
printf '%s\n' "$@" | jq -Rs 'split("\n") | map(select(length > 0))'
}
if [ "$issue_total" -gt 0 ]; then
issues_json=$(to_json_array "${ISSUES[@]:0:$MAX_FINDINGS}")
else
issues_json='[]'
fi
if [ "$warning_total" -gt 0 ]; then
warnings_json=$(to_json_array "${WARNINGS[@]:0:$MAX_FINDINGS}")
else
warnings_json='[]'
fi
echo "Scanned. $issue_total issues, $warning_total warnings." >&2
jq -n \
--argjson issues "$issues_json" \
--argjson warnings "$warnings_json" \
--argjson issue_total "$issue_total" \
--argjson warning_total "$warning_total" \
--argjson max "$MAX_FINDINGS" \
'{
success: true,
issues: $issues,
warnings: $warnings,
issueCount: $issue_total,
warningCount: $warning_total,
truncated: (($issue_total > $max) or ($warning_total > $max))
}'
Related skills
Forks & variants (1)
Web Quality Audit has 1 known copy in the catalog totaling 161 installs. They canonicalize to this original listing.
- tech-leads-club - 161 installs
How it compares
Choose web-quality-audit for fast, agent-friendly static HTML scans when you do not need a full headless browser trace.
FAQ
What are the Core Web Vitals?
LCP (Largest Contentful Paint) <2.5s, INP (Interaction to Next Paint) <200ms, CLS (Cumulative Layout Shift) <0.1.
What's the priority order for fixes?
Critical (security, failures) first, then High (Core Web Vitals), then Medium (performance opportunities), then Low (optimizations).
Is Web Quality Audit safe to install?
skills.sh reports 3 of 3 security scanners passed. Review the Security Audits panel on this page before installing in production.