How fast do crypto trading screens become usable?

Campaign trade-ready-2026-10-03 · generated 2026-10-03

Results in one paragraph. On a warm reload, Thalex is the fastest of the perpetual trading screens; Variational cannot be told apart from it. Coinbase TradingView is the slowest ranked screen at 8.0 s.

Defect found: Coinbase: the chart keeps the old market's name after a switch. You switch from BTC Perp to ETH Perp. The page title, the address and the candle prices all change to ETH, but the chart's legend still says BTC_USDC-PERPETUAL. It stays wrong while you remain on the page. Defect card CB-1 · on the Coinbase TradingView page

What was tested. Trading pages of crypto exchanges, opened in one logged-in Chrome profile with one tab, from the Netherlands. Each page was reloaded two ways: a warm reload (a normal reload of a page visited seconds before) and an uncached reload (ignoring the browser's stored files). Five rounds visited every page once in a random order fixed in advance (seed dcc318b9d02f…); Bitfinex ran first as a block of five, right after login, because its login expires after 10 minutes idle.

Trade-ready is the moment every panel a trader needs on screen (price, chart, order book, recent trades when visible, order form, account panel) shows real data, nothing is still loading, and the layout has stopped moving, held for half a second. A load that takes longer than 45 seconds counts as failed, never as 45 seconds.

Not measured: first-ever visits with an empty browser, whether on-screen prices are fresh, and market switching (a later run).

Perpetual trading screens (headline)

Rank (warm)	Possible rank	Exchange	Warm reload, median [range]	Behind the fastest	Uncached	Loads ready (warm · uncached)
1 of 27	1 to 2	Thalex	2.4 s [2.4 s–2.8 s]	fastest	2.6 s rank 1	5/5 · 5/5
2 of 27	1 to 5	Variational^*9	2.6 s [2.4 s–3.5 s]	+0.1 s 1.04×	3.0 s rank 2	5/5 · 5/5
3 of 27	2 to 4	Architect^*6,10	2.8 s [2.8 s–3.0 s]	+0.3 s 1.1×	3.0 s rank 3	5/5 · 5/5
4 of 27	2 to 5	Hyperliquid¹	3.1 s [2.7 s–3.3 s]	+0.6 s 1.3×	3.5 s rank 5	5/5 · 5/5
5 of 27	3 to 5	Binance^2,3	3.1 s [3.0 s–3.2 s]	+0.6 s 1.3×	3.0 s rank 4	5/5 · 5/5
6 of 27	6 to 8	HyperFlow⁴	3.5 s [3.3 s–3.7 s]	+1.0 s 1.4×	4.1 s rank 7	5/5 · 6/6
7 of 27	6 to 10	Insilico Terminal^3,5,7,8	3.5 s [3.5 s–4.0 s]	+1.1 s 1.4×	3.7 s rank 6	5/5 · 5/5
8 of 27	6 to 10	Pacifica¹	3.6 s [3.5 s–4.0 s]	+1.1 s 1.5×	4.7 s rank 11	5/5 · 5/5
9 of 27	7 to 11	Bybit^1,2,5	3.9 s [3.8 s–4.3 s]	+1.4 s 1.6×	4.7 s rank 12	5/5 · 5/5
10 of 27	7 to 13	Backpack^1,2	4.0 s [3.7 s–4.4 s]	+1.5 s 1.6×	4.4 s rank 9	4/4 · 4/4
11 of 27	9 to 12	Deribit⁶	4.2 s [3.8 s–4.4 s]	+1.7 s 1.7×	4.1 s rank 8	5/5 · 5/5
12 of 27	10 to 15	TxFlow¹	4.3 s [4.1 s–4.5 s]	+1.9 s 1.8×	4.7 s rank 13	5/5 · 5/5
13 of 27	12 to 20	Rise^1,2	4.6 s [4.4 s–4.8 s]	+2.1 s 1.9×	4.4 s rank 10	5/5 · 5/5
14 of 27	11 to 21	BloFin¹	4.6 s [4.3 s–5.2 s]	+2.2 s 1.9×	5.2 s rank 16	5/5 · 5/5
15 of 27	13 to 21	Lighter	4.8 s [4.5 s–5.1 s]	+2.3 s 1.9×	6.6 s rank 23	5/5 · 5/5
16 of 27	12 to 21	GRVT¹	4.8 s [4.3 s–5.1 s]	+2.3 s 2.0×	6.0 s rank 20	5/5 · 5/5
17 of 27	13 to 20	Bitfinex⁴	4.8 s [4.5 s–4.8 s]	+2.4 s 2.0×	4.8 s rank 14	5/5 · 5/5
18 of 27	13 to 20	ApeX	4.8 s [4.6 s–4.9 s]	+2.4 s 2.0×	5.1 s rank 15	5/5 · 5/5
19 of 27	16 to 25	Decibel¹	5.0 s [4.9 s–7.4 s]	+2.5 s 2.0×	6.5 s rank 22	5/5 · 5/5
20 of 27	13 to 23	Derive	5.1 s [4.7 s–5.8 s]	+2.6 s 2.1×	8.3 s rank 25	5/5 · 5/5
21 of 27	13 to 24	Extended¹	5.1 s [4.6 s–6.1 s]	+2.6 s 2.1×	5.4 s rank 17	5/5 · 5/5
22 of 27	19 to 24	Aster¹	5.6 s [5.3 s–6.4 s]	+3.1 s 2.3×	5.7 s rank 19	5/5 · 5/5
23 of 27	19 to 24	Gains¹	5.6 s [4.9 s–6.7 s]	+3.1 s 2.3×	5.7 s rank 18	5/5 · 5/5
24 of 27	20 to 24	Kraken Pro¹	5.9 s [5.7 s–6.1 s]	+3.4 s 2.4×	6.1 s rank 21	5/5 · 5/5
25 of 27	24 to 25	BTSE⁴	7.0 s [6.8 s–7.2 s]	+4.6 s 2.9×	7.0 s rank 24	5/5 · 5/5
26 of 27	26	Coinbase native^1,3,5	7.6 s [7.1 s–7.6 s]	+5.1 s 3.1×	8.4 s rank 26	5/5 · 5/5
27 of 27	27	Coinbase TradingView^1,5	8.0 s [7.7 s–8.4 s]	+5.6 s 3.3×	9.1 s rank 27	5/5 · 5/5

Rank is the order by median. Possible rank is the range the measurements leave open. The best possible rank counts only the exchanges that clearly beat it. The worst counts only the exchanges it clearly beats. Exchanges with overlapping ranges cannot be told apart. Clearly faster means an estimated gap of at least 0.1 s, with 95% confidence that a gap exists. Rows are green when the best possible rank is 1. Red starts at 1.5 times the fastest time and deepens as the time increases. The black bar shows the median. An exchange needs at least 4 ready loads to be ranked.

BTC options

Rank (warm)	Possible rank	Exchange	Warm reload, median [range]	Behind the fastest	Uncached	Loads ready (warm · uncached)
1 of 2	1	Deribit BTC options⁶	2.9 s [2.8 s–2.9 s]	fastest	3.0 s rank 1	5/5 · 5/5
2 of 2	2	Derive BTC options	4.8 s [3.3 s–5.7 s]	+2.0 s 1.7×	4.6 s rank 2	5/5 · 5/5
—	not measured	Thalex BTC options²	no load passed the setup checks	—	—	0/0 · 0/0

Columns and colours as in the headline table above.

Where the time goes: Perpetual trading screens (headline)

Each row is one exchange on a warm reload. Each dot is the median moment a panel first showed real, usable data; the tall tick is trade-ready. A wide gap between dots shows which panel holds the page back; a gap between the last dot and the tick is time spent settling after the data is there. Hover over a dot for its panel and time; each exchange's card below lists the same times as text.

price chart order book trades order form account quote trade-ready

Exchange	Trade-ready	Delay between panels in the campaign timings	Largest finding in the recorded load
Thalex	2.4 s	no single delay of 1 s or more; panels arrive close together	TH-1 Market data is on the socket 2 s before it is on screen.
Variational	2.6 s	no single delay of 1 s or more; panels arrive close together	VR-1 Four feed sockets, each needing 0.9 to 1.3 s to connect.
Architect	2.8 s	no single delay of 1 s or more; panels arrive close together	AR-1 Candle history is requested 0.7 s after the first panel shows.
Hyperliquid	3.1 s	no single delay of 1 s or more; panels arrive close together	HL-1 All first-party files travel over HTTP/1.1.
Binance	3.1 s	no single delay of 1 s or more; panels arrive close together	BN-1 About 3.4 MB of JSON at start-up, half of it marked no-store.
HyperFlow	3.5 s	no single delay of 1 s or more; panels arrive close together	HF-1 The chart is drawn 1.7 s after the book; its code arrives in a late wave.
Insilico Terminal	3.5 s	no single delay of 1 s or more; panels arrive close together	IN-1 The order book is drawn the moment a 0.79 s data request completes.
Pacifica	3.6 s	no single delay of 1 s or more; panels arrive close together	PA-1 The chart is drawn 2.0 s after the order book; three candle requests to Binance fail first.
Bybit	3.9 s	no single delay of 1 s or more; panels arrive close together	BY-1 The 4.9 MB chart library is requested only after book and price are up.
Backpack	4.0 s	no single delay of 1 s or more; panels arrive close together	BP-1 About 12 MB of JSON before the order book shows, 3.1 MB of it for pages the trader is not on.
Deribit	4.2 s	no single delay of 1 s or more; panels arrive close together	DB-1 Price and book show 2.6 s after the feed delivers.
TxFlow	4.3 s	slow start: no panel shows real data until 3.4 s (the price comes first), so the delay is in starting the app, before any one panel	TX-1 The react-router chunk starts 2.4 s of main-thread work.
Rise	4.6 s	settling: the page is not steady until 1.3 s after the last panel shows real data (on the six exchanges we checked, an animation still running in the chart; it can also be a placeholder, late fonts or images, or a moving layout)	RI-1 The feed takes 1.2 s to connect, and the order book shows 0.9 s after its first message.
BloFin	4.6 s	settling: the page is not steady until 1.1 s after the last panel shows real data (on the six exchanges we checked, an animation still running in the chart; it can also be a placeholder, late fonts or images, or a moving layout)	BF-1 Trade-ready comes 1.1 s after the last panel has its data: the chart is still animating.
Lighter	4.8 s	settling: the page is not steady until 1.6 s after the last panel shows real data (on the six exchanges we checked, an animation still running in the chart; it can also be a placeholder, late fonts or images, or a moving layout)	LI-1 An 8.7 MB vendor bundle at start-up.
GRVT	4.8 s	no single delay of 1 s or more; panels arrive close together	GR-1 The HTML takes 0.6 s to its first byte and is 1.1 MB.
Bitfinex	4.8 s	lagging panel: the order book arrives 1.6 s after every other panel	BFX-1 The order book is the last panel in every warm load, about 1.5 s after the chart.
ApeX	4.8 s	slow start: no panel shows real data until 3.5 s (the price comes first), so the delay is in starting the app, before any one panel	AX-1 A 9.3 MB main script.
Decibel	5.0 s	slow start: no panel shows real data until 3.3 s (the price comes first), so the delay is in starting the app, before any one panel	DC-1 Nothing shows until 3.5 s: data is requested at 1.9 s and drawn 1.3 s after it arrives.
Derive	5.1 s	no single delay of 1 s or more; panels arrive close together	DV-1 Market-data requests to api.lyra.finance take 1.6–2.2 s, and its sockets 0.9–1.6 s to connect.
Extended	5.1 s	no single delay of 1 s or more; panels arrive close together	EX-1 The HTML takes 0.7 s; it is marked no-store and missed the edge cache.
Aster	5.6 s	no single delay of 1 s or more; panels arrive close together	AS-1 Nothing paints until 2.85 s although the HTML arrives in 15 ms.
Gains	5.6 s	settling: the page is not steady until 1.2 s after the last panel shows real data (on the six exchanges we checked, an animation still running in the chart; it can also be a placeholder, late fonts or images, or a moving layout)	GN-1 A 14.2 MB application script.
Kraken Pro	5.9 s	slow start: no panel shows real data until 3.7 s (the price comes first), so the delay is in starting the app, before any one panel	KR-1 11.0 MB of JavaScript is loaded before the trading screen works.
BTSE	7.0 s	slow start: no panel shows real data until 5.1 s (the order form comes first), so the delay is in starting the app, before any one panel settling: the page is not steady until 1.1 s after the last panel shows real data (on the six exchanges we checked, an animation still running in the chart; it can also be a placeholder, late fonts or images, or a moving layout)	BT-1 The market feed sends its first frame only at 4.1 s, after three rounds of API requests.
Coinbase native	7.6 s	slow start: no panel shows real data until 6.3 s (the price comes first), so the delay is in starting the app, before any one panel	CBN-1 The price appears about 5.7 s after the live feed delivers.
Coinbase TradingView	8.0 s	slow start: no panel shows real data until 6.9 s (the price comes first), so the delay is in starting the app, before any one panel	CBT-1 The price appears about 4.7 s after the live feed delivers.

Named only when a delay is at least 1 s (the first panel at 3 s or later for a slow start); smaller gaps are within normal load-to-load spread. These timings show where the page waits, not why: the cause in requests, scripts or servers needs a recorded load of the page.

Bottlenecks: what slows each page, and what to do

Each exchange's page was recorded once with Chrome's performance trace on a warm reload. The grid shows which bottleneck patterns each page has, with the size of the gap where it has one; each exchange's card below gives the evidence, the fix and how to check it in Chrome DevTools. A darker cell is a larger gap. A blank cell means the pattern did not pass its threshold, not that the page is perfect. The grid only holds patterns a program can detect in that one recording; the last column names the largest finding written by hand from a closer reading of the captures, which often goes further.

Exchange

Slow HTML response
6 pages

Market data asked late
7 pages

Data arrives, screen waits
9 pages

Main thread blocked
21 pages

Many startup scripts
4 pages

Chart history asked late
3 pages

HTTP/1.1
2 pages

Third-party script
1 page

Largest written finding

Perpetual trading screens (headline)

Thalex

2.3 s

0.6 s

TH-1 Market data is on the socket 2 s before it is on screen. +2 more

Architect

0.7 s

AR-1 Candle history is requested 0.7 s after the first panel shows. +4 more

Hyperliquid

yes

HL-1 All first-party files travel over HTTP/1.1. +6 more

Binance

0.1 s

BN-1 About 3.4 MB of JSON at start-up, half of it marked no-store. +6 more

HyperFlow

2.1 s

yes

HF-1 The chart is drawn 1.7 s after the book; its code arrives in a late wave. +4 more

Insilico Terminal

1.7 s

0.8 s

IN-1 The order book is drawn the moment a 0.79 s data request completes. +7 more

Pacifica

0.5 s

PA-1 The chart is drawn 2.0 s after the order book; three candle requests to Binance fail first. +4 more

Bybit

2.8 s

1.0 s

BY-1 The 4.9 MB chart library is requested only after book and price are up. +5 more

Backpack

0.5 s

0.7 s

BP-1 About 12 MB of JSON before the order book shows, 3.1 MB of it for pages the trader is not on. +5 more

Deribit

1.9 s

1.0 s

DB-1 Price and book show 2.6 s after the feed delivers. +5 more

Rise

1.0 s

2.1 s

0.6 s

RI-1 The feed takes 1.2 s to connect, and the order book shows 0.9 s after its first message. +5 more

BloFin

0.9 s

BF-1 Trade-ready comes 1.1 s after the last panel has its data: the chart is still animating. +5 more

Lighter

1.2 s

LI-1 An 8.7 MB vendor bundle at start-up. +5 more

GRVT

0.6 s

2.2 s

2.0 s

0.6 s

GR-1 The HTML takes 0.6 s to its first byte and is 1.1 MB. +7 more

Bitfinex

1.8 s

0.8 s

BFX-1 The order book is the last panel in every warm load, about 1.5 s after the chart. +6 more

ApeX

1.4 s

AX-1 A 9.3 MB main script. +6 more

Decibel

0.5 s

1.9 s

1.3 s

1.5 s

DC-1 Nothing shows until 3.5 s: data is requested at 1.9 s and drawn 1.3 s after it arrives. +5 more

Derive

DV-1 Market-data requests to api.lyra.finance take 1.6–2.2 s, and its sockets 0.9–1.6 s to connect. +6 more

Extended

0.7 s

1.1 s

yes

EX-1 The HTML takes 0.7 s; it is marked no-store and missed the edge cache. +5 more

Aster

1.6 s

yes

AS-1 Nothing paints until 2.85 s although the HTML arrives in 15 ms. +6 more

Gains

1.0 s

GN-1 A 14.2 MB application script. +8 more

Kraken Pro

2.4 s

1.2 s

KR-1 11.0 MB of JavaScript is loaded before the trading screen works. +7 more

BTSE

0.8 s

4.1 s

1.5 s

BT-1 The market feed sends its first frame only at 4.1 s, after three rounds of API requests. +10 more

Coinbase native

5.7 s

1.6 s

yes

CBN-1 The price appears about 5.7 s after the live feed delivers. +8 more

Coinbase TradingView

4.7 s

1.4 s

yes

CBT-1 The price appears about 4.7 s after the live feed delivers. +9 more

BTC options

Deribit BTC options

2.5 s

1.2 s

Derive BTC options

0.9 s

TxFlow: not diagnosed, an unidentified pop-up covered the chart in both recorded loads (it did not appear during the timed campaign).

Variational: no recorded load in this diagnostic pass.

Thalex BTC options: no recorded load in this diagnostic pass.

Grades: B means the recording shows the problem directly (blocking tasks, protocol, third-party time); C means the order of events in one load points to it, but the dependency is not proven. No finding has been confirmed by an experiment (grade A) yet. Recording a trace slows pages somewhat, so the gaps here are indicative; the campaign's timed loads remain the measure of speed. Nothing here is graded higher, because no fix was confirmed by changing a page and measuring again.

Exchanges

ApeX Full page: bottlenecks and fixes →

Trade-ready: 4.8 s warm, 5.1 s uncached. Market data ready: 4.2 s warm. Last panel: chart. Trade-ready followed market-data readiness by a median 0.7 s.

Loads: 5 of 5 warm loads ready; 5 of 5 uncached loads ready.

Bottleneck seen in the timings: no panel shows real data until 3.5 s (the price comes first), so the delay is in starting the app, before any one panel.

Panels ready (median, warm): price 3.5 s → order book 3.5 s → order form 3.5 s → trades 3.6 s → account 3.6 s → chart 4.2 s

Servers, measured from the Netherlands:
page omni.apex.exchange: connect 12 ms, response 174 ms

Stack

React, built with Vite; TradingView chart library (library.js); two Ethereum libraries (viem and ethers) plus the MetaMask SDK and WalletConnect; Google reCAPTCHA; AppsFlyer.

Delivery

omni.apex.exchange served by nginx over HTTP/2; HTML no-cache; app files cached 30 days; 45 static files without a cache-control header; three fonts shipped as uncompressed TTF.

What happened, in order

From one uncached diagnostic load recorded on 1 October 2026 (cache disabled, browser extensions active), so totals are slower than the campaign's timed loads; file names, sizes, headers, order of events and main-thread times are what the findings rely on. A main-thread time given for a script counts all the work that starts in that script, including code it calls in other files, so it shows where start-up work begins, not what one library costs. Endpoint paths were masked when the capture was saved.

When	What
0.18 s	HTML arrives.
0.34–0.76 s	index-BYeI0AHq.js downloads: 3.1 MB compressed, 9.3 MB unpacked; with it viem (455 KB unpacked), ethers (431 KB) and CSS. The react chunk later starts 1.55 s of main-thread work.
0.77 s	reCAPTCHA (recaptcha__nl.js, 829 KB unpacked) loads; it is loaded a second time at 1.41 s.
1.16 s	MetaMask SDK (539 KB unpacked).
1.86 s	Page header shows the market.
1.91–2.64 s	A 3.1 MB response from omni.apex.exchange sent without compression, probably the zklink WebAssembly module.
2.02 s	WalletConnect wallet registry (1.2 MB unpacked); fetched again at 3.68 s, taking 1.7 s.
2.15–2.75 s	The chart library (library.js, 2.4 MB unpacked).
2.22 s	First paint.
4.51 s	Price and order book show.
6.74 s	Chart drawn, 2.2 s after the book: trade-ready in this load. 19 long tasks took 3.2 s of main thread.

Bottlenecks

AX-1 A 9.3 MB main script. grade B
AX-2 A 3.1 MB file is sent without compression; it is probably a WebAssembly module. grade B
AX-3 Duplicate and overlapping libraries at start-up. grade B
AX-4 The chart is drawn 2.2 s after price and book. grade C
AX-5 Trade-ready comes 0.7 s after the chart has its data: the chart is still animating. grade B
AX-6 Three fonts are uncompressed TTF, 147 KB each. grade B
AX-7 Four large images load while the chart is starting. grade C

Evidence, the fix and how to verify each one are on the exchange's full page: open it.

Aster¹ Full page: bottlenecks and fixes →

Trade-ready: 5.6 s warm, 5.7 s uncached. Market data ready: 4.9 s warm. Last panel: chart. Trade-ready followed market-data readiness by a median 0.7 s.

Loads: 5 of 5 warm loads ready; 5 of 5 uncached loads ready.

Panels ready (median, warm): price 3.9 s → order form 3.9 s → account 3.9 s → order book 4.1 s → chart 4.9 s

Servers, measured from the Netherlands:
page www.asterdex.com: observed CDN edge CloudFront Amsterdam, connect 14 ms, response 10 ms
market data fapi.asterdex.com: observed CDN edge CloudFront Amsterdam, connect 14 ms, response 234 ms

Stack

React; app files from static2.asterdexfx.com; BNB Chain RPC providers (Ankr, NodeReal, bscrpc, Ninicoin) and a SPACE ID name lookup; Privy wallet; market feeds from asterdex.com and a Binance stream.

Delivery

HTML from CloudFront (public, no-cache, edge hit); app files from static2.asterdexfx.com cached for a year; JSON from www.asterdex.com without a cache header.

What happened, in order

When	What
0.02 s	HTML arrives from CloudFront.
0.78–1.37 s	The first app scripts are only requested at 0.78 s: vendor (419 KB unpacked) and a shared locale bundle (544 KB unpacked).
1.71 s	A SPACE ID name lookup starts; it takes 2.1 s (until 3.80 s). BNB Chain RPC calls go out to Ankr, NodeReal, bscrpc and Ninicoin.
1.98 s	A 509 KB (unpacked) file from static.asterdexfx.com; the same 509 KB file is fetched again at 2.85 s.
2.08 s	An 819 KB (unpacked) JSON from www.asterdex.com; an 819 KB response is fetched again at 3.37 s and an 824 KB one at 3.39 s.
2.13 s	A Binance stream (nbstream.binance.com) opens; its handshake takes 1.7 s.
2.82 s	Page header shows the market; first paint at 2.85 s.
3.24 s	Aster's own market feeds open (fstream5, sstream); handshakes done at 4.00 s.
3.43 s	Price shows; order book at 4.20 s.
7.44 s	Chart drawn, 3.2 s after the book: trade-ready in this load. 19 long tasks took 3.5 s of main thread; vendor-BvbU0fAw.js alone 1.0 s.

Bottlenecks

AS-1 Nothing paints until 2.85 s although the HTML arrives in 15 ms. grade B
AS-2 The chart is drawn 3.2 s after the order book. grade C
AS-3 Exchange metadata, limits and translations are each requested twice. grade B
AS-4 Chain lookups run before the market data. grade C
AS-5 The market feeds open late and connect slowly. grade C
AS-6 The prediction-market catalog and all asset logos load on the perpetuals screen. grade C
AS-7 Trade-ready comes 0.7 s after the chart has its data: the chart is still animating. grade B

Evidence, the fix and how to verify each one are on the exchange's full page: open it.

recent trades not measured: inactive tab.

Backpack^1,2 Full page: bottlenecks and fixes →

Trade-ready: 4.0 s warm, 4.4 s uncached. Market data ready: 3.9 s warm. Last panel: entry, chart. Trade-ready followed market-data readiness by a median 0.2 s.

Loads: 4 of 4 warm loads ready (4 more not counted: test-side or session problems); 4 of 4 uncached loads ready (4 more not counted).

Panels ready (median, warm): price 2.5 s → order book 3.4 s → order form 3.7 s → chart 4.0 s

Servers, measured from the Netherlands:
page backpack.exchange: observed CDN edge CloudFront Amsterdam, connect 12 ms, response 233 ms

Stack

Next.js, bundled with Turbopack and rendered on the server; TradingView chart library (library.js, chart-widget-gui); Inter font from rsms.me.

Delivery

HTML rendered on the server and cached at CloudFront for 10 minutes (s-maxage=600), a miss in this load; market data from api.backpack.exchange; the chart library is served with max-age=0, while the app's own chunks are immutable for a year. On a warm reload 91 of 303 responses are re-checked with the server.

What happened, in order

When	What
0.47 s	HTML starts after a CloudFront miss (server-rendered, 753 KB unpacked). The 3 October recorded load: 0.51 s.
0.63–1.20 s	Eleven script chunks, up to 1.0 MB unpacked each.
0.99 s	Page header shows the market.
1.63 s	The live feed opens; handshake at 2.43 s, 0.8 s later; first message at 2.94 s.
2.17–2.87 s	Five api.backpack.exchange responses: 2.7, 2.1, 1.9 and 0.5 MB unpacked, plus 96 KB uncompressed: about 7 MB of JSON.
2.27 s	First paint.
2.40–2.90 s	Five more backpack.exchange responses of about 750 KB unpacked each (3.8 MB together), three of them the same size.
2.71–4.40 s	The chart library (library.js, 2.75 MB unpacked, max-age=0) takes 1.7 s; chart-widget-gui follows at 4.65–5.83 s.
2.91 s	Price shows.
5.01 s	Order book shows, 2.1 s after the feed's first message.
5.91 s	Chart drawn: trade-ready in this load.

Bottlenecks

BP-1 About 12 MB of JSON before the order book shows, 3.1 MB of it for pages the trader is not on. grade B
BP-2 The order book shows 2.1 s after the feed delivers, and the depth snapshot is requested twice. grade C
BP-3 The chart library is revalidated on every visit and takes 1.7 s. grade B
BP-4 The HTML waits 0.5 s for the server. grade B
BP-5 A 353 KB font is loaded from a third-party site. grade B
BP-6 Scripts keep arriving in late waves, also when cached. grade C

Evidence, the fix and how to verify each one are on the exchange's full page: open it.

measured logged out (fewer panels to load). recent trades not measured: inactive tab.

Binance^2,3 Full page: bottlenecks and fixes →

Trade-ready: 3.1 s warm, 3.0 s uncached. Market data ready: 2.8 s warm. Last panel: chart. Trade-ready followed market-data readiness by a median 0.3 s.

Loads: 5 of 5 warm loads ready; 5 of 5 uncached loads ready.

Panels ready (median, warm): price 1.7 s → trades 2.2 s → order form 2.2 s → order book 2.3 s → chart 2.8 s

Servers, measured from the Netherlands:
page www.binance.com: observed CDN edge CloudFront Amsterdam, connect 12 ms, response 9 ms

Stack

React (UMD vendor build) with app chunks from bin.bnbstatic.com; OneTrust banner; Sentry.

Delivery

HTML from www.binance.com through CloudFront, a miss in this load; app chunks cached a year; several JSON responses from www.binance.com are no-store; futures feed from fstream.binance.com.

What happened, in order

When	What
0.25 s	HTML starts after a CloudFront miss. The 3 October recorded load: 0.35 s.
0.36–0.85 s	App chunks (main 734 KB unpacked) and a 1.3 MB (unpacked) no-store JSON from www.binance.com.
0.80 s	Page header shows the market; first paint at 0.87 s.
0.86–2.35 s	A www.binance.com no-store request takes 1.5 s.
1.00 s	OneTrust banner SDK (555 KB unpacked).
1.87 s	The futures feed opens; handshake at 2.78 s; first message at 3.82 s.
1.90–2.84 s	A 1.6 MB (unpacked) JSON response.
3.06 s	Price shows, before the feed delivers; order book at 3.20 s.
4.21 s	Chart drawn: trade-ready in this load. The React vendor build starts 1.0 s of main-thread work.

Bottlenecks

BN-1 About 3.4 MB of JSON at start-up, half of it marked no-store. grade B
BN-2 The futures feed opens at 1.87 s and needs 0.9 s to connect. grade C
BN-3 The chart is drawn 1.0 s after the book, although its data and code arrive early. grade C
BN-4 Trade-ready comes 0.3 s after the chart: a font is still loading and the layout shifts. grade B
BN-5 The consent banner and error reporting run before the price. grade B
BN-6 In one of five uncached loads the recent-trades panel stayed empty for 25 seconds. grade C
BN-7 Ten to sixteen tracking beacons go out before the page is ready. grade C

Evidence, the fix and how to verify each one are on the exchange's full page: open it.

measured logged out (fewer panels to load). chart checked as drawn and updating, prices not read.

Bitfinex⁴ Full page: bottlenecks and fixes →

Trade-ready: 4.8 s warm, 4.8 s uncached. Market data ready: 4.7 s warm. Last panel: book. Trade-ready followed market-data readiness by a median 0.1 s.

Loads: 5 of 5 warm loads ready; 5 of 5 uncached loads ready.

Bottleneck seen in the timings: the order book arrives 1.6 s after every other panel.

Panels ready (median, warm): price 2.6 s → order form 2.6 s → chart 3.1 s → order book 4.7 s

Servers, measured from the Netherlands:
page trading.bitfinex.com: observed CDN edge Cloudflare Amsterdam, connect 13 ms, response 39 ms
market data api-pub.bitfinex.com: observed CDN edge Cloudflare Amsterdam, connect 13 ms, response 29 ms
market data api.bitfinex.com: observed CDN edge Cloudflare Amsterdam, connect 13 ms, response 33 ms

Stack

React, built with Vite (index and App chunks); TradingView chart library (library.js); Google Tag Manager.

Delivery

trading.bitfinex.com through Cloudflare over HTTP/2; HTML marked no-cache and not cached at the CDN (DYNAMIC); content-hashed app files cached for only one day; market data from api-pub.bitfinex.com and api.bitfinex.com.

What happened, in order

When	What
0.04 s	HTML arrives.
0.14–0.47 s	index.js (859 KB unpacked) and CSS.
0.49 s	First paint.
0.66–0.84 s	App.js (2.6 MB unpacked); both sockets open at 0.66 s. The public feed (api-pub) completes its handshake at 1.22 s and sends its first message at 1.24 s.
1.31–2.26 s	An api.bitfinex.com request takes 0.95 s.
2.40–2.87 s	Two REST responses from api-pub.bitfinex.com (337 KB and 197 KB unpacked, no-cache).
2.53 s	Price shows.
2.95 s	The chart library (library.js, 2.6 MB unpacked) is requested, after the price.
3.79 s	Chart drawn. This older capture did not time the order book, so it does not show trade-ready; in the five ranked warm loads the book is last, at 4.4–4.8 s.

Bottlenecks

BFX-1 The order book is the last panel in every warm load, about 1.5 s after the chart. grade C
BFX-2 Two REST responses are fetched 1.2 s after the public feed is connected. grade C
BFX-3 The chart library is requested after the price shows. grade C
BFX-4 Content-hashed files are cached for only one day. grade B
BFX-5 The order form changes height after everything is ready, which delays trade-ready by about 0.1 s. grade B
BFX-6 The ticker list is requested twice, 3 ms apart. grade C
BFX-7 Eleven media files (0.4 MB) are downloaded in the first second. grade C

Evidence, the fix and how to verify each one are on the exchange's full page: open it.

recent trades not measured: outside viewport.

BloFin¹ Full page: bottlenecks and fixes →

Trade-ready: 4.6 s warm, 5.2 s uncached. Market data ready: 3.5 s warm. Last panel: chart. Trade-ready followed market-data readiness by a median 1.1 s.

Loads: 5 of 5 warm loads ready; 5 of 5 uncached loads ready.

Bottleneck seen in the timings: the page is not steady until 1.1 s after the last panel shows real data (on the six exchanges we checked, an animation still running in the chart; it can also be a placeholder, late fonts or images, or a moving layout).

Panels ready (median, warm): price 1.2 s → account 2.6 s → order book 2.7 s → order form 2.7 s → chart 3.5 s

Servers, measured from the Netherlands:
page blofin.com: observed CDN edge Cloudflare Amsterdam, connect 13 ms, response 272 ms
market data openapi.blofin.com: observed CDN edge Cloudflare Amsterdam, connect 14 ms, response 10 ms

Stack

Not captured on 1 October: that diagnostic load was stopped by a Cloudflare bot check before the trading page loaded.

Delivery

blofin.com through Cloudflare over HTTP/3.

What happened, in order

From one warm reload recorded with Chrome's performance trace on 3 October 2026. Recording slows the page, so read the order and the gaps, not the totals. Some host names were masked when the recording was saved.

When	What
0.38 s	HTML arrives (3 October recorded warm load).
1.10 s	Price shows.
2.01–3.38 s	Three groups of chart requests, one after another: 2.01–2.29 s (probably the chart settings), 2.67–2.94 s and 3.12–3.38 s (probably two rounds of candles).
2.58 s	Account panel shows; order book and order form at 2.73 s.
3.09 s	Chart drawn.
4.22 s	Trade-ready in the recorded load: the chart keeps animating for 1.1 s after it has its data.

Bottlenecks

BF-1 Trade-ready comes 1.1 s after the last panel has its data: the chart is still animating. grade B
BF-2 The chart's first candles are requested late, after a settings request. grade C
BF-3 Small account and header requests are repeated, and a chatbot and a large header bundle load while the chart is starting. grade C
BF-4 151 script requests on a warm reload, a third of them in a group at 2 s. grade C
BF-5 One of three public feed sockets is opened and connected but never used. grade B
BF-6 The chart library's start-up blocks the main thread for about 0.23 s in its module runtime. grade C

Evidence, the fix and how to verify each one are on the exchange's full page: open it.

recent trades not measured: inactive tab.

BTSE⁴ Full page: bottlenecks and fixes →

Trade-ready: 7.0 s warm, 7.0 s uncached. Market data ready: 5.9 s warm. Last panel: chart. Trade-ready followed market-data readiness by a median 1.1 s.

Loads: 5 of 5 warm loads ready (2 more not counted: test-side or session problems); 5 of 5 uncached loads ready (2 more not counted).

Bottleneck seen in the timings: no panel shows real data until 5.1 s (the order form comes first), so the delay is in starting the app, before any one panel; the page is not steady until 1.1 s after the last panel shows real data (on the six exchanges we checked, an animation still running in the chart; it can also be a placeholder, late fonts or images, or a moving layout).

Panels ready (median, warm): order form 5.1 s → account 5.1 s → price 5.2 s → order book 5.2 s → chart 5.9 s

Servers, measured from the Netherlands:
page www.btse.com: observed CDN edge CloudFront Amsterdam, connect 13 ms, response 35 ms

Likely saving if fixed: About 3 s faster on a warm reload, from 7.0 s to about 4 s, with BT-1, BT-2, BT-4 and BT-5; reaching 2.5–3 s also needs BT-3.

Stack

Not captured on 1 October; from the 3 October recorded warm load only.

Delivery

www.btse.com through CloudFront.

What happened, in order

When	What
0.79 s	HTML arrives, among the slowest in the test.
1.67–2.69 s	About 20 API requests go out together; each waits 0.7–1.0 s for the server.
2.92–4.13 s	Two more rounds of API requests; the last one finishes at 4.13 s.
3.45 s	Order form and wallet panel show.
4.14 s	The page sends its first frame on the market socket (ws.btse.com), right after the last API round; first message at 4.37 s.
4.80 s	Price and order book show.
5.88 s	Chart drawn.
6.92 s	Trade-ready in the recorded load. Long tasks before the first panel: 1.5 s, the longest 575 ms.

Bottlenecks

BT-1 The market feed sends its first frame only at 4.1 s, after three rounds of API requests. grade C
BT-2 The HTML takes 0.8 s. grade B
BT-3 1.5 s of long main-thread tasks before the first panel. grade B
BT-4 Trade-ready comes 1.1 s after the last panel has its data: the chart is still animating. grade B
BT-5 The chart is drawn 0.7 s after price and book. grade C
BT-6 For a first-time visitor, a device-check script blocks the page for over 2 s. grade B
BT-7 API requests are preceded by a permission request, adding about 0.3 s per round. grade C
BT-8 A 1.1 MB translation file is re-checked on every load, and the fonts use an old format. grade B
BT-9 Advertising and tag scripts are requested in the first 1.4 s. grade C
BT-10 Scripts force the browser to recalculate layout 538 times during a warm reload. grade B
BT-11 A 0.75 s blocking task spent setting and clearing timers through the error-reporting wrapper. grade C

Evidence, the fix and how to verify each one are on the exchange's full page: open it.

recent trades not measured: outside viewport.

Bybit^1,2,5 Full page: bottlenecks and fixes →

Trade-ready: 3.9 s warm, 4.7 s uncached. Market data ready: 2.9 s warm. Last panel: chart. Trade-ready followed market-data readiness by a median 0.9 s.

Loads: 5 of 5 warm loads ready (1 more not counted: test-side or session problems); 5 of 5 uncached loads ready (1 more not counted).

Panels ready (median, warm): price 1.7 s → order book 2.0 s → account 2.0 s → order form 2.8 s → chart 2.9 s

Servers, measured from the Netherlands:
page www.bybit.com: connect 13 ms, response 23 ms

Stack

React 18.2; TradingView chart library (library.js, the largest in this test); unversioned "latest" scripts (data-core, by-vendors, header, antiPhishingCode); AppsFlyer, an A/B-test service and Google sign-in.

Delivery

www.bybit.com over HTTP/3 (OpenResty); HTML cached 60 s; hashed app files cached a year; unversioned "latest" scripts cached for 60–300 s; market data over one socket to ws2.bybit.com.

What happened, in order

When	What
0.07 s	HTML arrives.
0.21–0.55 s	main.js (2.4 MB unpacked), vendor-biz (0.9 MB), data-core.latest, by-vendors.latest; react.18.2 later starts 1.04 s of main-thread work.
0.72 s	First paint.
1.09 s	The market socket opens; handshake at 1.64 s; first message at 2.14 s.
1.71–1.90 s	header.latest.js (617 KB unpacked) and antiPhishingCode.latest.js (328 KB unpacked).
1.75–3.02 s	A/B-test requests to sc-abtest…de take 1.3 s.
2.75 s	Order book shows; price at 3.24 s.
3.70 s	The chart library is requested: library.js, 0.8 MB compressed, 4.8 MB unpacked.
3.78 s	Google sign-in script (268 KB unpacked).
5.29 s	Chart drawn: trade-ready in this load.

Bottlenecks

BY-1 The 4.9 MB chart library is requested only after book and price are up. grade C
BY-2 Eleven unversioned scripts are cached for only 60 to 300 seconds. grade B
BY-3 Marketing and sign-in scripts compete with the chart. grade C
BY-4 Trade-ready comes 0.9 s after the chart has its data: the chart is still animating. grade B
BY-5 In one of five uncached loads the order book dropped out for 5.7 seconds. grade C
BY-6 A 0.2 MB translation file and the web configuration are requested repeatedly. grade B

Evidence, the fix and how to verify each one are on the exchange's full page: open it.

measured logged out (fewer panels to load). order book or trades drawn as a picture; checked as drawn and updating, values not read. recent trades not measured: inactive tab.

Coinbase TradingView^1,5 Full page: bottlenecks and fixes →

Trade-ready: 8.0 s warm, 9.1 s uncached. Market data ready: 7.2 s warm. Last panel: account. Trade-ready followed market-data readiness by a median 0.7 s.

Loads: 5 of 5 warm loads ready (2 more not counted: test-side or session problems); 5 of 5 uncached loads ready (2 more not counted).

Bottleneck seen in the timings: no panel shows real data until 6.9 s (the price comes first), so the delay is in starting the app, before any one panel.

Panels ready (median, warm): price 6.9 s → order book 6.9 s → order form 6.9 s → chart 7.2 s → account 7.6 s

Servers, measured from the Netherlands:
page www.coinbase.com: observed CDN edge Cloudflare Amsterdam, connect 12 ms, response 110 ms
market data api.coinbase.com: observed CDN edge Cloudflare Amsterdam, connect 12 ms, response 15 ms

Likely saving if fixed: About 4–5 s faster on a warm reload, from 8.0 s to roughly 3–3.5 s, mostly by cutting the code-loading waves before the trading panels draw (CBT-1, CBT-2).

Stack

React app split into over a thousand small chunks (c_*.js); TradingView charting library from static-assets.coinbase.com; OneTrust banner; Google Pay script.

Delivery

www.coinbase.com through Cloudflare over HTTP/2 with long-lived cached app files; market data from Coinbase (drb.coinbase.com, ws-retail) and Deribit (www.deribit.com, history.deribit.com), Coinbase's derivatives exchange.

What happened, in order

When	What
0.16 s	HTML arrives.
0.31–0.71 s	app-shell.js (0.7 MB compressed, 3.4 MB unpacked) and boot scripts; 1.6 s of main-thread work later starts in c_boot-vendor.
1.79–2.97 s	A 5.1 MB (unpacked; 117 KB compressed) response from www.deribit.com marked no-store, and four no-store responses from www.coinbase.com of 1.1, 0.5, 0.4 and 0.3 MB.
1.82–2.45 s	The live feeds open (ws-retail, streams.drb, drb.coinbase.com); first messages at 2.45–2.93 s.
1.82–8.54 s	One www.coinbase.com request stays open for 6.7 s.
2.1–7.5 s	Chunk after chunk: c_CO0lZDQN.js (1.0 MB compressed, 5.4 MB unpacked) at 2.13 s, then dozens more until 7.5 s; 1,298 requests to www.coinbase.com in total before trade-ready.
9.43 s	Price shows (the order book is not separately detectable in this capture).
9.73 s	The chart library (library.js, 2.8 MB unpacked) is requested; trading.js at 10.22 s.
11.65 s	Chart drawn: trade-ready in this load.

Bottlenecks

CBT-1 The price appears about 4.7 s after the live feed delivers. grade C
CBT-2 About 1,260 code files load in waves before anything is usable, even from the browser cache. grade B
CBT-3 About 7 MB (unpacked) of uncacheable JSON on every load: the full Deribit instrument list and five product-list requests. grade B
CBT-4 The chart library is requested only after the price shows. grade C
CBT-5 The chart can show the wrong market after a switch. grade B
CBT-6 24 GraphQL requests and 15 analytics requests are spread over the load, most of them before the price. grade C
CBT-7 The consent banner and Google Pay load before the price shows. grade B
CBT-8 Coinbase rejects some of its own start-up requests with HTTP 429, and the page keeps retrying. grade B
CBT-9 Scripts force the browser to recalculate layout 70 times during the load. grade C
CBT-10 The chart library starts up with a 170 ms blocking task and loads optional dialogs and toolbars at once. grade C

Evidence, the fix and how to verify each one are on the exchange's full page: open it.

order book or trades drawn as a picture; checked as drawn and updating, values not read. recent trades not measured: inactive tab.

Coinbase native^1,3,5 Full page: bottlenecks and fixes →

Trade-ready: 7.6 s warm, 8.4 s uncached. Market data ready: 7.3 s warm. Last panel: account, chart. Trade-ready followed market-data readiness by a median 0.2 s.

Loads: 5 of 5 warm loads ready (1 more not counted: test-side or session problems); 5 of 5 uncached loads ready (1 more not counted).

Bottleneck seen in the timings: no panel shows real data until 6.3 s (the price comes first), so the delay is in starting the app, before any one panel.

Panels ready (median, warm): price 6.3 s → order book 6.3 s → order form 6.3 s → account 7.2 s → chart 7.3 s

Servers, measured from the Netherlands:
page www.coinbase.com: observed CDN edge Cloudflare Amsterdam, connect 13 ms, response 17 ms
market data api.coinbase.com: observed CDN edge Cloudflare Amsterdam, connect 14 ms, response 13 ms

Likely saving if fixed: About 4–5 s faster on a warm reload, from 7.6 s to roughly 3 s, mostly by cutting the code-loading waves before the trading panels draw (CBN-1, CBN-2).

Stack

React app split into over a thousand small chunks (c_*.js), with Coinbase's own chart; Sentry boot module; OneTrust banner; Google Pay script.

Delivery

www.coinbase.com through Cloudflare over HTTP/2; the HTML is marked no-store and is not cached at the CDN (cf-cache-status DYNAMIC); app files cached for a year. Market data from Coinbase (ws-retail, drb.coinbase.com) and Deribit (www.deribit.com, history.deribit.com). In the 3 October recorded reload Coinbase answered the first page request with HTTP 429 (too many requests) and the page loaded a second time; none of the 10 timed loads did.

What happened, in order

When	What
0.17 s	HTML arrives (no-store, not cached at the CDN).
0.39–0.78 s	app-shell.js (0.7 MB compressed, 3.4 MB unpacked) and boot scripts; 1.36 s of main-thread work later starts in c_boot-vendor and 0.68 s in c_boot-sentry.
1.65–2.61 s	A 5.1 MB (unpacked; 116 KB compressed) response from www.deribit.com marked no-store, plus four no-store responses from www.coinbase.com of 1.1, 0.5, 0.4 and 0.3 MB.
1.66–1.90 s	Live feeds open (ws-retail, streams.drb, drb.coinbase.com); first messages at 2.16–2.62 s; 203 messages on streams.drb before trade-ready.
1.69–8.20 s	One www.coinbase.com request stays open for 6.5 s.
1.9–6.9 s	Chunks keep arriving: c_CO0lZDQN.js (1.0 MB compressed, 5.4 MB unpacked) at 1.90 s, c_B_3SNTlO.js (0.8 MB, 3.3 MB) at 3.72 s, c_DJwp1o7e.js (0.4 MB, 1.4 MB) at 5.92 s; 1,284 requests to www.coinbase.com before trade-ready.
2.04 s	First paint.
8.09 s	Price shows.
9.83 s	Chart drawn: trade-ready in this load. 25 long tasks took 3.3 s of main thread.

Bottlenecks

CBN-1 The price appears about 5.7 s after the live feed delivers. grade C
CBN-2 About 1,150 code files load in waves before anything is usable, even from the browser cache. grade B
CBN-3 About 7 MB (unpacked) of uncacheable JSON on every load: the full Deribit instrument list and five product-list requests. grade B
CBN-4 About 2 s of main-thread work starts in two boot scripts. grade C
CBN-5 The chart is drawn 1.0 s after the price, although its candle data arrives at 1.4 s. grade C
CBN-6 25 GraphQL requests and 16 analytics requests are spread over the load, most of them before the price. grade C
CBN-7 The consent banner and Google Pay load before the price shows. grade B
CBN-8 Coinbase rejects some of its own start-up requests with HTTP 429, and the page keeps retrying. grade B
CBN-9 Scripts force the browser to recalculate layout 74 times during the load. grade C

Evidence, the fix and how to verify each one are on the exchange's full page: open it.

order book or trades drawn as a picture; checked as drawn and updating, values not read. chart checked as drawn and updating, prices not read. recent trades not measured: inactive tab.

Decibel¹ Full page: bottlenecks and fixes →

Trade-ready: 5.0 s warm, 6.5 s uncached. Market data ready: 4.2 s warm. Last panel: chart, positions, account-info. Trade-ready followed market-data readiness by a median 0.7 s.

Loads: 5 of 5 warm loads ready; 5 of 5 uncached loads ready.

Bottleneck seen in the timings: no panel shows real data until 3.3 s (the price comes first), so the delay is in starting the app, before any one panel.

Panels ready (median, warm): price 3.3 s → order book 3.3 s → order form 3.3 s → chart 4.2 s → account 4.3 s

Servers, measured from the Netherlands:
page app.decibel.trade: connect 14 ms, response 30 ms
market data api.mainnet.aptoslabs.com: connect 17 ms, response 16 ms

Stack

Next.js (Turbopack); TradingView chart library; Sentry with session replay; RudderStack analytics. Not captured on 1 October: from the 3 October recorded warm load, plus a logged-out follow-up recording that keeps the addresses but stopped at a legal notice.

Delivery

app.decibel.trade; market data from the Aptos API (api.mainnet.aptoslabs.com).

What happened, in order

When	What
0.49 s	HTML arrives.
1.87 s	First market-data request.
2.13 s	The market socket subscribes; first message at 2.26 s.
3.55 s	Price, order book and order form show, 1.3 s after the first message.
4.16 s	Positions and account panel show.
4.39 s	Chart drawn.
5.07 s	Trade-ready in the recorded load. 1.5 s of long tasks before the first panel, the longest 348 ms; 115 script requests before the first panel.

Bottlenecks

DC-1 Nothing shows until 3.5 s: data is requested at 1.9 s and drawn 1.3 s after it arrives. grade C
DC-2 1.5 s of long main-thread tasks before the first panel. grade B
DC-3 The HTML takes 0.5 s. grade B
DC-4 Trade-ready comes 0.7 s after the panels are in: the chart and the order form are still animating. grade B
DC-5 Analytics requests fail and are retried while the page loads. grade B
DC-6 A 227 KB font file. grade B

Evidence, the fix and how to verify each one are on the exchange's full page: open it.

recent trades not measured: inactive tab.

Deribit⁶ Full page: bottlenecks and fixes →

Trade-ready: 4.2 s warm, 4.1 s uncached. Market data ready: 3.5 s warm. Last panel: chart. Trade-ready followed market-data readiness by a median 0.7 s.

Loads: 5 of 5 warm loads ready (2 more not counted: test-side or session problems); 5 of 5 uncached loads ready (2 more not counted).

Panels ready (median, warm): price 2.8 s → order book 2.8 s → trades 2.8 s → order form 2.8 s → chart 3.5 s

Servers, measured from the Netherlands:
page www.deribit.com: observed CDN edge Cloudflare Amsterdam, connect 13 ms, response 22 ms
market data deribit.com: observed CDN edge Cloudflare Amsterdam, connect 13 ms, response 22 ms

Stack

React, built with Vite; TradingView chart library from assets.deribit.com; Highcharts; Sentry.

Delivery

www.deribit.com through Cloudflare over HTTP/2; hashed app files cached for only 4 hours; two of the seven fonts shipped as uncompressed TTF; market data over two sockets (www.deribit.com, streams.deribit.com).

What happened, in order

When	What
0.03 s	HTML arrives.
0.40–0.62 s	index (2.4 MB unpacked), GlobalEventEmitter (1.3 MB), CurrencySearch (1.15 MB), LayoutWithHeader (0.7 MB). index.js later starts 1.53 s of main-thread work.
0.90 s	Both market sockets open; first messages at 0.99 and 1.07 s. First paint at 0.90 s.
1.09 s	A 5.0 MB (unpacked) instrument response, no-store: the same one Coinbase's pages download.
1.31–1.51 s	GridLayout (2.5 MB unpacked), Highcharts and the trading modal.
2.42 s	Page header shows the market.
2.58–3.34 s	The chart library (library.js, 2.4 MB unpacked).
3.55 s	Price and order book show, 2.6 s after the feed's first messages.
4.55 s	Chart drawn: trade-ready in this load.

Bottlenecks

DB-1 Price and book show 2.6 s after the feed delivers. grade C
DB-2 The 5 MB instrument list is fetched twice on every load and cannot be cached. grade B
DB-3 Hashed files cached for only 4 hours. grade B
DB-4 Trade-ready comes 0.7 s after the chart has its data: the chart is still animating. grade B
DB-5 The chart code arrives in a late wave, also when cached. grade C
DB-6 Twelve media files (0.35 MB) are downloaded in the first second. grade C

Evidence, the fix and how to verify each one are on the exchange's full page: open it.

loaded behind a pop-up that appears on every load.

Derive Full page: bottlenecks and fixes →

Trade-ready: 5.1 s warm, 8.3 s uncached. Market data ready: 4.2 s warm. Last panel: chart. Trade-ready followed market-data readiness by a median 0.8 s.

Loads: 5 of 5 warm loads ready; 5 of 5 uncached loads ready.

Panels ready (median, warm): price 1.7 s → order form 2.5 s → trades 3.2 s → account 3.2 s → order book 3.3 s → chart 4.2 s

Servers, measured from the Netherlands:
page app.derive.xyz: connect 13 ms, response 28 ms
market data api.lyra.finance: observed CDN edge Cloudflare Amsterdam, connect 13 ms, response 260 ms
market data api.derive.xyz: observed CDN edge Cloudflare Amsterdam, connect 14 ms, response 256 ms

Stack

Next.js on Vercel; TradingView chart library (library.js); WalletConnect / web3modal, Alchemy RPC; Intercom.

Delivery

HTML from Vercel marked private, no-store, so never cached; market data from api.lyra.finance, whose responses the CDN does not cache (cf-cache-status: DYNAMIC), although some declare a short lifetime; the chart library is served with max-age=0, while the app's own script chunks are cached for a year.

What happened, in order

When	What
0.02 s	HTML arrives (Vercel).
0.18–0.88 s	Next.js chunks (up to 401 KB unpacked each).
0.50 s	Page header shows the market.
1.10–3.28 s	REST calls to api.lyra.finance take 1.6–2.2 s each.
1.24 s	Three separate sockets to api.lyra.finance open; their handshakes finish at 2.15, 2.51 and 2.87 s (0.9–1.6 s); first messages at 2.66–3.28 s.
1.32 s	First paint.
2.94–4.62 s	A 657 KB (unpacked) api.lyra.finance response takes 1.7 s.
3.02 s	Price and order book show.
3.69 s	The chart library (library.js, 2.5 MB unpacked, max-age=0) is requested.
5.21 s	Chart drawn: trade-ready in this load.

Bottlenecks

DV-1 Market-data requests to api.lyra.finance take 1.6–2.2 s, and its sockets 0.9–1.6 s to connect. grade B
DV-2 The chart library is requested after price and book, and revalidated on every visit. grade B
DV-3 Three sockets to the same API. grade B
DV-4 A 657 KB response overlaps the wait for the chart. grade C
DV-5 The three private order lists are each requested twice, 15 ms apart. grade C
DV-6 Thirteen tracking requests and two slow app requests run before the page is ready. grade C
DV-7 Trade-ready comes 0.8 s after the panels are in on a warm load and 1.9 to 2.6 s on an uncached one: the chart is still animating. grade B

Evidence, the fix and how to verify each one are on the exchange's full page: open it.

Extended¹ Full page: bottlenecks and fixes →

Trade-ready: 5.1 s warm, 5.4 s uncached. Market data ready: 4.3 s warm. Last panel: positions. Trade-ready followed market-data readiness by a median 0.8 s.

Loads: 5 of 5 warm loads ready; 5 of 5 uncached loads ready.

Panels ready (median, warm): price 2.9 s → order form 4.2 s → chart 4.3 s → order book 4.3 s → account 4.6 s

Servers, measured from the Netherlands:
page app.extended.exchange: observed CDN edge CloudFront Amsterdam, connect 13 ms, response 10 ms
market data api.starknet.extended.exchange: connect 242 ms, response 233 ms (high connect time, including name resolution; cause not isolated)

Stack

React, built with Vite; TradingView chart library from cdn.extended.exchange; two wallet SDKs (Dynamic and Privy) plus WalletConnect/Reown, viem and starknet-crypto; a service worker.

Delivery

HTML from AWS S3 through CloudFront, marked no-store; in the capture it missed the edge cache (x-cache: Miss). 225 of the app's static files carry no cache-control header. On a warm reload a service worker answers 236 of the 414 requests made before trade-ready.

What happened, in order

When	What
0.73 s	HTML arrives: a CloudFront miss to S3 (no-store). The 3 October recorded load measured 0.70 s.
0.91–1.47 s	Startup scripts download in parallel: dynamic-labs (0.9 MB compressed, 3.4 MB unpacked), viem (2.3 MB), privy (2.3 MB), starknet-crypto (1.4 MB), components (1.1 MB), reown (0.5 MB), walletconnect (0.45 MB): about 12 MB unpacked, most of it wallet and chain code.
1.87 s	First paint. Over the whole load, 1.29 s of main-thread work starts in index.js.
2.12 s	The live feed opens (app.extended.exchange); handshake done at 2.62 s; its first message arrives only at 5.95 s.
2.50 s	A 2.1 MB file from iconic.dynamic-static-assets.com (Dynamic's icons); the same 2.1 MB file is fetched again at 5.65 s.
2.96 s	The Privy iframe loads its script chunks.
4.15 s	A 1.0 MB JSON response sent without compression (no-store); the same 1.0 MB response is requested again at 5.60 s.
5.67 s	The page header shows the market; price at 6.31 s; order book at 7.42 s.
7.76 s	Chart drawn: trade-ready in this load. 23 long tasks took 3.4 s of main thread.

Bottlenecks

EX-1 The HTML takes 0.7 s; it is marked no-store and missed the edge cache. grade B
EX-2 About 12 MB of startup JavaScript, mostly two wallet SDKs and chain libraries. grade B
EX-3 The 1.0 MB market list is fetched twice per load, uncompressed, and a 2.1 MB icon file twice. grade B
EX-4 225 static files have no cache-control header. grade B
EX-5 The feed is connected at 2.6 s but delivers its first message at 6.0 s. grade C
EX-6 Trade-ready comes 0.8 s after the chart and book: the positions panel and the chart are still animating. grade C

Evidence, the fix and how to verify each one are on the exchange's full page: open it.

recent trades not measured: inactive tab.

Gains¹ Full page: bottlenecks and fixes →

Trade-ready: 5.6 s warm, 5.7 s uncached. Market data ready: 4.4 s warm. Last panel: chart. Trade-ready followed market-data readiness by a median 1.1 s.

Loads: 5 of 5 warm loads ready; 5 of 5 uncached loads ready.

Bottleneck seen in the timings: the page is not steady until 1.2 s after the last panel shows real data (on the six exchanges we checked, an animation still running in the chart; it can also be a placeholder, late fonts or images, or a moving layout).

Panels ready (median, warm): order form 2.9 s → account 3.0 s → price 3.7 s → order book 3.8 s → chart 4.4 s

Servers, measured from the Netherlands:
page gains.trade: observed CDN edge Cloudflare Amsterdam, connect 13 ms, response 12 ms
market data backend-pricing.eu.gains.trade: observed CDN edge Cloudflare Amsterdam, connect 14 ms, response 13 ms
market data backend-pricing.gains.trade: connect not reached, response not reached

Stack

Next.js (React); TradingView charting library served from gains.trade; Privy and WalletConnect wallets; Sentry; Intercom.

Delivery

gains.trade through Cloudflare over HTTP/3; HTML and app files carry max-age=300 with stale-while-revalidate=3600, although most file names are content-hashed. On a warm reload a service worker answers 116 of the 277 requests made before trade-ready.

What happened, in order

When	What
0.03 s	HTML arrives from Cloudflare's cache.
0.20–1.23 s	_app.js downloads: 3.7 MB compressed, 14.2 MB unpacked, the largest single script in this test. framework.js then runs 1.47 s and _app.js 0.82 s on the main thread.
0.58 s	First paint.
2.18–2.61 s	Two large JSON responses: backend-global (1.9 MB unpacked, no cache header) and backend-base (1.6 MB unpacked, max-age=0).
2.24 s	WalletConnect wallet registry, 1.2 MB unpacked.
2.27 s	The price feed (backend-pricing.eu.gains.trade) opens; handshake done at 3.43 s, 1.15 s later; first message at 3.54 s.
3.67 s	The Privy wallet iframe loads its script chunks (34 requests, 0.94 MB compressed).
5.57 s	Price shows, 2.0 s after the price feed's first message.
5.89 s	charting_library.js (0.6 MB compressed, 2.5 MB unpacked) is requested, after the price.
6.80 s	Chart drawn: trade-ready in this load. 17 long tasks took 2.9 s of main thread.

Bottlenecks

GN-1 A 14.2 MB application script. grade B
GN-2 Content-hashed files are cached for 5 minutes, then refreshed in the background. grade B
GN-3 The price shows 2.0 s after the price feed delivers. grade C
GN-4 The chart library is requested only after the price shows. grade C
GN-5 Wallet code and 3.6 MB of JSON load before the market is on screen. grade C
GN-6 The public Base RPC rejects requests during start-up (HTTP 429). grade C
GN-7 Tracking and support requests repeat before the chart. grade B
GN-8 Trade-ready comes 0.7 s after the chart has its data: the chart is still animating. grade B
GN-9 Scripts force the browser to recalculate layout 44 times during a warm reload. grade C

Evidence, the fix and how to verify each one are on the exchange's full page: open it.

recent trades not measured: inactive tab.

GRVT¹ Full page: bottlenecks and fixes →

Trade-ready: 4.8 s warm, 6.0 s uncached. Market data ready: 4.6 s warm. Last panel: price, chart. Trade-ready followed market-data readiness by a median 0.2 s.

Loads: 5 of 5 warm loads ready; 5 of 5 uncached loads ready.

Panels ready (median, warm): order form 3.0 s → order book 3.6 s → price 4.6 s → chart 4.6 s

Servers, measured from the Netherlands:
page grvt.io: observed CDN edge Cloudflare Amsterdam, connect 14 ms, response 285 ms
market data market-data.grvt.io: observed CDN edge Cloudflare Amsterdam, connect 13 ms, response 254 ms

Stack

Next.js, server-rendered; TradingView chart library (grvt.io/library.js); WalletConnect; PostHog, Plausible, Sentry and Intercom.

Delivery

HTML marked private, no-store and not cached at the CDN (Cloudflare DYNAMIC); app files immutable for a year; market data from market-data.grvt.io and trades.grvt.io.

What happened, in order

When	What
0.64 s	HTML starts to arrive after 0.64 s; the document is 1.1 MB unpacked (190 KB compressed) and finishes at 1.39 s. The 3 October recorded load: 0.59 s.
0.81–1.33 s	First wave of 36 scripts (the largest 1.4 MB unpacked).
1.16 s	Page header shows the market; first paint at 1.18 s.
2.09–2.18 s	Two feeds open (tradesiren, trades.grvt.io), and a rewards request (reward.grvt.io) that takes 1.5 s.
2.40–2.72 s	Second wave of 30 scripts (up to 0.9 MB unpacked).
3.39 s	The market-data feed opens, last of the three; handshake at 4.28 s, first message at 4.61 s; 1,522 messages before trade-ready.
3.46 s	WalletConnect registry, 1.2 MB unpacked.
4.89 s	Order book shows.
6.13 s	Price shows, 1.2 s after the book.
6.88–8.17 s	A market-data.grvt.io request takes 1.3 s.
8.26 s	Chart drawn: trade-ready in this load.

Bottlenecks

GR-1 The HTML takes 0.6 s to its first byte and is 1.1 MB. grade B
GR-2 The market-data feed opens last, at 3.39 s. grade C
GR-3 The price shows 1.2 s after the order book. grade C
GR-4 The chart is drawn right after a 1.3 s candle request that starts late. grade C
GR-5 edge.grvt.io/query is called 17 times before the page is ready. grade C
GR-6 Other pages are fetched at start-up, and positions are read twice. grade B
GR-7 Analytics, survey, support and wallet scripts load before the chart. grade B
GR-8 In most loads trade-ready comes up to 0.8 s after the panels are in: the chart is still animating. grade B

Evidence, the fix and how to verify each one are on the exchange's full page: open it.

recent trades not measured: inactive tab.

HyperFlow⁴ Full page: bottlenecks and fixes →

Trade-ready: 3.5 s warm, 4.1 s uncached. Market data ready: 2.8 s warm. Last panel: chart. Trade-ready followed market-data readiness by a median 0.7 s.

Loads: 5 of 5 warm loads ready (2 more not counted: test-side or session problems); 6 of 6 uncached loads ready (1 more not counted).

Panels ready (median, warm): order form 0.7 s → account 0.7 s → price 0.9 s → order book 1.8 s → chart 2.8 s

Servers, measured from the Netherlands:
page hyperflow.fun: connect 14 ms, response 32 ms
market data api.hyperliquid.xyz: observed CDN edge CloudFront Amsterdam, connect 12 ms, response 230 ms
market data api-ui.hyperliquid.xyz: observed CDN edge CloudFront Amsterdam, connect 12 ms, response 238 ms

Stack

React, built with Vite, on Vercel; TradingView chart library; viem and ethers; Privy and WalletConnect; trades on Hyperliquid through api.hyperliquid.xyz.

Delivery

hyperflow.fun on Vercel over HTTP/2 with every file served max-age=0, must-revalidate; market data from Hyperliquid's API (api.hyperliquid.xyz), over HTTP/1.1 and without compression.

What happened, in order

When	What
0.02 s	HTML arrives (Vercel).
0.11–0.45 s	index-DcwWVkXX.js (1.8 MB compressed, 6.2 MB unpacked) with viem and ethers; index starts 1.0 s of main-thread work.
0.51 s	First paint.
0.91 s	The Hyperliquid feed opens (handshake 1.47 s, first message 1.76 s) and four REST calls go out; the three large ones (72, 64 and 137 KB) are returned uncompressed at 1.55–1.72 s.
0.93 s	WalletConnect registry, 1.2 MB unpacked.
1.09 s	Page header shows the market; price at 1.50 s.
2.39 s	Order book shows.
4.13 s	Chart drawn, 1.7 s after the book: trade-ready in this load.

Bottlenecks

HF-1 The chart is drawn 1.7 s after the book; its code arrives in a late wave. grade C
HF-2 A 6.2 MB main script that is revalidated on every visit. grade B
HF-3 The first Hyperliquid API calls take 0.6 to 0.8 s, uncompressed and over HTTP/1.1. grade B
HF-4 Trade-ready comes 0.7 s after the chart has its data: the chart is still animating. grade B
HF-5 Wallet and token lists load before the market is on screen. grade C

Evidence, the fix and how to verify each one are on the exchange's full page: open it.

recent trades not measured: outside viewport.

Hyperliquid¹ Full page: bottlenecks and fixes →

Trade-ready: 3.1 s warm, 3.5 s uncached. Market data ready: 2.5 s warm. Last panel: chart, book. Trade-ready followed market-data readiness by a median 0.6 s.

Loads: 5 of 5 warm loads ready (1 more not counted: test-side or session problems); 5 of 5 uncached loads ready (1 more not counted).

Panels ready (median, warm): account 0.8 s → order form 1.7 s → price 1.9 s → order book 2.2 s → chart 2.5 s

Servers, measured from the Netherlands:
page app.hyperliquid.xyz: observed CDN edge CloudFront Amsterdam, connect 12 ms, response 8 ms
market data api.hyperliquid.xyz: observed CDN edge CloudFront Amsterdam, connect 12 ms, response 226 ms
market data api-ui.hyperliquid.xyz: observed CDN edge CloudFront Amsterdam, connect 13 ms, response 232 ms

Stack

React, built with Vite; TradingView charting library; Privy wallet iframe and WalletConnect; Statuspage embed.

Delivery

Page and files from AWS S3 through CloudFront over HTTP/1.1, compressed, with no cache-control header on the app files; market data from api-ui.hyperliquid.xyz through CloudFront. No service worker.

What happened, in order

When	What
0.02 s	HTML arrives (CloudFront, HTTP/1.1).
0.11–0.49 s	Entry scripts download: index (296 KB compressed, 1.3 MB unpacked), config (525 KB, 2.1 MB), index-CUao (226 KB, 0.8 MB), LineChart (88 KB).
0.85 s	The app opens the live feed to api-ui.hyperliquid.xyz and, at the same moment, fetches the WalletConnect wallet registry: 170 KB compressed, 1.2 MB unpacked.
0.91 s	First paint.
1.54 s	Live-feed handshake completes, 0.7 s after it started; first message at 1.95 s.
1.75–2.14 s	The Privy wallet iframe loads 31 scripts, 0.9 MB compressed and 3.4 MB unpacked.
2.40 s	Price shows; order book at 2.63 s.
2.57 s	Candle history is requested (46 KB); it answers at 3.56 s.
3.73 s	Chart drawn: trade-ready in this load. react-dom alone started 0.86 s of main-thread work.

Bottlenecks

HL-1 All first-party files travel over HTTP/1.1. grade B
HL-2 Candle history is requested late, just before the order book shows. grade C
HL-3 The wallet stack loads before the market is on screen. grade C
HL-4 The live feed needs 0.7 s to connect. grade C
HL-5 The app files have no cache-control header, and a warm reload re-checks 158 of 194 responses. grade B
HL-6 The chart is still animating 0.6 s after it has its data. grade B
HL-7 The status-page script is loaded twice in the first 0.5 s. grade B

Evidence, the fix and how to verify each one are on the exchange's full page: open it.

recent trades not measured: inactive tab.

Insilico Terminal^3,5,7,8 Full page: bottlenecks and fixes →

Trade-ready: 3.5 s warm, 3.7 s uncached. Market data ready: 3.5 s warm. Last panel: orders. Trade-ready followed market-data readiness by a median 0.0 s.

Loads: 5 of 5 warm loads ready; 5 of 5 uncached loads ready.

Panels ready (median, warm): price 1.7 s → order form 1.8 s → chart 2.5 s → order book 3.2 s → account 3.5 s

Servers, measured from the Netherlands:
page insilicoterminal.com: connect 28 ms, response 27 ms

Likely saving if fixed: About 1 s faster on a warm reload, from 3.5 s to roughly 2.5 s, if the order book and the orders panel get their data when the price does (IN-1, IN-2).

Stack

A trading terminal for other exchanges, measured with an Extended exchange account connected; it draws its book and trades on canvas. From the 3 October recorded warm load.

Delivery

insilicoterminal.com over HTTP/2; a service worker answers the HTML (in 5 ms) and 28 of the 31 scripts. Market and account data come from the connected exchange; the recording masks the data hosts, so it does not show whether the terminal reaches Extended directly or through its own servers.

What happened, in order

When	What
0.005 s	HTML arrives from the service worker.
0.11 s	Two Google Fonts stylesheets, each holding up the first paint for about 0.12 s.
0.45–0.65 s	A 305 KB (compressed) data response from insilicoterminal.com; older timed loads suggest it is /settings, which unpacks to 7.3 MB.
0.65–1.18 s	One 534 ms main-thread task, in a script from insilicoterminal.com.
1.0–1.76 s	Four data requests to the masked data hosts, 0.27 to 0.44 s each.
1.55 s	Price shows.
1.67 s	First market-data request.
1.85 s	Order form shows.
1.83–2.22 s	First frames received on a live feed at 1.83 s; first frame sent at 1.99 s and the next one received at 2.22 s.
2.65 s	A data request starts; its response arrives at 3.44 s.
2.75 s	Chart drawn.
3.14 s	Orders panel shows.
3.44 s	Order book drawn, as the 2.65 s request completes: trade-ready in the recorded load.

Bottlenecks

IN-1 The order book is drawn the moment a 0.79 s data request completes. grade C
IN-2 The orders panel is the last panel in every warm timed load. grade C
IN-3 The first ticker request goes out only at 1.7 s. grade C
IN-4 The main thread is busy for 0.83 s before the first panel, right after a 7.3 MB settings response. grade C
IN-5 The recent-trades canvas stays blank for 45 s in most loads. grade B
IN-6 Two Google Fonts stylesheets block the first paint. grade B
IN-7 Large images, a 0.9 MB font and 5.5 MB of route script load with the trading screen. grade B
IN-8 One worker script is requested 16 times, and the market status twice. grade C

Evidence, the fix and how to verify each one are on the exchange's full page: open it.

order book or trades drawn as a picture; checked as drawn and updating, values not read. chart checked as drawn and updating, prices not read. recent trades not measured: left out. measured with an Extended exchange account connected, so its market and account panels show Extended's data.

Kraken Pro¹ Full page: bottlenecks and fixes →

Trade-ready: 5.9 s warm, 6.1 s uncached. Market data ready: 5.9 s warm. Last panel: chart, book, orders. Trade-ready followed market-data readiness by a median 0.0 s.

Loads: 5 of 5 warm loads ready (3 more not counted: test-side or session problems); 5 of 5 uncached loads ready (3 more not counted).

Bottleneck seen in the timings: no panel shows real data until 3.7 s (the price comes first), so the delay is in starting the app, before any one panel.

Panels ready (median, warm): price 3.7 s → order form 3.7 s → order book 5.3 s → account 5.3 s → chart 5.9 s

Servers, measured from the Netherlands:
page pro.kraken.com: observed CDN edge Cloudflare Amsterdam, connect 13 ms, response 25 ms
market data futures.kraken.com: observed CDN edge Cloudflare Amsterdam, connect 14 ms, response 35 ms
market data api.kraken.com: observed CDN edge Cloudflare Amsterdam, connect 14 ms, response 10 ms

Stack

React; webpack bundles (main, frontend, vendor); TradingView-style chart library loaded as library.js; a feed web worker; OneTrust cookie banner, Sentry, Braze, an analytics script from seg.kraken.com and loader/collector scripts from ftlofs1.kraken.com.

Delivery

Through Cloudflare, almost all over HTTP/2 (281 of 297 requests); app files cached for 30 days (cf-cache-status HIT); the HTML is cached for 60 s at the edge.

What happened, in order

When	What
0.03 s	HTML arrives from Cloudflare's cache.
0.25–0.83 s	Three bundles download: main (1.1 MB compressed, 3.9 MB unpacked), frontend (1.0 MB, 3.9 MB), vendor (0.9 MB, 3.0 MB): 11.0 MB of JavaScript to parse and run.
0.56 s	About a dozen account and config calls to iapi.kraken.com.
0.67 s	First paint (an empty shell).
0.98 s	The feed worker script (0.75 MB unpacked) loads.
2.5–3.1 s	The OneTrust banner SDK (0.45 MB unpacked) and loader/collector scripts from ftlofs1.kraken.com (0.8 MB unpacked) load.
3.66 s	The live feeds open (ws-frontend.kraken.com, two to futures.kraken.com); first futures messages at 3.85–3.96 s.
4.66 s	Price shows.
5.08–6.01 s	A 1.1 MB (unpacked) JSON response from www.kraken.com; layout-components.js requested at 5.37 s.
7.03 s	Order book shows.
7.93 s	The chart library (library.js, 0.68 MB compressed, 2.7 MB unpacked) is requested; lt-pane-views.js at 8.83 s.
9.59 s	Chart drawn: trade-ready in this load. 27 long tasks took 4.4 s of main thread; vendor.js alone 2.6 s.

Bottlenecks

KR-1 11.0 MB of JavaScript is loaded before the trading screen works. grade B
KR-2 The live feeds open 2.8 s after the bundles have arrived. grade C
KR-3 The chart library is discovered only after the order book is up. grade C
KR-4 The order book shows 2.4 s after the price although the futures feed is already delivering. grade C
KR-5 Third-party scripts load before the market data. grade C
KR-6 About 5.3 MB of catalog and translation JSON is loaded at start-up, some of it uncacheable. grade B
KR-7 Account and settings requests are repeated three to five times. grade C
KR-8 Four more sockets are opened for other products and account data while the futures screen is still loading. grade C

Evidence, the fix and how to verify each one are on the exchange's full page: open it.

recent trades not measured: inactive tab.

Lighter Full page: bottlenecks and fixes →

Trade-ready: 4.8 s warm, 6.6 s uncached. Market data ready: 3.2 s warm. Last panel: trades, chart. Trade-ready followed market-data readiness by a median 1.6 s.

Loads: 5 of 5 warm loads ready (1 more not counted: test-side or session problems); 5 of 5 uncached loads ready (1 more not counted).

Bottleneck seen in the timings: the page is not steady until 1.6 s after the last panel shows real data (on the six exchanges we checked, an animation still running in the chart; it can also be a placeholder, late fonts or images, or a moving layout).

Panels ready (median, warm): order form 2.0 s → account 2.7 s → price 2.8 s → order book 3.0 s → trades 3.1 s → chart 3.2 s

Servers, measured from the Netherlands:
page app.lighter.xyz: observed CDN edge CloudFront Amsterdam, connect 13 ms, response 13 ms
market data mainnet.zklighter.elliot.ai: observed CDN edge CloudFront Amsterdam, connect 14 ms, response 11 ms

Stack

React, built with Vite; TradingView chart library (assets.lighter.xyz/library.js); Dynamic wallet SDK; AWS WAF bot-check scripts; QuickNode RPC.

Delivery

HTML and app files from S3 through CloudFront over HTTP/3, app files immutable for a year; market data from mainnet.zklighter.elliot.ai, served over HTTP/1.1 and without compression.

What happened, in order

When	What
0.02 s	HTML arrives (CloudFront, HTTP/3).
0.16–0.70 s	Startup scripts: vendor-ui-web3 (2.5 MB compressed, 8.7 MB unpacked), index (1.5 MB unpacked), dist (1.4 MB unpacked). vendor-react later starts 1.3 s of main-thread work.
0.91–1.63 s	Dynamic wallet assets: 769 KB, then a 2.1 MB icon file at 1.22 s; the same 2.1 MB file is fetched again at 3.16 s.
1.58–2.42 s	Market-data REST calls to mainnet.zklighter.elliot.ai, sent uncompressed (365 KB and 80 KB); several others take 1.3 s each (2.09–3.38 s).
1.60 s	First paint.
1.93–2.95 s	AWS WAF bot-check scripts load: jsapi.js (194 KB unpacked) and challenge.js (681 KB unpacked).
2.07 s	The live feed opens; handshake done at 3.07 s, 1.0 s later; first message at 3.40 s.
4.40 s	Price shows, 1.0 s after the first feed message; order book at 4.61 s.
5.44 s	Chart drawn: trade-ready in this load. 15 long tasks took 2.5 s of main thread.

Bottlenecks

LI-1 An 8.7 MB vendor bundle at start-up. grade B
LI-2 Trade-ready comes 1.5 s after the last panel has its data: the chart is still animating. grade B
LI-3 Market data is sent uncompressed over HTTP/1.1, and the feed takes 1 s to connect. grade B
LI-4 Bot-check and wallet assets load before the market is on screen. grade C
LI-5 One font file is 352 KB. grade B
LI-6 Two account lookups fail with HTTP 400 on every load. grade B

Evidence, the fix and how to verify each one are on the exchange's full page: open it.

Pacifica¹ Full page: bottlenecks and fixes →

Trade-ready: 3.6 s warm, 4.7 s uncached. Market data ready: 3.2 s warm. Last panel: chart, entry. Trade-ready followed market-data readiness by a median 0.4 s.

Loads: 5 of 5 warm loads ready (1 more not counted: test-side or session problems); 5 of 5 uncached loads ready (1 more not counted).

Panels ready (median, warm): account 1.4 s → price 1.4 s → order book 1.6 s → order form 3.1 s → chart 3.2 s

Servers, measured from the Netherlands:
page app.pacifica.fi: connect 13 ms, response 51 ms
market data api.pacifica.fi: observed CDN edge CloudFront Amsterdam, connect 12 ms, response 10 ms

Stack

Next.js on Vercel; TradingView chart library (library.js); Privy wallet and WalletConnect.

Delivery

HTML from Vercel marked no-store, so never cached; app chunks immutable for a year; market data from api.pacifica.fi and the feed ws.pacifica.fi. The lightest page in this test: 1.3 MB transferred.

What happened, in order

When	What
0.03 s	HTML arrives.
0.22–0.68 s	Script chunks (the largest about 220 KB unpacked).
0.68 s	First paint.
2.37 s	Header and price show, before the feed is opened.
2.75 s	The live feed opens, after the price is already on screen; handshake at 3.52 s; first message at 3.75 s.
3.00 s	Order book shows.
4.80–5.63 s	An api.pacifica.fi request takes 0.83 s.
4.95 s	Chart drawn, 2.0 s after the book: trade-ready in this load.

Bottlenecks

PA-1 The chart is drawn 2.0 s after the order book; three candle requests to Binance fail first. grade C
PA-2 The live feed opens only at 2.75 s and needs 0.8 s to connect. grade C
PA-3 Trade-ready comes 0.4 s after the panels are in: the chart is still animating. grade B
PA-4 On an uncached load the order form is the last panel, at 4.4 s. grade C
PA-5 A layout shift and 98 forced layout recalculations during the load. grade B

Evidence, the fix and how to verify each one are on the exchange's full page: open it.

recent trades not measured: inactive tab.

Rise^1,2 Full page: bottlenecks and fixes →

Trade-ready: 4.6 s warm, 4.4 s uncached. Market data ready: 3.3 s warm. Last panel: chart. Trade-ready followed market-data readiness by a median 1.3 s.

Loads: 5 of 5 warm loads ready (2 more not counted: test-side or session problems); 5 of 5 uncached loads ready (2 more not counted).

Bottleneck seen in the timings: the page is not steady until 1.3 s after the last panel shows real data (on the six exchanges we checked, an animation still running in the chart; it can also be a placeholder, late fonts or images, or a moving layout).

Panels ready (median, warm): price 2.5 s → order form 2.5 s → account 2.5 s → order book 2.9 s → chart 3.3 s

Servers, measured from the Netherlands:
page www.rise.trade: connect 12 ms, response 48 ms

Stack

Next.js; TradingView chart library (library.js); Privy wallet and WalletConnect; Sentry; an IP lookup (api.ipify.org); RISE chain RPC.

Delivery

HTML from Vercel marked private, no-store, so never cached; app chunks immutable for a year; market data from api.rise.trade.

What happened, in order

When	What
0.02 s	HTML arrives on 1 October; on 3 October the recorded load waited 0.99 s for it; it is marked no-store, so it is never served from a cache.
0.45–1.38 s	Script chunks: 1678 (646 KB compressed, 2.3 MB unpacked, the slowest at 0.92 s), 2743 (1.3 MB unpacked), 2399 (1.0 MB unpacked, later 0.79 s of main thread). A 157 KB image sent uncompressed with max-age=0.
0.83 s	Page header shows the market; first paint at 0.98 s.
1.90 s	The live feed opens; handshake done at 3.10 s, 1.2 s later; first message at 3.49 s.
1.93 s	WalletConnect registry (1.2 MB unpacked); Privy makes 35 requests.
2.37 s	Price shows, before the feed is connected, so it does not come from the feed.
3.02–3.89 s	RISE chain RPC calls.
4.35 s	Order book shows, 0.9 s after the first feed message.
5.39 s	Chart drawn: trade-ready in this load.

Bottlenecks

RI-1 The feed takes 1.2 s to connect, and the order book shows 0.9 s after its first message. grade C
RI-2 Trade-ready comes 1.3 s after the last panel has its data: the chart is still animating. grade B
RI-3 The HTML is never cached and can take a second. grade B
RI-4 Wallet, IP lookup and chain calls run before the book. grade C
RI-5 Start-up requests are repeated, and other pages are fetched through malformed addresses. grade B
RI-6 Error-reporting requests are rejected with HTTP 429, and the analytics script is missing (HTTP 404). grade C

Evidence, the fix and how to verify each one are on the exchange's full page: open it.

measured logged out (fewer panels to load). recent trades not measured: inactive tab.

Thalex Full page: bottlenecks and fixes →

Trade-ready: 2.4 s warm, 2.6 s uncached. Market data ready: 1.8 s warm. Last panel: chart, book. Trade-ready followed market-data readiness by a median 0.7 s.

Loads: 5 of 5 warm loads ready (3 more not counted: test-side or session problems); 5 of 5 uncached loads ready (3 more not counted).

Panels ready (median, warm): price 1.4 s → order form 1.4 s → trades 1.7 s → order book 1.7 s → chart 1.8 s

Servers, measured from the Netherlands:
page thalex.com: observed CDN edge Cloudflare Amsterdam, connect 13 ms, response 25 ms

Stack

Vue; TradingView chart library (library.js) from thalex.com; no third-party scripts at all.

Delivery

thalex.com through Cloudflare over HTTP/2; the HTML is marked no-cache and re-checked on each load (30 ms to the first byte); app files cached for ten years. In the 1 October capture only 14 KB was transferred, so although that capture was meant to be uncached, most files did not come over the network.

What happened, in order

When	What
0.03 s	HTML arrives.
0.09–0.47 s	index-CKxRR9q7.js (1.5 MB unpacked), from cache.
0.55 s	The market socket opens; handshake at 0.72 s; first message at 0.80 s.
0.71 s	First paint.
2.03 s	Page header shows the market.
2.77 s	Price and order book show, 2.0 s after the first feed message.
2.86 s	Chart drawn: trade-ready in this load.

Bottlenecks

TH-1 Market data is on the socket 2 s before it is on screen. grade C
TH-2 Trade-ready comes 0.7 s after the last panel has its data: the chart is still animating. grade B
TH-3 125 script requests go out before the first panel. grade C

Evidence, the fix and how to verify each one are on the exchange's full page: open it.

TxFlow¹ Full page: bottlenecks and fixes →

Trade-ready: 4.3 s warm, 4.7 s uncached. Market data ready: 3.4 s warm. Last panel: entry, positions, price, chart, book. Trade-ready followed market-data readiness by a median 0.9 s.

Loads: 5 of 5 warm loads ready (2 more not counted: test-side or session problems); 5 of 5 uncached loads ready (2 more not counted).

Bottleneck seen in the timings: no panel shows real data until 3.4 s (the price comes first), so the delay is in starting the app, before any one panel.

Panels ready (median, warm): price 3.4 s → chart 3.4 s → order book 3.4 s → order form 4.3 s → account 4.3 s

Servers, measured from the Netherlands:
page app.txflow.com: observed CDN edge Cloudflare Amsterdam, connect 13 ms, response 363 ms
market data api.txflow.com: observed CDN edge Cloudflare Amsterdam, connect 13 ms, response 254 ms

Stack

React with React Router, built with Vite; TradingView chart library plus ECharts; web3 and ethers bundles; Privy and WalletConnect; Sentry.

Delivery

app.txflow.com through Cloudflare over HTTP/3; HTML no-cache; app files cached a year; market data and feed from api.txflow.com.

What happened, in order

When	What
0.28 s	HTML arrives.
0.47–0.79 s	web3 (0.8 MB compressed, 2.8 MB unpacked), index (1.2 MB unpacked) and ethers. The react-router chunk later starts 2.4 s of main-thread work.
0.99 s	The market socket opens; handshake at 1.90 s, 0.9 s later; first message at 2.43 s.
1.32–1.63 s	Trade, PositionsModule and ECharts chunks.
1.58–3.50 s	An api.txflow.com request takes 1.9 s.
1.61 s	First paint.
2.41 s	Page header shows the market; order book at 2.65 s.
2.53–3.20 s	The chart library (library.js, 0.9 MB compressed, 6.2 MB unpacked); Privy loads 35 requests from 2.71 s.
3.46–4.36 s	trading.js (0.5 MB unpacked).
4.36 s	Price shows, 1.7 s after the book.
6.80 s	Chart drawn, 2.4 s after the price: trade-ready in this load. 22 long tasks took 3.1 s of main thread.

Bottlenecks

TX-1 The react-router chunk starts 2.4 s of main-thread work. grade B
TX-2 The chart is drawn 2.4 s after the price, with a 6.2 MB chart library. grade C
TX-3 In one capture the price showed 1.7 s after the book. grade C
TX-4 A pop-up blocked the chart in both recorded loads on 3 October. grade B
TX-5 On a warm reload the order form and positions are the last panels, at 4.3 s, about 0.9 s after the market panels. grade B
TX-6 api.txflow.com/info is called 47 times per load, with a round of permission requests first. grade B
TX-7 The second feed socket connects, then waits 1.4 s before sending anything. grade C

Evidence, the fix and how to verify each one are on the exchange's full page: open it.

recent trades not measured: inactive tab.

Variational^*9 Full page: bottlenecks and fixes →

Trade-ready: 2.6 s warm, 3.0 s uncached. Market data ready: 2.0 s warm. Last panel: quote. Trade-ready followed market-data readiness by a median 0.6 s.

Loads: 5 of 5 warm loads ready; 5 of 5 uncached loads ready.

Panels ready (median, warm): price 0.7 s → chart 2.0 s → quote 2.6 s

Servers, measured from the Netherlands:
page omni.variational.io: observed CDN edge Cloudflare Amsterdam, connect 13 ms, response 19 ms

Stack

SvelteKit app from omni.variational.io; TradingView chart library (library.js) from assets.variational.io; Web3Modal and WalletConnect; Google Tag Manager; Cloudflare Insights; own monitoring at mon.variational.io.

Delivery

omni.variational.io through Cloudflare over HTTP/3; the HTML comes from the edge cache (first byte after 18 ms); app and chart files cached a year, immutable; live feed from omni-ws-server.prod.ap-northeast-1.variational.io, a host named for the AWS Tokyo region.

What happened, in order

When	What
0.10 s	HTML arrives from Cloudflare's edge cache.
0.11–0.66 s	App chunks: 76 scripts from omni.variational.io (73 of them before 0.5 s), the largest 438 KB (1.9 MB unpacked).
0.50 s	Page shows the market; first paint at 0.52 s.
0.83–1.29 s	Nine requests to the Web3Modal API.
1.00–2.56 s	A 496 KB (1.7 MB unpacked) response from omni.variational.io, not served from the CDN cache.
1.03 s	The first two feed sockets are created; their handshakes finish at 1.97 s and 2.27 s.
1.59–1.80 s	TradingView chart library (667 KB, 2.8 MB unpacked), the first of 32 chart files from assets.variational.io.
2.63 s	Chart drawn.
2.91 s	The fourth feed socket finishes its handshake; first message at 3.17 s.
3.21 s	Last panel has data: end of this capture. Six long main-thread tasks total 1.0 s.

Bottlenecks

VR-1 Four feed sockets, each needing 0.9 to 1.3 s to connect. grade B
VR-2 A 1.7 MB animation player (WebAssembly) takes 1.6 s and bypasses the CDN cache. grade B
VR-3 The chart library is requested 1.1 s after the page is up. grade C
VR-4 The wallet stack loads before the market data. grade C
VR-5 Eighteen monitoring requests go out before the last panel has data. grade C
VR-6 The same API addresses are called up to six times at start-up. grade C
VR-7 A 350 KB font file, next to a second copy of Inter from Google. grade B
VR-8 Three blocking start-up tasks (0.41 s together) run before the feed sockets are opened. grade C

Evidence, the fix and how to verify each one are on the exchange's full page: open it.

its screen has no order book, so it has fewer panels to load.

Architect^*6,10 Full page: bottlenecks and fixes →

Trade-ready: 2.8 s warm, 3.0 s uncached. Market data ready: 2.1 s warm. Last panel: chart. Trade-ready followed market-data readiness by a median 0.7 s.

Loads: 5 of 5 warm loads ready; 5 of 5 uncached loads ready.

Panels ready (median, warm): price 1.3 s → order form 1.3 s → account 1.3 s → order book 1.4 s → trades 1.5 s → chart 2.1 s

Servers, measured from the Netherlands:
page app.architect.exchange: observed CDN edge Cloudflare Amsterdam, connect 14 ms, response 40 ms
market data api.architect.exchange: connect not reached, response not reached

Stack

Single-page app from app.architect.exchange, loaded as 75 scripts and 52 stylesheets. The recording does not identify the framework.

Delivery

App files from app.architect.exchange over HTTP/3; on this warm reload 110 of its 124 requests were answered "not modified" (55 KB transferred in all), so the files are re-checked one by one, not re-downloaded. 21 requests use HTTP/1.1 (364 KB); their host name was masked in the recording.

What happened, in order

When	What
0.03 s	HTML arrives.
0.70 s	A 110 KB data response over HTTP/1.1, the largest before the first panel.
1.13 s	First frame sent on a live feed; first one received at 1.19 s.
1.21 s	Price, order form and positions show.
1.51 s	Order book and recent trades show.
1.95 s	Candle history requested: two requests, 113 KB together; two more at 2.09 s.
2.22 s	Chart drawn.
2.96 s	Trade-ready in this load, 0.74 s after the chart.

Bottlenecks

AR-1 Candle history is requested 0.7 s after the first panel shows. grade C
AR-2 Trade-ready comes 0.7 s after the chart is drawn: the chart is still animating. grade B
AR-3 Market data travels over HTTP/1.1. grade B
AR-4 34 scripts are requested before the first panel. grade C
AR-5 On a warm reload 110 app files are re-checked with the server one by one. grade B

Evidence, the fix and how to verify each one are on the exchange's full page: open it.

loaded behind a pop-up that appears on every load. measured on a stock perpetual (SPCX), not on BTC.

Deribit BTC options⁶ Full page: bottlenecks and fixes →

Trade-ready: 2.9 s warm, 3.0 s uncached. Market data ready: 2.6 s warm. Last panel: price, chain. Trade-ready followed market-data readiness by a median 0.3 s.

Loads: 5 of 5 warm loads ready (3 more not counted: test-side or session problems); 5 of 5 uncached loads ready (3 more not counted).

Panels ready (median, warm): price 2.6 s → options chain 2.6 s

Servers, measured from the Netherlands:
page www.deribit.com: observed CDN edge Cloudflare Amsterdam, connect 13 ms, response 23 ms
market data deribit.com: observed CDN edge Cloudflare Amsterdam, connect 13 ms, response 24 ms

Diagnosis from one recorded load

Recorded trade-ready at 3.1 s; recording slows a page, so read the order and gaps, not the total. 92 requests before trade-ready.

When	What
0.0 s	Document response
0.5 s	First frame sent on a live feed
0.6 s	First frame received on a live feed
3.0 s	price ready
3.0 s	options chain ready
3.1 s	Trade-ready

Deribit BTC options 1 Live data arrives 2.5 s before the first price or book shows grade C
Deribit BTC options 2 At least 1159 ms of main-thread blocking before the first panel grade B

Evidence, the fix and how to verify each one are on the exchange's full page: open it.

loaded behind a pop-up that appears on every load.

Derive BTC options Full page: bottlenecks and fixes →

Trade-ready: 4.8 s warm, 4.6 s uncached. Market data ready: 2.9 s warm. Last panel: balances, price, chain, entry. Trade-ready followed market-data readiness by a median 1.2 s.

Loads: 5 of 5 warm loads ready; 5 of 5 uncached loads ready.

Bottleneck seen in the timings: the page is not steady until 1.4 s after the last panel shows real data (on the six exchanges we checked, an animation still running in the chart; it can also be a placeholder, late fonts or images, or a moving layout).

Panels ready (median, warm): price 2.9 s → options chain 2.9 s → order form 2.9 s → account 3.5 s

Servers, measured from the Netherlands:
page app.derive.xyz: connect 13 ms, response 28 ms
market data api.lyra.finance: observed CDN edge Cloudflare Amsterdam, connect 13 ms, response 257 ms
market data api.derive.xyz: observed CDN edge Cloudflare Amsterdam, connect 13 ms, response 258 ms

Diagnosis from one recorded load

Recorded trade-ready at 2.7 s; recording slows a page, so read the order and gaps, not the total. 136 requests before trade-ready.

When	What
0.1 s	Document response
1.4 s	First market-data request
2.3 s	First frame sent on a live feed
2.7 s	price ready
2.7 s	options chain ready
2.7 s	order form ready
2.7 s	account panel ready
2.7 s	Trade-ready

Derive BTC options 1 At least 856 ms of main-thread blocking before the first panel grade B

Evidence, the fix and how to verify each one are on the exchange's full page: open it.

Thalex BTC options² Full page: bottlenecks and fixes →

Not measured. No load passed the checklist's setup checks, so no time is reported; these failures say nothing about speed: the options chain ended more than 24 px from its checklist position (2 of 10 loads); the test browser had an extra tab open (3 of 10 loads); the test tab was not in front (4 of 10 loads); the page was not on the checklist's market (2 of 10 loads); the sign-in control did not match the checklist's sign-in state (4 of 10 loads).

Loads: 0 of 0 warm loads ready (5 more not counted: test-side or session problems); 0 of 0 uncached loads ready (5 more not counted).

Servers, measured from the Netherlands:
page thalex.com: observed CDN edge Cloudflare Amsterdam, connect 12 ms, response 25 ms

measured logged out (fewer panels to load).

Issue register

ID	Exchange	What a trader sees
`CB-1`	Coinbase (TradingView chart)	After switching from BTC to ETH, the chart shows ETH candles but keeps the name BTC.

Defect cards

`CB-1` Coinbase: the chart keeps the old market's name after a switch

What you see. You switch from BTC Perp to ETH Perp. The page title, the address and the candle prices all change to ETH, but the chart's legend still says BTC_USDC-PERPETUAL. It stays wrong while you remain on the page.

Why it happens. The chart layout saved for the ETH market contains BTC as its symbol. Every visit to ETH loads that saved layout and does not set the chart back to the market of the page, and every later autosave writes the wrong symbol back.

What it breaks. The chart lies about which market it shows. Anything inside the chart that relies on its symbol, such as drawings or alerts, can attach to the wrong market without the trader noticing.

How to fix it. After loading a saved layout, set the chart to the page's market and check that it took effect. Do not save a layout while the chart's symbol and the page's market disagree.

Still unknown. How the wrong layout was first saved; the likeliest cause is a save racing a market switch. Whether other market pairs are affected.

Technical detail

Reproduction in the DevTools console on the ETH Perp page (top context): [location.pathname, document.querySelector('iframe[name^="tradingview_"]').contentWindow.tradingViewApi.activeChart().symbol()] returns ['/advanced-trade/perpetuals/ETH_USDC-PERPETUAL', 'BTC_USDC-PERPETUAL']. Measured on 2 October 2026: the legend title read BTC_USDC-PERPETUAL at 0, 2, 5 and 10 s after the switch while its O/H/L/C values were at ETH's price level. Evidence: bench/out/session4-coinbase-chart-api/2026-10-02T03-00-32-132Z/result.json and the Coinbase chart-symbol map in .scratch/coinbase-chart-symbol/.

Footnotes

recent trades not measured: inactive tab
measured logged out (fewer panels to load)
chart checked as drawn and updating, prices not read
recent trades not measured: outside viewport
order book or trades drawn as a picture; checked as drawn and updating, values not read
loaded behind a pop-up that appears on every load
recent trades not measured: left out
measured with an Extended exchange account connected, so its market and account panels show Extended's data
its screen has no order book, so it has fewer panels to load
measured on a stock perpetual (SPCX), not on BTC

Back to the ranking

Glossary

Term	Meaning in this report
Trade-ready	The moment every panel on the exchange's checklist shows real data, nothing is still loading and the layout has stopped moving. It says nothing about whether the account is allowed to trade.
Market data ready	The latest of: the right market named, a live price, a filled order book and a drawn chart. Trade-ready can come later, when the order form or account panel is last.
Warm reload	A normal reload of a page that was loaded seconds before, so the browser can reuse its stored files.
Uncached reload	A reload with the browser's stored files switched off. Login, cookies and open connections stay, so it is not a first-ever visit; first-ever visits were not measured.
Checklist	The list of panels that must be loaded for one exchange, with the evidence each panel must show. It was fixed for each exchange before the campaign.
Rank and possible rank	Rank is the order by median. Possible rank is the range the measurements leave open: the best counts only the exchanges that clearly beat this one, the worst counts only those it clearly beats. Two exchanges whose ranges overlap cannot be told apart by these measurements.
Clearly faster	The estimated gap between two exchanges is at least 0.1 s, and we are 95% confident that there is a gap at all. It is not 95% confidence that the gap is 0.1 s or more.
Median	The middle of the five loads. One unusually slow or fast load does not move it.
Loaded behind a pop-up	The panels were ready, but a recurring pop-up of the exchange covered part of them.

Method and environment

Statistics: one venue is faster than another only when the Hodges-Lehmann shift of all pairwise load differences is at least 100 ms and its exact 95% interval excludes zero, which is 95% confidence that there is a gap, not that the gap is 100 ms or more. Each venue's possible rank counts only such clear results; the comparisons are pairwise and are not adjusted for their number. Workspace checklists were piloted per page and frozen before the campaign (manifest 85d0aa991ce3…); harness commit edba713937. The in-page probe samples every 100 ms and costs about 8 to 18 ms of each sample on these pages. Servers: connect time and HEAD response time to the root of each page and data host, median of up to 10 successful attempts from the test machine; "not reached" means no attempt succeeded. They are context, not a distance correction: the timed loads do not record how long each request waited, and a slow response can come from a distant server or a slow nearby one. The edge shown is the CDN location a probe response reported; it does not locate the venue’s own servers. Hosts with a ws-labelled name (live feeds) are left out; the other figures are probes of host roots, not of the live feeds or the actual data requests. Most venues have five ready loads per reload type; the table shows the exceptions. 17 venues whose loads were lost to test-side setup problems (expired logins, a second browser tab) completed their five loads in a 25-minute top-up run right after the main run, with the same frozen method and checklists. Aster and BloFin were measured again in five fresh rounds after a harness fix: see-through page layers had been counted as covering their panels. Insilico, Extended and ApeX were rescored from their stored loads after checklist changes: Insilico without its recent-trades panel, Extended with a dash in its positions table read as none instead of loading, and ApeX with its order form on Market (one input field) as it was during the campaign. Thalex options is not measured: no load passed the checklist’s setup checks (an extra or hidden test tab, the sign-in control, the market, or the options chain ending more than 24 px from its recorded position). Earlier results used a different method and are not comparable; they are kept in the earlier reports.

Benchmark by @RNR_0

How fast do crypto trading screens become usable?

Perpetual trading screens (headline)

BTC options

Where the time goes: Perpetual trading screens (headline)

Bottlenecks: what slows each page, and what to do

Exchanges

ApeX Full page: bottlenecks and fixes →

Stack

Delivery

What happened, in order

Bottlenecks

Aster1 Full page: bottlenecks and fixes →

Stack

Delivery

What happened, in order

Bottlenecks

Backpack1,2 Full page: bottlenecks and fixes →

Stack

Delivery

What happened, in order

Bottlenecks

Binance2,3 Full page: bottlenecks and fixes →

Stack

Delivery

What happened, in order

Bottlenecks

Bitfinex4 Full page: bottlenecks and fixes →

Stack

Delivery

What happened, in order

Bottlenecks

BloFin1 Full page: bottlenecks and fixes →

Stack

Delivery

What happened, in order

Bottlenecks

BTSE4 Full page: bottlenecks and fixes →

Stack

Delivery

What happened, in order

Bottlenecks

Bybit1,2,5 Full page: bottlenecks and fixes →

Stack

Delivery

What happened, in order

Bottlenecks

Coinbase TradingView1,5 Full page: bottlenecks and fixes →

Stack

Delivery

What happened, in order

Bottlenecks

Coinbase native1,3,5 Full page: bottlenecks and fixes →

Stack

Delivery

What happened, in order

Bottlenecks

Decibel1 Full page: bottlenecks and fixes →

Stack

Delivery

What happened, in order

Bottlenecks

Deribit6 Full page: bottlenecks and fixes →

Stack

Delivery

What happened, in order

Bottlenecks

Derive Full page: bottlenecks and fixes →

Stack

Delivery

What happened, in order

Bottlenecks

Extended1 Full page: bottlenecks and fixes →

Stack

Delivery

What happened, in order

Bottlenecks

Gains1 Full page: bottlenecks and fixes →

Stack

Delivery

What happened, in order

Aster¹ Full page: bottlenecks and fixes →

Backpack^1,2 Full page: bottlenecks and fixes →

Binance^2,3 Full page: bottlenecks and fixes →

Bitfinex⁴ Full page: bottlenecks and fixes →

BloFin¹ Full page: bottlenecks and fixes →

BTSE⁴ Full page: bottlenecks and fixes →

Bybit^1,2,5 Full page: bottlenecks and fixes →

Coinbase TradingView^1,5 Full page: bottlenecks and fixes →

Coinbase native^1,3,5 Full page: bottlenecks and fixes →

Decibel¹ Full page: bottlenecks and fixes →

Deribit⁶ Full page: bottlenecks and fixes →

Extended¹ Full page: bottlenecks and fixes →

Gains¹ Full page: bottlenecks and fixes →

GRVT¹ Full page: bottlenecks and fixes →

HyperFlow⁴ Full page: bottlenecks and fixes →

Hyperliquid¹ Full page: bottlenecks and fixes →

Insilico Terminal^3,5,7,8 Full page: bottlenecks and fixes →

Kraken Pro¹ Full page: bottlenecks and fixes →

Pacifica¹ Full page: bottlenecks and fixes →

Rise^1,2 Full page: bottlenecks and fixes →

TxFlow¹ Full page: bottlenecks and fixes →

Variational^*9 Full page: bottlenecks and fixes →

Architect^*6,10 Full page: bottlenecks and fixes →

Deribit BTC options⁶ Full page: bottlenecks and fixes →

Thalex BTC options² Full page: bottlenecks and fixes →

`CB-1` Coinbase: the chart keeps the old market's name after a switch