Lighthouse Auditor

Run Google Lighthouse audits on any URL and get performance, accessibility, SEO, and best practices scores with Core Web Vitals metrics.

What does Lighthouse Auditor do?

This Actor runs Google Lighthouse audits programmatically via Apify. It launches a real Chrome browser, navigates to your target URL, and returns detailed scores and metrics — the same data you'd get from Chrome DevTools, but automated and at scale.

Key capabilities:

• Performance scores (0-100) for each audit category
• Core Web Vitals — LCP, FCP, TBT, CLS, TTI, SI with good/needs-improvement/poor ratings
• Failing audits — top 10 worst-scoring audits so you know what to fix
• Optimization opportunities — potential time and byte savings, sorted by impact
• Mobile and desktop device emulation
• Configurable throttling — simulated, DevTools, or none
• Optional HTML reports saved to key-value store

Why use this Actor?

Use Case	How It Helps
SEO Monitoring	Track SEO scores across all your sites on a schedule
Performance Budgets	Alert when scores drop below your thresholds
Competitor Analysis	Compare your Core Web Vitals vs competitors
CI/CD Integration	Block deployments if Lighthouse scores fail
Client Reporting	Generate automated audit reports for clients
Bulk Auditing	Audit many URLs by scheduling one run per URL
Regression Monitoring	Persist scores per URL and alert on drops (built-in monitoring mode)

How much does it cost to run?

Cost depends on your Apify plan and on how heavy each audit is:

• Page complexity (more resources = longer audit)
• Number of categories selected
• Whether the HTML report is saved
• Throttling mode (devtools is slower than simulated)

Each run audits a single URL. Check the compute usage shown on a completed run to gauge your own per-audit cost, and consult the Apify pricing page for current rates.

Input

