Expand page health monitoring to work for any website — platform agnostic

[Ajay-Singh-Adhikari]

Problem

A web performance audit isn't really about any single metric — page load, query time, plugin count. It's about reading the fundamentals of how an application uses its server: what's installed, what runs per request, where data lives, how that data ages. Every engineer doing a performance audit reaches for the same handful of signals first, regardless of the stack.

Today the dashboard captures page-level health (the symptom layer) and one server-side metric (autoload options). Everything else — the cause layer — still requires an engineer to SSH in, run platform-specific commands, query the database by hand, and write findings down. Each engagement starts from zero. The dashboard tells us a site is slow; it doesn't tell us why.

The fundamentals we're missing

Every web application — WordPress, Laravel, Django, Node, anything custom — exposes the same categories of performance signal. The names differ; the shape doesn't.

Category	What it tells you	WordPress shape	Generalizes to
Extension footprint	How much third-party code runs per request	Active/inactive plugin count	Composer packages, npm deps, Django apps, middleware stack
Per-request execution	What fires on every page render	WP Doctor hook count per page	Middleware count, event listeners, route handler chain
Storage shape	Where data lives and how it's structured	DB table sizes	Same across all relational stacks
Config-layer load	How much config is read on bootstrap	Autoload options size	env-var count, config cache size, settings table reads
Data aging	Whether transactional data is archived or hoarded	Order table size + oldest order age	Any transactional table — orders, events, audit logs, sessions

These are the questions an engineer asks in the first 15 minutes of any audit. The dashboard should already have the answers when they open it.

Why this matters now

Two motions converge here, and neither is possible without the fundamentals layer:

1. The dashboard becomes a product, not a per-client report. Today each audit is custom consulting — same questions, same commands, written up fresh each time. Once the fundamentals are captured automatically, the audit starts from information. The engineer's job shifts from data collection to interpretation.

2. Cross-client intelligence becomes possible. When the same signals are captured for every client in the same shape, patterns surface across the portfolio: which extension counts correlate with slow page health, which storage shapes predict future degradation, what archival cadence keeps transactional tables healthy. The dashboard stops being a per-site reporter and becomes a learning system.

Expected outcome

The adapter pattern captures the five fundamental categories above, automatically, on a schedule, pushed to BigQuery.

WordPress is the first platform implementation (it's where the live engagement is). The collector interface is designed so the same five categories map to other platforms when the next engagement arrives. Adding a new platform = implementing the five collectors for it, not rewriting the dashboard.

What changes downstream

• Audit kickoff time drops from days to minutes. The first conversation with a new client opens with diagnosis on the screen, not a list of commands the engineer needs to run.
• The "WordPress performance" framing stops being WordPress-specific. The same dashboard view answers Laravel, Django, custom-stack questions — because the categories are the same.
• A new performance-audit engagement is a configuration, not a build. Point the adapter at the new site; the dashboard fills in.

Related

WordPress-specific metrics (plugin count, hook count, DB sizes) are tracked separately in: coloredcow/performance-adapter-wp