How I built 100+ crypto calculators in 6 languages on Astro

Konstantin Iakovlev — Sat, 23 May 2026 15:48:33 +0000

A year ago I had a problem. Every time someone asked me "is mining still profitable?" or "what's my impermanent loss?" I'd find five different calculators across five different sites, each missing a feature, slow on mobile, and crowded with popups.

So I built a site for it. Then another. Then a hundred.

Today CryptoCalk has 100+ specialized crypto calculators running in 6 languages, served as static HTML from a CDN, no signup, no data leaving the browser. This is the technical story — what worked, what broke, and what I'd do differently.

TL;DR

Stack: Astro (SSG) + vanilla TS + plain CSS
Scale: ~108 calculators × 6 locales ≈ 650 static HTML pages
Why static: because Google still rewards real HTML, and because calc forms are perfectly cacheable
Hardest part: i18n routing without exploding bundle size
Live: https://cryptocalk.com

Why not Next.js / Vite SPA

The default 2026 reflex when you say "calculator" is React. I started there. It was wrong for this project.

Three reasons:

1. 108 calculators don't share state. A mining ROI calc has zero overlap with an impermanent-loss calc — different inputs, different formulas, different SEO intent. Shipping a 300KB React bundle to a user who needs one calculator is wasteful.

2. SEO is the whole game. Most of my traffic is people typing "asic mining calculator" into Google. Static HTML pre-rendered with the calculator visible (and a meaningful <title> and <h1>) ranks. CSR React with a "loading…" spinner does not — Googlebot indexes the empty shell.

3. CWV is hard with SPAs. Hydration costs you LCP. Route-change runtime kills INP. With a static page, LCP is literally "the time it took your CDN to send the HTML."

So: Astro. It lets me write components in any framework (or none) and emit static HTML by default. Hydration is opt-in per island. Each calculator page is a separate route, separate bundle.

The 108-calculator problem

The math: 108 calculators × 6 locales = 648 pages. Each one needs:

A different formula
Different input fields (a DCA calc needs "buy frequency", a tax calc needs "country" + "income bracket")
Localized labels, helper text, error messages
Locale-aware number formatting (commas vs dots, thousand separators)
Locale-aware currency (USD primary, but EUR, BRL, RUB, INR, TRY for context)
Localized SEO meta + JSON-LD

The naive way is to maintain 648 markdown files. That's a content-team job. The slightly smarter way is to define each calculator as data + a renderer.

What I ended up with (simplified):

// calculators/asic-mining.ts
export const calc = {
  slug: 'asic-mining',
  category: 'mining',
  inputs: [
    { id: 'hashrate',    type: 'number', unit: 'TH/s',    required: true },
    { id: 'power',       type: 'number', unit: 'W',       required: true },
    { id: 'electricity', type: 'number', unit: '$/kWh',   default: 0.10 },
    { id: 'pool_fee',    type: 'number', unit: '%',       default: 1.0 },
  ],
  compute: (i, { btcPrice, networkHashrate, blockReward }) => {
    const dailyBTC = (i.hashrate / networkHashrate) * blockReward * 144;
    const grossUSD = dailyBTC * btcPrice;
    const electricityCost = (i.power / 1000) * 24 * i.electricity;
    const netUSD = grossUSD * (1 - i.pool_fee/100) - electricityCost;
    return { dailyUSD: netUSD, dailyBTC, breakeven: i.power / netUSD };
  },
  seo: {
    en: { title: 'ASIC Mining Calculator', h1: 'Bitcoin ASIC Mining Profitability' },
    es: { title: 'Calculadora de Minería ASIC', h1: 'Rentabilidad de Minería Bitcoin ASIC' },
    // ... 4 more
  },
};

A single Astro template at src/pages/[locale]/[slug].astro reads this and renders 6 pages per calculator at build time. Total build: ~45s on a 4-core box. Output: pure HTML + a thin (~3KB gzipped) JS island per page that handles the form submission and runs compute() in the browser.

No backend. Live prices come from the CoinGecko free API client-side. The calculator math is also client-side — your inputs never leave your browser. (This was a marketing decision as much as an engineering one. "Privacy-first calculator" sells.)

i18n routing without bloating

Astro has astro:i18n but I rolled my own router because I wanted full control over the URL structure:

English at root: /asic-mining-calculator
Other locales as subfolder: /es/calculadora-de-mineria-asic
hreflang tags emitted in every <head>
Localized slugs (not just labels) — this matters for ranking on Spanish-language queries

The mistake I made early: I tried to share a single messages.json file across the whole site. By the time I hit calculator #50, the file was 280KB. Every page shipped the whole dictionary even though it only needed the strings for that one calc.

