Introducing CodeGecko: a straight answer after every deploy.

Today we’re opening the CodeGecko waitlist.

CodeGecko answers one question after every deploy: did this release make your site faster or slower for the people using it? Not a score. Not a trend line you have to squint at. A verdict, per release, with the page to fix.

The question we kept asking

Teams ship several times a week and rarely know what a release did to speed. Every tool we tried could show a number. None could say, with confidence, whether last Tuesday’s deploy was the one that slowed checkout. Three things kept getting in the way.

1. 01Lab scores aren’t your visitors. A Lighthouse run on a fast laptop says little about a mid-range phone on a train.
2. 02Averages hide the slow page. A site-wide “fine” can sit on top of a product page that got 25% slower.
3. 03Regressions surface weeks late. By the time a dashboard trend looks off, ten releases have shipped.

So we built the comparison first, and everything else around it.

What CodeGecko does

Your CI tells CodeGecko which commit is live. Your visitors’ browsers report how each page load felt. CodeGecko then compares every release with the one before it, page by page and device by device, using real visitors’ Core Web Vitals.

Each metric gets a verdict, and the verdicts roll up into one word for the release:

Here the release is Mixed: interactions got faster and layout got steadier, but the largest element on mobile now paints 130ms later. That’s the line to look at first.

Rules, not guesses

Every verdict comes from the same three published questions, applied the same way to every release:

1. 01Is there enough data? At least 30 real visits on both releases, for that page, device and metric. Otherwise the verdict is Inconclusive.
2. 02Is the change real? The 75th percentile has to move by more than 5% or the metric’s floor, whichever is larger. Otherwise it’s Unchanged.
3. 03Which way did it move? Every metric is lower-is-better, so the direction decides between Improved and Regressed.

“Inconclusive” is an answer. When there isn’t enough data, we say so instead of guessing.

No AI guesses, no p-values dressed up as certainty, no claims about cause we can’t back up. The methodology lists every floor and rule, with the numbers.

Setup: one script tag, one CI step

Add the collector to your site, and add one step to your deploy. Each new commit becomes the next release: v1.0.0, v1.0.1 and so on. Roll back, and the old version goes live again.

<!-- 1 · In your site’s <head> -->
<script async src="https://www.codegecko.dev/collector.js"
  data-project="…" data-key="cg_pub_…"></script>

# 2 · In CI, after each production deploy
curl -X POST https://www.codegecko.dev/api/releases \
  -H "Authorization: Bearer $CODEGECKO_SECRET" \
  -F projectId=… -F commit=$GIT_SHA
# → { "version": "v1.0.7" }

The collector is built on Google’s web-vitals library, weighs about 7 kB and loads async, so it never blocks rendering. Your next two releases are your first comparison.

When a release got slower

A verdict tells you that something moved. The report puts the evidence next to it, so you know where to start:

1. 01Which page? Every comparison breaks down by page and device, so one slow template can’t hide behind a healthy average.
2. 02Where did the time go? Load steps from DNS to DOM ready, plus long animation frames and the script that blocked longest.
3. 03What got heavier? JavaScript, CSS, image and font bytes per page, and the cost of third-party domains.
4. 04What shipped? The commits that went out with the release, with a link to compare them on GitHub.

Privacy by default

CodeGecko doesn’t collect query strings, fragments or cookies. IDs, emails and tokens in URLs and error messages are replaced before anything leaves the browser. The public key in your script tag can only send data, only from your site, and secrets are stored as hashes.

Why a waitlist

The verdict rules are stable. Everything around them is young, and we’d rather get it right with a small group than open the doors to everyone at once. So we’re letting teams in a few at a time, and early access is free.

Join the waitlist and we’ll email you once, when your spot opens. Nothing before that. If you want to see it working first, the demo runs on a sample project with real reports.

We read every message. If there’s a metric you want measured, or a reason CodeGecko wouldn’t fit your stack, tell us.