
Web Performance Audit
- 493 installs
- 305 repo stars
- Updated March 4, 2026
- aj-geddes/useful-ai-prompts
web-performance-audit is an agent skill that guides Core Web Vitals measurement, bottleneck detection, and optimization recommendations for developers who need faster, SEO-friendly web pages.
About
web-performance-audit is a Claude Code skill from aj-geddes/useful-ai-prompts that walks developers through comprehensive web performance audits. The skill structures lab and field measurement of Core Web Vitals—LCP, FID, CLS, and FCP—with concrete good and poor thresholds, then maps findings to prioritized fixes for images, JavaScript bundles, caching, and mobile networks. It ships four reference guides covering performance metrics, analysis process, optimization strategies, and continuous monitoring workflows. Developers reach for web-performance-audit after major frontend changes, when users report slowness, during SEO tuning, or while setting performance budgets before launch. The workflow emphasizes regular measurement, realistic targets, slow-network testing, and documenting improvements rather than one-off tuning without baseline data or ongoing monitoring. The Quick Start section encodes LCP, FID, and CLS good-versus-poor thresholds in YAML so agents compare lab runs against Google guidance. Best-practice checklists warn against optimizing a single metric, ignoring field data, or skipping mobile throttling during audits.
- Measures all Core Web Vitals including LCP, FID, CLS, and FCP
- Identifies exact bottlenecks affecting load time and user experience
- Delivers prioritized optimization list with expected impact
- Supports both desktop and mobile performance baselines
- Integrates directly into agent workflows for post-change audits
Web Performance Audit by the numbers
- 493 all-time installs (skills.sh)
- Ranked #617 of 2,153 Testing & QA skills by installs in the Skillselion catalog
- Data as of Aug 5, 2026 (Skillselion catalog sync)
npx skills add https://github.com/aj-geddes/useful-ai-prompts --skill web-performance-auditAdd your badge
Show developers this skill is listed on Skillselion. Paste this into your README.
| Installs | 493 |
|---|---|
| repo stars | ★ 305 |
| Last updated | March 4, 2026 |
| Repository | aj-geddes/useful-ai-prompts ↗ |
How do you audit Core Web Vitals bottlenecks?
Automatically measure Core Web Vitals, detect performance bottlenecks, and receive concrete optimization recommendations.
Who is it for?
Frontend developers auditing page speed, Core Web Vitals, and SEO performance after releases or user latency reports.
Skip if: Developers who only need backend API latency profiling without browser metrics, lab data, or frontend asset optimization.
When should I use this skill?
User asks to measure LCP/FID/CLS, audit page speed, fix slow web performance, or set performance budgets.
What you get
Core Web Vitals report, bottleneck list, optimization recommendations, and monitoring plan from four reference guides.
- Performance audit report
- Optimization checklist
- Monitoring plan
By the numbers
- Bundles 4 reference guides for metrics, analysis, optimization, and monitoring
- Documents Core Web Vitals thresholds for LCP, FID, CLS, and FCP
Files
Web Performance Audit
Table of Contents
Overview
Web performance audits measure load times, identify bottlenecks, and guide optimization efforts to create faster, better user experiences.
When to Use
- Regular performance monitoring
- After major changes
- User complaints about slowness
- SEO optimization
- Mobile optimization
- Performance baseline setting
Quick Start
Minimal working example:
Core Web Vitals (Google):
Largest Contentful Paint (LCP):
Measure: Time to load largest visible element
Good: <2.5 seconds
Poor: >4 seconds
Impacts: User perception of speed
First Input Delay (FID):
Measure: Time from user input to response
Good: <100 milliseconds
Poor: >300 milliseconds
Impacts: Responsiveness
Cumulative Layout Shift (CLS):
Measure: Visual stability (unexpected layout shifts)
Good: <0.1
Poor: >0.25
Impacts: User frustration
---
Additional Metrics:
First Contentful Paint (FCP):
// ... (see reference guides for full implementation)Reference Guides
Detailed implementations in the references/ directory:
| Guide | Contents |
|---|---|
| Performance Metrics | Performance Metrics |
| Performance Analysis Process | Performance Analysis Process |
| Optimization Strategies | Optimization Strategies |
| Monitoring & Continuous Improvement | Monitoring & Continuous Improvement |
Best Practices
✅ DO
- Measure regularly (not just once)
- Use field data (real users) + lab data
- Focus on Core Web Vitals
- Set realistic targets
- Prioritize by impact
- Monitor continuously
- Setup performance budgets
- Test on slow networks
- Include mobile in testing
- Document improvements
❌ DON'T
- Ignore field data
- Focus on one metric only
- Set impossible targets
- Optimize without measurement
- Forget about images
- Ignore JavaScript costs
- Skip mobile performance
- Over-optimize prematurely
- Forget about monitoring
- Expect improvements without effort
Monitoring & Continuous Improvement
Monitoring & Continuous Improvement
// Setup performance monitoring
class PerformanceMonitoring {
setupMonitoring() {
return {
tools: [
"Google Analytics (Web Vitals)",
"Datadog or New Relic",
"Sentry for errors",
"Custom monitoring",
],
metrics: [
"LCP (Largest Contentful Paint)",
"FID (First Input Delay)",
"CLS (Cumulative Layout Shift)",
"FCP (First Contentful Paint)",
"TTI (Time to Interactive)",
],
frequency: "Real-time monitoring",
alerts: {
lcp_degradation: "Alert if >3 seconds",
fid_degradation: "Alert if >200ms",
cls_degradation: "Alert if >0.2",
},
};
}
defineBaselines(metrics) {
return {
baseline: {
lcp: metrics.lcp,
fid: metrics.fid,
cls: metrics.cls,
},
targets: {
lcp: metrics.lcp * 0.9, // 10% improvement
fid: metrics.fid * 0.8,
cls: metrics.cls * 0.8,
},
review_frequency: "Weekly",
improvement_tracking: "Month-over-month trends",
};
}
setupPerformanceBudget() {
return {
javascript: {
target: "150KB gzipped",
monitor: "Every build",
alert: "If exceeds 160KB",
},
css: {
target: "50KB gzipped",
monitor: "Every build",
alert: "If exceeds 55KB",
},
images: {
target: "500KB total",
monitor: "Every deployment",
alert: "If exceeds 550KB",
},
};
}
}Optimization Strategies
Optimization Strategies
Performance Optimization Roadmap:
Quick Wins (1-2 days):
- Enable gzip compression
- Minify CSS/JavaScript
- Compress images (lossless)
- Remove unused CSS
- Defer non-critical JavaScript
- Preload critical fonts
Medium Effort (1-2 weeks):
- Implement lazy loading
- Code splitting (split routes)
- Service worker for caching
- Image optimization (WebP, srcset)
- Critical CSS extraction
- HTTP/2 server push
Long-term (1-3 months):
- Migrate to faster framework
- Database query optimization
- Content delivery optimization
- Architecture refactor
- CDN implementation
- Build process optimization
---
Optimization Checklist:
Network:
[ ] Gzip compression enabled
[ ] Brotli compression enabled
[ ] HTTP/2 enabled
[ ] CDN configured
[ ] Browser caching configured
[ ] Asset fingerprinting
JavaScript:
[ ] Code split by route
[ ] Unused code removed
[ ] Minified and mangled
[ ] Source maps generated
[ ] Deferred non-critical
CSS:
[ ] Critical CSS extracted
[ ] Unused CSS removed
[ ] Minified
[ ] Preloaded fonts
[ ] WOFF2 format used
Images:
[ ] Optimized and compressed
[ ] WebP with fallback
[ ] Responsive srcset
[ ] Lazy loading
[ ] SVG where possiblePerformance Analysis Process
Performance Analysis Process
# Conduct performance audit
class PerformanceAudit:
def measure_performance(self, url):
"""Baseline measurements"""
return {
'desktop_metrics': self.run_lighthouse_desktop(url),
'mobile_metrics': self.run_lighthouse_mobile(url),
'field_data': self.get_field_data(url), # Real user data
'lab_data': self.run_synthetic_tests(url), # Lab measurements
'comparative': self.compare_to_competitors(url)
}
def identify_opportunities(self, metrics):
"""Find improvement areas"""
opportunities = []
if metrics['fcp'] > 1.8:
opportunities.append({
'issue': 'First Contentful Paint slow',
'current': metrics['fcp'],
'target': 1.8,
'impact': 'High',
'solutions': [
'Reduce CSS/JS for critical path',
'Preload critical fonts',
'Defer non-critical JavaScript'
]
})
if metrics['cls'] > 0.1:
opportunities.append({
'issue': 'Cumulative Layout Shift high',
'current': metrics['cls'],
'target': 0.1,
'impact': 'High',
'solutions': [
'Reserve space for dynamic content',
'Avoid inserting content above existing',
'Use transform for animations'
]
})
return sorted(opportunities, key=lambda x: x['impact'])
def create_audit_report(self, metrics, opportunities):
"""Generate comprehensive report"""
return {
'overall_score': self.calculate_score(metrics),
'current_metrics': metrics,
'target_metrics': self.define_targets(metrics),
'opportunities': opportunities,
'quick_wins': self.identify_quick_wins(opportunities),
'timeline': self.estimate_effort(opportunities),
'recommendations': self.prioritize_recommendations(opportunities)
}Performance Metrics
Performance Metrics
Core Web Vitals (Google):
Largest Contentful Paint (LCP):
Measure: Time to load largest visible element
Good: <2.5 seconds
Poor: >4 seconds
Impacts: User perception of speed
First Input Delay (FID):
Measure: Time from user input to response
Good: <100 milliseconds
Poor: >300 milliseconds
Impacts: Responsiveness
Cumulative Layout Shift (CLS):
Measure: Visual stability (unexpected layout shifts)
Good: <0.1
Poor: >0.25
Impacts: User frustration
---
Additional Metrics:
First Contentful Paint (FCP):
Measure: First visible content appears
Target: <1.8 seconds
Time to Interactive (TTI):
Measure: Page is fully interactive
Target: <3.8 seconds
Total Blocking Time (TBT):
Measure: JavaScript blocking time
Target: <300ms
Interaction to Next Paint (INP):
Measure: Latency of user interactions
Target: <200ms
---
Measurement Tools:
- Google PageSpeed Insights
- Lighthouse (Chrome DevTools)
- WebPageTest
- New Relic
- Datadog
- GTmetrix#!/bin/bash
# health-check.sh - Check service health
# Usage: ./health-check.sh <service_url>
set -euo pipefail
SERVICE_URL="${{1:?Usage: $0 <service_url>}}"
echo "Checking health: $SERVICE_URL"
# TODO: Implement health checks
# - HTTP endpoint check
# - Response time validation
# - Dependency health
# - Resource utilization
# - Error rate check
echo "Health check complete."
# Monitoring Dashboard Configuration
# TODO: Customize for your monitoring platform (Grafana, Datadog, etc.)
dashboard:
title: "Service Dashboard"
refresh: 30s
panels:
- title: "Request Rate"
type: graph
# TODO: Add metric query
- title: "Error Rate"
type: graph
# TODO: Add metric query
- title: "Latency (p50/p95/p99)"
type: graph
# TODO: Add metric query
alerts:
- name: "High Error Rate"
# TODO: Configure alert thresholds
Related skills
How it compares
Pick web-performance-audit for structured Core Web Vitals audits with reference playbooks instead of ad-hoc Lighthouse runs without prioritization.
FAQ
What metrics does web-performance-audit cover?
web-performance-audit covers Google Core Web Vitals—LCP, FID, CLS—and additional metrics like FCP. The skill documents good and poor thresholds and ties each metric to user-perceived speed, responsiveness, and layout stability.
When should developers run web-performance-audit?
web-performance-audit fits regular monitoring, post-release checks, mobile optimization, SEO tuning, and baseline setting. The skill recommends combining lab tests with real-user field data instead of measuring once.
What reference material ships with web-performance-audit?
web-performance-audit includes four reference guides: performance metrics, analysis process, optimization strategies, and monitoring with continuous improvement. Each guide supports structured audits and documented follow-ups.