Epic: fastest storefront in Mongolia#293

openedAug 25, 2026byAAviddaram

Most Mongolian e-commerce runs on AWS or other clouds with everything in Hong Kong, so shoppers pay a cross-border round trip on every click. We run Cloudflare Workers and confirmed production traffic lands at the ULN (Ulaanbaatar) edge colo (cf-ray: ...-ULN). That means we can serve TTFB of 10-130ms to Mongolian users while competitors start at 200ms+ before their app even boots.

This epic tracks the remaining work to make amerikvitamin.mn measurably the fastest storefront experience in the country, not just fast for us.

Where we are (benchmarked Aug 25 from UB, Lighthouse 13 mobile throttling)

PageScoreLCPTBTCLS
Product921.9s300ms0
Category listing891.7s420ms0
Home536.2s690ms0
Product (desktop)990.8s40ms0.002

The catalog is already instant after full prerendering. The homepage is the gap, plus a handful of payload and font issues.

Work items

  • #287 Homepage hero LCP: fetchpriority, preload, defer eager hydration
  • #286 Brand logos through cdn-cgi resizing (~250KB waste on home)
  • #289 Defer PostHog past window load (197KB + US round trips during render)
  • #288 Font subsets: cover Өө/Үү, fold ₮ into cyrillic subset, drop latin-ext (~130KB)
  • #290 Remove .webmcp bridge from production
  • #291 Cache server islands / client session probe
  • #292 Sitemap: drop old-slug redirect URLs

Target state

  • Every public page scores >= 90 mobile under Lighthouse throttling
  • Every page LCP < 2.5s throttled, TBT < 200ms, CLS ~0
  • Homepage total transfer under 900KB
  • Zero font fallback glyphs for Mongolian text
  • No third-party requests inside the render window

How we measure

Lighthouse 13 with default mobile throttling against production, cross-checked with unthrottled Chrome timing from Ulaanbaatar (which is what our users actually experience via the ULN colo). Numbers above are from the Aug 25 baseline run.

Competitor benchmark — Aug 25, from UB

Full methodology: plain curl timings (3 runs/site) + Lighthouse 13 mobile (single run) + real-Chrome performance entries via agent-browser. Spot checks, not the official baseline.

Delivery layer (curl, home HTML, warm)

SiteEdge / stackTCP connectServer think-time (ttfb − tls)
amerikvitamin.mnCF ULN, Workers13 ms~150–190 ms (home)
shoppy.mnnginx on UB-local racks (iTools JSC)11 ms~5–10 ms shell + APIs at 115 ms avg
bsb.mnCF ULN + Next.js origin, s-maxage=90016 ms28–53 ms (app-level page cache)
new-tech.mnCF ULN proxy → WordPress origin10 ms1.8–2.3 s (regenerates 1.19 MB HTML per view)
gobi.mn / next.mn / btf.mnVercel (no MN colo)60–120 ms210–540 ms
nomin.mnCF ULN proxy → Node origin, HTML always DYNAMIC10 ms2.6–4.6 s
beautyme.mn (Zochil)DigitalOcean New Jersey, Next.js, no-cache headers236 ms350 ms–1.4 s

Lighthouse 13 mobile, single run

PerformanceLCPTBTPage weight
beautyme.mn2521.4 s9,670 ms17.9 MB
amerikvitamin.mn (home)623.2 s2,080 ms1.3 MB

Key corrections to this epic's claims

  1. "Competitors in Hong Kong" is wrong for beautyme — Zochil storefronts serve from a single DO droplet in New Jersey (~236 ms RTT). Understated if anything.
  2. We are not the only ones at ULN: nomin, new-tech, and bsb all terminate at ULN. The differentiator is what happens after the edge.
  3. Nobody in the set runs compute at the edge except us — everyone else is a proxied origin; their HTML is cf-cache-status: DYNAMIC.
  4. The only serious rival is bsb.mn (same architecture: prerendered HTML + edge cache). nomin.mn proves the race is won at the app layer, not the network.

→ New work item from this audit: #297 (serve prerendered HTML as edge-cached assets; also flags product.getInventory at 388–965 ms per call).