Are WebSockets required for a real-time trading dashboard?

Not always. Server-sent events work well for one-way streams such as prices and alerts, and polling is fine for data that changes every few minutes. WebSockets are the usual choice when the browser needs to subscribe, unsubscribe and send actions over the same connection.

How much does market data cost?

It depends on the venues, the vendors, the number of users, whether they are professional or non-professional, and whether the use is display or non-display. Exchanges and vendors publish their policies and fee schedules, and the cost per user should be modelled before the design is fixed.

Can we show delayed data instead of real-time data?

For research screens, client portals and many internal views, delayed data is often enough and much cheaper. It must be clearly labelled as delayed, and redistributing it, particularly in a paid service, usually still needs a licence.

How do we show that a price is stale?

Carry the source timestamp with every value, set a staleness threshold per asset class, and change the value’s appearance when the threshold passes. Show market status and connection status separately, so traders can tell a closed market from a broken feed.

Can Wideline build a real-time trading dashboard?

Our team has shipped trading software in regulated financial services, and we build the data pipelines, integrations and screens behind real-time dashboards. If a vendor terminal or an off-the-shelf product covers your needs, we will say so.

Designing a real-time trading dashboard: data, latency and the screen

Updated 18 October 2026 · 12 min read

The short answer

A real-time trading dashboard is a data pipeline before it is a screen. Prices arrive from exchanges or vendors under licences that control who may see them and how. A server normalises them and streams changes to the browser, usually over WebSockets, and the browser renders only what changed while showing clearly when any number is stale. Get the licensing and the latency budget right first, because they shape every later decision.

For the screen itself, design for the decision the trader makes, not for the amount of data available. Dense layouts work for experts when alignment, number formatting and colour are consistent, every value carries its age, alerts are rare enough to be trusted, and every action is permissioned and audited. Test with recorded market data, including the busiest days you can find, before you rely on live feeds.

Market data: sources and licensing

Market data comes from three broad kinds of source: direct feeds from exchanges and trading venues, consolidated or normalised feeds from data vendors, and public sources such as central banks and debt management offices. Most of the commercial data comes with a licence, and the licence is often a bigger constraint on the design than the technology.

Exchange policies typically distinguish display use, where a person sees the data on a screen, from non-display use, where software consumes it. NYSE’s policy, for example, defines non-display use as accessing, processing or consuming its data for any purpose other than display or redistribution, and lists activities such as algorithmic trading and risk management. Fees are commonly charged per user or device, with different rates for professional and non-professional users. CME Group requires firms that receive its data to run entitlement systems that control and record access, and to keep those records for audit.

Delayed data is usually cheaper or free, but it has rules too. LSEG, for example, publishes data 15 minutes after first publication on its delayed data service, and requires a licence for redistribution in fee-charging services. Derived data, such as an index or analytics calculated from licensed prices, and storing data for historical use can each need separate permission. Read the current policies of every venue and vendor you plan to use, and model the cost per user before you commit to a design.

Source	Strengths	Watch for
Direct exchange feed	Lowest latency, full depth, authoritative	Connectivity and hardware cost, per-venue licences, your own normalisation
Data vendor feed or API	One integration for many venues, normalised symbols, reference data	Vendor fees plus pass-through exchange fees, vendor-specific entitlements
Delayed data	Much cheaper, often enough for research and client portals	Must be labelled as delayed; redistribution still licensed
Public sources (central banks, treasuries)	Free or low cost, authoritative for official curves and rates	Published once a day or less; check terms of reuse

Streaming or polling

Not every number on a trading dashboard needs to stream. Reference data, end-of-day positions and official yield curves can be fetched on load or polled every few minutes. Prices, orders and alerts that change many times a second need a push model.

For push, WebSockets are the common choice: a single long-lived, two-way connection standardised in RFC 6455 and supported by every current browser. Server-sent events are a simpler alternative when data only flows from server to browser; they run over ordinary HTTP and the browser reconnects automatically. Choose the simplest option that meets the need, and keep the message format independent of the transport so that you can change it later.

