> For the complete documentation index, see [llms.txt](https://triton.pharos.ai/pharos-triton/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/pharos-triton/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](/pharos-triton/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](/pharos-triton/beyond-apex/profiling/backend-calls.md) — wrap your Apex calls in `timeBackendCall(...)` and pick from four error-handling scenarios.
* [User Interactions](/pharos-triton/beyond-apex/profiling/user-interactions.md) — time anything kicked off by a user (form submits, multi-step flows) with `timeUserInteraction(...)`.
* [Component Lifecycle](/pharos-triton/beyond-apex/profiling/component-lifecycle.md) — track mounts, unmounts, render counts, and understand per-instance isolation.
* [Custom Performance Marks](/pharos-triton/beyond-apex/profiling/custom-marks.md) — drop browser-style marks anywhere in your code with `startPerformanceMark` / `endPerformanceMark`.


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://triton.pharos.ai/pharos-triton/beyond-apex/profiling.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.