- Evidence
- 1 October capture: first socket messages at 0.99 s (www.deribit.com) and 1.07 s (streams.deribit.com); price and book at 3.55 s. Meanwhile about 9 MB of unpacked script loads (GridLayout-B3XAMKEz.js 2.5 MB at 1.31 s, index-B0aPppd7.js 2.4 MB, GlobalEventEmitter 1.4 MB, CurrencySearch 1.2 MB) and 1.53 s of main-thread work starts in index.js. The 3 October recorded warm reload shows the same pattern with a 1.9 s gap: first message at 0.63 s, price and book at 2.56 s. With the files cached, that load still has 1.16 s of long tasks, the two longest (263 ms at 1.58 s and 183 ms at 2.00 s) before the price shows. The captures do not show that the first message already carries the price.
- Gap observed
- 2.6 s between the first socket message and the price, in the 1 October capture
- Holds back
- Price (median 2.8 s in the timed loads), book (median 2.8 s in the timed loads).
- Fix
- Render price and book from the first socket messages before the grid layout and other modules load.
- Where
- Trading page start-up order (GridLayout, modules).
- Verify
- DevTools → Performance: price paint within 200 ms of the first ticker message.
Deribit: 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 4.2 s (median of 5 loads), 11 of 27 perpetual trading screens, possible rank 9 to 12; after an uncached reload 4.1 s.
The largest bottleneck: Price and book show 2.6 s after the feed delivers. First change to try: Render price and book from the first socket messages before the grid layout and other modules load.
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 4.2 s, range 3.8 s–4.4 s; loads: 4.4 s, 4.2 s, 4.0 s, 3.8 s, 4.2 s |
| Uncached reload | median 4.1 s, range 4.0 s–4.2 s; loads: 4.2 s, 4.1 s, 4.2 s, 4.0 s, 4.1 s |
| Standing | 11 of 27 by median; possible rank 9 to 12. 1.7 s behind the fastest, Thalex (2.4 s): 1.7 times as long. 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 s3 s4 s
Price2.8 s
Order book2.8 s +0.0 s
Recent trades2.8 s +0.0 s
Order form2.8 s +0.0 s
Chart3.5 s +0.6 s
Trade-ready4.2 s +0.7 s settling
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).
| Host | Role | CDN edge seen | Connect | Response |
|---|---|---|---|---|
| www.deribit.com | page | Cloudflare Amsterdam | 13 ms | 22 ms |
| deribit.com | market data | Cloudflare Amsterdam | 13 ms | 22 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 orderdiagnostic capture 1 October, uncached
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.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. |
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.6 s | First frame sent on a live feed |
| 0.6 s | First frame received on a live feed |
| 2.6 s | Price ready |
| 2.6 s | Order book ready |
| 2.6 s | Recent trades ready |
| 2.6 s | Order form ready |
| 3.3 s | Chart ready |
| 4.0 s | Trade-ready |
172 requests before trade-ready; 10 long main-thread tasks (over 50 ms) before trade-ready, longest 263 ms; 57 script requests before the first panel; 0 requests over HTTP/1.1.
Request waterfalldiagnostic capture 1 October, uncached
64 of the 159 requests (the page itself, the longest and the largest) started before market data was ready in the 1 October uncached capture, 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.
PageScriptData requestFont, media, other fileStylesheetwaiting for the serverdownloading
Bottlenecks and fixes, largest firstdiagnostic capture 1 October, uncached
- Evidence
- All 20 timed loads request /api/v2/public/get_instruments twice with the same address (for example at 1.10 and 1.38 s), 5.1 MB unpacked each time, 10.2 MB together; it compresses to 116 KB, so the download is small; handling 10 MB of JSON is the likely cost, though the captures do not time it. In the 1 October capture the response is marked "no-store, public, max-age=10": the no-store cancels the 10 seconds it declares. Coinbase's perpetuals pages request the same endpoint.
- Measured
- two 5.1 MB no-store instrument responses per load
- Holds back
- Not established: the captures do not show which panel waits for this.
- Fix
- Share one get_instruments request between its two callers, ask only for the currency and kind the page shows, and drop no-store so the declared max-age can work.
- Where
- The two start-up callers of /api/v2/public/get_instruments; its cache-control header.
- Verify
- DevTools → Network, filter "get_instruments": one request, under 100 KB unpacked or from cache on reload.
- Evidence
- max-age=14400 on the content-hashed scripts (index, GridLayout, GlobalEventEmitter, CurrencySearch, LayoutWithHeader) and on the chart library assets.deribit.com/library.1ac08da24621d68cbd6c.js (2.5 MB unpacked). Five fonts are already WOFF2; the two on the chart host, CoinbaseSans-Regular.ttf and CoinbaseSans-Medium.ttf, are uncompressed TTF of 114 KB each, requested at 4.0 and 4.3 s.
- Measured
- max-age=14400 on hashed scripts and the chart library; two uncompressed TTF fonts
- Holds back
- Not established: the captures do not show which panel waits for this.
- Fix
- Cache hashed assets for a year (immutable), and ship the two CoinbaseSans fonts on assets.deribit.com as WOFF2.
- Where
- Cloudflare cache rules; the chart's font files on assets.deribit.com.
- Verify
- DevTools → Network → Headers on index-*.js: max-age=31536000; CoinbaseSans files are woff2.
- Evidence
- All 5 warm and all 5 uncached campaign loads: between the chart having its data and trade-ready (warm 0.69 to 0.78 s, median 0.69 s) the only readiness condition failing is an animation running in the chart panel. Recorded load: 0.70 s, 7 of 8 samples. Nothing moves and no font or image is pending.
- Gap observed
- 0.69 s median between the chart and trade-ready in the five warm loads
- Holds back
- Trade-ready itself: the page counts as ready only when nothing in a panel is still animating or loading.
- Fix
- Record a reload with DevTools → Animations and find what still animates in the chart after the candles are drawn, for example a toolbar loading spinner or a fade-in; end it when the data is in.
- Where
- The chart panel and its loading states.
- Verify
- DevTools → Animations during a reload: nothing in the chart container animates after the candles appear.
- Likely saving
- Up to ~0.7 s
- Evidence
- All 20 timed loads make 83 script requests in the same four steps: about 31 at the start, 21 a second later, 5 more, and a last group of about 26 chart files 1.5 to 2.5 s after the second step (at 2.5 s in the recorded warm load, at 3.5 s in the 1 October capture). The chart library itself is requested at 2.58 s and takes until 3.34 s in the capture. In the campaign the chart is the last panel in all 5 warm loads (median 3.5 s against 2.8 s for the other panels).
- Gap observed
- 0.63 s between the median of the other panels and the chart median
- Holds back
- Chart (median 3.5 s in the timed loads).
- Fix
- Add preload links for the chart library and its chunks on the trading route so they load with the first wave.
- Where
- Trading route entry and HTML head; the chart loader.
- Verify
- DevTools → Network, filter JS: no new group of script requests after 1.5 s; library.js starts before 1 s.
- Likely saving
- Up to ~0.6 s on the chart (chart 3.5 s, other panels 2.8 s)
- Evidence
- 1 October capture: 12 media files (sounds or short clips; the capture masks their names) from www.deribit.com, 349 KB together, requested from 0.78 s and complete by 0.87 s, before either feed delivers its first message at 0.99 s.
- Measured
- 12 media files, 349 KB, in the first second
- Holds back
- Not established: the captures do not show which panel waits for this.
- Fix
- Load notification sounds and other media on first use, not at start-up.
- Where
- The code that preloads media on the trading page.
- Verify
- DevTools → Network, filter "Media": no requests before the order book shows.
- Likely saving
- Small
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.
Savings are estimates from the timeline, not measured after a change. They overlap, so they do not add up; the summary gives the combined estimate.
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.