Profiling

Capture rich performance telemetry from your LWC components — backend calls, user interactions, render cycles, and custom marks — using Triton's built-in profiling APIs.

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:

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 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.

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.

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.

myComponent.js

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');
    }
}

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 — wrap your Apex calls in timeBackendCall(...) and pick from four error-handling scenarios.

• User Interactions — time anything kicked off by a user (form submits, multi-step flows) with timeUserInteraction(...).

• Component Lifecycle — track mounts, unmounts, render counts, and understand per-instance isolation.

• Custom Performance Marks — drop browser-style marks anywhere in your code with startPerformanceMark / endPerformanceMark.