Hoppla runs Google Lighthouse against mobile and desktop in a single check and scores Performance, Accessibility, Best Practices and SEO from 0 to 100. It keeps the lab metrics behind each score (LCP, CLS, TBT, the rest) plus up to eight failing audits per category. So you don't just see that a score fell. You see what pulled it down. And it stays in its lane: it flags a warning on the monitor, it never opens a downtime incident.
acme.io lighthouse · mobile perf 41 / desktop perf 88 · worst 41 → WARNING · LCP 4.2s · TBT 610ms · top fail: unsized images
Fictional values. Not a live measurement.
Every run, Hoppla drives Google Lighthouse against your page as a throttled mobile device (three runs, median kept) and as desktop, and scores four categories from 0 to 100 on each: Performance, Accessibility, Best Practices, SEO. It pulls the lab metrics behind those scores (FCP, LCP, CLS, TBT, Speed Index, TTI) per form factor, and lists up to eight failing audits in every category, heaviest first, so the recommendation is already sitting in the result. The status comes from the lowest category score across both devices. A healthy desktop can't paper over a mobile that fell apart.
A worker runs Google Lighthouse against your URL as a throttled mobile device, three times with the median kept, and once as desktop, inside one check. Both form factors come off a single schedule, not two monitors you have to keep in sync. The throttled-mobile run is usually the one that tells the real story.
Each run scores Performance, Accessibility, Best Practices and SEO from 0 to 100, per form factor. Hoppla stores the lab metrics underneath (FCP, LCP, CLS, TBT, Speed Index, TTI) so a Performance score isn't a mystery number. You can tell a slow LCP from main-thread blocking in TBT.
For every category, Hoppla keeps up to eight failing audits, the heaviest first: unsized images, render-blocking resources, missing alt text, whatever Lighthouse flagged. The fix list rides along with the score. No re-running the audit by hand to find out what to do next.
Hoppla takes the lowest category score across mobile and desktop and applies your thresholds, OK at 70+ by default, WARNING under 70, FAIL under 30, adjustable per check through the API. This is advisory. It flags the regression on the monitor; it never opens a downtime incident or treats a slow page like an offline one.
Most teams glance at desktop in DevTools and ship. Hoppla scores both form factors every run and grades on the worse of the two, so the throttled-mobile Performance score, the one your actual users feel, can't slip through just because desktop looked fine.
Anyone can run Lighthouse once. Hoppla runs it on a schedule and watches all four categories over time, so the deploy that quietly dropped Performance from 88 to 41 trips a warning while it's still your problem and not a user's.
A number that fell tells you nothing you can act on. Hoppla keeps up to eight failing audits per category plus the lab metrics behind them, so "Performance dropped" comes attached to "because LCP is 4.2s and three images ship unsized."
Late on a Friday you merge a marketing font and three hero images and ship, because the only QA step is you. Mobile Performance falls off a cliff and you'd never know until conversions sag. Hoppla re-runs Lighthouse on a schedule and shows you mobile Performance went 84 to 39, with LCP and the unsized images named, so you fix it before users start bouncing off a landing page that now takes four seconds to paint.
Your clients don't read JSON. They read the monthly. Schedule a Lighthouse audit per client site and the Accessibility and SEO scores turn into a number that moved: "a11y 76 to 91 after we shipped the alt text and labels." It's a recurring deliverable that shows the retainer earns its keep, and the failing-audit list tells your developer exactly what to bill against next month, no re-auditing twenty sites by hand.
Nobody is opening DevTools on hundreds of client sites, and one CMS theme update can tank Best Practices across a whole cohort at once. Every site is scored on a schedule and graded on its worst form factor, so a category dropping below threshold raises a warning on that site's monitor, and the account manager can see "site 47 regressed" before the client files a ticket. The scores sit next to that site's uptime and SSL, one monitor each. Not a separate audit tool to license.
Performance auditing is a recurring upsell that costs you nothing to build. Hoppla is white-label, so the scores, the failing audits and the report carry your brand on your domain, and your customers never see us. Sell scheduled mobile-and-desktop Lighthouse audits as a tier on top of the hosting they already buy, set the OK/WARNING/FAIL thresholds (per check, via the API) to the standard you promise, and let the warnings show up under your name as proof you're watching their speed.
Import the monitors you already run in another tool. What comes across depends on the provider. Run both side by side for 24 hours or 7 days before you switch.
The importer opens in your workspace once you have access.
Get early accessDebugBear is a dedicated performance-monitoring product, and if continuous lab-and-field analysis is your whole job, it goes deeper than this does. Hoppla's angle is different. Lighthouse audits live on the same monitor as your uptime, SSL, DNS and cron checks, on one dashboard and one bill. You get scheduled mobile-and-desktop scores, the failing audits and regression warnings without standing up a second tool. Performance is one more check on a site you're already watching.
Lab. Hoppla runs Lighthouse in a controlled, throttled environment, so the numbers are synthetic and repeatable, which is exactly what you want for catching the regression a deploy introduced. That's a different thing from field data like CrUX, gathered from your actual visitors over time. Lab answers "did this change make the page slower?" It isn't a measurement of what every real user experienced.
No. Lighthouse is advisory. A low score marks the check as warning (or failing, under 30) on the monitor, but it never opens a downtime incident. A slow page is something to schedule, not a 3am wake-up, so it won't hit you the way a confirmed, dual-region uptime failure does.
Yes. The thresholds are configurable per check through the API. The defaults are OK at 70 and above, WARNING below 70, FAIL below 30, applied to the worst category score across both form factors. Tighten them to whatever standard you hold sites to, handy if you're a reseller committing to a performance SLA.
Checks, alerts and status pages in one workspace. Now in early access: join the list for an invite.