- Evidence
- 1 October capture: sockets to omni-ws-server.prod.ap-northeast-1.variational.io are created at 1.03, 1.03, 1.34 and 1.71 s; their handshakes finish at 1.97, 2.27, 2.63 and 2.91 s. The last one delivers its first message at 3.17 s, 0.04 s before the last panel has data. In the campaign the quote panel is the last panel in all 5 warm loads (median 2.6 s, 0.6 s after the chart); in one of them the chart is still animating for 0.3 s after the quote. The host name suggests the AWS Tokyo region; the captures do not measure where the server is.
- Gap observed
- 0.9 to 1.3 s for each of four socket connections
- Holds back
- Probably the quote (median 2.6 s in the timed loads): the timing points to it, but the captures do not show that this panel waits for it.
- Fix
- Open the feed sockets from the first script, check whether the four can share one connection, and measure where the 0.9 to 1.3 s of each handshake goes before moving the server.
- Where
- Feed client start-up and the omni-ws-server deployment.
- Verify
- DevTools → Network → WS: sockets created before 0.6 s; handshake under 0.3 s.
Variational: 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.6 s (median of 5 loads), 2 of 27 perpetual trading screens, possible rank 1 to 5; after an uncached reload 3.0 s.
The largest bottleneck: Four feed sockets, each needing 0.9 to 1.3 s to connect. First change to try: Open the feed sockets from the first script, check whether the four can share one connection, and measure where the 0.9 to 1.3 s of each handshake goes before moving the server.
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.6 s, range 2.4 s–3.5 s; loads: 2.4 s, 3.5 s, 2.8 s, 2.6 s, 2.6 s |
| Uncached reload | median 3.0 s, range 2.8 s–3.2 s; loads: 2.8 s, 2.8 s, 3.0 s, 3.2 s, 3.0 s |
| Standing | 2 of 27 by median; possible rank 1 to 5. 0.1 s behind the fastest, Thalex (2.4 s): 1.0 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 | its screen has no order book, so it has fewer panels to 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
Price0.7 s
Chart2.0 s +1.3 s
Quote2.6 s +0.6 s
Trade-ready2.6 s +0.0 s settling
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.
| Host | Role | CDN edge seen | Connect | Response |
|---|---|---|---|---|
| omni.variational.io | page | Cloudflare Amsterdam | 13 ms | 19 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.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. |
Request waterfalldiagnostic capture 1 October, uncached
67 of the 246 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 fileImagewaiting for the serverdownloading
Bottlenecks and fixes, largest firstdiagnostic capture 1 October, uncached
- Evidence
- 1 October capture: requested at 1.00 s, first byte at 1.29 s, finished at 2.56 s (496 KB transferred, 1.7 MB unpacked). The timed loads and a logged-out follow-up name a file of exactly that size, /_app/immutable/assets/dotlottie-player.B5Wh5MC6.wasm, the Lottie animation player; the match is by size, host and order. It carries a one-year immutable cache header, but Cloudflare reports it as DYNAMIC, so the edge passes each request to the origin; a returning browser has it cached. A second response, /api/settlement_pools/leverage (50 KB, 747 KB unpacked), runs from 1.53 to 2.77 s, also DYNAMIC.
- Gap observed
- 1.56 s from requesting the 1.7 MB animation player to its completion
- Holds back
- Not established: the captures do not show which panel waits for this.
- Fix
- Load the Lottie player only when an animation is about to be shown, and let Cloudflare store the .wasm file, which is already marked immutable.
- Where
- The import of dotlottie-player in the app shell; the Cloudflare cache rule for /_app/immutable/assets/*.wasm.
- Verify
- DevTools → Network, filter "wasm": no request before the quote panel shows; cf-cache-status HIT.
- Evidence
- The page shows the market at 0.50 s; library.js is requested at 1.59 s and the chart is drawn at 2.63 s. In the campaign the chart follows the price by 1.3 s on a warm reload (0.7 s to 2.0 s).
- Gap observed
- 1.09 s between the market header appearing and the chart-library request
- Holds back
- Chart (median 2.0 s in the timed loads).
- Fix
- Request the chart library with the app chunks, for example with a preload in the HTML.
- Where
- Chart loader and the document head.
- Verify
- DevTools → Network: library.js requested before 0.6 s.
- Evidence
- Nine Web3Modal API requests go out in two batches at 0.83 s and 1.11 s, two WalletConnect RPC calls at 1.06 s and 1.25 s, and a WalletConnect relay socket at 1.58 s. All of them start before any feed socket has finished its handshake (1.97 s), so they share the network and the main thread with the market data.
- Measured
- nine Web3Modal API requests, two WalletConnect RPC calls and a relay socket
- Holds back
- Not established: the captures do not show which panel waits for this.
- Fix
- Start the wallet libraries after the first price and quote are on screen, or when the user opens the wallet dialog.
- Where
- Web3Modal and WalletConnect start-up.
- Verify
- DevTools → Network: no api.web3modal.com or walletconnect.com request before the first feed message.
- Evidence
- 1 October capture: 18 requests to mon.variational.io; one fails at once, 17 succeed, all starting between 1.30 s and 2.71 s and each waiting 0.3 to 0.5 s for its first byte, in the same window as the feed handshakes and the chart library. The follow-up names them: /_mon/api/v2/rum (page monitoring) and /_mon/api/v2/replay (session replay); a timed warm load sends 15 monitoring requests and one replay upload (2.74–3.15 s) before trade-ready.
- Gap observed
- 0.3 to 0.5 s from each monitoring request to its first byte
- Holds back
- Not established: the captures do not show which panel waits for this.
- Fix
- Queue monitoring events and send them in one batch after the page is trade-ready; start session replay after trade-ready.
- Where
- The mon.variational.io client (rum and replay).
- Verify
- DevTools → Network: no mon.variational.io request before the quote panel shows.
- Evidence
- 1 October timed loads, uncached and warm: /api/settlement_pools/leverage is requested six times (1.32 to 2.78 s; one answer is 747 KB unpacked, the others 1 to 5 KB), /api/metadata/supported_assets three times (one answer 475 KB) and /api/banner twice. The request parameters are not recorded, so the calls may ask for different things.
- Measured
- one endpoint called six times and another three times per load
- Holds back
- Not established: the captures do not show which panel waits for this.
- Fix
- Check which of the six leverage calls and three supported_assets calls differ, share the identical ones, and ask the large ones only for the market on screen.
- Where
- The callers of /api/settlement_pools/leverage and /api/metadata/supported_assets.
- Verify
- DevTools → Network, filter "settlement_pools/leverage": fewer requests, none over 100 KB unpacked before the quote shows.
- Likely saving
- Unknown
- Evidence
- 1 October capture: assets.variational.io/Inter-Variable.woff2 is 350 KB (1.03 s), and a 48 KB Inter file from fonts.gstatic.com loads at 0.95 s.
- Measured
- one 350 KB font file and a second Inter file
- Holds back
- Not established: the captures do not show which panel waits for this.
- Fix
- Ship one subset of Inter with the ranges and weights in use.
- Where
- The @font-face rules of the app and of the chart.
- Verify
- DevTools → Network, filter "woff2": one Inter file, under 100 KB.
- Likely saving
- Small on a reload; about 0.3 MB less on a first visit
- Evidence
- Logged-out follow-up recording: tasks of 110 ms (at 0.16 s), 153 ms (at 0.33 s) and 150 ms (at 0.63 s) on the main thread, before the first feed sockets are created at 0.79 s. The CPU profile places them in the app's own chunks: 33 ms in CVfNU1ZZ.js, 73 ms in the initialiser of DKkrxZ2C.js, and 28 and 22 ms in CSJ1lJwL.js and CSaMAIZ7.js. That recording stopped at a captcha, so it has no panel times.
- Gap observed
- 0.41 s of blocking tasks before the first socket is created, in the follow-up recording
- Holds back
- Not established: the captures do not show which panel waits for this.
- Fix
- Open the feed sockets before this initialisation runs, and look at what the three chunks set up synchronously at start-up.
- Where
- The app shell's start-up order: socket creation against the initialisers of DKkrxZ2C.js, CVfNU1ZZ.js, CSJ1lJwL.js and CSaMAIZ7.js.
- Verify
- DevTools → Network → WS: sockets created before 0.3 s; Performance: no task over 100 ms before them.
- Likely saving
- Up to ~0.4 s on the feed start
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.