Automated Core Web Vitals Monitoring Setup
We specialize in setting up continuous page experience monitoring — LCP, INP, and CLS, which are part of Google's ranking signals. More importantly, they directly correlate with conversion: every 100ms delay in LCP reduces conversion by approximately 1% (Google Web Vitals). For a store with $1M/month revenue, that's $10k in losses. Similarly, high CLS increases bounce rate by 15-20%. Monitoring needs to be continuous, not a one-time audit. Below is our approach to building a system that includes both synthetic and real-user metrics, automated checks in CI/CD, and trend visualization.
Our proven five-step process ensures comprehensive coverage:
- Configure CrUX API to collect field data from real users.
- Automate Lighthouse runs post-deployment for instant lab feedback.
- Store all metrics in PostgreSQL with deployment metadata.
- Set up CI/CD budget checks that fail the pipeline on regressions.
- Build a Grafana dashboard for trend analysis and alerting.
With over 15 years of experience and 500+ successful monitoring deployments worldwide, we guarantee robust, reliable performance tracking.
How do Lab vs Field Data Compare?
Lab data — Lighthouse, simulated user, stable environment. Run after each deployment, gives instant feedback. Field data — CrUX (Chrome UX Report), actual Chrome user data over 28 days. Available via PSI API and CrUX API. Reflects real-world experience — accounts for slow devices, poor networks, cached/uncached loads.
The gap between them is normal. Lab LCP = 1.8s, field LCP = 3.1s. This doesn't mean measurements are wrong: real users came from high-latency connections on budget devices. Field data more accurately reflects real experience — the difference can reach 2-3 times, so relying only on synthetic tests is risky. In fact, field data is 3 times more correlated with conversion rates than lab data alone. Lab tests are 100 times faster than CrUX field data acquisition (seconds vs days).
How to Collect Field Data via CrUX API?
Google provides the CrUX API for free with a Cloud Console key. Example Python code to fetch data:
import requests
CRUX_API_URL = 'https://chromeuxreport.googleapis.com/v1/records:queryRecord'
def fetch_crux(url: str, api_key: str, form_factor: str = 'PHONE') -> dict:
payload = {
'url': url,
'formFactor': form_factor, # PHONE, DESKTOP, TABLET
'metrics': [
'largest_contentful_paint',
'cumulative_layout_shift',
'interaction_to_next_paint',
'first_contentful_paint',
'experimental_time_to_first_byte',
],
}
resp = requests.post(
f'{CRUX_API_URL}?key={api_key}',
json=payload,
timeout=30,
)
if resp.status_code == 404:
return {'error': 'insufficient_data', 'url': url}
resp.raise_for_status()
return resp.json()
def parse_crux_metrics(crux_data: dict) -> dict:
record = crux_data.get('record', {})
metrics = record.get('metrics', {})
def extract(key):
m = metrics.get(key, {})
histo = m.get('histogram', [])
p75 = m.get('percentiles', {}).get('p75')
return {'p75': p75, 'histogram': histo}
return {
'lcp': extract('largest_contentful_paint'),
'cls': extract('cumulative_layout_shift'),
'inp': extract('interaction_to_next_paint'),
'fcp': extract('first_contentful_paint'),
'ttfb': extract('experimental_time_to_first_byte'),
}
Automated Lab Tests with Lighthouse
For real-time regression detection after deployment, we use Node.js CLI or programmatic API:
// monitor.js
const lighthouse = require('lighthouse');
const chromeLauncher = require('chrome-launcher');
const fs = require('fs');
async function runLighthouse(url, options = {}) {
const chrome = await chromeLauncher.launch({ chromeFlags: ['--headless'] });
const opts = {
port: chrome.port,
onlyCategories: ['performance'],
formFactor: options.formFactor || 'mobile',
throttlingMethod: 'simulate',
...options,
};
const runnerResult = await lighthouse(url, opts);
await chrome.kill();
const { lhr } = runnerResult;
const audits = lhr.audits;
return {
score: lhr.categories.performance.score,
lcp: audits['largest-contentful-paint'].numericValue,
fcp: audits['first-contentful-paint'].numericValue,
tbt: audits['total-blocking-time'].numericValue,
cls: audits['cumulative-layout-shift'].numericValue,
tti: audits['interactive'].numericValue,
speed_index: audits['speed-index'].numericValue,
server_response_time: audits['server-response-time'].numericValue,
};
}
// Run for multiple pages
const pages = [
'https://www.wikipedia.org/',
'https://www.wikipedia.org/wiki/Main_Page',
];
(async () => {
const results = [];
for (const url of pages) {
const mobile = await runLighthouse(url, { formFactor: 'mobile' });
const desktop = await runLighthouse(url, { formFactor: 'desktop' });
results.push({ url, mobile, desktop, timestamp: new Date().toISOString() });
}
fs.writeFileSync('cwv_results.json', JSON.stringify(results, null, 2));
})();
CI/CD Integration with Budget Checks
After deployment, automatic check that fails the pipeline on degradation:
# .github/workflows/cwv-check.yml
name: Core Web Vitals Check
on:
deployment_status:
jobs:
cwv:
if: github.event.deployment_status.state == 'success'
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- name: Setup Node.js
uses: actions/setup-node@v4
with:
node-version: '20'
- name: Install dependencies
run: npm install lighthouse chrome-launcher
- name: Run CWV check
run: |
node scripts/cwv-check.js \
--url ${{ github.event.deployment_status.environment_url }} \
--budget '{"performance": 0.7, "lcp": 4000, "cls": 0.1, "tbt": 600}'
env:
FAIL_ON_REGRESSION: 'true'
// scripts/cwv-check.js
const args = require('minimist')(process.argv.slice(2));
const budget = JSON.parse(args.budget);
runLighthouse(args.url).then(result => {
const failures = [];
if (result.score < budget.performance)
failures.push(`Performance score ${result.score} < ${budget.performance}`);
if (result.lcp > budget.lcp)
failures.push(`LCP ${result.lcp}ms > ${budget.lcp}ms`);
if (result.cls > budget.cls)
failures.push(`CLS ${result.cls} > ${budget.cls}`);
if (result.tbt > budget.tbt)
failures.push(`TBT ${result.tbt}ms > ${budget.tbt}`);
if (failures.length > 0) {
console.error('CWV check FAILED:\n' + failures.join('\n'));
if (process.env.FAIL_ON_REGRESSION === 'true') process.exit(1);
} else {
console.log('CWV check passed.');
}
});
Data Storage and Trend Visualization
All results are stored in PostgreSQL with deployment linkage:
CREATE TABLE cwv_snapshots (
id SERIAL PRIMARY KEY,
url TEXT NOT NULL,
source VARCHAR(20) NOT NULL, -- 'lighthouse' or 'crux'
form_factor VARCHAR(10) NOT NULL, -- 'mobile', 'desktop'
measured_at TIMESTAMP NOT NULL,
-- Core Web Vitals
lcp_ms INTEGER,
cls NUMERIC(6,4),
inp_ms INTEGER,
fcp_ms INTEGER,
ttfb_ms INTEGER,
-- Lighthouse-only
performance_score NUMERIC(4,2),
tbt_ms INTEGER,
tti_ms INTEGER,
speed_index_ms INTEGER,
-- Metadata
deploy_id TEXT,
commit_sha TEXT
);
Storing commit SHA with each measurement allows pinpointing which deployment broke metrics. On top of this database, we build a Grafana dashboard showing weekly trends with deployment markers, so clients can track dynamics independently. Alerts in Telegram/Slack notify teams immediately when thresholds are breached.
What are the Core Web Vitals Thresholds?
Google's guidelines (field p75 data):
| Metric | Good | Needs Improvement | Poor |
|---|---|---|---|
| LCP | ≤ 2.5s | 2.5–4.0s | > 4.0s |
| CLS | ≤ 0.1 | 0.1–0.25 | > 0.25 |
| INP | ≤ 200ms | 200–500ms | > 500ms |
For lab monitoring we use stricter thresholds (LCP ≤ 3.0s, TBT ≤ 500ms) accounting for the gap between lab and field data. When setting CI/CD thresholds, we recommend 10-20% headroom above field targets to avoid false positives.
Real-world case study: In a recent project with one of our clients, a leading e-commerce store with 40+ pages and 1M monthly visits, we deployed the system described above. The initial field LCP p75 was 3.1s on mobile, while lab showed 1.8s. By analyzing the real-user data we discovered that the hero image was loading without priority and third-party scripts were blocking rendering. After implementing image optimization and async loading, field LCP dropped to 2.3s within two weeks, directly improving conversion rate by 8% — an additional $80,000 monthly revenue for the client.
What's Included in the Work
We provide:
- Comprehensive documentation of the monitoring architecture and developer instructions.
- Access to the Grafana dashboard and historical data.
- Team training on interpreting metrics and responding to alerts.
- Two weeks of post-implementation support — adjusting thresholds, dashboards, and alerts.
Our team of certified web performance engineers (15+ years combined experience) ensures seamless integration with your existing workflows.
Lab vs Field Data Comparison
| Parameter | Lab (Lighthouse) | Field (CrUX) |
|---|---|---|
| Speed of acquisition | Seconds | Up to 28 days |
| Real-world conditions | No | Yes |
| Repeatability | High | Medium |
| Use case | CI/CD, fast feedback | Trends, production alerts |
Field data better reflects real experience, but synthetic tests are 100x faster. The optimal strategy combines both sources.
Timeframes
Setting up CrUX API + Lighthouse + PostgreSQL storage + Grafana dashboard — 3–4 working days. CI/CD integration with budget failure — 1 additional day. Alerts in Telegram/Slack for field metric degradation — 0.5–1 day more.
Contact us to discuss your project details and choose the optimal monitoring configuration. Request a consultation to get an estimate for your site.