Django LiveView vs Phoenix LiveView: a real benchmark

I was curious: how does Django LiveView hold up against the original Elixir implementation when you compare them under identical conditions? Not with theoretical arguments, but with real numbers.

I built an identical alert dashboard in both frameworks: add, delete, and search alerts in real time. The benchmark is automated with Playwright headless Chromium, measuring the time between the user action and the DOM change, plus the bytes sent over WebSocket per interaction.

The source code is in the repository and is fully reproducible with Docker Compose.

Let's look at the results.

The stack

Common scenarios

I ran 10 iterations (2 warmup) for add, delete, and search on a list with a few items.

A complete tie. Both frameworks land in the same range: ~22 ms for mutations and ~7 ms for search. The difference is statistically irrelevant.

Edge cases

This is where things get interesting.

With 500 alerts loaded, Phoenix is slightly faster. Rapid fire is practically identical.

However, the most striking data point is the payload:

With the large list, Django LiveView transfers 327 KB per action versus Phoenix's 67 KB. Every time you add an alert with 500 already loaded, Django LiveView sends you the entire table again. Phoenix only sends the new row.

It's a design difference, not an implementation flaw. In Django LiveView you explicitly define which selector to update and with what HTML:

@liveview_handler("add_alert")
def add_alert(consumer, content):
    alerts = list(Alert.objects.all())
    html = render_to_string("components/_alerts_table.html", {"alerts": alerts})
    send(consumer, {"target": "#alerts-container", "html": html})

In Phoenix LiveView you update the assigns and the framework computes the diff:

def handle_event("add_alert", _params, socket) do
  alert = Alerts.create_random_alert()
  {:noreply, assign(socket, alerts: [alert | socket.assigns.alerts])}
end

Phoenix knows which part of the template changed and only sends that. Django LiveView has no such mechanism, so granularity is up to you: point to a small selector and you send less, point to a large container and you send everything. Does this matter? On slow connections or with many concurrent clients, yes. In an app with few users or small lists, it will be indistinguishable.

Concurrency

What happens when multiple users act at the same time? I launched between 1 and 50 simultaneous clients all firing the same action together, synchronized with a barrier so they all start at once.

With few clients (1-5) both behave similarly, with Django even slightly faster in p50. From 25 simultaneous clients the gap becomes clear: Phoenix scales better, especially on add_alert where at 50 clients Django doubles Phoenix's latency.

Conclusion

The data answers my original question: yes, Django LiveView holds up against Phoenix LiveView. In day-to-day operations they are practically equal. Phoenix's advantage shows when the payload grows or when concurrency is high, although these are problems you can mitigate with careful design in Django LiveView by targeting more specific selectors and distributing load.

The advantage of Django LiveView is staying in Python and the Django ecosystem without leaving what you already know, and that Django LiveView is more explicit and predictable: you decide what HTML to send and where to place it.

I'm pleasantly surprised.

PS: You are looking at a site built 100% with Django LiveView, I invite you to push its limits.