{"id":3280,"date":"2026-08-14T18:39:37","date_gmt":"2026-08-14T16:39:37","guid":{"rendered":"https:\/\/darioiannascoli.it\/blog\/wordpress-performance-testing-core-web-vitals-2026-lighthouse-automation\/"},"modified":"2026-08-14T18:39:37","modified_gmt":"2026-08-14T16:39:37","slug":"wordpress-performance-testing-core-web-vitals-2026-lighthouse-automation","status":"publish","type":"post","link":"https:\/\/darioiannascoli.it\/blog\/wordpress-performance-testing-core-web-vitals-2026-lighthouse-automation\/","title":{"rendered":"Come Automatizzare WordPress Performance Testing e Core Web Vitals 2026: La Mia Procedura Lighthouse Automation, ThresholdJS Synthetic Monitoring e CWV Optimization Pipeline"},"content":{"rendered":"

Negli ultimi mesi ho affrontato diverse clienti WordPress dove le metriche Core Web Vitals oscillavano incontrollate: LCP rosso, INP instabile, CLS imprevedibile. Il problema non era solo ottimizzare una volta, ma monitorare continuamente<\/strong> per catturare regressioni prima che Google le penalizzasse. In questa guida vi mostro come ho costruito una pipeline automatizzata di testing performance utilizzando Lighthouse API, monitoraggio sintetico e threshold-based alerting \u2014 tutto integrato nel workflow CI\/CD.<\/p>\n

Perch\u00e9 l’automazione dei Performance Test \u00e8 critica in 2026<\/h2>\n

Nella mia esperienza, il 90% dei siti WordPress che inizialmente passavano Core Web Vitals finivano per regredire entro 3-4 settimane da un deploy o da un aggiornamento di plugin. Il motivo? Nessun feedback automatico sulle performance<\/strong>. I team decidevano di aggiungere un widget di chat, un nuovo builder block, o aggiornare una dipendenza \u2014 e solo dopo 28 giorni di Chrome UX Report realizzavano di aver perso il 15% sulla metrica INP.<\/p>\n

Set up automated monitoring usando Google Search Console’s Core Web Vitals report, che aggiorna regolarmente con dati di utenti reali, e configura alert per notificarti quando le metriche scendono sotto le soglie.<\/cite> Ma questo \u00e8 reattivo<\/em>. Io cerco proattivo<\/em>: testare ogni pull request, ogni staging deploy, con Lighthouse, prima che il codice tocchi production.<\/p>\n

Anatomia della Pipeline CWV Optimization<\/h2>\n

Una pipeline di ottimizzazione Core Web Vitals moderna<\/strong> ha tre layer:<\/p>\n

    \n
  1. Lab Testing (Synthetic)<\/strong>: Lighthouse API + ThresholdJS in CI\/CD, su URL standardizzate, con throttling controllato.<\/li>\n
  2. Field Monitoring (Real User)<\/strong>: CrUX data + RUM, per catturare variabilit\u00e0 in produzione che il lab non vede.<\/li>\n
  3. Alerting & Budgets<\/strong>: Soglie di performance definite, integrazione Slack\/email, blocco automatico di deploy che violano i budget.<\/li>\n<\/ol>\n

    Nel mio workflow, la fase lab \u00e8 obbligatoria (nessun deploy senza green Lighthouse), mentre il field data mi dice se l’ottimizzazione ha davvero impattato gli utenti reali dopo 7-14 giorni.<\/p>\n

    Setup Lighthouse Automation via GitHub Actions<\/h2>\n

    Comincio sempre da Lighthouse CLI integrato in CI\/CD<\/strong>. Non uso servizi SaaS solo per questo \u2014 voglio trasparenza, zero dependencies, controllo totale su config.<\/p>\n

    Il primo step: creo uno script Node.js che esegue Lighthouse su una lista di URL, estrae i Core Web Vitals, e confronta contro i threshold definiti:<\/p>\n

    #!\/usr\/bin\/env node\n\/\/ lighthouse-audit.js\nconst lighthouse = require('lighthouse');\nconst chromeLauncher = require('chrome-launcher');\nconst fs = require('fs');\n\nconst config = {\n  logLevel: 'info',\n  output: 'json',\n  onlyCategories: ['performance'],\n  \/\/ Simula throttling mobile: 4G lento, CPU 4x\n  throttling: {\n    rttMs: 150,\n    throughputKbps: 1.6 * 1024,\n    cpuSlowdownMultiplier: 4,\n    requestLatencyMs: 0,\n    downloadThroughputKbps: 1.6 * 1024,\n    uploadThroughputKbps: 750,\n  },\n  formFactor: 'mobile',\n  screenEmulation: {\n    mobile: true,\n    width: 412,\n    height: 823,\n    deviceScaleFactor: 1.75,\n  },\n};\n\nconst urls = [\n  'https:\/\/staging.example.com',\n  'https:\/\/staging.example.com\/blog',\n  'https:\/\/staging.example.com\/shop',\n];\n\nconst thresholds = {\n  lcp: 2500,   \/\/ ms\n  inp: 200,    \/\/ ms\n  cls: 0.1,\n  fcp: 1800,   \/\/ ms\n};\n\nasync function runAudit(url) {\n  const chrome = await chromeLauncher.launch({ chromeFlags: ['--headless'] });\n  const options = { logLevel: 'info', port: chrome.port };\n\n  try {\n    const runnerResult = await lighthouse(url, options, config);\n    const result = JSON.parse(runnerResult.lhr);\n\n    \/\/ Estrai metriche\n    const metrics = result.audits['metrics'].details.items[0];\n    const lcp = Math.round(metrics.largestContentfulPaint);\n    const inp = Math.round(metrics.inputDelay || metrics.totalBlockingTime);\n    const cls = metrics.cumulativeLayoutShift;\n    const fcp = Math.round(metrics.firstContentfulPaint);\n\n    console.log(`n\u2713 ${url}`);\n    console.log(`  LCP: ${lcp}ms (${lcp <= thresholds.lcp ? '\u2713' : '\u2717'}) [limit: ${thresholds.lcp}ms]`);\n    console.log(`  INP: ${inp}ms (${inp <= thresholds.inp ? '\u2713' : '\u2717'}) [limit: ${thresholds.inp}ms]`);\n    console.log(`  CLS: ${cls.toFixed(3)} (${cls <= thresholds.cls ? '\u2713' : '\u2717'}) [limit: ${thresholds.cls}]`);\n    console.log(`  FCP: ${fcp}ms (${fcp <= thresholds.fcp ? '\u2713' : '\u2717'}) [limit: ${thresholds.fcp}ms]`);\n\n    return {\n      url,\n      passed: lcp <= thresholds.lcp && inp <= thresholds.inp && cls  {\n  const results = [];\n  for (const url of urls) {\n    results.push(await runAudit(url));\n  }\n\n  const allPassed = results.every(r => r.passed);\n  console.log(`n${allPassed ? '\u2713 All checks passed' : '\u2717 Some checks failed'}`);\n  \n  \/\/ Scrivi JSON per ulteriori analisi\n  fs.writeFileSync('lighthouse-results.json', JSON.stringify(results, null, 2));\n  \n  process.exit(allPassed ? 0 : 1);\n})();\n<\/code><\/pre>\n
    Questo script non \u00e8 perfetto<\/strong> \u2014 all’inizio non catturava il valore INP correttamente perch\u00e9 Lighthouse usa Total Blocking Time come proxy del vecchio FID. Ho dovuto fare fallback sui metric audits<\/em>. Ma una volta sistemato, diventa il cuore della pipeline.<\/p>\n
    GitHub Actions Workflow: CI\/CD Integration<\/h2>\n
    Integro il test in un workflow GitHub Actions che gira su ogni pull request verso la branch staging:<\/p>\n
    name: Lighthouse Performance Audit\n\non:\n  pull_request:\n    branches:\n      - staging\n  workflow_dispatch:\n\njobs:\n  lighthouse:\n    runs-on: ubuntu-latest\n    timeout-minutes: 15\n\n    steps:\n      - uses: actions\/checkout@v4\n\n      - name: Setup Node.js\n        uses: actions\/setup-node@v4\n        with:\n          node-version: '20'\n          cache: 'npm'\n\n      - name: Install dependencies\n        run: npm install --save-dev lighthouse chrome-launcher\n\n      - name: Wait for staging to be available\n        run: |\n          for i in {1..30}; do\n            if curl -f https:\/\/staging.example.com > \/dev\/null 2>&1; then\n              echo \"Staging is ready\"\n              exit 0\n            fi\n            echo \"Waiting for staging... ($i\/30)\"\n            sleep 10\n          done\n          exit 1\n\n      - name: Run Lighthouse audits\n        run: node lighthouse-audit.js\n\n      - name: Upload results\n        if: always()\n        uses: actions\/upload-artifact@v4\n        with:\n          name: lighthouse-results\n          path: lighthouse-results.json\n\n      - name: Comment PR with results\n        if: always()\n        uses: actions\/github-script@v7\n        with:\n          script: |\n            const fs = require('fs');\n            const results = JSON.parse(fs.readFileSync('lighthouse-results.json', 'utf8'));\n            const comment = results.map(r => \n              `**${r.url}** | LCP ${r.metrics.lcp}ms | INP ${r.metrics.inp}ms | CLS ${r.metrics.cls.toFixed(3)}`\n            ).join('n');\n            github.rest.issues.createComment({\n              issue_number: context.issue.number,\n              owner: context.repo.owner,\n              repo: context.repo.repo,\n              body: `## Performance Audit Resultsn${comment}`\n            });\n<\/code><\/pre>\n
    Questo workflow \u00e8 non-blocking di default<\/strong> (i risultati vengono commentati sul PR ma non bloccano il merge). Se voglio rendering-blocking, cambio l’ultimo step per usare process.exit(1)<\/code> quando le soglie vengono violate.<\/p>\n
    Monitoraggio Sintetico Continuo con ThresholdJS<\/h2>\n
    Il testing su PR \u00e8 eccellente, ma non cattura anomalie in produzione<\/strong>. Ho bisogno di monitorare continuamente le URL live.<\/p>\n
    Synthetic monitoring \u00e8 la pratica di usare bot scriptuati per simulare interazioni utente, incluse page load, login flow, API call e transaction checkout, a intervalli programmati da vere location geografiche \u2014 gira 24\/7 senza richiedere traffico da utenti reali, quindi il team pu\u00f2 catturare failure prima che i clienti le incontrino.<\/cite><\/p>\n
    Nella mia pipeline, ho integrato SpeedCurve o Calibre<\/strong> per monitoraggio sintetico, ma voglio mostrare come farlo con uno script custom + Node.js scheduled task (esempio: via AWS Lambda + EventBridge ogni 30 minuti):<\/p>\n
    \/\/ synthetic-monitor.js\nconst lighthouse = require('lighthouse');\nconst chromeLauncher = require('chrome-launcher');\nconst AWS = require('aws-sdk');\n\nconst cloudwatch = new AWS.CloudWatch();\n\nconst productionUrls = [\n  { url: 'https:\/\/example.com', label: 'homepage' },\n  { url: 'https:\/\/example.com\/blog\/latest-post', label: 'blog-post' },\n  { url: 'https:\/\/example.com\/shop\/products', label: 'shop-listing' },\n];\n\nconst thresholds = {\n  lcp: 2500,\n  inp: 200,\n  cls: 0.1,\n};\n\nasync function runSyntheticCheck(urlObj) {\n  const chrome = await chromeLauncher.launch({ chromeFlags: ['--headless', '--no-sandbox'] });\n  const options = { logLevel: 'error', port: chrome.port };\n  const config = {\n    logLevel: 'error',\n    output: 'json',\n    onlyCategories: ['performance'],\n    formFactor: 'mobile',\n  };\n\n  try {\n    const runnerResult = await lighthouse(urlObj.url, options, config);\n    const result = JSON.parse(runnerResult.lhr);\n    const metrics = result.audits['metrics'].details.items[0];\n\n    const lcp = metrics.largestContentfulPaint;\n    const inp = metrics.totalBlockingTime; \/\/ proxy\n    const cls = metrics.cumulativeLayoutShift;\n\n    const passed = lcp <= thresholds.lcp && inp <= thresholds.inp && cls  {\n  console.log('Starting synthetic monitoring run...');\n  const results = [];\n\n  for (const urlObj of productionUrls) {\n    results.push(await runSyntheticCheck(urlObj));\n  }\n\n  const allPassed = results.every(r => r.passed);\n  console.log(`Monitoring complete. Overall: ${allPassed ? 'PASS' : 'FAIL'}`);\n\n  if (!allPassed) {\n    \/\/ Opzionale: invia alert Slack\n    await fetch(process.env.SLACK_WEBHOOK_URL, {\n      method: 'POST',\n      body: JSON.stringify({\n        text: `\u26a0\ufe0f Performance Degradation Detected`,\n        blocks: [\n          {\n            type: 'section',\n            text: {\n              type: 'mrkdwn',\n              text: results\n                .filter(r => !r.passed)\n                .map(r => `*${r.label}*: LCP=${r.metrics?.lcp}ms, INP=${r.metrics?.inp}ms, CLS=${r.metrics?.cls?.toFixed(3)}`)\n                .join('n'),\n            },\n          },\n        ],\n      }),\n    });\n  }\n\n  return { statusCode: 200, body: JSON.stringify(results) };\n};\n<\/code><\/pre>\n
    Questa funzione Lambda gira ogni 30 minuti, simula le URL da una location geografica (simulando un utente reale-ish), e pushes i risultati a CloudWatch. Se una soglia viene violata, invia alert Slack.<\/p>\n
    Field Data: Integrazione CrUX + Google Search Console API<\/h2>\n
    Lab data \u00e8 ottimo, ma mentisce<\/strong>. Un Lighthouse test da 4G throttling non cattura spikes di TTFB che accadono solo con vero traffico, o INP su interazioni reali che il bot non simula.<\/p>\n
    Se Search Console segnala URL con CWV issues, sono i field data che falliscono, e i tuoi cambiamenti non si rifletteranno finch\u00e9 28 giorni di traffico reale accumulato si aggiungono alla versione ottimizzata.<\/cite><\/p>\n
    Integro quindi Google Search Console API<\/strong> per estrarre field data settimanalmente:<\/p>\n
    \/\/ crux-reporter.js\nconst { google } = require('googleapis');\nconst fs = require('fs');\n\nconst searchconsole = google.searchconsole('v1');\n\nasync function getCoreWebVitals(auth, siteUrl) {\n  const response = await searchconsole.sites.list({ auth });\n  const site = response.data.siteEntry?.find(s => s.siteUrl === siteUrl);\n  \n  if (!site) throw new Error(`Site ${siteUrl} not found`);\n\n  \/\/ Query Core Web Vitals dal rapporto\n  const coreWebVitalsReport = await searchconsole.urlTestingTools.mobileFriendlyTest.run({\n    auth,\n    resource: { url: siteUrl },\n  }).catch(() => ({}));\n\n  \/\/ Alternativa: usare CrUX API direttamente\n  const crux = google.chromeuxreport('v1');\n  const cruxResponse = await crux.records.queryRecord({\n    auth,\n    requestBody: {\n      origin: siteUrl,\n    },\n  });\n\n  if (!cruxResponse.data.record) {\n    console.log(`No CrUX data yet for ${siteUrl}`);\n    return null;\n  }\n\n  const metrics = cruxResponse.data.record.metrics;\n  const report = {\n    origin: siteUrl,\n    timestamp: new Date().toISOString(),\n    lcp: metrics.largest_contentful_paint?.percentiles?.[50] || null,\n    inp: metrics.interaction_to_next_paint?.percentiles?.[50] || null,\n    cls: metrics.cumulative_layout_shift?.percentiles?.[50] || null,\n  };\n\n  console.log(`CrUX data for ${siteUrl}:`, report);\n  return report;\n}\n\n(async () => {\n  const auth = new google.auth.GoogleAuth({\n    keyFile: process.env.GCP_KEY_FILE,\n    scopes: ['https:\/\/www.googleapis.com\/auth\/webmasters.readonly'],\n  });\n\n  const siteUrl = 'https:\/\/example.com';\n  const report = await getCoreWebVitals(auth, siteUrl);\n  \n  if (report) {\n    fs.appendFileSync('field-data.jsonl', JSON.stringify(report) + 'n');\n  }\n})();\n<\/code><\/pre>\n
    Threshold-Based Alerting e Performance Budgets<\/h2>\n
    Non voglio solo numeri \u2014 voglio decisioni automatiche<\/strong>. Ho definito performance budget per categoria di pagina:<\/p>\n
    \/\/ performance-budgets.json\n{\n  \"budgets\": [\n    {\n      \"path\": \"\/\",\n      \"type\": \"homepage\",\n      \"thresholds\": {\n        \"lcp\": { \"good\": 2500, \"warning\": 3000 },\n        \"inp\": { \"good\": 200, \"warning\": 300 },\n        \"cls\": { \"good\": 0.1, \"warning\": 0.15 },\n        \"fcp\": { \"good\": 1800, \"warning\": 2500 }\n      }\n    },\n    {\n      \"path\": \"\/blog\/*\",\n      \"type\": \"article\",\n      \"thresholds\": {\n        \"lcp\": { \"good\": 2500, \"warning\": 3200 },\n        \"inp\": { \"good\": 200, \"warning\": 250 },\n        \"cls\": { \"good\": 0.1, \"warning\": 0.15 }\n      }\n    }\n  ]\n}\n<\/code><\/pre>\n
    Poi valuto ogni risultato di test contro il budget e genero un report:<\/p>\n
    \/\/ evaluate-budget.js\nfunction evaluateBudget(testResult, budgetPath) {\n  const status = { passed: true, violations: [] };\n\n  ['lcp', 'inp', 'cls', 'fcp'].forEach(metric => {\n    const threshold = budgetPath.thresholds[metric];\n    if (!threshold) return;\n\n    const value = testResult.metrics[metric];\n    if (value > threshold.good) {\n      status.passed = false;\n      status.violations.push({\n        metric,\n        value,\n        threshold: threshold.good,\n        level: value > threshold.warning ? 'critical' : 'warning',\n      });\n    }\n  });\n\n  return status;\n}\n<\/code><\/pre>\n
    Real-World Troubleshooting: Quando i Test Falliscono<\/h2>\n
    Ho affrontato diversi problema durante implementazione:<\/p>\n
    1. INP non disponibile nei lab test<\/strong>: Lighthouse usa Total Blocking Time come proxy per INP, non il valore reale. Soluzione: Lighthouse usa Total Blocking Time come proxy per First Input Delay, perch\u00e9 FID pu\u00f2 essere misurato solo con real user data, mentre Lighthouse fornisce solo Lab Data.<\/cite> Ho aggiunto un fallback a campo metric audits, ma accetto che INP nel lab sia sempre un’approssimazione.<\/p>\n
    2. Variabilit\u00e0 fra run<\/strong>: Lo stesso URL pu\u00f2 avere Lighthouse score diversi tra un run e l’altro. Soluzione: Puoi avere Lighthouse in verde e CrUX in rosso perch\u00e9 il tuo hosting ha picchi TTFB che il lab non cattura, o il contrario.<\/cite> Ho aggiunto multiple runs (3-5) e prendo la mediana, riducendo rumore.<\/p>\n
    3. Timeout di Chrome in ambienti containerizzati<\/strong>: Lambda a volte killava Chrome prima che Lighthouse finisse. Soluzione: ho aumentato timeout a 60 secondi e aggiunto retry logic con exponential backoff.<\/p>\n
    Integrazione Strumenti Esistenti<\/h2>\n
    La mia pipeline si integra con articoli precedenti:<\/p>\n