Field	Type	Required	Default	Description
url	String	Yes	—	The URL to audit (https:// is added automatically if missing)
device	String	No	mobile	Device to emulate: mobile or desktop
categories	Array	No	All	Which categories to audit. Options: performance, accessibility, best-practices, seo
saveHtmlReport	Boolean	No	false	Save the full HTML Lighthouse report to key-value store
throttling	String	No	simulated	Network throttling preset: simulated (fast), devtools (accurate), or none (full speed)
monitoringMode	Boolean	No	false	Persist scores per URL and detect regressions vs the prior run
regressionThreshold	Integer	No	5	Point drop (1–50) in any category that triggers a regression alert
alertWebhookUrl	String	No	—	Optional URL to POST a JSON alert to when a regression exceeds the threshold (Slack, Discord, Zapier, custom)

Input example

{
    "url": "https://example.com",
    "device": "mobile",
    "categories": ["performance", "seo"],
    "saveHtmlReport": true,
    "throttling": "simulated"
}

Output

Results are saved to the default dataset with scores (0-100) and Core Web Vitals metrics.

Output fields

Field	Type	Description
url	String	The final URL after redirects
requestedUrl	String	The original URL requested
device	String	Device type used for the audit
timestamp	String	ISO timestamp of the audit
performance	Number	Performance score (0-100)
accessibility	Number	Accessibility score (0-100)
bestPractices	Number	Best Practices score (0-100)
seo	Number	SEO score (0-100)
coreWebVitals	Object	Core Web Vitals metrics with ratings (see below)
failingAudits	Array	Top 10 worst-scoring audits (score < 50), sorted worst first
opportunities	Array	Top 10 optimization opportunities, sorted by potential time savings
lighthouseVersion	String	Version of Lighthouse used
fetchTime	String	Lighthouse fetch time for the run
userAgent	String	User agent used to load the page
throttling	String	Throttling preset used
categories	Array	Lighthouse categories that were run
htmlReportKey	String	Key-value store key for HTML report (when saveHtmlReport is true)
htmlReportUrl	String	Direct URL to the HTML report (when saveHtmlReport is true)
regression	Object	Score deltas vs the prior run and any threshold breaches (when monitoringMode is true and a prior run exists)
error	Boolean	Present and true on an error row when the audit failed
errorMessage	String	Error detail on an error row when the audit failed

If an audit fails (unreachable site, Lighthouse error, Chrome launch failure), the run still succeeds and the dataset contains a single error row (error: true, errorMessage, timestamp) instead of scores.

Output example

{
    "url": "https://example.com/",
    "requestedUrl": "https://example.com",
    "device": "mobile",
    "timestamp": "2025-01-15T10:30:00.000Z",
    "performance": 85,
    "accessibility": 92,
    "bestPractices": 100,
    "seo": 90,
    "coreWebVitals": {
        "FCP": 1200,
        "FCP_rating": "good",
        "LCP": 2500,
        "LCP_rating": "good",
        "TBT": 150,
        "TBT_rating": "good",
        "CLS": 0.1,
        "CLS_rating": "good",
        "SI": 3200,
        "SI_rating": "good",
        "TTI": 3800,
        "TTI_rating": "good"
    },
    "failingAudits": [
        {
            "id": "render-blocking-resources",
            "title": "Eliminate render-blocking resources",
            "score": 0,
            "displayValue": "Potential savings of 1,230 ms",
            "description": "Resources are blocking the first paint of your page."
        }
    ],
    "opportunities": [
        {
            "id": "unused-javascript",
            "title": "Reduce unused JavaScript",
            "savingsMs": 1200,
            "savingsBytes": 245760,
            "displayValue": "Potential savings of 240 KiB"
        }
    ],
    "lighthouseVersion": "12.x.x",
    "throttling": "simulated"
}

Core Web Vitals reference

Core Web Vitals are Google's key metrics for page experience. Here's how to interpret the values:

Metric	Full Name	Good	Needs Work	Poor	Unit
LCP	Largest Contentful Paint	≤2500	≤4000	>4000	ms
FCP	First Contentful Paint	≤1800	≤3000	>3000	ms
TBT	Total Blocking Time	≤200	≤600	>600	ms
CLS	Cumulative Layout Shift	≤0.1	≤0.25	>0.25	score
SI	Speed Index	≤3400	≤5800	>5800	ms
TTI	Time to Interactive	≤3800	≤7300	>7300	ms

Throttling options explained

Option	Speed	Accuracy	Use Case
simulated	Fast	Good	Quick audits, bulk testing
devtools	Slow	Excellent	Accurate performance data
none	Fastest	Variable	When you only need scores, not timing

Recommendation: Use simulated for most cases. Use devtools when you need accurate Core Web Vitals for performance debugging.

Integrations

Schedule regular audits

Use Apify Scheduler to run audits daily, weekly, or hourly. Track scores over time by exporting to a database.

Send alerts

Connect to Zapier or Make to send Slack/email alerts when scores drop below thresholds.

CI/CD pipelines

Call this Actor from GitHub Actions, GitLab CI, or Jenkins to gate deployments on Lighthouse scores.

Example: GitHub Actions

- name: Run Lighthouse Audit
  run: |
    curl -X POST "https://api.apify.com/v2/acts/YOUR_ACTOR/runs?token=${{ secrets.APIFY_TOKEN }}" \
      -d '{"url": "${{ github.event.deployment.url }}", "device": "mobile"}'

Regression monitoring (v2.2)

Set monitoringMode: true to turn the Actor into a scheduled site-health guard. On each run it:

1. Saves the four category scores for the URL to the key-value store (keyed by URL).
2. On the next run, compares the new scores against the saved baseline.
3. Flags any category that dropped by at least regressionThreshold points (default 5).
4. If alertWebhookUrl is set, POSTs a JSON alert to it when a regression exceeds the threshold.

The dataset row includes a regression object with the per-category deltas and the list of threshold breaches. The first run for a URL just stores a baseline (no alert). Schedule the Actor per URL to track drift over time.

FAQ

Do I need an API key or a Google account? No. The Actor runs a real headless Chrome on Apify and uses the open-source Lighthouse engine — there's nothing to configure.

How is this different from PageSpeed Insights? It runs the same Lighthouse engine, but automated and at scale: schedule it, audit many URLs, export the raw scores/metrics to a dataset, and wire it into CI/CD or alerts.

Can I audit many URLs at once? Each run audits one URL. To cover many, trigger the Actor once per URL (e.g. from a loop or several scheduled tasks) and combine the datasets.

Mobile or desktop scores? Set device to mobile (default) or desktop. Mobile is the stricter, Google-default profile.

Which throttling setting should I use? simulated (fast) for most monitoring and bulk runs; devtools for the most accurate Core Web Vitals when you're debugging performance; none when you only need scores, not timings.

Why do scores vary slightly between runs? Lighthouse lab data has natural run-to-run variance (network, CPU contention). For trend tracking, schedule regular runs and compare moving averages, or use devtools throttling for steadier numbers.

How do I get the full HTML report? Set saveHtmlReport: true — the report is saved to the key-value store and the dataset row includes htmlReportKey / htmlReportUrl.

Can I gate deployments on the scores? Yes — call the Actor from GitHub Actions / GitLab CI / Jenkins (see the Integrations example) and fail the build when a category drops below your threshold.

Limitations

• Single page per run. Each run audits exactly one URL — it does not crawl the site. For bulk audits, run the Actor once per URL (e.g. from a loop or several scheduled tasks) and combine the datasets.
• Lab data, not field data. Results come from a single headless Chrome run in the Apify cloud, so scores have natural run-to-run variance and do not reflect real-user (CrUX) data.
• Cold start. The first audit in a run includes browser launch time, so a single audit typically takes tens of seconds to a couple of minutes depending on page weight and throttling.
• Per-attempt timeout. The Lighthouse step is capped at 3 minutes per attempt and retries up to 3 times; very slow pages may exhaust the retries and produce an error row.
• Bot protection. Some sites block or challenge headless Chrome (CAPTCHAs, WAFs, geo-blocks), which can skew or fail the audit.
• JS-heavy / auth-gated pages. Single-page apps that render slowly, or pages behind logins, may score lower or fail — the Actor does not perform authentication.
• Mobile is the default profile. Mobile emulation (Google's stricter default) is used unless you set device: desktop; the two profiles are not directly comparable.
• Monitoring baseline is per key-value store. Regression monitoring compares against the baseline stored in the run's key-value store, so use a named/persistent store (or scheduled task) to retain history across runs.

Changelog

• v2.2 — Added regression monitoring mode (per-URL score baselines, threshold alerts, optional webhook); audit failures now record an error row instead of failing the whole run
• v2.1 — Added failing audits, optimization opportunities, CWV ratings, fixed HTML report as single dataset row
• v2.0 — Updated for Lighthouse 12, removed PWA category, improved stability
• v1.0 — Initial release with full Lighthouse 11 support

Support

Questions or issues? Contact the developer or open an issue on the Actor's page.

---

Built by Jaclyn