Documentation
Complete guide to setting up website monitoring with PingZen. API documentation, code examples, and best practices.
Monitor website performance with Google PageSpeed Insights (Lighthouse). PingZen calls the PageSpeed API on a schedule and tracks Performance, Accessibility, SEO, and Best Practices scores along with Core Web Vitals (LCP, FCP, TBT, CLS, Speed Index).
What It Is For
Regressions after a deploy
A new library, an unoptimised image, a third-party script someone added in the tag manager. The score drops quietly — the site still works, it is just slower. A threshold with an alert catches that the same day instead of a quarter later.
The Core Web Vitals Google ranks on
LCP, FCP, TBT, CLS and Speed Index come back with every check, so you see not only the score but which metric spoiled it.
Mobile and desktop are two different stories
The same URL on the mobile strategy is almost always noticeably slower. Run a monitor for each and compare them over time instead of guessing from one number.
Accessibility and SEO next to performance
Lighthouse computes four categories in one run and PingZen stores all four, so a broken alt text or a missing meta tag shows up in the same place as the speed.
What It Is Not For
PageSpeed runs a Lighthouse audit on a schedule. It is a quality signal, not an uptime signal:
| You want to know | Use instead |
|---|---|
| Is the site up right now? | An HTTP monitor. PageSpeed runs rarely and is the wrong tool for detecting an outage |
| How fast is the site for my real visitors? | This is a lab test from one place with fixed settings, not real-user monitoring |
| How long does my backend take to answer? | The response time on an HTTP monitor measures that directly |
| Does a multi-step flow still work? | Transaction monitor |
How It Works
- PingZen sends your URL to the Google PageSpeed Insights API v5
- Google runs a full Lighthouse audit (mobile or desktop strategy)
- PingZen receives scores (0-100) for Performance, Accessibility, SEO, and Best Practices
- Core Web Vitals are extracted: LCP, FCP, TBT, CLS, Speed Index
- If the Performance score is below your threshold, the monitor status is set to DEGRADED
Core Web Vitals
Google’s Core Web Vitals measure real-world user experience:
LCP (Largest Contentful Paint)
Time until the largest content element is visible. Good: < 2.5s, Needs improvement: 2.5-4s, Poor: > 4s.
FCP (First Contentful Paint)
Time until the first text or image is rendered. Good: < 1.8s, Needs improvement: 1.8-3s, Poor: > 3s.
TBT (Total Blocking Time)
Total time the main thread was blocked after FCP. Good: < 200ms, Needs improvement: 200-600ms, Poor: > 600ms.
CLS (Cumulative Layout Shift)
Visual stability score. Measures unexpected layout shifts. Good: < 0.1, Needs improvement: 0.1-0.25, Poor: > 0.25.
Speed Index
How quickly the page contents are visually populated. Good: < 3.4s, Needs improvement: 3.4-5.8s, Poor: > 5.8s.
Lighthouse Scores
Each audit category receives a score from 0 to 100:
Performance (0-100)
Weighted combination of Core Web Vitals and other performance metrics. Used for threshold alerting.
Accessibility (0-100)
WCAG compliance: contrast, ARIA, labels, keyboard navigation, semantic HTML.
SEO (0-100)
Meta tags, crawlability, mobile-friendliness, structured data, canonical URLs.
Best Practices (0-100)
HTTPS, no mixed content, modern APIs, no deprecated libraries, CSP headers.
Configuration
URL
The page URL to analyze. Must be publicly accessible. HTTPS recommended.
Strategy
Choose Mobile or Desktop. Mobile uses throttled network and CPU to simulate a mid-tier phone. Desktop uses unthrottled settings.
Performance Threshold
Performance score threshold (0-100). If the score drops below this value, the monitor status changes to DEGRADED and alerts are triggered. Default: 50.
Status Logic
Monitor status is determined by the Performance score and your threshold:
| Status | Condition |
|---|---|
| UP | Performance score >= threshold |
| DEGRADED | Performance score < threshold |
| DOWN | API error, invalid URL, or quota exceeded |
Key Features
- Google Lighthouse engine — same scores as Chrome DevTools
- Core Web Vitals: LCP, FCP, TBT, CLS, Speed Index
- 4 audit categories: Performance, Accessibility, SEO, Best Practices
- Mobile and Desktop strategies
- Configurable performance threshold for DEGRADED alerts
- Automatic retry with exponential backoff on rate limits (429)
- Free tier: 25,000 API calls/day
Common Questions
What protocols can I monitor?
PingZen supports 23 protocols: HTTP/HTTPS, WebSocket (WS/WSS), TCP, UDP, ICMP Ping, gRPC, DNS, WHOIS, TLS/SSL certificates, Email (SMTP/IMAP/POP3), FTP/FTPS, DNSBL, PageSpeed, SOCKS5, MTProxy, API Check, and Transaction. You can monitor websites, APIs, servers, databases, and any network service.
How fast can I get alerts?
Telegram alerts are delivered within 1-2 seconds of detection. Slack and Discord notifications arrive almost instantly. You can configure multiple alert channels for redundancy.
Can I organize monitors by project?
Yes! PingZen supports workspaces, which let you organize monitors by project, environment, or team. Each workspace can have its own alert configurations and team members.
Is there an API for automation?
Absolutely. PingZen provides a full REST API with OpenAPI documentation. You can create, update, and delete monitors programmatically.
How do status pages work?
Status pages are public, branded pages showing your services' uptime. You can display real-time status and allow customers to subscribe for updates.
What happens if I reach my monitor limit?
We'll notify you when approaching your limit. You can pause some monitors or contact us for increased capacity. We never stop monitoring without warning, ensuring your critical services stay protected.
Ready to stop missing downtime?
Join thousands of teams who trust PingZen. Setup takes 30 seconds.