> For the complete documentation index, see [llms.txt](https://triton.pharos.ai/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://triton.pharos.ai/beyond-apex/profiling.md).

# Profiling

LWC components don't just need logging — they need to be *fast*. Slow page loads, sluggish form submissions, and runaway re-renders all hurt the user experience, and they're notoriously hard to diagnose after the fact. Triton ships with a set of profiling helpers that piggy-back on the existing logger so you can capture performance data with the same fluent API you already use for logs.

Every profiling event ends up as a regular `pharos__Log__c` record, with a `duration` value and a typed `TYPE.*` marker, which means everything you've already built around Triton (dashboards, notifications, taxonomies, issue tracking) lights up automatically once you start instrumenting components.

## What Triton Captures

Triton's profiling layer covers four common LWC performance scenarios:

| Scenario                            | Method                                                 | Log type                   |
| ----------------------------------- | ------------------------------------------------------ | -------------------------- |
| Apex / backend wire calls           | `timeBackendCall(name, fn)`                            | `TYPE.BACKEND_CALL`        |
| User-driven interactions            | `timeUserInteraction(name, fn)`                        | `TYPE.USER_INTERACTION`    |
| Component lifecycle (mount/unmount) | `trackComponentLifecycle('connected'\|'disconnected')` | `TYPE.COMPONENT_LIFECYCLE` |
| Render cycles                       | `trackComponentRender()`                               | `TYPE.COMPONENT_RENDER`    |
| Arbitrary timed regions             | `startPerformanceMark` / `endPerformanceMark`          | `TYPE.PERFORMANCE`         |

The expanded `TYPE` enum in `c/triton` looks like this:

```javascript
export const TYPE = {
    BACKEND: 'Backend',
    FRONTEND: 'Frontend',
    BACKEND_CALL: 'BackendCall',
    COMPONENT_LIFECYCLE: 'ComponentLifecycle',
    COMPONENT_RENDER: 'ComponentRender',
    USER_INTERACTION: 'UserInteraction',
    PERFORMANCE: 'Performance'
};
```

## Component Binding is Required

The profiling APIs only work after you've called `bindToComponent()`. The same binding you use for [regular LWC logging](/beyond-apex/lwc.md) doubles as the anchor for performance tracking — Triton generates a unique instance ID under the hood (`componentKey = name-uuid`) so two instances of the same component on a page get isolated marks, render counts, and lifecycle events.

If you call a profiling method without binding first, Triton logs a console warning and returns without doing anything — it deliberately won't throw and break your component.

{% hint style="info" %}
You only need to bind once per component. The instance you get back from `bindToComponent()` is a Proxy around the singleton `Triton` instance, so calling `new Triton().bindToComponent('Name')` in two components on the same page is perfectly safe.
{% endhint %}

## Minimum Viable Setup

Here's a complete example that wires Triton up for performance tracking. Add this skeleton to any component you want to profile and you'll get lifecycle and render telemetry for free, plus the option to instrument specific operations.

{% code title="myComponent.js" lineNumbers="true" %}

```javascript
import Triton from 'c/triton';

export default class MyComponent extends LightningElement {
    triton;

    connectedCallback() {
        this.triton = new Triton().bindToComponent('MyComponent');
        this.triton.trackComponentLifecycle('connected');
    }

    renderedCallback() {
        this.triton.trackComponentRender();
    }

    disconnectedCallback() {
        this.triton.trackComponentLifecycle('disconnected');
    }
}
```

{% endcode %}

That's it. Every mount, unmount, and render now produces a structured log entry tied to your component, the current transaction, and the bound user. From here you can layer in the more specialized profiling helpers covered in the rest of this section.

## Locker Service Compatibility

All profiling internals use a safe `getCurrentTime()` helper that prefers `performance.now()` and falls back to `Date.now()` when the Performance API is restricted (which happens under Locker Service in some component contexts). You don't need to think about it — timing will work everywhere your LWC runs.

## Where to Go Next

Pick the area that matches what you're trying to measure:

* [Backend Calls](/beyond-apex/profiling/backend-calls.md) — wrap your Apex calls in `timeBackendCall(...)` and pick from four error-handling scenarios.
* [User Interactions](/beyond-apex/profiling/user-interactions.md) — time anything kicked off by a user (form submits, multi-step flows) with `timeUserInteraction(...)`.
* [Component Lifecycle](/beyond-apex/profiling/component-lifecycle.md) — track mounts, unmounts, render counts, and understand per-instance isolation.
* [Custom Performance Marks](/beyond-apex/profiling/custom-marks.md) — drop browser-style marks anywhere in your code with `startPerformanceMark` / `endPerformanceMark`.