SiteVerdict: Core Web Vitals, Speed & Revenue Scanner

Find out exactly what makes a site slow, which element to fix, what each tag costs, and roughly what slowness costs in revenue, in about 35–45 seconds per site.

PageSpeed tells you a score. SiteVerdict tells you what to do on Monday morning:

• Which element is your LCP, with a screenshot, and why it is late: TTFB, late discovery, download or render delay.
• Which elements jump around, with close-up screenshots and a likely cause.
• How fast the page reacts to taps. We tap real menus and buttons and time them: a lab INP proxy.
• Which "buttons" do nothing. Every suspected dead click is clicked in a sandbox and kept only if nothing happens.
• Which third-party tags block the main thread, and for how many milliseconds each.
• A fix list ranked by impact ÷ effort, with the estimated LCP saving and revenue per fix.
• Optional extras: real-user data (CrUX), you vs 5 competitors, daily monitoring with Slack alerts, a white-label PDF, and AI-written code fixes using your own key.

It uses Lighthouse's scoring curves and PageSpeed's throttling constants, and it is benchmarked against Lighthouse; see the benchmark for where the numbers agree and where they don't.

---

Three ways people use it

1. Agencies: win the pitch and the retainer.

• Scan the prospect and up to 5 of their competitors in one run.
• Send a white-label PDF that says "you're #4 of 6 on mobile speed, here are the 5 fixes, ≈£2,300/month at stake (estimate)".
• Then schedule it daily with Slack alerts so you catch regressions before the client does.

2. E-commerce owners: know which fix pays first.

• Add your monthly visitors, conversion rate and order value.
• Every fix gets an effort rating and, where it affects LCP, an estimated monthly gain.
• The method and its sources are printed under every estimate.

3. CRO and dev teams: catch UX killers before release.

• Get verified dead clicks, slow taps (with the script responsible) and layout-shift culprits with screenshots.
• Run it after each deploy with monitoringMode so you only hear about changes.

---

Before / after: what you get

A typical PageSpeed wrapper gives you:

{ "url": "https://shop.example", "performance": 41, "LCP": 4800, "CLS": 0.21, "TBT": 760 }