Approach	Direction	Good fit	Watch for
Polling	Browser asks, server answers	Data that changes every few minutes or less often	Wasted requests; worst-case staleness equals the interval
Long polling	Server holds the request until data changes	Occasional updates where WebSockets are blocked	Connection churn under load
Server-sent events	Server to browser only	Read-only streams such as prices and alerts	One direction only; text-based messages
WebSockets	Both directions	Live prices, subscriptions, order updates	Your own reconnection, heartbeats, back-pressure and scaling

Designing the streaming layer

A dependable stream needs a protocol on top of the socket. The browser subscribes to the instruments on screen, receives a snapshot of current state, then receives changes. Each message carries a sequence number so that the client can detect a gap and request a fresh snapshot rather than silently drifting out of step.

Markets are bursty, and a busy minute can produce more updates than a browser can draw. Conflate on the server: for each instrument, send the latest value at a fixed maximum rate rather than every tick. Traders watching a screen need the current price, not every intermediate one, while systems that need every tick should consume the feed directly.

Authenticate the connection, check entitlements on every subscription, and recheck them when permissions change. Send heartbeats in both directions so that a dead connection is noticed in seconds, and reconnect with randomised back-off so that thousands of clients do not reconnect at the same instant after an outage.

A latency budget

Latency is easiest to manage as a budget: decide how old a price may be when it reaches the trader’s eyes, then allocate that time across the stages it passes through. Measure each stage separately, because an average across the whole pipeline hides where the time is going. Measure percentiles rather than averages, since traders remember the slow updates.

The browser is often the overlooked stage. A screen that refreshes 60 times a second leaves about 16 milliseconds per frame for everything the page does, so redrawing a large table on every update can add more delay than the network. Batch updates per frame, update only the cells that changed, and keep heavy calculation off the main thread.

Stage	What adds latency	How to measure
Source to ingest	Distance to the venue or vendor, feed handler processing	Compare source timestamps with receipt time
Normalise and enrich	Symbol mapping, calculations, database writes in the hot path	Timestamps at entry and exit of each service
Fan-out	Serialisation, per-client filtering, slow consumers	Queue depth and send time per connection
Network to the user	Distance, mobile or office networks, proxies	Round-trip time from heartbeats
Render	Large re-renders, layout work, chart redraws	Browser performance tooling and frame timings

Staleness indicators

A wrong price that looks live is worse than no price at all. Every value on a trading screen should carry the time it was produced at source, and the interface should change its appearance when that time passes a threshold. The right threshold differs by asset class and instrument: a liquid currency pair that has not moved for ten seconds is suspicious, while an illiquid bond quote may be hours old and still valid.

Distinguish the reasons a value is not updating. A closed market, a halted instrument, a disconnected feed and a dropped browser connection are different situations, and traders need to know which one they are looking at. Show connection status prominently, and never display a cached value from before a reconnection as if it were current.

Show the source time on hover or in a detail view for every value.
Dim or mark values that pass their staleness threshold.
Label delayed data as delayed, as most licences require.
Show market status (open, closed, halted) separately from data status.

Yield curves and bond screens

Bond screens differ from equity screens in ways that matter for design. Much bond trading happens over the counter, so prices are often quotes from dealers, some indicative and some executable, and the screen must make that distinction clear. Prices and yields move in opposite directions, conventions for day counts and quoting differ by market, and traders usually think in yield or spread rather than price.

A yield curve plots yield against maturity. Official curves are published by many central banks and treasuries: the European Central Bank, for example, publishes euro area curves every TARGET business day at noon, and the US Treasury publishes daily par yield curve rates based on closing market bid prices. These are estimates fitted to market prices, so a good curve screen shows the fitted line and the observed points behind it, labels the method and the time, and lets the trader compare today’s curve with earlier dates.

Heat maps

