- Evidence
- First message received on the live feed at 0.6 s; the first price or book appears at 3.0 s. Whether that first message carries this market's data is not verified.
- Holds back
- Not established: the captures do not show which panel waits for this.
- Fix
- Find what the app waits for after the first snapshot arrives (other requests, the framework mounting, a wallet or config step) and render price and book from the first snapshot.
- Verify
- DevTools → Network → filter "WS", open the socket, Messages tab and DevTools → Performance, record a reload, open the Main track: compare the first snapshot message with the first paint of the price.
Deribit BTC options: where its trading screen loses time, and what to fix
Measured from the Netherlands in a logged-in Chrome, October 2026.
In short. On a warm reload the screen is trade-ready after 2.9 s (median of 5 loads), 1 of 2 BTC options screens, rank 1 is the only one the measurements leave open; after an uncached reload 3.0 s.
The largest bottleneck: Live data arrives 2.5 s before the first price or book shows First change to try: Find what the app waits for after the first snapshot arrives (other requests, the framework mounting, a wallet or config step) and render price and book from the first snapshot.
Three measurements appear on this page, and their times differ. Rank and results come from the campaign's timed reloads. The diagnostic capture and the recorded reload are single loads made with recording switched on, which slows the page: read them for the order of events and the gaps, not for totals.
Resultscampaign: 5 warm and 5 uncached reloads
| Warm reload | median 2.9 s, range 2.8 s–2.9 s; loads: 2.9 s, 2.9 s, 2.8 s, 2.9 s, 2.9 s |
| Uncached reload | median 3.0 s, range 2.8 s–3.1 s; loads: 3.1 s, 3.0 s, 2.8 s, 2.9 s, 3.0 s |
| Standing | 1 of 2 by median; rank 1 is the only one the measurements leave open. The fastest in its group. The possible rank is the range the measurements leave open: it counts only the exchanges that clearly beat this one and those it clearly beats. Exchanges whose ranges overlap cannot be told apart. |
| Loads ready | 5 of 5 warm, 5 of 5 uncached |
| Notes | loaded behind a pop-up that appears on every load |
Where the time goescampaign medians, warm reload
Panels in the order they first showed real, usable data on a warm reload. The coloured part of each row is the time that panel added after the one before it. The last row is trade-ready: every panel is ready and the page has stopped moving.
0 s1 s2 s
Price2.6 s
Options chain2.6 s +0.0 s
Trade-ready2.9 s +0.3 s settling
| Host | Role | CDN edge seen | Connect | Response |
|---|---|---|---|---|
| www.deribit.com | page | Cloudflare Amsterdam | 13 ms | 23 ms |
| deribit.com | market data | Cloudflare Amsterdam | 13 ms | 24 ms |
Median of up to 10 attempts from the test machine. Response time includes the server's own time, so it is not a distance.
What happened, in order
Recorded warm reload, 3 October
One warm reload recorded with Chrome's performance trace. Recording slows the page, so read the order and the gaps, not the total.
| When | What |
|---|---|
| 0.0 s | HTML arrives |
| 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 |
92 requests before trade-ready; 10 long main-thread tasks (over 50 ms) before trade-ready, longest 231 ms; 53 script requests before the first panel; 0 requests over HTTP/1.1.
Request waterfallrecorded warm reload 3 October
61 of the 92 requests (the page itself, the longest and the largest) started before trade-ready in the warm reload recorded on 3 October, in start order. The outlined part of a bar is waiting for the server; the solid part is downloading. Rows are numbered so a request can be pointed to. The numbers on the right are the size received and the total time. Vertical lines mark when a panel had data in this capture.
PageData requestScriptStylesheetwaiting for the serverdownloading
Bottlenecks and fixes, largest firstrecorded warm reload 3 October
- Evidence
- 10 long tasks (over 50 ms) before trade-ready, longest 231 ms; 53 script files were requested before the first panel showed. Counts cover the 10 longest tasks only.
- Holds back
- Not established: the captures do not show which panel waits for this.
- Fix
- Split the startup bundle so the trading screen's first panels do not wait for code they do not use (wallet, settings, other routes); break up the longest tasks.
- Verify
- DevTools → Performance, record a reload, open the Main track: long tasks show a red corner; the Bottom-up tab names the scripts.
Grade B: the capture shows the problem directly. Grade C: the order of events in the capture points to it; the dependency is for the team to confirm. The order is our judgement of each finding's effect on trade-ready, largest first; it is not sorted by gap. A gap is the time between two observed events or the time one piece of work takes; gaps overlap and do not add up. Where a finding is about size or count and no time was measured, the row says what was measured instead. Holds back names the panel the finding delays. Nothing here is graded higher, because no fix was confirmed by changing a page and measuring again.
How this was measured
Timings: 5 warm and 5 uncached reloads in a seeded random order across all exchanges, each judged against a checklist frozen for this page before the campaign; trade-ready is the first moment every checklist panel shows real data, nothing is still loading, and the layout holds still for 0.5 s. The findings on this page come from separate recorded loads, which are never part of the timings. Full method.