We all know the drill. You launch a new website, run a Lighthouse audit, see a satisfying wall of green 90+ scores, and move on. Then six months pass. Marketing adds three new tracking scripts. Content uploads a 4 MB uncompressed hero image. A plugin update quietly breaks your caching headers.
When you finally remember to run Lighthouse again, those green circles have turned a depressing shade of orange and red.
Performance degradation rarely happens overnight. It happens slowly, one minor update at a time. The problem is not that we do not know how to optimize websites; the problem is that we do not monitor them consistently. Running Lighthouse manually is easy enough, but remembering to run it every week, tracking whether scores are improving or getting worse, and sharing those results with a client or a team? That is the part nobody actually does.
Lighthouse Dashboard started as an internal tool to solve exactly this. We kept using external services and online tools to run Lighthouse audits for our clients, but we wanted something we could run locally, on our own infrastructure, and (most importantly) track scores over time instead of just getting a one-off snapshot. So we built it.
🔗 View the repository on GitHub
👉🇫🇷 Read this article in french here | Lire cet article en français ici
👉🇮🇹 Read this article in italian here | Leggere questo articolo in italiani qui
What Lighthouse Dashboard is
Lighthouse Dashboard is a self-hosted, open-source tool that runs Google Lighthouse audits on a schedule, stores the results in a local SQLite database, and serves a web interface where you can track performance trends over time.
It is designed for developers, agencies, and freelancers who want ongoing visibility into site performance without paying monthly fees for a SaaS monitoring platform or setting up a complex stack involving Docker, PostgreSQL, and a separate frontend build pipeline. You install it via npm, point it at your URLs, and it runs in the background.
The tool is built on top of the same Lighthouse engine that powers Chrome DevTools audits. Every audit captures four category scores (Performance, Accessibility, Best Practices, and SEO) and six raw Core Web Vitals metrics: First Contentful Paint (FCP), Largest Contentful Paint (LCP), Cumulative Layout Shift (CLS), Total Blocking Time (TBT), Speed Index (SI), and Time to Interactive (TTI).
The problem with manual auditing
If you rely on manual Lighthouse runs, you are operating without a baseline. When a client complains that their site feels slow, you open Chrome DevTools, run an audit, and see a Performance score of 65. But was it 65 last week? Was it 85 before the new marketing campaign launched and added four third-party scripts? Without historical data, you have no way to know.
The second problem is consistency. Running Lighthouse on your local machine produces results influenced by your current CPU load, your browser extensions, and your local network conditions. Two runs on the same page five minutes apart can produce noticeably different scores. By moving audits to a dedicated background process with a consistent headless Chrome environment, you eliminate that local variance and get data you can actually compare over time.
It is the same idea behind FlowAudit: replace scattered manual checks with a structured, repeatable process that gives you data you can act on.
How it works
The architecture is deliberately simple. When you start the dashboard server, a scheduler fires immediately and then repeats on a configurable interval (the default is every 24 hours). On each tick, it iterates over every URL you have added, runs a Lighthouse audit in headless Chrome, and saves the results to a SQLite database file on your disk.
The web interface is served by the same Node.js process. There is no separate frontend application to build or deploy. The UI is plain JavaScript with Chart.js for the trend charts, served directly as static files. It auto-refreshes every 30 seconds, so results appear without any manual page reload.
The database
The entire data store is a single SQLite file. This is intentional. There is no database server to provision, no connection pooling to configure, and no backup procedure more complex than copying a file. The database uses WAL (Write-Ahead Logging) mode to handle concurrent reads without locking issues, and each audit record is roughly 200 bytes, so even thousands of audits stay well under 100 MB.
The CLI
The tool is usable entirely from the command line, without opening the web interface at all. You can add URLs, list what is being monitored, run one-off audits, and remove URLs with simple commands. The CLI outputs color-coded results directly in the terminal, which is handy during development when you want a quick score check without spinning up the full dashboard.
If you already use Prismo for on-site audits, Lighthouse Dashboard is the natural complement: Prismo gives you the snapshot, Lighthouse Dashboard gives you the trend.
The trend charts
The most useful feature in practice is the trend chart view. Click the Trend button on any site card and you get a line chart showing how all four scores have moved over the last 30 days. This is where the tool really earns its keep: when a client asks why their SEO score dropped last Tuesday, you can open the chart, point to the exact date, and correlate it with whatever was deployed that day. Without this data, that conversation is guesswork.
Getting started
The installation assumes you have Node.js 18+ and Google Chrome (or Chromium) installed. Both are standard on any development machine or server.
# install the dashboard and lighthouse
npm install -g @dishine/lighthouse-dashboard lighthouse
# add a URL to monitor
npx lighthouse-dashboard add https://yoursite.com "My Site"
# start the server
npx lighthouse-dashboard start
Open http://localhost:3000 and the dashboard is ready. The first audit runs immediately on startup, so you will have data within about 60 seconds.
For production use, we recommend running the process with pm2 or as a systemd service. Both ensure the dashboard keeps running after a server reboot. The README includes ready-to-use configuration for both.
If you want to put the dashboard behind a domain with HTTPS, a simple nginx or Caddy reverse proxy pointing to localhost:3000 is all you need.
What it is not
A few honest clarifications.
Lighthouse Dashboard does not replace a full synthetic monitoring service like Calibre or SpeedCurve. Those tools run audits from multiple geographic locations, support authenticated page testing, and offer alerting integrations. If you need that level of infrastructure, this is not it.
It does not audit pages behind a login by default. Lighthouse runs in a standard headless browser session. Authenticated page monitoring requires custom Lighthouse configuration that is outside the scope of this tool.
It does not send alerts. There is no email or Slack notification when a score drops below a threshold. You check the dashboard or query the API yourself. We may add alerting in a future version.
Why we built it
Before Lighthouse Dashboard existed, we were doing the same thing manually: running audits through external online tools, copying scores into spreadsheets, and trying to remember which client site we had checked last. It worked, but it was tedious, and the data was scattered across different services.
What we really wanted was simple: run those same audits on our own machine, automatically, and see how scores evolve over weeks and months, not just a single snapshot. We looked for existing tools that did this. Most were either enterprise-grade platforms with pricing to match, or required a full DevOps setup with Docker and Postgres that felt way too heavy for what is essentially “run Lighthouse, save the number, show me a chart.”
We built the smallest thing that would do the job. One npm install, one SQLite file, one web interface. Nothing more.
It is open source, MIT licensed, and available on npm as @dishine/lighthouse-dashboard.