# Synthetic Monitoring
Synthetic monitoring runs automated tests against your website from a controlled environment. VitalSentinel uses Google Lighthouse to measure performance, accessibility, best practices, and SEO.
## What is Synthetic Monitoring? [#what-is-synthetic-monitoring]
Unlike RUM, which measures real user experiences, synthetic monitoring:
* Runs in a consistent, controlled environment
* Produces reproducible results
* Tests from specific locations and device profiles
* Doesn't require any traffic to your site
Synthetic monitoring is great for catching performance regressions early, before they impact real users. Regular automated tests help you identify issues introduced by deployments or third-party changes.
## Lighthouse Metrics [#lighthouse-metrics]
Each synthetic test produces a comprehensive report:
### Performance Score (0–100) [#performance-score-0100]
Based on weighted metrics:
* First Contentful Paint (10%)
* Speed Index (10%)
* Largest Contentful Paint (25%)
* Total Blocking Time (30%)
* Cumulative Layout Shift (25%)
### Accessibility Score (0–100) [#accessibility-score-0100]
Evaluates:
* Color contrast
* ARIA labels
* Keyboard navigation
* Screen reader compatibility
### Best Practices Score (0–100) [#best-practices-score-0100]
Checks:
* HTTPS usage
* No console errors
* Correct image aspect ratios
* Valid source maps
### SEO Score (0–100) [#seo-score-0100]
Verifies:
* Meta descriptions
* Valid robots.txt
* Crawlable links
* Mobile-friendly viewport
## Core Web Vitals from Lighthouse [#core-web-vitals-from-lighthouse]
Synthetic tests also provide lab-based Core Web Vitals:
| Metric | Description |
| ------ | ----------------------------------- |
| LCP | Largest Contentful Paint |
| CLS | Cumulative Layout Shift |
| TBT | Total Blocking Time (proxy for INP) |
| TTFB | Time to First Byte |
| FCP | First Contentful Paint |
Lighthouse uses TBT (Total Blocking Time) instead of INP because INP requires real user interactions.
## Using Synthetic Monitoring [#using-synthetic-monitoring]
### Adding URLs [#adding-urls]
Navigate to your domain's **Synthetic Monitoring** section and click **Manage Pages**.
1. Enter URLs in the text area (one per line for bulk import, or a single URL)
2. Select the **Test Frequency** (Every 8 Hours, Every 12 Hours, or Daily, depending on your plan)
3. Select **Test Locations** (Google's Servers is the default)
4. Click **Add page** (or **Add pages** for multiple)
Available test frequencies and locations depend on your plan.
### Editing a URL [#editing-a-url]
After a URL is added, open it from the URL list to change:
* **Test frequency** – any frequency your plan allows
* **Test locations** – add or remove locations (at least one location is always required)
Saved changes apply to the next scheduled run.
### Test Locations [#test-locations]
Synthetic tests can run from one or more locations. Two location types are available:
**Google's Servers (Google PSI)**
* Powered by Google PageSpeed Insights infrastructure
* Available on every plan, including Free
* A good baseline that matches what Google itself sees
**Custom Pods**
* VitalSentinel-operated test agents in additional regions
* Available on paid plans only
* Use them when you need to measure performance from a specific geography (for example, testing a European site from a North American pod)
The **number of locations you can attach to a single URL** is determined by your plan. The Free plan allows one location per URL; higher tiers allow more, letting you compare results from several regions side by side.
### Viewing Results [#viewing-results]
For each URL, you'll see:
* **Latest scores** for all four categories
* **Core Web Vitals** from the most recent test
* **Historical trend** of scores over time
* **Mobile vs Desktop** comparison
### Mobile vs Desktop [#mobile-vs-desktop]
Each test runs in two configurations:
**Mobile:**
* Throttled CPU (4x slowdown)
* Throttled mobile network
* Emulated mobile viewport
**Desktop:**
* No CPU throttling
* No network throttling
* Desktop viewport (1350x940)
Device emulation and network throttling follow Google PageSpeed Insights (Lighthouse) defaults.
## Test Frequency [#test-frequency]
You can configure how often synthetic tests run for each URL. Available frequencies depend on your plan:
| Frequency | Description |
| -------------- | ----------------------------------------- |
| Every 8 hours | Most frequent testing (Advanced plan) |
| Every 12 hours | Twice daily (Standard and Advanced plans) |
| Every 24 hours | Daily testing (all plans) |
Higher-tier plans allow more frequent testing intervals. Check your plan details for available options.
## Interpreting Results [#interpreting-results]
### Score Ranges [#score-ranges]
| Score | Rating |
| ------ | -------------------------- |
| 90–100 | Good (green) |
| 50–89 | Needs Improvement (orange) |
| 0–49 | Poor (red) |
### Variability [#variability]
Synthetic tests can vary between runs due to:
* Server response time variations
* Third-party resource timing
* Dynamic content loading
A variance of 5–10 points is normal. Focus on trends rather than individual scores.
### Lab vs Field Data [#lab-vs-field-data]
Lab data (Synthetic) vs Field data (RUM/CrUX):
| Lab Data | Field Data |
| -------------------------- | -------------------- |
| Consistent environment | Real user conditions |
| Reproducible | Variable |
| Specific device simulation | Actual devices |
| Good for debugging | Good for assessment |
Use synthetic for debugging; use RUM/CrUX for Google ranking assessment.
## Detailed Reports [#detailed-reports]
Click on any test to see:
### Opportunities [#opportunities]
Suggestions to improve performance:
* Eliminate render-blocking resources
* Properly size images
* Defer offscreen images
* Minify JavaScript
### Diagnostics [#diagnostics]
Technical details about:
* Main thread work
* JavaScript execution time
* DOM size
* Network requests
### Request Waterfall [#request-waterfall]
Visual timeline of all network requests:
* Request timing
* Resource sizes
* Blocking dependencies
* Third-party resources
## Comparing Over Time [#comparing-over-time]
Track improvements:
1. View the **Trend** chart for your URL
2. Compare scores across test dates
3. Identify regressions after deployments
4. Verify improvements after optimizations
## Best Practices [#best-practices]
### What to Test [#what-to-test]
* **Homepage** – First impression for visitors
* **Key landing pages** – High-traffic entry points
* **Product pages** – Critical for e-commerce
* **Checkout flow** – Revenue-impacting pages
### When to Use Synthetic vs RUM [#when-to-use-synthetic-vs-rum]
**Use Synthetic for:**
* Debugging specific issues
* Pre-launch testing
* Comparing before/after changes
* Pages with low traffic
**Use RUM for:**
* Understanding real user experience
* Geographic performance differences
* Device-specific issues
* Google ranking assessment
## Multi-Location Testing [#multi-location-testing]
Synthetic tests can run from multiple geographic locations to show how your site performs for users in different regions.
### Available Locations [#available-locations]
Tests can run from:
| Location Type | Description |
| ------------- | ------------------------------------------ |
| Google PSI | Google's PageSpeed Insights infrastructure |
| Custom Pods | Additional testing locations (paid plans) |
### Viewing Location Data [#viewing-location-data]
1. Navigate to **Synthetic** for your domain
2. Use the location filter tabs to switch between locations
3. Compare metrics across different testing locations
### Use Cases [#use-cases]
* **Global websites** - Ensure performance for international visitors
* **CDN verification** - Confirm CDN is serving content correctly
* **Regional issues** - Identify location-specific problems
* **Edge caching** - Verify cache behavior across regions
Multi-location testing availability depends on your plan. Higher-tier plans include more testing locations.
## Related Features [#related-features]
Real user performance data
Google's view of your performance
Availability and response time