You'll know
why it broke.

Kanso runs Lighthouse tests on every PR, cross-references regressions across builds, and uses AI to pinpoint the exact code change that caused the regression.

Book a demo →See how it works

30s setup

Zero CI changes

Auto preview detection

kanso Bot 2 min ago

Kanso | Performance Report

feature/new-hero → main · Vercel preview detected automatically

Metric	main	PR	Δ
Performance	94	71	−23	❌
LCP	1.2s	3.8s	+2.6s	❌
TBT	120ms	896ms	+776ms	❌
CLS	0.02	0.04	+0.02	⚠️
FCP	0.9s	1.1s	+0.2s	✅

🤖 Regression detected · Agent analysis in progress…

kanso

— Performance regression detected

Details

Regressions caught in the PR.
Not in production.

Kanso automates Lighthouse audits on every pull request, reads the diff to isolate what broke, and posts an actionable fix directly in the PR. No extra step in your workflow.

Ticket

Code

kanso

Audits

Analyse

Fix

Prod

Ticket

Code

kanso

Audits

Analyse

Fix

Prod

↓

What Kanso reads

Production baseline

Lighthouse on main — or your budgets if defined. Skipped when budgets are set.

PR preview audit

Same Lighthouse run on the deploy preview. Multi-page, auto-detected.

The PR diff

Only what changed — lockfiles, snapshots, and tests excluded.

What gets posted to the PR

components/Hero.vue· line 14

- <img src="/hero.webp" class="hero-img" />+ <img src="/hero.webp" class="hero-img" loading="lazy" />

kansocommented

LCP regressed by +2.6s. This PR added loading="lazy" to the hero image — but it's the LCP element. The lazy attribute bypasses the browser preload scanner, deferring the fetch until after layout. Remove it on above-the-fold images, and prefer fetchpriority="high" instead.

When it regresses,
it tells you why.

Detection is the easy part. The hard part is fixing it. On every regression, our agent reads the diff, the Lighthouse trace, and the fetch waterfall. Then he writes a Likely cause + Code suggestions straight in the PR.

PR #142 · perf/hero-lazy-load · Agent Analysis

claude-sonnet-4.6

Detected impact

Perf -28

9163

Lcp +3.6s

1.2s4.8s

Si +2.7s

1.4s4.1s

✷ Likely cause

LCP delay caused by `loading="lazy"` on the hero image

The LCP element — <img class="hero-img"> — received loading="lazy" in this PR.
loading="lazy" bypasses the browser preload scanner, deferring the network fetch until the image enters the viewport.
Since this image IS the above-the-fold viewport, the fetch is delayed by a full layout cycle — directly causing the +3.6s LCP.
Confirmed in trace: LCP resource fetch begins at 4 210 ms on this PR vs 650 ms on main.

↳ Prioritized actions

1. Remove loading="lazy" — never apply it to above-the-fold images.
2. Add fetchpriority="high" to explicitly signal the LCP element to the browser.
3. Pair with <link rel="preload" as="image" href="/assets/hero.webp"> in <head> for maximum fetch priority.

index.html

head.html

view raw ↗

24

25<section class="hero">

26− <img src="/assets/hero.webp"

27−alt="Kanso dashboard"

28−class="hero-img">

26+ <img src="/assets/hero.webp"

27+alt="Kanso dashboard"

28+class="hero-img"

29+loading="lazy">

30 <h1>Catch regressions before they ship</h1>

31</section>

33/* — agent suggestion — */

29−loading="lazy">

29+fetchpriority="high">

✦

Suggested fix — removing loading="lazy" and adding fetchpriority="high" recovers LCP −3.6s on the homepage.

Reads the diff

Source-aware

The agent traces the regression back to the actual lines you changed, not a vague Lighthouse hint.

Reads the trace

Lighthouse-grounded

Cross-references the Lighthouse trace timings and fetch waterfall before pointing to a cause.

Posts to the PR

Where you already work

The analysis lands in the PR comment thread. No new dashboard. No Slack. No tab to keep open.

Why not just
Lighthouse CI?

