內容簡介
Aftercare 是一款專為 WordPress 網站設計的監控外掛，能夠追蹤網站性能變化並記錄相關數據，幫助使用者了解網站速度變慢的原因，並提供即時的性能報告，適合代理商和自由工作者使用。
【主要功能】
• 每日監控 Core Web Vitals 數據
• 設定性能預算並自動開啟事件
• 變更追蹤與即時通知
• 支援多個網址的性能監測
• 實時用戶監控選項
外掛標籤
開發者團隊
原文外掛簡介
Know what changed. Know what it cost. Prove what you did.
Aftercare watches your WordPress site after launch. Every day it records your real-world Core Web Vitals; every second it records the changes made to the site. When performance regresses, it connects the two — an incident opens, an email goes out, and the incident page shows every change from the 72 hours before the regression, right next to the trend.
It is built for agencies and freelancers who maintain client sites on monthly care plans — and for any site owner who wants an answer to “why did the site just get slower?” that is based on data instead of guesswork.
📈 Core Web Vitals monitor
Daily p75 values for LCP, INP, CLS and TTFB from the Chrome UX Report — real field data from actual Chrome users, fetched with your own free Google API key
Daily Lighthouse lab checks (mobile, median of 3 runs) through the PageSpeed Insights API with the same key: LCP, CLS, TTFB and Total Blocking Time, so sites with too little traffic for the Chrome UX Report still get data. Shown separately from field data, never mixed with it
Optional real-user monitoring beacon: ~2 KB, no external libraries or services, loaded for a configurable sample of visits and aggregated to daily p75 on your own site
Track the homepage plus as many other URLs as you like, with sparkline trends and pass / warn / fail status pills
💰 Performance budgets and incidents
Editable budgets per metric (defaults: LCP 2.5 s, INP 200 ms, CLS 0.1, TTFB 800 ms)
A daily p75 over budget — or 20% worse than your 28-day baseline — opens an incident and emails you
A lab reading 20% worse than the 28-day lab baseline, and worse by more than normal Lighthouse variation, opens a separate lab incident the same day it is measured
Re-test after every change: 15 minutes after a plugin or theme update, plugin activation, theme switch or core update, Aftercare runs a lab check again. A bulk update produces one re-test, and an incident it opens names the changes it was re-testing
Incidents track status (open, acknowledged, resolved, dismissed) and resolve automatically when the metric recovers
Every incident shows the raw change timeline from the 72 hours before the breach
📒 Change ledger
Records plugin updates (old → new version), activations, deactivations, theme updates and switches, core updates, allow-listed settings changes, content publishes and new users
Human-readable entries with the responsible user: “WP Rocket updated 3.15 to 3.16 by admin”
Filterable timeline by type and date, CSV export, and the full history kept by default
🚨 Error watch
PHP fatal errors are recorded from the moment Aftercare loads, grouped by file and line on a PHP Errors screen with the plugin or theme that most likely caused them
A new fatal error writes a ledger entry and opens an incident with an email alert, even when it broke the site while plugins were loading
An availability check requests the homepage and tracked URLs every hour and shortly after each update, and opens an incident when a page returns a server error, goes missing or is cut off before it finishes rendering
Only the file, line and first line of the message are stored, on your own site, with nothing about the visitor
🧰 Fits into your workflow
Dashboard widget with vitals status and open incidents on the main wp-admin screen, plus a pass / warn / fail dot in the admin bar
Site Health integration — checks that vitals collection is configured, daily checks are running, lab checks reach PageSpeed Insights and budgets are not breached
WP-CLI commands — wp aftercare pull, wp aftercare check, wp aftercare status, wp aftercare run and wp aftercare lab for scripted setups and real server crons
Weekly digest email — vitals status, changes made and incidents from the past 7 days (opt-out in settings)
Guided first run — a three-step setup pointer until first data arrives, and suggested privacy-policy text for the RUM beacon
🔒 Private by design
No phoning home, no accounts, no external service. CrUX calls go straight from your server to Google with your key; RUM beacons post to your own site’s REST API
Uninstall removes every table and option unless you choose to keep the data
This plugin is complete in itself. Nothing here is capped, timed or held back: every URL you add is monitored, vitals are kept for thirteen months and the change ledger is kept in full.
A separate add-on plugin, distributed outside this directory, adds ranked cause attribution and white-label monthly client reports with Slack and webhook delivery. It is not required, and this plugin does not check for a licence, prompt for one or change behaviour without it.
Aftercare is built and maintained by Nomad Developer.
Privacy
Aftercare does not phone home. CrUX data is fetched directly from Google’s API using the key you provide. The optional RUM beacon posts anonymous metric values (no cookies, no personal data, no IPs stored) to your own site’s REST API and can be disabled at any time.
External Services
Aftercare connects to the following external services. No connection is made until you configure it.
Chrome UX Report API (Google) — used to retrieve real-user Core Web Vitals field data for the URLs you choose to track. Once you enter your own Google API key, the plugin sends your tracked URLs (or your site’s origin) together with that API key to https://chromeuxreport.googleapis.com once per day per URL. No visitor data, personal data or site content is sent. This service is provided by Google: Terms of Service, Privacy Policy. If no API key is configured, no request is ever made.
PageSpeed Insights API (Google): used for the daily Lighthouse lab checks. When lab checks are enabled and a Google API key is configured, the plugin sends the homepage and up to 5 tracked URLs together with that API key to https://www.googleapis.com/pagespeedonline/v5/runPagespeed, 3 times per URL per day, plus at most 4 re-tests a day after plugin, theme or core changes. Google then loads those public pages from its own servers. No visitor data or personal data is sent. This service is provided by Google: Terms of Service, Privacy Policy. Lab checks can be turned off in Settings, and no request is made without an API key.
