Core Web Vitals
Largest Contentful Paint, Interaction to Next Paint and Cumulative Layout Shift, tracked on both mobile and desktop against Google's thresholds.
Performance monitoring
Catch the performance regression in the week it happens
Core Web Vitals, PageSpeed scores and server response time tracked continuously per template, not once when somebody remembers to run a test. When an update slows a page down, you find out in days rather than at the next audit.
Included on every plan. No add-on pricing.
Updated
PerformanceExample data
Passing CWV
28
of 34
Median LCP
1.9s
improved
Regressions 30d
2
both traced
Median TTFB
312ms
NRnorthridge-dental.com
GoodHVharvest-collective.store
Needs workMPmeridian-partners.com
PoorBFbramble-fields.org
GoodWhat is Core Web Vitals monitoring?
Core Web Vitals monitoring checks a site's loading speed (Largest Contentful Paint), responsiveness (Interaction to Next Paint) and visual stability (Cumulative Layout Shift) on a schedule, so you see when a change makes pages slower instead of finding out weeks later. WordPress sites have room to improve: in August 2026, 48.7 percent of WordPress sites had good Core Web Vitals on mobile, against 53.0 percent of all sites, according to the HTTP Archive Core Web Vitals Technology Report.
WPCentrify runs Google PageSpeed checks for every WordPress site you connect, on mobile and desktop, automatically and again whenever you press recheck. It shows each site's scores and Core Web Vitals side by side, and can email you when a site gets slower after an update. Our guide on how to improve Core Web Vitals on WordPress covers the fixes for each metric.
WPCentrify performance monitoring at a glance
- Google PageSpeed scores and Core Web Vitals (LCP, INP and CLS) for every connected site.
- Mobile and desktop measured separately.
- Checked automatically, and rechecked on demand in one click.
- An optional email when a site gets slower after an update.
- Every site's Web Vitals in one column of the Websites list.
The problem
Performance decays quietly
Sites are usually fast on launch day. Then a plugin gets added, a hero image goes up unoptimised, a tracking script is pasted into the header, a page builder ships a heavier release, and the site gets slower by a fraction each time. A database nobody has cleaned in five years adds to it quietly, which is what database cleanup is for. Nobody notices, because nobody is comparing this month to six months ago.
A single PageSpeed run tells you almost nothing. It is one measurement, of one page, at one moment, on one network. What matters is the trend line, per template, over time. Our guide to WordPress performance monitoring explains how to read those trends and trace a regression back to the change that caused it, and our guide on how to improve Core Web Vitals on WordPress covers the fixes for each metric.
What this looks like without a platform
- A one-off Lighthouse score with nothing to compare it to
- Testing the home page and assuming the rest matches
- Discovering a Core Web Vitals problem from Search Console weeks later
- No idea which change made the site slower
How it works
What WordPress performance monitoring measures
Per template, not just the home page
Home, a typical post, a category, a product page and checkout are measured separately. A fast home page and a slow product page is the normal situation, and the product page is the one that matters. Which of those templates visitors actually reach is a question for per-site traffic analytics.
Server response time
Time to First Byte tracked continuously alongside uptime checks, which usually identifies whether a problem is hosting, a plugin, or the front end.
Page weight and request breakdown
Total size, number of requests, and what is contributing, so a regression can be traced to the specific asset that caused it.
In practice
WordPress PHP error monitoring, and turning measurement into action
A site throwing PHP fatal errors is not a slow site, it is a broken one, and it can still return HTTP 200 to anything checking only the status code. Fatal error detection runs as part of the health checks around every update, so an error that appears after a change is reported against that change rather than found weeks later. The rest of this section is what happens once a measurement, or an error, becomes something worth acting on.
Regression alerts tied to changes
When a metric degrades meaningfully, the alert includes what changed around the same time: which update ran, which plugin was activated.
Portfolio ranking
Every site ranked by Core Web Vitals status so you can see which accounts need attention first, which is one of the inputs to the maintenance dashboard the team works from.
Trend over time
Six and twelve month history per template so improvement or decay is visible rather than inferred.
Included in client reports
Performance appears in the monthly report as a trend, which is a much better conversation than a single score.
At scale
PageSpeed monitoring across every WordPress site you manage
- Core Web Vitals status across every connected site in one view
- Per-template measurement including checkout and account pages
- Mobile and desktop tracked separately
- Alerts on sustained regression, not one noisy measurement
- Correlation with updates and plugin changes
- Historical trend included in reporting
Answers
Questions about performance monitoring
What people ask before they turn this on.
Both. Synthetic tests run on a schedule for consistent comparison, and Chrome UX Report field data is shown alongside where it is available, because real users and lab conditions do not always agree.
Daily by default on key templates, and additionally after any update that could plausibly affect rendering. Frequency is configurable per site.
It identifies and attributes them rather than rewriting your site. It will tell you the product template regressed on 12 August after a specific plugin update, which is usually the hard part.
Use a tool that runs the checks on a schedule for every site and keeps the results side by side. WPCentrify checks Google PageSpeed and Core Web Vitals for every connected site on mobile and desktop, and can email you when a site gets slower after an update.
Google treats a page as good when Largest Contentful Paint is 2.5 seconds or less, Interaction to Next Paint is 200 milliseconds or less and Cumulative Layout Shift is 0.1 or less, measured at the 75th percentile of page visits.
They are one signal among many. Google uses page experience, including Core Web Vitals, but relevant, helpful content matters more, so treat good scores as a tie-breaker between similar pages rather than a way to outrank better content. Faster pages also keep more visitors.
Early access open
Try performance monitoring on your own sites
Connect a site in under two minutes and see this working against something real. Free during early access.
Free during early access. Keep your data, export any time.