It's a great tool, but Lighthouse CI only tells you what regressed, not why.

Lighthouse CI

Numbers, no narrative.

✓Runs Lighthouse on every PR
✓Tracks scores over time
−Never reads your code
−"LCP regressed" : you go investigate

AI code review

Code, no runtime.

✓Smart feedback on the diff
✓Catches bugs and style issues
−Never runs your app
−Blind to runtime performance

Kanso

Metrics + the line that broke them.

✓Lighthouse on every PR
✓Reads the PR diff
✓Cross-references both
✓Find the root cause

Configure once,
enforced on every PR.

Kanso auto-detects your preview URL from Vercel, Netlify, Render, Railway, Cloudflare Pages, and AWS Amplify. Manage your configuration through a .kanso.yml file at the root of your repository to define custom pages and performance thresholds.

staging

Dynamic URL with {branch} or {pr}. Works with any host.

urls

Audit every critical page, not just the homepage. Each one gets its own report.

budgets

Per-metric thresholds. Block only what matters to your team.

yml.kanso.yml

# .kanso.yml

# Your production URL
base_url: "https://my-domain.com"

staging:
  # optional · auto-detected for Vercel, Netlify, Render, Railway, Cloudflare Pages, Amplify
  url: "https://acme-git-{branch}.staging.app"

urls:
  - path: /
    name: Homepage
  - path: /pricing
    name: Pricing
  - path: /blog
    name: Blog

# If your production configuration differs, prefer using budgets
budgets:
  performance: 90   # score / 100 · blocks merge if below
  lcp: 2500     # ms · Largest Contentful Paint
  tbt: 200      # ms · Total Blocking Time
  cls: 0.1      # Cumulative Layout Shift
  fcp: 1800     # ms · First Contentful Paint

ai_analysis: true  # root-cause analysis on regressions

Questions,
answered.

The ones we get most often — before they come up in the demo.

How is this different from CodeRabbit or Greptile?+

Those tools review your code. Kanso reviews what happens when your code runs. We cross-reference Lighthouse audits with your PR diff to name the exact line that regressed a metric — code review tools never run your app.

Will it slow down my CI?+

No. Kanso runs on your preview deploy, separately from your CI. Each PR gets two parallel audits (preview + production/budgets reference) — typically under 2 minutes total. Nothing on your critical path, nothing blocking your merge queue.

What if I don't use Vercel or Netlify?+

Render, Railway, Cloudflare Pages and AWS Amplify are supported out of the box. For any other host, point Kanso at your preview URL pattern with a {branch} or {pr} token in your .kanso.yml.

How accurate is the AI root-cause analysis?+

The agent only fires when Lighthouse confirms a measurable regression (above 10% on a tracked metric). It reads your PR diff plus the Lighthouse trace — not your whole codebase. The output is always grounded in a measurable signal, never in guesswork.

Is my code sent to a third party?+

Only the relevant slice of the diff on a failing PR — never your full repo, never your secrets. Lockfiles, snapshots and test files are skipped. A self-hosted option is on the roadmap for teams with stricter isolation requirements.

Full access, free

All features unlocked during beta. No credit card.

Shape the roadmap

Direct line to the founders.

Lock in your pricing

Early-adopter rates when we launch.

Ship faster.
Ship without regressions.

Max 5 teams to start. We'll reach out within 48 hours.

Book a demo →

You'll knowwhy it broke.

Kanso | Performance Report

Regressions caught in the PR.Not in production.

When it regresses, it tells you why.

LCP delay caused by loading="lazy" on the hero image

Reads the diff

Source-aware

Lighthouse-grounded

Where you already work

Why not justLighthouse CI?

Numbers, no narrative.

Code, no runtime.

Metrics + the line that broke them.

Configure once,enforced on every PR.

Questions,answered.

Ship faster.Ship without regressions.

You'll know
why it broke.

Regressions caught in the PR.
Not in production.

When it regresses,
it tells you why.

LCP delay caused by `loading="lazy"` on the hero image

Why not just
Lighthouse CI?

Configure once,
enforced on every PR.

Questions,
answered.

Ship faster.
Ship without regressions.