The fix was boring but worked: one messages file per calculator per locale, statically imported into the corresponding page. Astro inlines only what each page references. Bundle size per page dropped from 280KB to ~6KB.

src/i18n/
  asic-mining/
    en.json   ← 1.2KB
    es.json   ← 1.4KB
    ...
  impermanent-loss/
    en.json
    ...

The 6-language SEO trap

Six languages means six chances to get hreflang wrong. The combinations:

hreflang="en" → /asic-mining-calculator
hreflang="es" → /es/calculadora-de-mineria-asic
hreflang="pt" → /pt/calculadora-de-mineracao-asic
hreflang="ru" → /ru/калькулятор-майнинга-asic (or transliterated)
hreflang="hi" → /hi/asic-माइनिंग-कैलकुलेटर
hreflang="tr" → /tr/asic-madencilik-hesaplayicisi
hreflang="x-default" → /asic-mining-calculator

If you forget the reciprocal links (every language version must point to every other version, including itself), Google quietly stops treating them as alternates and you end up with duplicate-content competition between your own pages.

I built a single Astro middleware that generates the full hreflang block from a central language config. One source of truth, can't drift. Took two hours and saved me a future panic.

Performance: keeping LCP under 1.2s globally

The cliché says "make it fast." The reality is more interesting:

No web fonts on first paint. I preload DM Sans but use font-display: swap, and the calculator UI is fully readable in system fonts during the swap window.
AdSense lazy-loaded after requestIdleCallback. Loading the ads.js synchronously in <head> was killing FCP by 800ms. Now it loads after first interaction or 3s, whichever first.
CoinGecko prices fetched lazy. A "Refresh price" button fires the fetch; on first load the page uses the last-cached price baked into the static HTML (regenerated every 15 min by CI). LCP no longer waits on a third-party API.
Critical CSS inlined per route. Astro does this automatically with its <style> block; the rest of the stylesheet streams in parallel.

Current numbers on a mid-range Android (Moto G Power, throttled 4G, US East CDN edge):

LCP : 1.1s
INP : 24ms
CLS : 0.00

The 0.00 CLS is intentional — every ad slot has a reserved height. The ad either fills it or stays empty. No layout shift either way.

AdSense + privacy: the consent dance

Running AdSense in the EU, UK, and California means you need a CMP (Consent Management Platform). I tested three; ended up with Google's own free CMP because it auto-syncs with AdSense and didn't tank my fill rate.

The boring code that matters:

<script>
  // Set default consent to denied — required to load gtag *before* user choice.
  gtag('consent', 'default', {
    ad_storage: 'denied',
    analytics_storage: 'denied',
    ad_user_data: 'denied',
    ad_personalization: 'denied',
  });
</script>

This runs before the GA tag. Without it you'll get "Consent not signaled" warnings in AdSense and reduced revenue.

What I'd do differently

1. I'd skip the Russian transliterated URLs. Initially I had /ru/калькулятор-майнинга-asic (Cyrillic). Then I discovered some browsers and link-sharing tools mangle the URL. Switched to romanized: /ru/asic-mining-calculator-ru. Lost some keyword density but kept link integrity.

2. I'd add IndexNow earlier. It's a 10-line integration that pings Bing instantly when content changes. I added it 8 months in. Bing indexation went from 60% to 95% within a week.

3. I'd separate the "marketing" pages from "calculator" pages on the build level. Right now they share a build pipeline. The marketing pages don't need the calculator runtime; pulling them apart would save another ~2KB on those routes.

4. I'd write more tests for the math. I have golden-file tests that compare my outputs against published references (CoinGecko, StakingRewards, etc) but only for ~30 of 108 calculators. The other 78 are tested by "people email me when something looks off." This is bad. I'm fixing it now.

Numbers

108 calculators
648 statically pre-rendered HTML pages
6 languages
~45s build time on 4-core CI
3KB average JS per page (after gzip)
0 signups required
0 user data collected
DR 17 (Ahrefs, May 2026 — still climbing)
3-4k weekly organic clicks across the 11-domain Calk Empire network

Try it

https://cryptocalk.com — pick a category, run a calc, no signup. If you spot a math bug or a missing calculator, open an issue or ping me.

If you're building something similar and want to compare notes on Astro at scale, i18n routing, or AdSense pain — DM on LinkedIn.

Konstantin Iakovlev is the founder of the 11-domain Calk Empire calculator network including calk.kz, calk.kg, and cryptocalk.com. 14+ years in internet marketing, 8+ years in financial analytics.

DEV Community: Konstantin Iakovlev