Introduction

If your realtime avatar looks fine in isolation but feels sluggish once you drop it into a React app, the problem is usually not “React is slow” in a vague sense. It is almost always one or more concrete latency buckets: rendering work in the UI thread, unnecessary re-renders, event propagation delays, media pipeline stalls, or state synchronization problems between the voice agent and the video surface.

By the end of this post, you should be able to identify where the latency is coming from, separate render lag from media lag, and apply fixes that actually reduce perceived delay instead of just moving the bottleneck around.

What “slow” usually means in a realtime avatar UI

Start by naming the symptom. Developers often say “the avatar is slow,” but there are at least four distinct failure modes:

• Input-to-response delay: the user speaks, but the avatar starts reacting late.

• Speech-to-lip-sync drift: audio begins, but mouth motion lags or desynchronizes.

• UI update lag: the React component updates state late, causing visible stutter or stale controls.

• Playback stalls: video frames arrive, but the browser decodes or composites them inconsistently.

Those are different layers. React primarily affects the third one, but it can amplify the others by introducing extra work on the main thread and delaying media-related callbacks.

React bottleneck: too much state, too often

The most common self-inflicted problem is tying every realtime event to React state. If your avatar emits frequent events — transcript chunks, speaking indicators, session metrics, connection state, animation frames — and you call setState for each one, you force React to reconcile on every tick. That may be fine for occasional updates, but it is a bad fit for high-frequency media events.

Remember that React rendering is not the same thing as browser painting, and neither is the same thing as media decoding. If a component tree re-renders often enough, it will steal time from the main thread and delay input handling, message processing, and layout work that the browser still needs to do.

Use a split model:

• Keep hot, high-frequency data out of React state when the UI does not need to change every event.

• Store mutable transport data in refs or an external store.

• Promote to React state only when the user-visible UI actually changes.

import { useEffect, useRef, useState } from "react";

}

import { useEffect, useRef, useState } from "react";

}

import { useEffect, useRef, useState } from "react";

}

If you truly need frequent UI updates, batch them. For example, accumulate events in a ref and flush them on a timer or animation frame. That gives you a controlled update cadence instead of one render per packet.

Media lag: the browser is not waiting for React

A realtime avatar is usually a media problem first and a UI problem second. If you are embedding or rendering video, the browser has to receive, decode, and composite frames. If you are also playing audio, A/V sync has to stay tight enough that the face motion matches the speech. A React component can display the latest session state, but it cannot make decoding faster.

Common browser-side causes of media lag:

• Main-thread contention: heavy React renders, expensive layout, large JSON parsing, or logging block media callbacks.

• Excessive DOM churn: recreating the video element, canvas, or wrapper element forces renegotiation or reset of internal playback state.

• Autoplay and permission edge cases: if audio is delayed by browser policy, the session may appear “slow” even though the network is fine.

• Low-quality device performance: mobile and older laptops are often limited by decode throughput, not network RTT.

For React specifically, do not mount and unmount the avatar element as part of normal state transitions. Keep the media surface stable. If the underlying SDK exposes a long-lived session or element, preserve it across renders and use props only for true configuration changes.

Also, be careful with CSS. Expensive effects such as blur, large box shadows, and frequent transforms on a video container can introduce visible jank on lower-end devices. The avatar may be receiving frames on time, but the page still feels delayed because composition is expensive.

Network and agent latency: reduce the work before the avatar ever renders

The biggest delay in many systems is not React or the browser at all; it is the path from user speech to the agent’s first response. For a voice-driven avatar, that path typically includes:

1. audio capture in the browser or app

2. transport to the voice service or agent runtime

3. speech detection / transcription

4. LLM turn generation

5. text-to-speech generation

6. video/lip-sync synthesis or avatar frame production

7. delivery back to the client

Each hop adds latency. If the avatar feels slow, measure which hop dominates before you optimize the frontend. Instrument at least these timestamps:

• user speech start

• first partial transcript

• first token or first response chunk

• first audible audio

• first visible speaking motion

That separation matters because the right fix differs. If first transcript is late, your speech or transport path is slow. If transcript is fast but first motion is late, your avatar/video pipeline is the bottleneck. If everything is fast except the UI, React is the problem.

Practical fixes that usually move the needle

In descending order of value, these are the fixes I would apply first:

• Keep the avatar surface mounted. Avoid remounts caused by changing keys, conditional rendering, or route transitions.

• Isolate realtime state from normal app state. Use refs or a small external store for hot data.

• Throttle visible updates. The user does not need 60 UI state changes per second for every transcript fragment.

• Defer nonessential work. Analytics, logging, and heavy markdown rendering should not run in the critical path.

• Profile with real session traces. React DevTools, browser performance traces, and network logs will usually show you the bottleneck within minutes.

One subtle issue: if you manage the avatar with a component that receives a new object literal on every render, React may treat it as changed and propagate unnecessary updates. Memoize configuration objects and callbacks when they are passed into the avatar layer.

const avatarConfig = useMemo(() => ({

}, []);

const avatarConfig = useMemo(() => ({

}, []);

const avatarConfig = useMemo(() => ({

}, []);

That does not magically speed up media, but it prevents avoidable rerenders in the parent tree.

Where Protoface fits when the bottleneck is outside React

When the delay is in the avatar pipeline itself, the most useful thing is to shorten the path between your agent and the rendered face. That is where Protoface fits: it provides surfaces for realtime avatar sessions via a REST API, a Python SDK, and integrations for agent frameworks and embeddable web experiences. The important part is not the brand name; it is that the avatar and session model lives outside your React tree, so you can keep the frontend thin.

For example, if you are using the LiveKit Agents plugin, the avatar can be attached to the agent process instead of being recreated by UI state changes. That keeps the media surface and the agent lifecycle aligned. The code below is illustrative; exact fields and session options are in the docs.

# Illustrative only; check docs for exact field names

# Illustrative only; check docs for exact field names

# Illustrative only; check docs for exact field names

If you want a quick mental model, treat the UI as a viewer, not the owner, of the realtime session. The closer you keep the session lifecycle to the agent or backend, the less React has to coordinate during the critical path.

If you are wiring this into a voice agent, the OpenAI Realtime quickstart is a useful reference for how to keep the response loop tight without overloading the frontend. For Python-based backend control, the Python SDK is the right place to inspect the session lifecycle and keep UI code out of transport logic. If you are working from the agent side, the Pipecat integration guide is also relevant: Protoface in Pipecat.

Conclusion

If your realtime avatar feels slow in React, do not guess. Measure where latency accumulates, then fix the layer that actually owns that delay. In practice, the biggest wins usually come from reducing unnecessary rerenders, keeping media surfaces mounted, batching high-frequency updates, and moving session lifecycle concerns out of the React tree.

Once you have a clean separation between UI state and realtime media state, the avatar usually feels much more responsive without any exotic optimization. If you need implementation details for your stack, start with the docs at docs.protoface.com and profile one full turn end to end before changing architecture.