- Evidence
- All 5 warm campaign loads have the chart last (median 3.5 s) with trade-ready at a median 4.6 s; the median wait inside the loads is 1.13 s, and the recorded load shows 1.13 s too. In the recorded load and in all 10 timed loads we could replay, the readiness condition still failing during this wait is an animation running inside the chart panel; nothing moves in that interval. A logged-out recording the same morning names it: the chart toolbar's loading spinner (an animation named tv-button-loader) still runs on 3 to 9 elements from 4.46 to 5.67 s, after the chart legend and candles are on screen at 4.05 s. In 3 of the 5 warm loads a placeholder in the account panel also lasts into the wait.
- Gap observed
- 1.13 s median between the last panel and trade-ready inside 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
- Stop the chart toolbar's loading animation (tv-button-loader) once the candles are in, and check with DevTools → Animations that nothing else in the chart keeps animating.
- Where
- The chart toolbar's loading animation (tv-button-loader) and the chart's loading states.
- Verify
- DevTools → Animations during a reload: nothing in the chart container animates after the candles appear.
BloFin: 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.6 s (median of 5 loads), 14 of 27 perpetual trading screens, possible rank 11 to 21; after an uncached reload 5.2 s.
The largest bottleneck: Trade-ready comes 1.1 s after the last panel has its data: the chart is still animating. First change to try: Stop the chart toolbar's loading animation (tv-button-loader) once the candles are in, and check with DevTools → Animations that nothing else in the chart keeps animating.
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.6 s, range 4.3 s–5.2 s; loads: 4.3 s, 4.6 s, 4.3 s, 5.2 s, 4.7 s |
| Uncached reload | median 5.2 s, range 5.0 s–5.3 s; loads: 5.0 s, 5.2 s, 5.2 s, 5.3 s, 5.0 s |
| Standing | 14 of 27 by median; possible rank 11 to 21. 2.2 s behind the fastest, Thalex (2.4 s): 1.9 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 | recent trades not measured: inactive tab |
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
Price1.2 s
Account panel2.6 s +1.4 s
Order book2.7 s +0.1 s
Order form2.7 s +0.0 s
Chart3.5 s +0.8 s
Trade-ready4.6 s +1.1 s settling
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.
| Host | Role | CDN edge seen | Connect | Response |
|---|---|---|---|---|
| blofin.com | page | Cloudflare Amsterdam | 13 ms | 272 ms |
| openapi.blofin.com | market data | Cloudflare Amsterdam | 14 ms | 10 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 orderrecorded warm reload 3 October
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. |
Request waterfallrecorded warm reload 3 October
62 of the 355 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 requestwaiting for the serverdownloading
Bottlenecks and fixes, largest firstrecorded warm reload 3 October
- Evidence
- Recorded load: three groups of chart requests at 2.01–2.29 s, 2.67–2.94 s and 3.12–3.38 s; the chart shows at 3.09 s, after the second group. The timed loads name them: first /uapi/v1/kline_drawings/sync-setting (chart settings, not candles), then two rounds that each pair /uapi/v1/market/candlesticks with /uapi/v1/candlesticks/query/order_kline. In one timed warm load the settings run 2.61–2.90 s and the candle rounds 3.61–3.90 s and 4.18–4.47 s, each about 0.3 s, with the chart at 4.14 s. In all 5 timed warm loads the chart shows after the first candle round, before the second starts. The first chart request starts 0.9 s after the price is on screen.
- Gap observed
- 0.91 s between the price and the first chart request
- Holds back
- Chart (median 3.5 s in the timed loads).
- Fix
- Send the first /uapi/v1/market/candlesticks request at start-up, in parallel with the settings request and the other market data; the chart shows as soon as that first round is in.
- Where
- Chart datafeed: when the first candlesticks request is sent, and its size.
- Verify
- DevTools → Network, filter "candlesticks": the first request starts before 1 s.
- Evidence
- A timed warm load: the header configuration and public/time are each requested twice, the ticker three times, and notification/unread/count twice, taking 0.66 and 1.01 s. A logged-out recording shows the shared site header script (blofin-nav-header-bundled, 527 KB) at 1.68 s and a 640 KB animated image for the header at 2.02 s, then chatbot-entry.js (2.60–3.36 s) followed by the chatbot script (146 KB) and stylesheet from 3.37 to 4.15 s, while the chart appears at 4.05 s.
- Measured
- four small endpoints requested two or three times; a chatbot script, a 527 KB header script and a 640 KB header image before the chart
- Holds back
- Not established: the captures do not show which panel waits for this.
- Fix
- Share one request per address for the header, time, ticker and notification calls; load the chatbot after trade-ready; replace the 640 KB header GIF with a lighter image.
- Where
- The callers of those four endpoints; the chatbot loader; the site header bundle and its image.
- Verify
- DevTools → Network, filter "notification/unread", "public/time": one request each; filter "chatbot": no request before the chart is drawn.
- Likely saving
- Not measured
- Evidence
- Recorded load: 151 script requests; 62 start between 0.5 and 1.0 s and a second group of 56 between 2.0 and 2.5 s, after the price is on screen at 1.10 s. All 10 timed loads show an early group of 41 and later groups that run until shortly before trade-ready (up to 4.5–5.0 s). Two tasks block the main thread for 199 ms (at 0.85 s) and 105 ms (at 2.95 s, just before the chart).
- Measured
- 151 script requests, 56 of them in a second group at 2.0–2.5 s
- Holds back
- Not established: the captures do not show which panel waits for this.
- Fix
- Preload or bundle the scripts of the later group with the first one.
- Where
- Bundler chunking for the futures route; the HTML head.
- Verify
- DevTools → Network, filter JS: no new group of script requests after 1.5 s.
- Likely saving
- Unknown
- Evidence
- Both logged-out follow-up recordings: three sockets to ws-public.blofin.com are opened; the second one connects (handshake at 4.18 s in one recording, 3.76 s in the other) but sends and receives nothing for the rest of the recording, while the other two exchange frames. Its purpose is unknown.
- Measured
- one of three public sockets connected and never used, in two recordings
- Holds back
- Not established: the captures do not show which panel waits for this.
- Fix
- Find what opens the second public socket and either use it or stop opening it; each socket costs a connection and a handshake of over a second here.
- Where
- The feed client's socket set-up (three connections to ws-public.blofin.com).
- Verify
- DevTools → Network → WS: every open socket shows frames within a second of connecting.
- Likely saving
- Small: one handshake less, about 1.2 s of connection time in parallel with the others
- Evidence
- Both logged-out follow-up recordings: a task of 223 ms (at 2.74 s) and 233 ms (at 3.06 s), of which 127 and 134 ms are sampled inside one function of the chart library's module runtime (sdk/charting_library10/bundles/runtime.0716c8089d42c5b9ea4c.js) and 25 ms in inserting elements into the page. After the chart is on screen, its resize callback (_invalidationRAFCallback in library.js) forces 31 layout recalculations, 30 ms in total.
- Measured
- a 223 to 233 ms task in the chart runtime in each of two recordings
- Holds back
- Not established: the captures do not show which panel waits for this.
- Fix
- Look at what the chart runtime evaluates synchronously at start-up and defer the optional modules; batch the chart's size reads in its resize callback.
- Where
- TradingView library set-up and its invalidation callback.
- Verify
- DevTools → Performance: no task over 100 ms from the chart runtime; no forced reflow from library.js after the candles are drawn.
- Likely saving
- Up to ~0.2 s
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.