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.
PerformanceLive
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
Good 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. 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.
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.
Server response time
Time to First Byte tracked continuously alongside availability, 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
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.
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.
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.