Using AI to Automatically Audit WordPress Core Web Vitals
⚡ TL;DR
To automate core web vitals check with AI and n8n, the clean workflow is: run a daily scheduled workflow, call Google’s PageSpeed Insights API for your key URLs, extract the performance score and a few critical audit signals, optionally ask an LLM to summarize the likely cause in plain English, then send a Slack alert only when the score drops below 90. That means your team stops manually checking Lighthouse scores and starts treating performance regressions like real operational incidents. In plain English: daily cron → PageSpeed API → threshold check → AI summary → Slack alert.
Most people treat Core Web Vitals checks like a dentist appointment. They know they should do it, they avoid doing it, and then they act surprised when something expensive hurts later.
That is exactly why this workflow matters. Performance regressions rarely arrive with drama. They slip in quietly after a plugin update, a bloated hero image, a new chat widget, a third-party script, a theme tweak, or some “small” frontend change a developer swore was harmless. Then rankings soften, conversions get weird, and everyone starts holding a group séance around PageSpeed screenshots.
The smarter move is obvious. Check your important pages daily. Use machines for the repetitive part. Use humans for the judgment part. And if the score falls under 90, do not politely log it in a spreadsheet nobody opens. Put it in Slack where people can feel mildly judged in real time.
What automate core web vitals check actually means
To automate core web vitals check means running scheduled performance tests against important URLs, capturing the key performance data programmatically, and triggering alerts or follow-up actions when the results cross a threshold. In this case, the threshold is a PageSpeed performance score below 90, and the automation layer is n8n.
The useful nuance here is that we are not just automating a score fetch. We are automating performance monitoring with routing logic. That is what makes it operational instead of decorative.
The short framework
| Step | What the workflow does | Why it matters |
|---|---|---|
| 1 | Runs every day on a schedule | You catch regressions before they become habits |
| 2 | Calls the PageSpeed Insights API for target URLs | Gets a machine-readable performance snapshot |
| 3 | Extracts the performance score and key diagnostics | Turns the raw payload into actionable signals |
| 4 | Checks whether the score is below 90 | Filters noise and avoids alert spam |
| 5 | Sends a Slack message with the problem summary | Your team sees the issue where actual work happens |
That is the adult version. Not “someone remember to run Lighthouse later.” A system.
Why the PageSpeed API is the right trigger source
Because it is already built for this job. Google’s PageSpeed Insights API still exposes the runPagespeed endpoint, which returns performance data, audit details, and Lighthouse-derived metrics for a supplied URL. That gives you a reliable machine-readable source instead of asking somebody to open a browser tab and squint at a score.
And yes, there is a deeper point here. Teams often say they care about Core Web Vitals, but what they really mean is they care about performance when they happen to remember it exists. API-based monitoring fixes that memory problem.
Why n8n is a good fit for daily monitoring
Because this workflow is mostly orchestration. Schedule. Request. Parse. Compare. Notify. That is n8n territory.
The Schedule Trigger node supports cron-style scheduling, which means daily checks are trivial. The HTTP Request node can hit the PageSpeed API directly. The Slack node can send the alert. That is a very clean chain. No heroic engineering needed.
And since performance monitoring is repetitive by nature, boring tools are actually an advantage here. You do not need something glamorous. You need something that quietly runs every day without turning into its own source of drama.
The workflow architecture
Schedule Trigger (daily)
│
▼
Set URLs to check
│
▼
HTTP Request → PageSpeed Insights API
│
▼
Code / Set node → extract performance score + key audits
│
▼
IF node → score < 90 ?
┌─┴───────────────┐
│ │
No Yes
│ │
▼ ▼
End workflow Optional AI summary
│
▼
Slack message alert
│
▼
Team investigates issueThis is exactly the kind of workflow n8n handles well. One trigger, one API call, one logic branch, one communication channel. Simple enough to trust. Flexible enough to grow later.
Daily PageSpeed API request pattern
The request itself is not complicated. Google’s endpoint is still runPagespeed, and you can pass the URL plus strategy parameters like mobile or desktop. For most WordPress monitoring, mobile is the better default because that is where people usually discover their frontend sins.
GET https://www.googleapis.com/pagespeedonline/v5/runPagespeed?url=https://example.com&strategy=mobile&category=performanceIn n8n, the HTTP Request node should hit that endpoint once per URL you care about. Home page, top landing pages, high-value blog posts, maybe your money category pages. Not every tiny archive URL on earth. Performance monitoring becomes useless very quickly if you drown it in low-priority pages.
What to extract from the API response
This is where a lot of people get messy. They ask for the whole response, then stare at a mountain of JSON like it has insulted them personally.
You usually need only a few values:
| Field | Why it matters | How to use it |
|---|---|---|
| Performance score | Main threshold trigger | Alert if below 90 |
| LCP audit | Tells you if the page got visually slow | Good clue for media or render-blocking problems |
| CLS audit | Tells you if layout stability worsened | Useful when widgets or ads shift content |
| TBT or blocking-time audits | Flags JS bloat and script problems | Great for catching plugin or third-party regressions |
| Final URL | Confirms what was actually tested | Useful when redirects or canonicals complicate things |
The score gets the attention. The audits tell you where to look first. Without that second part, the Slack alert is just a panic button with no diagnosis.
How the Slack alert should work
Please do not send vague alerts like “performance bad.” That is not operational monitoring. That is electronic whining.
Your Slack message should include the tested URL, the current performance score, the prior score if you store it, and one or two likely causes pulled from the key audits. That is enough context for someone to act without digging through raw JSON like a digital archaeologist.
🚨 Core Web Vitals Alert
URL: https://example.com/blog/post-slug
Performance score: 84
Threshold: below 90
Likely issue: LCP slowed down, main-thread blocking increased
Strategy: mobile
Suggested next step:
Review hero image weight, third-party scripts, and recent frontend changes.That message is simple, but it is useful. Useful beats clever every time in alerting systems.
Where AI actually helps here
The AI part should be small and disciplined.
Do not ask an LLM to replace the metric. Ask it to summarize the metric. That is the sane boundary. The PageSpeed API gives you the facts. The LLM can translate the ugliest audit details into a short plain-English explanation for Slack. That makes the alert easier to act on without letting the model invent the diagnosis from thin air.
That distinction matters. If you let the model improvise too freely, you get performance astrology. If you make it summarize real audit data, you get something closer to a useful incident note.
n8n workflow node layout
| Node | Function | Why it belongs |
|---|---|---|
| Schedule Trigger | Runs every day | Creates predictable monitoring cadence |
| Set | Defines the list of URLs | Keeps the workflow easy to maintain |
| HTTP Request | Calls PageSpeed Insights API | Pulls the actual performance data |
| Code or Set | Extracts score and key audits | Turns raw JSON into operational fields |
| IF | Checks if score is below 90 | Prevents useless noise |
| AI node or HTTP LLM call | Creates a short summary | Makes the alert easier for humans to parse |
| Slack | Sends the alert message | Puts the regression in front of the team fast |
This is one of those workflows where overengineering is genuinely embarrassing. You do not need sixteen nodes and an agent swarm to tell you your homepage got slower.
Example score-check logic
In the PageSpeed response, the performance score is usually returned as a decimal fraction between 0 and 1. So your logic should multiply it by 100 and then compare it against 90. That tiny transformation matters because otherwise people end up comparing 0.84 to 90 and wondering why the workflow is behaving like it has recently suffered a concussion.
const rawScore = $json.lighthouseResult.categories.performance.score;
const score = Math.round(rawScore * 100);
return [
{
json: {
url: $json.id,
score,
lcp: $json.lighthouseResult.audits["largest-contentful-paint"]?.displayValue,
cls: $json.lighthouseResult.audits["cumulative-layout-shift"]?.displayValue,
tbt: $json.lighthouseResult.audits["total-blocking-time"]?.displayValue
}
}
];That small node does most of the useful cleanup work. The rest is just routing.
Why 90 is the right threshold for this workflow
Because below 90 is where performance stops looking comfortably green and starts becoming a real warning sign for pages that are supposed to be healthy.
Could you set it lower? Sure. But then you are basically telling the workflow to ignore problems until they get uglier. Could you set it higher? Also yes, but then many teams end up generating too much noise and eventually ignoring the alerts. Ninety is a good operational compromise for important WordPress pages that should stay well-optimized.
What docs do not tell you
The daily schedule matters less than the URL selection. Monitoring fifty mediocre archive pages is less useful than monitoring five URLs that actually drive leads, sales, or search visibility.
Slack alerts without context become wallpaper. If the message does not include score, URL, and likely cause, the team will stop caring quickly.
AI should summarize, not diagnose from scratch. The PageSpeed data is the source of truth. The model is just there to make the alert easier to understand.
Daily checks are good, but trend storage is better. A one-day drop matters. A seven-day downward slide matters more. Once this workflow is running, the next smart move is logging scores over time.
🛠 Pro-Tip
Do not alert on the first bad score alone if your site has volatile third-party scripts. Store the last few daily scores and trigger Slack only when the score stays below 90 for two consecutive runs or drops by more than, say, 8 points day over day. That small bit of threshold engineering reduces false positives and makes the alert channel much more credible.
Our experience with automate core web vitals check
Our experience with automate core web vitals check workflows is that the biggest mistake is treating performance like a one-time optimization project instead of an operational signal. Teams fix a slow page once, celebrate, and then quietly let performance regress through ordinary site changes. Monitoring is what turns performance from a vague aspiration into something that can actually be defended.
We have also found that the best performance alerts are surprisingly unemotional. They do not dump raw audit sludge into Slack. They do not scream about every tiny wobble. They simply say, “this page dropped below the line, here is the score, here is the likely pain point, go look.” That level of restraint makes people trust the workflow instead of muting it.
And honestly, that is the bigger lesson here. If your WordPress site still depends on someone manually noticing that the homepage got slower after a plugin or design change, you do not really have performance governance. You have performance hope. And hope is a terrible monitoring strategy.