SiteVerdict gives you (real output, trimmed, from the benchmark run on https://wordpress.org/ with the default Slow 4G profile, 11 Oct 2026):

{
  "url": "https://wordpress.org/",
  "scores": { "overall": 89, "performance": 76, "ux": 100, "seo": 100 },
  "summary": "Overall 89/100 (performance 76, UX 100, SEO 100). Mobile LCP 3.81 s, CLS 0.017, tap response 144 ms, 0 dead click(s). Best first fix: Third-party tags block the main thread for ≈597 ms on mobile (top: Google Tag Manager) (medium effort).",
  "devices": { "mobile": {
    "lcpMs": 3808, "cls": 0.0168, "tbtMs": 590, "inpProxyMs": 144,
    "lcpElement": { "tag": "img", "selector": "figure.wp-block-image.size-full > img.wp-image-48979", "url": "https://i0.wp.com/wordpress.org/files/2025/12/wporg-69-design.png?w=720&ssl=1", "fetchpriority": null, "preloaded": false },
    "lcpPhases": { "ttfbMs": 591, "loadDelayMs": 417, "loadDurationMs": 729, "renderDelayMs": 2071, "bottleneck": "render-delay" },
    "interactions": [{ "kind": "button", "text": "Open menu", "latencyMs": 144, "inputDelayMs": 35, "processingMs": 86, "presentationMs": 23,
                       "scripts": [{ "entity": "First party (wordpress.org)", "durationMs": 78 }, { "entity": "Google Tag Manager", "durationMs": 5 }] }]
  } },
  "thirdPartyBreakdown": [{ "entity": "Google Tag Manager", "category": "tag-manager", "blockingMs": 597, "scriptMs": 754, "requests": 2, "transferBytes": 331410,
                            "topScripts": [{ "url": "https://www.googletagmanager.com/gtag/js?id=G-...", "scriptMs": 505 }] }],
  "topFixes": [
    { "id": "third-party-cost", "title": "Third-party tags block the main thread for ≈597 ms on mobile (top: Google Tag Manager)", "effort": "medium", "impact": 5.1, "priorityScore": 2.55 },
    { "id": "lcp-not-prioritised", "title": "The LCP image starts downloading 417 ms after the HTML arrives", "effort": "low", "impact": 1.6, "estLcpSavingsMs": 250,
      "fix": "Add fetchpriority=\"high\" to the LCP <img> (or <link rel=\"preload\" as=\"image\" fetchpriority=\"high\">)..." }
  ],
  "elementScreenshots": [{ "role": "lcp", "key": "shot-wordpress-org-lcp-0" }, { "role": "layout-shift", "key": "shot-wordpress-org-layout-shift-1" }]
}

Add monthlyVisitors, conversionRatePct and averageOrderValue and each LCP fix also gets estMonthlyRevenueGain, plus a site-level revenueImpact block labelled "ESTIMATE - not a guarantee" with its assumptions and dated sources. The full item is in docs/sample-output.json.

In the key-value store you also get:

• an HTML report (REPORT)
• optional PDFs (REPORT-<site>.pdf)
• COMPARISON
• an agent-ready SUMMARY
• per-site EVIDENCE-<site> packs
• all screenshots

---

Benchmark vs Lighthouse / PageSpeed

Measured 11 Oct 2026 against Lighthouse 12.8.2 (the engine behind PageSpeed Insights), run locally on the same Chromium. The run was partial: 13–14 of 27 public sites are complete, because heavy jobs were paused while the shared server was overloaded. Full tables are in BENCHMARK.md.

What we checked (mobile unless noted)	Result
Same LCP element as Lighthouse	92% of 12 sites
Desktop LCP / FCP / CLS in the same Google rating bucket	93% / all / all of the 13–14 completed sites (small, partial sample)
Mobile performance score: rank correlation with Lighthouse (Spearman ρ)	0.71
Mobile TBT: rank correlation	0.64
Wall time per URL, both devices	35 s for everything on this page vs 40 s for Lighthouse's performance audit only
Extras Lighthouse wrappers don't output	LCP screenshot on 13/13 sites, shift-culprit screenshots on 10, tap-test INP proxy on 12

Honest caveat. On mobile, Lighthouse/PageSpeed simulate a slow phone. Their absolute numbers come out higher than real, applied throttling: median LCP 5.3 s vs our 2.8 s. On an overloaded machine Lighthouse's simulated TBT also balloons (166 s on one site). So mobile ranks agree better than mobile buckets (31% same LCP bucket). Real-user CrUX data, which Google ranks on, is one input away (googleApiKey).

Method: Lighthouse runs back to back with SiteVerdict for each site; full method and per-site numbers in BENCHMARK.md.

Feature comparison (top Apify Store tools for "lighthouse / pagespeed / core web vitals", Oct 2026)

	SiteVerdict	Lighthouse wrappers (e.g. lighthouse-auditor, website-speed-checker)	PSI API wrappers (e.g. page-speed-analyzer)
Mobile + desktop in one result	✅	✅ / one per run	one device per report
LCP element + LCP breakdown	✅ with screenshot	in the raw report only	in the raw report only
Layout-shift culprits	✅ with screenshots + likely cause	❌	❌
Tap-response test (INP proxy)	✅	❌ (lab has no INP)	❌
Dead clicks, verified by clicking	✅	❌	❌
Third-party cost per vendor (ms)	✅	❌	❌
Real-user CrUX data	✅ (your key)	❌	some
You vs 5 competitors table	✅	❌	❌
Monitoring + Slack/webhook alerts	✅	✅ (lighthouse-auditor)	❌
White-label PDF	✅	❌	❌
AI code fixes (your key)	✅	❌	❌
Revenue estimate with sources	✅ (labelled estimate)	❌	❌
Needs Google PSI quota	no	no	yes

---

Pricing (pay per event)

Event	Price
Page scanned (mobile + desktop, everything above)	$0.04 per page
Extra lab run (each extra load when "runs per device" is above 1)	$0.01
Field data: real-user CrUX data returned (your Google key)	$0.005 per site
Competitor comparison	$0.05 per run
PDF report	$0.10 per site
AI fix pack (your LLM key returned usable fixes)	$0.05 per site
Regression alert delivered to Slack and/or a webhook	$0.01

Examples:

• 100 sites (home page each): 100 × $0.04 = $4.
• 100 sites with a PDF each: 100 × ($0.04 + $0.10) = $14.
• You vs 5 competitors: 6 × $0.04 + $0.05 = $0.29.
• 20 client sites monitored daily for 30 days with 3 runs per device: 600 × ($0.04 + 4 × $0.01) + about 10 alerts × $0.01 = about $48/month.

Nothing is charged for failed pages, robots-blocked pages, undelivered alerts or empty AI answers. Set "Max total charge" on the run to cap spend.

These are the prices configured on the Actor (checked 15 Oct 2026). The Actor's pricing tab is always the authoritative source.

---

Input examples

Audit a site and get the money estimate

{ "startUrls": [{ "url": "https://www.example-shop.co.uk" }], "monthlyVisitors": 80000, "conversionRatePct": 1.8, "averageOrderValue": 65, "currency": "GBP" }

You vs competitors, with a white-label PDF

{ "startUrls": [{ "url": "https://client.com" }], "competitorUrls": [{ "url": "https://rival-a.com" }, { "url": "https://rival-b.com" }],
  "pdfReport": true, "agencyName": "Northwind Digital", "agencyLogoUrl": "https://northwind.example/logo.png" }

Daily monitoring with Slack alerts (schedule the Actor in Apify)

{ "startUrls": [{ "url": "https://client.com" }, { "url": "https://client.com/pricing" }], "monitoringMode": true, "monitorName": "client-daily",
  "runsPerDevice": 3, "onlyChanged": true, "slackWebhookUrl": "https://hooks.slack.com/services/..." }

Real-user data + AI fixes (both keys are yours, stored as secrets)

{ "startUrls": [{ "url": "https://example.com" }], "googleApiKey": "AIza...", "aiProvider": "anthropic", "aiApiKey": "sk-ant-..." }

---

How it works

1. Real Chrome. Each page loads on a 390×844 phone (touch, 4× CPU, Slow 4G by default: the PageSpeed profile) and on a 1366×768 desktop.
2. Lab metrics. LCP, CLS (session windows), TBT, FCP and TTFB come from Chrome's own performance APIs and are scored on Lighthouse's curves. Three to five runs per device give medians.
3. Element evidence. The LCP element and the top layout-shift nodes are marked, outlined and photographed. LCP is split into its four phases.
4. Tap test. Up to 6 safe elements are tapped under CPU throttling and timed with the Event Timing API. Scripts are attributed with the Long Animation Frames API.
5. Click sandbox. During the tap test and the dead-click checks, main-frame navigation and every non-GET request (forms, carts, APIs) are blocked. Pop-ups are closed and dialogs dismissed. We never click anything that reads buy, add to cart, checkout, pay, submit, sign in, register, book, accept or consent.
6. Third parties. Network bytes and long-frame script time are grouped by vendor (about 80 known vendors, the rest by domain).
7. Fix list. Each finding has an impact (score points), an effort rating and, where it can be reasoned about, an LCP saving and a revenue estimate.

---

FAQ

Why are my numbers different from PageSpeed Insights? Several reasons:

• Throttling method. Lab tests vary run to run. PageSpeed simulates throttling, while we apply real network and CPU throttling.
• Location. PSI runs from Google's data centres.
• What to rely on. Our benchmark shows how closely we track PageSpeed. For decisions, use runsPerDevice: 3 and add your Google key for real-user (CrUX) data, which is what Google ranks on.

Is the revenue figure real? It is an estimate, and every result is labelled that way.

• Method: each second of mobile LCP above 2.5 s is assumed to cost 4.42% of conversions (Portent 2019, 100M+ page views), capped at 5 s and compounded per second.
• Basis: real-user LCP is used when you supply a Google key.
• Sources: larger effects reported by Deloitte/Google 2020 and by the web.dev Vodafone case study are cited but not used.
• Validation: check it with an A/B test.

Is clicking on my site safe?

• Navigation and all non-GET requests are blocked during the click tests, so no form is posted and nothing is added to a basket.
• Risky-looking buttons are never clicked.
• You can turn off testInteractions and verifyDeadClicks.

What is the INP proxy? INP is measured from real users' interactions. In the lab we tap a few menus and buttons and time the next paint, the same measurement Chrome uses. Because we only try a few safe taps, it is a lower bound. Real-user INP comes from CrUX (Google key).

Do you need my Google or LLM keys? No, both are optional and stored as secrets. They are never logged or written to the output. The CrUX API is free; enable "Chrome UX Report API" in Google Cloud.

Can I white-label the report? Yes: set agencyName, agencyLogoUrl and reportAccentColor. The PDF footer then says "Generated by SiteVerdict for

Does it work behind logins or on staging? Only on publicly reachable pages. It does not log in or bypass bot protection. If a site blocks automated browsers, the result says so.

---

Limits

• Lab numbers vary. Expect ±10–20% run to run. Use 3 runs per device for monitoring.
• The INP proxy is a lower bound. It covers up to 6 safe interactions per device.
• CrUX needs traffic. Small sites often have no real-user data; we fall back from URL to origin level and say so.
• Third-party cost counts long frames only. It covers script time inside long animation frames (>50 ms), which is what blocks users. Short scripts are not counted.
• Some things are heuristics. The layout-shift "likely cause" and the effort ratings are labelled as such.
• Pages per run. Up to 10 internal pages per site and 5 competitors per run.

Compliance and sources

• Respectful crawling:
  • Loads only public pages, like a browser.
  • Respects robots.txt for start URLs and internal pages (it can be turned off only for sites you own or are authorised to test).
  • Identifies itself with a SiteVerdict-SpeedScanner user-agent token.
  • Never bypasses CAPTCHAs, logins or bot protection.
  • No proxy rotation by default.
• No personal data is collected. Screenshots show the public page as any visitor would see it.
• Real-user data: Chrome UX Report API (Google), via your own key, with the collection period shown on every result.
• Revenue sources are cited with dates and links in every result:
  • Portent 2019 (archived) and 2022
  • Deloitte & Google "Milliseconds Make Millions" 2020
  • web.dev Vodafone case study
  • web.dev Web Vitals thresholds
• Lighthouse: scoring curves follow Lighthouse's published control points. Lighthouse is Apache-2.0 and is not bundled in this Actor.
• Not legal or financial advice. The revenue estimate is indicative only.
• Where results are stored: the default dataset and key-value store of the run (results, screenshots, HTML/PDF reports), inside your own Apify account. These default storages are unnamed. How long Apify keeps them is set by Apify and your plan, not by SiteVerdict (Apify data retention); you can delete them sooner in Apify Console.
• Monitoring (off by default): when you turn it on, each site's previous scores and finding IDs are kept in a named key-value store in your account called siteverdict-speed-<your monitor name>. Apify keeps named stores until you delete them.
• Third parties you choose: real-user data comes from Google's Chrome UX Report API with your own key (Google receives the URLs/origins queried). The optional AI fix pack sends the page URL, detected platform, the trimmed <head> and the findings to Anthropic or OpenAI under your own key and their terms. Alerts go only to the Slack/webhook URLs you enter.
• What SiteVerdict keeps: nothing. The Actor runs in your Apify account and sends no data to SiteVerdict.
• Contact: Use the Issues tab on this Actor's Store page.