Site Health

What this page shows

Every number here comes from a real Lighthouse audit run against a production build of this site. Lighthouse loads the page in a headless browser, throttles the connection and the CPU to imitate a mid-range phone, and reports four category scores out of 100 plus the three Core Web Vitals that describe how the page felt to load.

The scan covers one representative page per template rather than every URL. Templates are what actually differ: a service detail page, a hub, an intake form, a search page. Fixing a template fixes every page built on it.

• Performance, Accessibility, Best practices, SEO: Lighthouse category scores. 90 and above is the pass line.
• LCP (largest contentful paint): how long until the main content appears. 2.5 seconds or less is good.
• TBT (total blocking time): how long the page was unresponsive to taps and clicks while loading. 200 milliseconds or less is good.
• CLS (cumulative layout shift): how much the layout jumped while loading. 0.1 or less is good.

An accessibility score is not a certificate. Lighthouse catches the machine-checkable failures, roughly a third of the WCAG criteria. The rest needs a human. The City’s full position on accessibility, including how to report a barrier, is on the accessibility page.

How these numbers are produced

1. The site is built for production and served locally, the same output that would go to a live server.
2. A scan script walks the template list and runs Lighthouse twice per page, once as a mobile device and once as a desktop, one run at a time so the runs do not compete for the machine. One discarded warm-up run comes first, so no measured page pays the cost of starting the tooling itself.
3. The four category scores and the three vitals are written to a JSON file alongside the timestamp of the run.
4. The next build reads that file and renders these tables. The date at the top of this page is the date of the scan, not the date you happen to be reading it.

That ordering is what keeps the page honest. There is no live monitoring behind it, no agent pinging pages in the background, and no dashboard service reporting on itself. The page shows the last measurement that was actually taken, and says when it was taken. If a run fails, that row reads “not measured” instead of borrowing an older number.

In an ongoing engagement, the scan belongs in the deployment pipeline, so every release measures itself and the numbers on this page are never older than the code that is live.

Why a city should ask for this

Most municipal website contracts describe accessibility and speed as promises. A promise is checked at launch, if it is checked at all, and then the site drifts. Content editors add a 4MB photo, a third-party widget lands on the payments page, a plugin update breaks a heading order. Nobody notices until a resident cannot complete a task, or until a complaint arrives.

A page like this changes who holds the evidence. The measurements live in the City’s own repository, on the City’s own site, in a format staff can read without a vendor login or a support request. Council can see it. Procurement can quote it. A resident who wants to know whether the City takes accessibility seriously can read the same numbers as everyone else.

It also changes what a vendor can get away with. When the score is published and dated, “the site is fast” stops being a sales line and becomes a number somebody can check. Any competent vendor can produce this page. The City expects it from anyone it hires.

Honest limits

The City of Silvermere is a fictional municipality, and this site is a concept build used to demonstrate how a municipal website could work. The city, the staff, and the services are invented.

The numbers on this page are not. They are real Lighthouse measurements of these real pages, taken at the time stamped above. What is being demonstrated is the pattern: measure the templates, publish the results, date them, and let anyone check.

Two things this page deliberately does not claim. It is not live monitoring, and it is not a WCAG conformance statement. It is a dated set of automated test results, which is exactly as much as an automated test can honestly support.

One score needs its own caveat. This concept site is deliberately excluded from search engines (every page carries a noindex directive) so a fictional city never pollutes real search results. Lighthouse treats that as a failed crawlability audit and caps the SEO category on every template. That cap is the cost of publishing the concept responsibly; a production municipal site carries no such directive, and its SEO category is measured without it.

This page is one of the concept’s testable patterns. See the rest of how this concept works.