I built a free site speed report that names the slow file. Pro Watch ($19/mo) just went live.

The “quiet gap” is the part I’d lean into hardest. A lot of speed work fails because people treat one score as truth, then celebrate a fix that is still inside normal variance.

For Watch, I reckon the buying trigger is not really “monitor my score.” It is “tell me when a deploy created work I should actually schedule.” That means the alert has to separate noise from action very clearly.

I’d love to see alerts framed almost like: changed beyond quiet gap, likely file, expected impact, and whether it is worth an afternoon. That last bit matters because a 2-point dip and a 20-point regression should not create the same sense of urgency.

If PafCore can protect agencies from both missed regressions and pointless speed work, $19/mo becomes much easier to justify.

I haven't run PafCore yet. One reporting detail I'd look for: show the three individual measurements and label their spread as the observed range. For before/after checks, expose the browser version, test location, CPU/network settings and cache state so the comparison uses the same setup. Three quiet runs can still vary without a code change; a tighter spread alone doesn't establish that a fix worked. Lighthouse's variability guide explains why: https://github.com/GoogleChrome/lighthouse/blob/main/docs/variability.md . That would make the quiet gap easier to interpret.

I'm building something with a similar free-check → monitoring idea in a completely different space, so this was useful to read.

The part I'm struggling with too is whether the free result creates enough reason to come back. I like that you're treating the return visit after a fix as the real signal instead of just counting free reports.

Curious to see whether Watch converts once you have more stranger traffic.

Hey Femi,

