I've been using Fathom's site speed dashboard more heavily over the last few months, and it's become a crucial part of my routine site audits. While it's not a full replacement for tools like WebPageTest or Lighthouse for deep, one-off analysis, it's fantastic for tracking performance trends and catching regressions over time.
The key is knowing what to look for and how to connect this data to action. Here's my typical workflow:
* **Start with the Core Web Vital trends.** I don't just look at the current "Good/Needs Improvement/Poor" status. I set the date range to the last 30-60 days and check the graphs for LCP, INP, and CLS. A slow creep in LCP often points to a new render-blocking resource or hosting issue.
* **Correlate spikes with deployments.** I'll note any sharp changes in the metrics and cross-reference them with my deployment calendar. Fathom's overlay of "Annotations" (if you use them) is perfect for this.
* **Segment by page group.** This is powerful. I create a group for key funnels (e.g., `/pricing`, `/signup/*`) and compare their performance against the site average. It quickly shows if a critical business page is underperforming.
To make this data actionable, I pipe it into a spreadsheet using Fathom's API. A simple weekly check for pages that have slipped from "Good" to "Needs Improvement" flags issues before they impact too many visitors.
Here's a basic example of the API call I use to get vital data for a specific page group:
```bash
curl "https://api.usefathom.com/v1/aggregations?entity=pageview&entity_id=&aggregates=visits&field_grouping=page&date_from=2024-05-01&date_to=2024-05-28&fields=lcp,cls,inp"
-H "Authorization: Bearer YOUR_API_TOKEN"
```
How are others using this data? Have you found effective ways to automate alerts or connect it to your CI/CD pipeline to prevent performance regressions from being merged?
Correlating spikes with deployments is the step most teams miss. They see the regression and start a wild goose chase, when the commit log already has the culprit.
Annotations are useful if you're disciplined. I've seen teams add them for a week then forget, making the historical data worse than useless. You need to automate it, tie it to your CI/CD pipeline, or don't bother.
Segmenting by page group is key for audits. If a compliance-related page, like a data request form or privacy notice, is slow, you've got a real problem that isn't just about bounce rates.
Trust but verify – and audit
That's a really helpful workflow breakdown. I'm still trying to get my head around the Core Web Vitals data from our setup.
When you say you cross-reference spikes with your deployment calendar, is that a manual check each time? I'm wondering if there's a simple way to tag Fathom data with a version number automatically, maybe from a GitHub Action. Seems like that could save some guesswork later.