NewNow measuring page weight, third-party cost and JS errors on every release.See what’s new
Sign inConnect your site

Release performance monitoring

Catch performance regressions in every deploy.

CodeGecko compares each release with the one before, using real visitors’ Core Web Vitals — and shows you what got faster, what got slower, and the exact page to fix.

Connect your site Explore the demo
v1.0.7 vs v1.0.6 · mobileMixed
LCP2.71s +5.0%Needs improvementRegressed
INP161ms −18.7%GoodImproved
CLS0.036 −29.4%GoodImproved

FCP and TTFB unchanged.

Start with /products/:slug — LCP +25% there on mobile (+5% site-wide), and 114 kB more JavaScript.

Sample project · typical visit · not customer results

Setup

One script tag.
One step in CI.

Add the collector to your site and pages group themselves: /products/blue-shoe-42 becomes /products/:slug. After each deploy, CI sends the commit, and it becomes the next release: v1.0.0, v1.0.1, and so on. Roll back, and the old version goes live again.

Send your recent git history with it, and any release that regresses lists the commits that shipped in it.

In your site’s <head>Public key
<script async
  src="https://codegecko.vercel.app/collector.js"
  data-project="…"
  data-key="cg_pub_…"></script>
After each deploy · deployment secretRequired
curl -X POST https://codegecko.vercel.app/api/releases \
  -H "Authorization: Bearer $CODEGECKO_SECRET" \
  -F projectId=… -F commit=$GIT_SHA
→ { "version": "v1.0.7" }

Works from any CI. Add data-commit to the tag to match every visit to its exact build.

Beyond the vitals

When a page gets slower, see where the time went — and what shipped.

Sample project · /products/:slug · mobile · v1.0.7 vs v1.0.6

  1. 01

    Which page?

    The one slow page, found.

    Every comparison breaks down by page and device, so an overall “fine” can’t hide a regression — and pages grouped wrongly can be merged.

    /collections/:slug2.58s → 2.17s−16.0%
    /products/:slug2.71s → 3.39s+25.0%
    /2.37s → 2.39sUnchanged
  2. 02

    Where did the time go?

    Load steps

    DNS, connect, server, download and DOM ready — so a slower load has an address.

    DNS 20Connect 60Server 380Download 70DOM ready 410

    DOM ready 410ms · up 120ms this release

    Long animation frames

    Main-thread blocking per visit, with the script that blocked longest.

    340ms Needs improvement

    longest: gallery.[hash].js

    Chrome and Edge

  3. 03

    What got heavier?

    Page weight

    Compressed JS, CSS, image and font bytes each page actually loaded.

    JS
    412 kB +114 kB
    CSS
    48 kB
    Images
    1.2 MB
    Fonts
    96 kB

    Third-party cost

    Bytes and blocking from other domains. Only domains are sent, never URLs.

    • analytics.example.net140ms blocking
    • chat-widget.example.io96 kB
    • fonts.example.com58 kB
  4. 04

    What shipped?

    What shipped

    When a release regresses, its report lists the commits that went out with it, with a link to compare them on GitHub.

    3 commits since v1.0.6 · newest first

    • a41c9e2Add product image gallery
    • 7d03b18Lazy-load reviews
    • c2f8a01Bump analytics SDK

    What shipped, not a diagnosis · Compare on GitHub

    JavaScript errors

    Share of visits with an error, plus the top messages — emails, IDs and tokens stripped.

    1.8% from 3.1%

    TypeError: cart is undefined

Privacy by default. No query strings, no fragments, no personal segments. The browser key only sends data, only from your site, and secrets are stored as hashes.

Three questions. Every metric. Every release.

  1. 01Is there enough data?

    At least 30 real visits of the metric on both releases, for the page and device you’re viewing.

    Otherwise: Gathering data

  2. 02Is the change real?

    The 75th percentile has to move by more than max(5%, a per-metric floor).

    Otherwise: Unchanged

  3. 03Which way did it move?

    Lower is better. No AI guesses, no causal claims.

    Improved or Regressed
verdict · v1.0.7 vs v1.0.6 · mobile · typical visitSample project
Metrictypical visit, before → after01 · visits02 · change vs threshold03 · directionVerdict
LCP2.58s → 2.71s214 / 196 +130ms vs 129ms Regressed
INP198ms → 161ms182 / 167 −37ms vs 20ms Improved
CLS0.051 → 0.036214 / 196 −0.015 vs 0.010 Improved
FCP1.69s → 1.71s214 / 196 +20ms vs 100ms belowUnchanged
TTFB652ms → 606ms214 / 196 −46ms vs 50ms belowUnchanged
Improved and regressed together release isMixed
Mixed Some metrics improved, some regressed.Regressed At least one regressed.Improved At least one improved, none regressed.Unchanged Nothing moved past its threshold.

Each release is compared with the one before it. Health badges use Google’s Core Web Vitals ranges and show where a metric stands; the verdict shows how it moved. Load steps and third-party cost explain changes but don’t decide verdicts.

The full methodology

Before you connect

A few useful answers.

Something else? Ask us or browse the setup guides.

One script tag with your project ID and public key, plus one step in CI after each deploy that sends the git commit. The dashboard gives you both, ready to copy.

As people visit. Your first release is the starting point; the comparison starts with the next one, once both have 30 visits per metric for the page and device you’re viewing.

You’ll still collect data, but verdicts take longer. Until there’s enough, results show Gathering data rather than a guess. If the next release replaces one before it gets enough, that comparison ends Inconclusive.

Every full page load is measured, on any framework. Route changes inside a single-page app (soft navigations) aren’t tracked yet.

Not on its own. When a release regresses, its report lists the commits that shipped in it, with a GitHub compare link, next to what changed: pages, load steps, blocking scripts, bytes and third parties. It doesn’t say which commit caused it. Code-diff analysis is on the roadmap.

Lighthouse is a lab test: one simulated load on one machine. CodeGecko uses your real visitors, compares each release with the one before it, and breaks the result down by page and device.

It’s about 7 kB gzipped and loads async. It sends data in batches when the page is hidden, never retries, and stops for the session after any rejection. On busy sites, data-sample="0.25" measures a quarter of page loads.

No cookies. Query strings and fragments are never sent; IDs, emails and tokens in URLs and error messages are replaced; third parties are reported by domain only.

Every browser that reports these metrics. Long animation frames come from Chrome and Edge only.

Early access

Free while in early access.

Launch pricing when paid plans open. Every feature on every plan; plans differ only in projects, traffic and history.

Connect your site See pricing

Starter

$19 /month

  • 1 project
  • 30 days of history
  • All features

Pro

$49 /month

  • 5 projects
  • 90 days of history
  • All features

Scale

$99 /month

  • 15 projects
  • 180 days of history
  • All features

USD, billed monthly once paid plans open. Higher plans also include more traffic — details on the pricing page.

Ready when you are

Stop guessing what your deploy did.

One script tag and one CI step. Your next two releases are your first comparison.

Connect your site How it works

Free while in early access.