Blog
Core Web Vitals on JS-Heavy Crypto Exchanges: Five Bottlenecks We Fix Most
Crypto exchanges run on JavaScript-heavy stacks (React/Next, real-time price tickers, WalletConnect, embedded charting). Core Web Vitals suffer in predictable ways. Here are the five bottlenecks we fix in every Foundation engagement.
A typical crypto exchange front-end runs Next.js or React, real-time price tickers via WebSocket, embedded TradingView charts, WalletConnect SDKs for 30+ wallets, and a handful of analytics scripts. By the time a user hits the homepage, the browser has executed 4–6 MB of JavaScript and the LCP has slipped past 4 seconds. Google’s Core Web Vitals fail rate on the crypto-exchange page-experience cohort is the highest we measure across any vertical we audit.
This post is the five bottlenecks we end up fixing on every Foundation engagement, in priority order. Code-level, not theory.
Quick facts
| Parameter | Value |
|---|---|
| Median LCP on audited crypto exchanges | 3.8s mobile / 2.6s desktop (75th percentile) |
| Median CLS | 0.18 (Google fails at >0.10) |
| Median INP | 320ms (Google fails at >200ms) |
| Typical JS bundle size | 4–7 MB transferred / 12–22 MB parsed |
| Largest contributors | Charting library, wallet SDKs, analytics, ad scripts |
| Realistic fix timeline | 2–4 weeks for top-3 bottlenecks |
What’s the LCP killer on crypto exchanges?
Almost always the charting library or hero ticker. Trading View Lightweight Charts ships ~280 KB minified and fetches data on mount; the heavier embedded TradingView widget is 1.4 MB+ and blocks LCP for 1.5–2.5 seconds on mobile. The ticker is worse — many exchanges hydrate the homepage hero with live WebSocket data, blocking the LCP element until the first payload arrives.
The fix is two-step. Step 1 — defer charting to user interaction. The home page rarely needs the chart on first paint; render a static SVG or pre-rendered PNG snapshot, then swap to the live chart on click or scroll-into-view. We’ve seen LCP drop from 4.2s to 1.6s with this single change.
Step 2 — pre-render the ticker hero with last-known prices and update over WebSocket after hydrate. The first paint shows yesterday’s close (cached server-side), which is wrong by the second pixel but right enough for LCP measurement. The actual price flickers in 200–400ms after hydrate. Users barely notice; Lighthouse scores jump.
Why is CLS so bad on these sites?
Three patterns we fix most often. Asynchronous wallet connect modals that appear above the fold without space reserved — the modal pops in, pushes content down, CLS spikes. Fix: reserve a fixed-height container for the modal trigger from initial render.
Late-loading market-cap stat blocks — the homepage shows “$X market cap” pulled from CoinGecko after hydrate; the placeholder is shorter than the final number, layout shifts. Fix: pre-render with a wider placeholder (“$0,000,000,000”) and shrink to actual on update.
Web fonts loading without size descriptors — font-display: swap causes flash of unstyled text and reflow when the custom font loads. Fix: size-adjust and ascent-override CSS descriptors to match metrics, or font-display: optional if you can accept fallback rendering.
What kills INP (the new responsiveness metric)?
Long-running JavaScript on user interaction — wallet-connect button click triggers a 600–1,200ms script execution because every wallet adapter loads its own bundle synchronously. By the time the modal opens, INP is well past 200ms.
The fix: lazy-load wallet adapters. Only the metadata (icons, names) ships in initial bundle; the actual adapter SDK loads on adapter-click. WalletConnect, MetaMask, Phantom, Ledger — all ~150–400 KB each. Loading 30 adapters at once is wasteful when the user only ever picks one.
Synchronous analytics on click is the second offender. GTM + Mixpanel + Amplitude + Heap all firing on the same click handler add up to 100–250ms of blocking JS. Fix: requestIdleCallback for non-critical analytics, or batch into sendBeacon calls.
How do we measure this in practice?
Three layers. Lighthouse CI on every deploy to catch regressions in synthetic conditions — runs in GitHub Actions or CF Pages build hook, fails the deploy if LCP/CLS/INP regress past thresholds.
Real-User Monitoring via web-vitals.js + Cloudflare Analytics or Vercel Speed Insights for actual user data. Synthetic Lighthouse scores routinely diverge 30–60% from real-user CrUX data on crypto sites because real users are on slower networks (mobile, 3G, geo-distant).
GSC Core Web Vitals report for the long view. GSC aggregates field data over 28 days; a CWV improvement shows up there 10–14 days after deploy. We pair GSC with our own Supabase + Looker Studio dashboard for daily granularity.
What about server-side rendering — does it solve the problem?
Partially. SSR + hydration is what most crypto exchanges already do (Next.js with getServerSideProps or App Router). The problem is hydration: the JavaScript that runs after SSR delivers the HTML still has to parse, compile and execute. SSR helps LCP but doesn’t help INP.
The cleaner architecture for performance is partial hydration (Astro islands, Qwik, or Next.js App Router with selective 'use client'). Static HTML for the hero/marketing surface, hydrated islands only where interaction is needed (wallet connect, chart). We’ve migrated three exchanges this way; LCP improvements were 40–55%, INP 60–70%.
This is rarely a one-week fix because the existing component graph has client-side dependencies woven through everything. But it’s the path that holds the gains; the per-component optimisations get clawed back as features ship.
Frequently asked questions
Is migrating to Astro/Qwik realistic for a production exchange? For the marketing surface (homepage, pricing, blog, jurisdiction pages) — yes, and it’s where we’ve seen the biggest CWV wins. For the trading interface itself — no, those need full client-side reactivity.
Should we self-host TradingView instead of embedding? TradingView’s Charting Library (self-hosted) is faster than the embedded widget by ~1.5–2× on first paint, but licence fees are non-trivial ($25k+ for the proper version). Lightweight Charts (free, self-hosted) is the better starting point for most exchanges.
Does Cloudflare’s auto-minify hurt or help CWV?
Help, marginally. Cloudflare Auto Minify saves 5–12% bundle size for typical exchanges. The bigger Cloudflare wins are HTTP/3, Early Hints (103 status), and Argo smart routing for geo-distant users.
How often do we run a full performance audit? Quarterly on Growth retainers; monthly on Authority. CWV regresses after every major feature ship — we’ve seen LCP slip 30% from a single charting-library upgrade. Continuous monitoring + Lighthouse CI catches it.