Bloosprout.co.uk scored 61 out of 100 on mobile Lighthouse this week. Desktop scored 95. We are publishing both numbers today, not once mobile catches up, because that is the actual test of the receipts model we sell to everyone else: does it survive pointing at ourselves.
If we only published the numbers that made us look good, "receipts" would just be a word in a pitch deck. The rule we hold clients to is that a claim without a re-derivation command does not ship. No case study, no scorecard, no line on a services page gets to stand on a number nobody can re-run. The same rule applies to us, including on the day the command comes back with a number we would rather not show you. This post is not a before-and-after. There is no earlier snapshot of our own site to compare against, because we had not run this check on ourselves before. It is a starting point, dated and reproducible, and a log of what has moved against it since.
The number, and how to check it yourself
We ran npx -y lighthouse@12 <url> --preset=perf --form-factor=mobile --screenEmulation.mobile --chrome-flags="--headless=new" against bloosprout.co.uk three times, headless Chrome, mobile emulation. Mobile came back 61. The same command with the desktop preset gave 95. Anyone can run that exact line against our homepage right now and expect to land in roughly the same place. That is the point of publishing a command instead of a screenshot: the number stops being ours to manage.
Sixty-one is not a catastrophe, but it is a real gap against the 95 we get on desktop, and it trails both of the other sites referenced below. We are not filing it under "on the roadmap" and moving on. It is on the roadmap, queued for the next build, and this post is the log of what has moved so far and what has not. We will come back and update it as that work lands, rather than let a fixed number sit next to a stale post that no longer describes the site.
What was actually broken, and what we fixed first
The same night we ran the Lighthouse numbers, we also captured a metadata baseline across every page on the site: titles, descriptions, canonical URLs. What that baseline found was not a performance bug, it was worse in a quieter way. The site's root layout was setting a single canonical URL for every page: the homepage. That meant /about, /blog, /privacy, /cookies, and every blog post were each declaring themselves a duplicate of the homepage to any search engine that checked. Only the free calculator tools, which set their own canonical individually, escaped it.
That kind of defect does not throw an error. Nothing 404s, nothing crashes, every page still renders fine in a browser, which is exactly why it survives so long unnoticed. What it does is tell Google that only one page on the site is worth indexing as itself, and everything else is a copy of the homepage not worth ranking on its own terms. A blog can publish good work against that for months and never understand why none of it shows up in search, because the symptom looks identical to simply not ranking yet.
That one is fixed now. Each page sets its own canonical through its own metadata export; there is no shared default left at the layout level for a page to silently inherit. It will not move the Lighthouse score by a single point, it was never a performance problem, but it is the kind of defect that costs more, over more time, than a slow paint does, so it went first.
Why we are confident mobile is fixable too
We are not guessing that a 61 can move, because we have moved this exact number before, just not on our own site yet. A UK property platform we run currently holds 93 on mobile and 99 on desktop, after its own optimisation pass. On a venture-backed e-commerce SaaS we ran a rescue pass for, mobile moved from 40 up into an 83 to 88 range. Two different codebases, two different root causes, neither one obvious from the score alone until someone actually opened the trace and looked at what the page was doing before it painted.
We do not have a diagnosed single cause for our own 61 yet. That is honest, not evasive: the point of a fix log is that you get to see the "we don't know yet" entries alongside the "here's what we found" entries, not only the second kind. What we do know is the shape of the work, because we have done that shape of work twice already elsewhere: profile the actual page, find what is holding up the largest paint or blocking the main thread, cut or defer it, re-run the same command, and only then claim the new number.
What is still open
Mobile performance on this site is queued for the next build pass. When that work lands, this becomes a real before-and-after with a command on both ends, not a promise with one end missing. Until then, 61 is the honest current number, and it stays the number in this post even after we have improved it elsewhere on the site, because a fix log that quietly edits its own starting point stops being a log.
If you want to see how we score and verify work more broadly, including where it fails, that lives on our receipts page. And if you want the same kind of pass run against your own site, mobile score, canonical tags, and the rest of it, the way to start is to book the free 15-minute audit, not a sales call dressed up as one.