> ## Documentation Index
> Fetch the complete documentation index at: https://docs.arguserror.xyz/llms.txt
> Use this file to discover all available pages before exploring further.

# Performance Monitoring with Argus

> Argus captures web vitals (LCP, CLS, FCP, TTFB) and page-load transactions from the browser SDK and aggregates them per project.

Performance monitoring shows you how fast — or slow — your application really is. With the browser SDK installed, every page view automatically reports a `page.load` **transaction** plus the four core **web vitals**, and the dashboard aggregates them into percentiles so you can spot regressions before your users complain.

<Note>
  Requires `@argusdev/sdk-browser` (or `@argusdev/sdk-react`) **v0.2.0 or later**. Vitals capture is on by default — no extra configuration.
</Note>

## How capture works

The SDK uses buffered `PerformanceObserver`s so metrics are captured even if `init()` runs after the page started loading:

| Vital    | Full name                | How it's measured                                                                        |
| -------- | ------------------------ | ---------------------------------------------------------------------------------------- |
| **LCP**  | Largest Contentful Paint | Last `largest-contentful-paint` entry — perceived load speed                             |
| **CLS**  | Cumulative Layout Shift  | Sum of `layout-shift` entries, ignoring shifts right after user input — visual stability |
| **FCP**  | First Contentful Paint   | The `first-contentful-paint` paint entry — initial render speed                          |
| **TTFB** | Time to First Byte       | `responseStart` from navigation timing — server responsiveness                           |

Exactly **one report per page view**: when the page is hidden or unloaded (`pagehide` / `visibilitychange`), the SDK sends a single transaction envelope with `keepalive`, so it survives navigation. Nothing is sent for background tabs that never rendered.

Opt out per app:

```ts theme={null}
init({ dsn: "...", vitals: false });
```

<Note>
  Performance events go through the same ingest pipeline as errors — DSN-authenticated, rate-limited, and **counted against your monthly event quota**.
</Note>

## Transactions

A **transaction** is one unit of work — today, a page load (`page.load /dashboard`). Each carries `name`, `duration` (ms), `status`, `traceId`, an optional `vitals` object, and a timestamp. The dashboard and API aggregate them **by name** into `count`, `p50`, `p75`, `p95`, and `lastSeen`.

### Spans <sup>planned</sup>

Spans (sub-operations inside a transaction — a DB query, an outbound HTTP call) are part of the data model but not yet produced by any SDK. They arrive with the Node.js timing integration in a future release.

## Ratings

Vitals are reported at **p75** (the web-vitals standard) and rated against web.dev thresholds:

| Vital | Good   | Needs improvement | Poor   |
| ----- | ------ | ----------------- | ------ |
| LCP   | ≤ 2.5s | ≤ 4s              | > 4s   |
| CLS   | ≤ 0.1  | ≤ 0.25            | > 0.25 |
| FCP   | ≤ 1.8s | ≤ 3s              | > 3s   |
| TTFB  | ≤ 0.8s | ≤ 1.8s            | > 1.8s |

## Viewing performance data

1. Open your project and click **Performance** in the sidebar.
2. The four vitals cards show the p75 for each metric, color-coded by rating, with sample counts.
3. The transactions table lists each operation with count, p50/p75/p95 durations, and when it was last seen.
4. Switch the window with the **24h / 7d / 30d** selector.

## API access

See the [Performance API reference](/api/performance) for the `GET .../performance/transactions` and `GET .../performance/vitals` endpoints and their response shapes.