Heat maps compress a whole market or portfolio into a single view, and they are easy to get wrong. Use a diverging colour scale centred on zero for changes, so that a flat day looks neutral, and fix the scale’s limits rather than letting them stretch to the day’s extremes, or a quiet day will look as dramatic as a crash.

Colour cannot carry the meaning alone. WCAG’s use of colour criterion requires another visual means, such as a sign, a label or a pattern, and some traders cannot reliably tell red from green. Show the value on hover and in an accessible table, and throttle colour updates so that the map does not flicker during busy periods.

Alerts people trust

An alert that fires too often is soon ignored, and an ignored alert is worse than none. Evaluate alerts on the server, against the same data the screen shows, so that they still fire when the trader’s browser is closed. Add hysteresis, so that a price hovering around a threshold does not trigger repeatedly, and group related alerts rather than sending one per instrument.

Every alert needs a clear owner, an acknowledgement and a record. For alerts that matter to risk or compliance, record who saw it, when they acknowledged it and what they did, because those records will be asked for after a bad day.

Permissions and audit

A trading dashboard has two layers of permission. Data entitlements decide which feeds a user may see, and they follow your licences. Functional permissions decide what a user may do: view, trade, approve, change limits. Keep both on the server and enforce them on every request and every subscription, not only in the interface.

Audit every action that changes state: orders, amendments, cancellations, limit changes, alert configuration and permission changes. Record who did it, from where, what the screen showed at the time where that matters, and the result. Data entitlement records double as the evidence exchanges ask for in usage audits.

Density versus clarity

Professional traders work across several large monitors and want a great deal on screen at once. That is legitimate, and a sparse consumer-style layout will frustrate them. Density works when the structure is strict: right-aligned numbers in tabular figures, consistent decimal places per instrument, one colour meaning per colour across the whole product, and a clear visual hierarchy so that the eye finds the important value first.

Let users arrange their own layouts, save them and restore them on another machine. Support keyboard shortcuts for frequent actions, and make every destructive or trading action require a deliberate step. Colour conventions for up and down are not universal across markets, so make them configurable if your users trade in more than one.

Testing with recorded market data

Live markets are a poor test environment: you cannot repeat a scenario, and the interesting days are rare. Record real feeds, replay them through the whole pipeline at normal and accelerated speeds, and keep a library of difficult sessions, such as market opens, major announcements and volatile closes, as regression tests.

Test the failures as carefully as the happy path: gaps in sequence numbers, out-of-order messages, a feed that stops, a browser that loses its connection and comes back, a slow client that cannot keep up. Set performance budgets for latency and frame time and fail the build when they are exceeded. Check your licences before you store data for replay, because historical use can be licensed separately.

Replay recorded sessions at 1x and accelerated speed.
Inject gaps, duplicates, out-of-order messages and stalled feeds.
Simulate reconnection storms with many clients.
Measure end-to-end latency percentiles and frame times on every build.

Questions

Are WebSockets required for a real-time trading dashboard?: Not always. Server-sent events work well for one-way streams such as prices and alerts, and polling is fine for data that changes every few minutes. WebSockets are the usual choice when the browser needs to subscribe, unsubscribe and send actions over the same connection.
How much does market data cost?: It depends on the venues, the vendors, the number of users, whether they are professional or non-professional, and whether the use is display or non-display. Exchanges and vendors publish their policies and fee schedules, and the cost per user should be modelled before the design is fixed.
Can we show delayed data instead of real-time data?: For research screens, client portals and many internal views, delayed data is often enough and much cheaper. It must be clearly labelled as delayed, and redistributing it, particularly in a paid service, usually still needs a licence.
How do we show that a price is stale?: Carry the source timestamp with every value, set a staleness threshold per asset class, and change the value’s appearance when the threshold passes. Show market status and connection status separately, so traders can tell a closed market from a broken feed.
Can Wideline build a real-time trading dashboard?: Our team has shipped trading software in regulated financial services, and we build the data pipelines, integrations and screens behind real-time dashboards. If a vendor terminal or an off-the-shelf product covers your needs, we will say so.