Understanding your Health Score

Your Website Health Score is a single number from 0–100 that summarizes how production-ready your Bricks project is. It’s designed to be a score you can track over time and show to clients, not a vanity metric.

How it’s calculated

Every finding carries a weight based on its severity, a critical issue costs far more than a minor one. Those weights add up into a “problem points” total, which is mapped to a score on a diminishing-returns curve:

• The first issues you fix move the score the most.
• As the project gets cleaner, each remaining issue matters less.

This is deliberate: it rewards clearing the worst problems first, and it means a large site with a few minor issues still scores well.

The five audit scores

Alongside the overall score, each audit gets its own score so you can see where the work is:

• Design, color, spacing, and typography consistency
• Classes, reusable styling instead of copy-paste
• Responsive, how pages behave on every screen size
• Performance, lean structure and right-sized media
• Accessibility, WCAG 2.2 A and AA checks a machine can decide

What the Responsive score measures

Three of the five audits read your Bricks data on the server, so they cover every page you have. Responsive is different: it loads pages in a real browser at each breakpoint and measures the result, which is the only way to catch overflow and clipping honestly, and it is far slower than reading data. Accessibility is both: its static checks read your Bricks data like the first three, and the rest ride along with the responsive pass, because contrast and focus outlines can only be judged as painted.

So on a site with more than 25 Bricks pages, the responsive pass measures the 25 you edited most recently rather than all of them. A 300-page site would otherwise mean 1,200 page loads in one scan. Your other three scores still cover everything.

If you want a wider sweep, raise the cap with a filter:

add_filter( 'bricks_health/responsive_measure_cap', fn() => 100 );

Pages you have excluded in Settings are never loaded for measurement at all.

Baseline mode and score history

Inherited sites arrive with hundreds of findings, and most of them are not yours. Baseline mode draws a line under them. Open Baseline & score history from the trend icon in the dashboard header (between Settings and Fix history) and set a baseline: from then on, every scan marks only what is new since that line, in a New since baseline tab on each audit, with a “new” chip on each card, or “1 of N new” on a grouped finding. The score card carries the count as a pill, which opens the same panel.

A few things worth knowing about how it decides what is new:

• A finding is identified by its rule, its page, its element and its subject. A page that is deleted and recreated therefore reads as new, by design.
• There is one baseline per site. Setting another replaces it, and Reset clears it.
• The panel also shows the overall score across your retained scans, with the baseline’s scan marked and the change since the previous scan and since the baseline. History covers the ten most recent scans.

How to improve it

1. Start at the top of the findings list, issues are ranked by severity.
2. Apply Smart Fixes where they’re offered (they snapshot and undo cleanly, see Applying Smart Fixes safely).
3. Re-run the scan. The score updates immediately, so you can watch it climb.

A perfect 100 isn’t the goal on every project, a healthy, trending-up score is. Use it to decide when a build is ready to ship.