Tested [https://progressinc.netlify.app/](https://progressinc.netlify.app/) on PafCore and ran a GTmetrix check alongside it. Here is the direct report breakdown and comparison feedback to help answer your questions:

---

### GTmetrix vs. PafCore Comparison

• GTmetrix (Desktop / Seattle): 75% Performance | LCP: 555ms | TBT: 475ms | CLS: 0
• PafCore (Mobile Throttled): 48/100 Score (Variance: 47 to 56) | Main picture display wait: 11.3s

Key Insight: GTmetrix hides the real mobile execution bottleneck. On a fast desktop CPU, GTmetrix logs a rapid 555ms LCP. However, PafCore’s mobile emulation exposes that wiki_logo.jpg finishes downloading quickly, but script parsing (dist-DO_wn7qf.js locking the main thread for ~2.7s) delays actual image rendering by nearly 10.9s.

---

### Feedback on Your Questions

• Does "Start Here" feel true? Yes. Pinpointing the exact bundle (dist-DO_wn7qf.js) blocking the rendering of wiki_logo.jpg gives a clear entry point. Standard audits usually just output a generic "Reduce JavaScript execution time" without mapping the script to the visual element it delays.
• The 9-point noise gap: Highlighting the variance band (47 to 56) is the best feature on the page. Knowing that a 5-point jump post-deploy could just be run-to-run variance saves hours of chasing phantom fixes.
• What makes $5 credits worth it: Being able to isolate whether splitting dist-DO_wn7qf.js specifically clears the mobile render lock before committing code to production.

Nice work on closing the loop between standard Lighthouse scores and actual script-to-file tracing!

Free path leading into a paid diagnostic is a smart funnel, especially for people who already suspect something's slow but don't know where. I'm building something in a totally different space (team chat for AI agents) but the same instinct applies: give people the free thing that proves the pain is real before asking for money.

This is a really interesting approach. I like that you focus on identifying the actual slow file instead of just giving users another performance score.

I build websites and landing pages with AI, so the “what should I fix first?” part is especially useful for me. I’ll try it on one of my demos and share some feedback if I find anything interesting.

I tried it on my site, and the H1 finding was accurate. Traced the root causes myself: an unnecessary auth check was gating the entire page render before anything could paint; there was no route-level code splitting, so the landing page shipped the whole app's JS bundle, and a render-blocking third-party script sat ahead of the deferred module scripts in the document head. Fixed all three. Good, specific finding — not generic advice."

100% resonate with this. Managing complexity and staying lean is always the hardest part in the early days.

This is a really interesting approach. I like that you focus on uncovering hidden data gaps instead of just giving users another generic dashboard.

I run an AI consultancy for UK businesses, so the “what should I fix first?” part is especially useful for me. I’ll try it on one of my test sites and share some feedback if I find anything interesting.

The quiet gap is a useful idea because it stops a one-off Lighthouse jump from looking like a fix. I’d be curious whether you plan to show the three raw runs right beside the recommendation, so people can see when a change actually clears the normal spread rather than just landing on a nicer score.

The "quiet gap" idea is smart — most tools just give you one number and let you assume it's stable. One thing I didn't see covered above: does the free report only work on public pages, or can it also test logged-in views? A lot of the slowest experiences I've run into are actually behind auth (dashboards, account settings), and those never show up in public speed audits since almost every tool needs a publicly reachable URL to run against.

Congrats on shipping — the credit-pack-plus-subscription-bundle model is simple at this stage but worth locking down two things before "stranger paid credits" (your next gate) scales it up: do unused credits expire or roll over, and does that change month to month with Pro Watch's bundled 60? Doesn't affect anything today, but it's the kind of thing that's painless to decide now and annoying to retrofit later once real volume hits. On your Q3 — price isn't what'd stop me buying $5 in credits, clarity on what happens to the ones I don't use is.

I ran PafCore against my own site out of curiosity. Interestingly, Chrome Lighthouse is giving me 99 Performance, 96 Accessibility, 100 Best Practices and 100 SEO, while the three PafCore runs came back at 71, 78 and 82. The 96 Accessibility is from a contrast issue I already know about, so I'm particularly curious about the performance difference. How are you defining the PafCore score and baseline compared with Lighthouse?

The “quiet gap” idea is really interesting. I’ve definitely seen PageSpeed scores jump around between runs and wondered whether a change actually helped or I just got a better run. Nice way of thinking about the problem.

The free report is a good conversation starter because it gives people a concrete artifact. For finding first customers, I’d spend a week with one narrow group—small agencies managing a handful of client sites—and ask what they do after a bad score. The follow-up behavior (retest, share the report, or add another site) will tell you which audience has real urgency better than likes.

thanks

The quiet-gap idea is the best part of this, and it is the piece almost no speed tool exposes. Most people never learn that a single lab run has a confidence interval, so they ship a change, watch the number move six points, and file it as a win. Three quiet loads plus the spread between them turns a score back into a measurement.

One failure mode worth adding to the report later, because it is invisible to every speed tool including this one: a page can be genuinely fast and still convert nothing, because the only button on it sits below the fold on the viewport most of the traffic actually uses.

The check takes a minute. Chrome, Cmd+Shift+M for the device toolbar, custom size 390 x 844 (the CSS viewport of an iPhone 12, 13 and 14), hard reload, then do not scroll and count the primary actions you can see. On a normal hero the arithmetic goes: sticky header and padding about 140, a 48px headline that sits on one line at desktop wrapping to three about 170, a two-line subhead becoming four about 110, a stacked 16:9 hero image across a 390 column about 220. That is roughly 640 of your 844 gone before the first real sentence.

Programmatic and long-tail pages fail it hardest, and it is not sloppiness: the first screen comes from one template reviewed once at desktop width and then multiplied across hundreds of URLs. One template fix moves every page.

For anyone who wants the non-speed side graded in the same sitting, ContentMation has a free score at contentmation.com/score covering six channels including technical. A different question from PafCore, which answers "which file is slow" directly.

Cool website design!

The real test: what % of free users hit the wall that makes them upgrade? Not "we gave 1000 people the free report." The meaningful signal is how many run it, get actionable insights, and then want to keep running it on their sites. That's the measurement that separates freemium conversions that actually drive revenue from ones that just add to the noise.

Naming the slow file is the right DX. Most site-is-slow reports are too abstract to act on. If Pro Watch can show the owning route or component next to the file, that is an even faster loop for solo builders who do not have a perf team. SAO-W2-SPEED

The quiet gap idea is the most useful part of this. Showing how much the score moves with nothing changed reframes the whole conversation. Clients stop chasing the number and start asking about the actual file. That is a much better place to have the conversation from.

The $5 credit after a fix makes sense as a gate. You already gave them the problem and the file. The credit is for proof that the fix worked, which is the thing anyone selling speed work needs to show a client. That feels like a natural next step rather than a paywall.

Tried it on utilvance.com. The start here call was clear and the file level detail was more useful than a score alone.

The free report and paid monitoring form a clear “diagnose, then prevent” progression. I’d make the first return visit the main activation event: after someone fixes the named file, prompt them to schedule a retest so you can see whether the free answer naturally creates demand for Watch. For the agency segment, the client-facing report idea could be a stronger value signal than adding more dashboard detail.

The quiet gap is a smart way to make noisy speed scores actionable, especially when a founder is deciding whether a fix actually helped. I would be curious to see whether the report can separate files the site owner controls from third-party scripts, since that changes the next step completely. The free report plus a clear retest loop feels like a useful wedge for agencies and solo builders alike.

I build an audit tool with a free scan, so adjacent to you rather than the same thing. Nineteen comments in and nobody has raised what I think will produce your hardest support ticket: lab versus field.

Three quiet loads is lab data. If someone cares about speed because of SEO, the number Google actually uses is CrUX, which is real user data over a rolling 28 day window. So the sequence goes: they fix the file you named, your report improves that afternoon, and their Core Web Vitals in Search Console do not move for up to a month. From where they sit, that looks like your tool being wrong.

CrUX is free through the API. Pulling it alongside your lab run would let you say something no other free report says: here is what moved in the lab today, here is the field number it should move, and roughly when.

Worth telling them plainly when a page has too little traffic to have CrUX data at all. That is its own useful finding.

If the buyer is an agency, $19/mo is the wrong shape. Agencies do not buy monitoring, they buy something they can put their logo on and bill a client for, so a white-labeled report priced per client site lands ten sites in one sale instead of one seat. That also fixes your funnel, because the agency owner holds the deploy access and the budget, while the solo freelancer you are attracting today has neither.

The "quiet gap" frame is pure measurement design - it proves to yourself that the score is noise. But here's the conversion gate I'd watch: the free report solves the diagnosis problem (what's slow). The real question is whether naming the file creates a paying user gap.

Split your early users three ways:

• Diagnosis only (free report, never return)
• Diagnosis + curiosity (open credits, never retest)
• Diagnosis + conviction (retest after a fix, become Pro)

That third bucket is the only number that matters for monetization. The free report doesn't convert them - the confidence after they fix something converts them. You're not selling naming the file. You're selling proof that the fix worked.

Right now "credits" is a lever but not a signal. Once you have 50+ reports where someone named a file, fixed it, and then paid for a retest to verify - that's when you know the monetization actually works. Until then, free report might be complete product for 95% of the market.

The "quiet gap" framing is the part that would have saved me time. What stopped me with similar tools was that the named slow file was usually a third-party tag I couldn't change. If the start-here list splits "yours to fix" from "tell your vendor", the answer stays true.

"Building in the open on X" is the line I can answer. I opened that account tonight: 405 followers. A reply I sent last night has about 20 views. The site table still has no row labeled indiehackers.

Naming the slow file is the same job as naming the thread. The paid part only starts if someone comes back after the name.

I would write down which X reply this week named a file and then opened Watch, versus which reply only got a like. Two columns. One week.

Which column has a number tonight?

The free report answers “what’s slow.” Credits need to answer “did my fix work?” before the user leaves. Are you tracking how many reports reach a retest after a specific file is named?

The free report proves the diagnosis; the real test is what happens next. Are users actually paying for credits or Pro Watch after seeing a concrete slow file, or is the free report solving enough of the problem by itself?

https://pafcore.site/