DEV Community: OPTTOYSCHINA

The carton is the unit: what 385,000 wholesale listings say about minimum order quantity

OPTTOYSCHINA — Tue, 22 Sep 2026 09:45:49 +0000

The carton is the unit: what 385,000 listings say about minimum order quantity

Every new importer asks the same first question — "what is your minimum order?" — and expects a number in dollars. It almost never is one. The minimum is a physical fact: how many pieces the factory puts in one box.

We run a wholesale catalogue of 385,341 listings from 5,530 Chinese factories. Here is what the numbers actually look like when you measure them instead of guessing.

The numbers

From a 6,000-item sample of the live catalogue:

median price per piece: ¥9.30 (about $1.45 at our published rate)
52% of items are under ¥10 a piece
92% are under ¥50
median minimum order: 84 pieces
the common carton sizes: 24, 36, 48, 72, 96, 120

Those carton sizes are not a pricing tier. They are the factory's packing line: a large radio-controlled truck comes twelve to a carton, small figures come several hundred. The box is the unit, and nobody downstream gets to redefine it.

Why "one piece" is not cheaper for anyone

Breaking a carton sounds like a favour to a small buyer. It is not, for three reasons that all cost money:

The remainder becomes dead stock. Nineteen pieces of a twenty-piece carton sit in a warehouse until someone wants exactly nineteen.
The factory packaging is destroyed. That packaging is what lets the goods be sold as new.
The handling cost per piece explodes. Picking, repacking and re-labelling one item costs the same as handling a whole carton.

So the honest answer to "can I order one?" is no — and the useful answer is that a test carton of a cheap model costs less than most people expect. At a median ¥9.30 and a median carton of 84, a typical test is around ¥781, roughly $122 at our rate. That is the real entry price of wholesale, and it is a fifth of what most first-time buyers assume.

What this changes about buying

Buy width, not depth, on the first order. Twenty models at one carton each tells you what sells. One model at twenty cartons tells you nothing until it is too late.

Price per piece is the wrong comparison number. Compare price per carton against the shelf space the carton will occupy and the weeks it will take to clear.

Minimum order value is a separate question from minimum order quantity. We do not have a minimum order value at all: one carton of one model is a valid order. Many suppliers do have one, and conflating the two is how buyers end up ordering four times what they need.

The part nobody budgets for

The carton decides freight too. Freight is charged on gross weight or volumetric weight, whichever is greater, and cheap bulky toys are almost always volumetric. A carton of ¥11 plush is light and enormous; a carton of ¥11 die-cast cars is small and heavy. The same money buys wildly different freight bills, and you find out at the quote, not at the order.

Transit times matter for the same reason: sea is the cheapest and the slowest, and the ranges run from 2 days to Hong Kong to 45 days to Chile. We publish them per country for 62 destinations.

And one date overrides all of it: Chinese New Year falls on 6 February 2027, with roughly six weeks of disrupted output around it. The backward count from your shelf date is on our production calendar.

The catalogue itself, with per-piece and per-carton prices on every item, is at opttoyschina.com.

Stop using a generic FX API for prices. Use the central banks.

OPTTOYSCHINA — Mon, 21 Sep 2026 14:45:07 +0000

Our catalogue is priced in one currency — Chinese yuan — and read by buyers in dozens of countries. Somewhere between the database and the buyer's screen, ¥9.30 has to become a number they recognise, and it has to be the same number on every reload.

That turns out to be three separate problems, and the usual answer ("call an FX API") solves none of them well. Here is what we ended up with, including the two bugs that cost us the most.

Problem one: which rate is the real rate

A generic FX API gives you a mid-market rate aggregated from somewhere. For a price a buyer will act on, that is the wrong number, for a boring reason: your buyer's accountant does not use it. They use whatever their central bank published this morning, because that is what the invoice will be checked against.

So we take each currency from the institution that actually sets the reference:

Currency	Source
CNY → USD	People's Bank of China, central parity (`ccpr.json`)
RUB	Central Bank of Russia
KZT	National Bank of Kazakhstan
UZS	Central Bank of Uzbekistan
AED	USD peg, 3.6725 — it is a peg, not a market

The AED line is the interesting one. There is no point calling an API for a currency that has been pegged at 3.6725 to the dollar since 1997. We derive it:

// Дирхам привязан к доллару фиксированно. Тянуть его из «курсовой» ленты —
// значит каждый день заново узнавать одно и то же число, и однажды получить шум вместо него.
const AED_ZA_USD = 3.6725;
rates.AED = rates.USD * AED_ZA_USD;

One source of truth, no drift between two feeds that should agree.

Everything else falls through to USD. That was a deliberate narrowing: we used to localise currency for far more countries, and every extra currency was another surface where the price could be wrong. A buyer in Chile reading a dollar price is not confused. A buyer in Chile reading a wrong peso price is gone.

Problem two: the rate is not the price

A published price is not the raw rate. Ours is two multipliers on top, and keeping them separate matters:

// два множителя, и они НЕ взаимозаменяемы:
//   product_pct — наша наценка на товар, экономика
//   currency_pct — запас на курс: комиссии банков и движение курса за сутки
const opublikovannyi = syroi * (1 + currency_pct / 100);

Today's live numbers from our own feed, straight out of the endpoint:

Currency	Raw	Published	Ratio
USD per CNY	0.14810207	0.155507	×1.05
KZT	66.68	70.014	×1.05
RUB	12.567	13.19535	×1.05
UZS	1767.71	1856.0955	×1.05
AED	0.54390486	0.5711	×1.05

The 15% product markup lives in the product price, not in the rate. Two reasons, both learned the hard way: the markup changes for commercial reasons and the buffer changes for financial ones, and if they share a variable you can no longer answer "why did this price move?" — which is the only question anyone asks about prices.

The rates refresh once a day, 06:30 UTC, on a timer. Not per request. A price that changes while a buyer is reading it is a price they will not trust, and a central bank publishes once a day anyway.

Problem three: the flicker

This is where we shipped the actual bug, and it is worth describing because it is invisible in code review and obvious to a customer.

Country detection is asynchronous — we read it from the edge:

window.OTC_COUNTRY_READY = fetch('/cdn-cgi/trace').then(razobrat);

Which means at first paint you do not know the country. The naive flow is: render in a default currency, then swap when detection resolves. So a buyer in Dubai loaded the page, saw tenge, and watched it turn into dirhams a beat later. From their side that is not a loading state. That is a site that just showed them someone else's price.

Two fixes, and both were needed:

1. The default has to be the global one, not the home one. Our fallback was the domestic currency because the domestic market came first historically. Wrong default: a wrong dollar price is a rounding argument, a wrong tenge price is a different country.

const VALYUTA_PO_UMOLCHANIYU = 'USD';

2. Convert before paint, not after. Ship the raw yuan value in the markup and let a blocking inline script do the arithmetic before anything is displayed:

<span class="cena" data-rmb="9.30">…</span>
<script is:inline>
  /* до первой отрисовки: ничего не мигает, потому что нечему меняться */
  var k = window.__KURS__ || 0.155507;
  document.querySelectorAll('.cena[data-rmb]').forEach(function (e) {
    e.textContent = (Number(e.dataset.rmb) * k).toFixed(2) + ' $';
  });
</script>

An Astro-specific trap that cost us a day here: <script is:inline>{ … }</script> — with the body wrapped in braces — is not executed. Astro treats it as an expression and emits the code as text. It has to be a plain <script is:inline> with the JavaScript directly inside. The page looks fine, the script is in the HTML, and nothing runs.

The rules we kept

Take the rate from the institution your buyer's accountant will quote, not from an aggregator.
A pegged currency is arithmetic, not a feed.
Keep the commercial markup and the FX buffer in separate variables, even when they are both "just a multiplier".
Refresh on a schedule, not per request. Daily source, daily cadence.
The default currency is the one most of the world reads, because the default is what a buyer sees when detection is slow — and slow detection is the normal case on a cold mobile connection.
Do the conversion before first paint. A flicker between two currencies is read as a broken price, not as a loading state.

Our catalogue is public if you want to see the result under load — 385,341 listings, prices recomputed daily, at opttoyschina.com. The delivery-side of the same problem, where the inputs include a factory calendar that goes to zero for six weeks a year, is written up here.

Delivery dates are a data problem: 62 lanes, 385k SKUs and a calendar that zeroes production

OPTTOYSCHINA — Sun, 20 Sep 2026 10:18:14 +0000

We run a wholesale catalogue of 385,341 listings from 5,530 Chinese factories, and we ship to 62 countries. Every product page has to answer one question a buyer actually cares about: when will this be on my shelf?

For a long time we treated that answer as a field. It is not a field. It is a pipeline with three independent inputs, and one of those inputs drops to zero for six weeks every year. This post is about how we model it, with the real numbers from our own data.

The naive version, and why it breaks

The obvious model is a lookup:

const dni = srokiPoStrane[strana];   // "18-40"

That is wrong in three separate ways, and each one shows up as an angry email.

It assumes one transport mode. Air, rail and sea to the same country differ by a factor of five.
It assumes the goods exist. Half a catalogue is stock, half is made to order.
It assumes a factory is working today. For roughly six weeks a year, it is not.

Input one: the transit matrix

Our matrix is 62 destinations × 3 modes. Not every cell is filled — and the empty cells carry as much information as the full ones.

Region	Countries	Air	Rail	Sea
Europe	28	5–9 d	12–22 d (all 28)	22–38 d
Asia-Pacific	11	1–9 d	—	2–30 d
Middle East	9	4–8 d	18–25 d (1 of 9)	14–32 d
Africa	7	6–12 d	—	22–40 d
South America	4	11–15 d	—	30–45 d
North America	3	8–15 d	—	18–40 d

Rail exists for 29 of 62 destinations and for exactly one reason: continuous track from China. Every European destination has a rail figure; the Middle East has one (Iran); the Americas, Africa and the island parts of Asia-Pacific have none and never will. A null in that column is not missing data — it is geography, and the code should say so:

// null в колонке rail — это НЕ «данных нет», это «рельсов нет».
// Их нельзя дозаполнить позже и нельзя подставить среднее по региону.
const dostupno = ['air', 'sea', ...(lane.rail ? ['rail'] : [])];

If you let a null fall through to "unknown" your UI will eventually offer a train to Brazil.

The widest spread is Asia-Pacific: sea from 2 days to 30. A single regional average would be useless for both ends of it. Aggregate for display, never for a promise.

Input two: does the thing exist yet

Across a 6,000-item sample of our live catalogue:

median price ¥9.30
47% of items under ¥10, 90% under ¥50
median MOQ 72 pieces, with the common cartons at 24 / 36 / 48 / 72 / 96 / 120

Those carton sizes matter to the date calculation more than the price does. A stocked carton ships this week. Anything below a carton does not ship at all — we do not break cartons — and anything above available stock becomes a production order with its own lead time of 15–30 days, stretching to 45 in peak season.

So the second input is not a number, it is a branch:

function proizvodstvo(poziciya, kolichestvo) {
  if (kolichestvo % poziciya.moq !== 0) return { otkaz: 'ниже коробки' };
  if (kolichestvo <= poziciya.ostatok) return { dney: 0 };          // со склада
  return { dney: poziciya.pik ? [30, 45] : [15, 30] };              // под заказ
}

Input three: the calendar that zeroes everything

This is the one that generic logistics models miss, and it is the largest single term in the equation.

Chinese New Year 2027 falls on 6 February. The official holiday is about a week. The real shutdown is roughly six weeks: factories wind down two to three weeks ahead as workers leave for their home provinces, and take three to four weeks afterwards to get back to full output, because a meaningful share of workers do not return to the same employer.

There is a second, smaller one: Golden Week, 1–7 October. Only a week, but it lands inside the run-up to the Western fourth quarter, when every hour of capacity is already booked. A week lost there cannot be made up.

In code, the calendar is not an offset you add. It is a function that can make a date impossible:

// Календарь не «сдвигает» срок — он может сделать срок недостижимым.
// Это разные вещи, и ответ клиенту тоже разный: «позже» или «в этом сезоне никак».
function skvozKalendar(startDate, dney) {
  const okna = prostoi(startDate.getFullYear());   // CNY ± wind-down, Golden Week
  let ostalos = dney, d = new Date(startDate);
  while (ostalos > 0) {
    d.setDate(d.getDate() + 1);
    if (!vOkne(d, okna)) ostalos--;                // в простое счётчик не идёт
  }
  return d;
}

The practical consequence, and the thing almost nobody acts on: for a small importer the cheapest available improvement is not a better price, it is ordering six weeks earlier. It costs nothing and it moves you out of the queue. We wrote the full year-by-year breakdown up as a production calendar page, because it turned out to be the single question buyers asked most.

Putting it together, backwards

The only direction that works is backwards, from the shelf date to the order date. Four blocks, counted separately:

shelf date
  − marketplace check-in      up to 14 d
  − freight (mode, lane)       2–45 d
  − consolidation + QC          3–5 d
  − production                  0–45 d
  − calendar blackout           0–42 d
= order date

Run that for November 2026 and you get cut-offs that look absurdly early but are simply arithmetic: sea to the US had to leave by early September, rail and road to Europe by mid-September, air holds until mid-October at peak-season rates.

What we changed in the code

Three rules came out of this, and all three were bought with support tickets:

Never store a delivery date. Store the inputs and compute on read. A stored date is a promise that silently rots.
Distinguish "no data" from "not possible". Empty rail is not a gap in the dataset.
Let the calendar veto. The function that returns a date must be allowed to return "not this season" instead of a later date, because those are different answers to the buyer.

The full transit table by country is public on our shipping and transit times page, and the live catalogue with prices and carton sizes is at opttoyschina.com. If you model delivery dates for physical goods and you have solved the calendar-veto problem more elegantly, I would genuinely like to read it.

Stale-while-revalidate on the edge: how our marketplace killed the cold start (and kept geo-currency)

OPTTOYSCHINA — Tue, 21 Jul 2026 12:11:33 +0000

"Cold start" is not a law of nature. It's a caching strategy you haven't finished. Here's how our SSR marketplace serves a warm copy from ~300 datacenters — to every visitor, always, including the very first one after a deploy.

Context: B2B toy marketplace, 389,000 products, mobile PageSpeed 93 on the full site. Receipts and the whole story here.

The two classic pains

SSR pain: while the page renders on the server, the user stares at a blank screen. Cache pain: the copy expires once a day, and some unlucky visitor pays for the rebuild.

Both die with one construct in the edge middleware — stale-while-revalidate:

Request comes in → serve the cached copy instantly, even if it's stale.
In the background (ctx.waitUntil), rebuild the page and store the fresh one.
s-maxage=86400 + Tiered Cache + Cache Reserve: the copy lives a day, regional PoPs pull from the upper tier, the reserve keeps a central fallback.

Nobody ever waits for a render. FCP is a stable 1.4s from any point on the globe.

The dilemma everyone solves wrong: personalization vs. caching

A marketplace must show tenge in Almaty, som in Tashkent, dollars in Berlin. The usual answer — server-side geo rendering — means one cached copy per country, most of them permanently cold. Congratulations, your cache is decorative.

Our answer: fully neutral SSR. One HTML for the whole world → one cache → always hot. On the client:

// the CDN already knows the geo — ask it for free
fetch('/cdn-cgi/trace')  // → country=KZ → sessionStorage
// prices in HTML are a neutral base; the client applies the local rate
// BEFORE prices paint — no flash of wrong currency

Personalization lives, and so does the cache.

A living storefront that doesn't kill the API cache

We wanted the homepage to rotate bestsellers every 5 minutes. Random offset per user = cache murder. Deterministic window = free liveliness:

window = floor(now / 5min) % pool   // every user on Earth gets the same slice

Redis serves it from memory; the storefront breathes at zero cost. (One follow-up rake: the window must respect your anti-bot depth cap — invariant: window ≤ min(pool, cap) — or the block silently starves once in a while.)

The honest caveat

1 PageSpeed run in 5 still catches a 77: the LCP poster on a rare ice-cold PoP. We inlined a 6 KB data-URI webp poster and deferred the 4 MB hero video past window.load — the tail is almost dead, but not fully. We publish that number anyway; that's the difference between a measurement and marketing.

Verify, don't trust

Open DevTools on opttoyschina.com — every search request returns an open Server-Timing header, and pasting the domain into pagespeed.web.dev takes 30 seconds. Questions on the middleware, cache keys, or the deterministic rotation — comments are open.

Camera product search on the mobile web — the feature Alibaba and Amazon keep locked in their apps

OPTTOYSCHINA — Tue, 21 Jul 2026 12:10:16 +0000

Camera-based product search has always been a flex reserved for the giants' native apps: Alibaba has it in the app, Amazon has it in the app. On the mobile web, among B2B marketplaces, we couldn't find it at anyone. So we shipped it on the website itself — and it costs our LCP exactly nothing.

Context: B2B toy marketplace, 389,000 products from 5,530 factories. The full performance story with PageSpeed receipts is here.

The use case that sold us

A wholesale buyer stands at a trade fair in Guangzhou — or in a competitor's shop — points a phone at a toy, and gets the product plus its analogs from our catalog: carton price, MOQ, freight to their hub. No app install, no account wall. One tap from the browser toolbar.

The pipeline

Client: a deferred 50 KB camera modal (more on that below). Photo gets downscaled client-side before upload — nobody ships 12 MP over trade-fair Wi-Fi.
Encoder: SigLIP with a LoRA we fine-tuned on toy imagery, running on a rented RTX A4000 (~$0.085/hr). Encode: ~38 ms.
Retrieval: kNN over 886,219 image embeddings — ~190 ms.
End-to-end, camera click → results: ~0.5 s.

Why a LoRA? Generic CLIP-family models are decent at "a plush toy". Wholesale buyers need "THIS plush hippo, and the three factories making lookalikes". Fine-tuning on toy imagery moved retrieval from cute demo to daily tool.

The performance trick: the feature that isn't there

The camera modal weighs 50 KB — and it is not in the critical path at all. It loads as a deferred chunk after the first screen is painted. Lighthouse literally cannot see it. Our mobile PageSpeed stays 93 on the full 389k-product site, camera search included.

That's the thesis we keep hammering: everything "only a native app can do" — done on the open web, indexed by Google, one link away.

Verify, don't trust

Every text-search request on the site returns an open Server-Timing header — open DevTools on opttoyschina.com and watch the stages. Try the camera button from a phone. Questions about the LoRA training set, the embedding pipeline, or why we didn't use an off-the-shelf visual search API — comments are open.

From 9,663 ms to 18 ms: sorting a 389k-product catalog in Postgres (no magic, three steps)

OPTTOYSCHINA — Tue, 21 Jul 2026 12:09:02 +0000

Sorting a catalog by price took 9,663 ms. Same database, same hardware, three boring steps later: 18 ms. Here's the whole playbook — no exotic extensions, just Postgres used properly.

Context: we run a B2B toy marketplace — 389,000 products from 5,530 factories, full story with PageSpeed receipts here.

The crime scene

Classic marketplace schema drift: the price lived in a JSON field on the main products table, while all the storefront filters (category, stock, MOQ) hit a separate filter table. Every "sort by price" forced Postgres to join back, extract from JSONB, and sort 389k rows with nothing to lean on. EXPLAIN ANALYZE read like a horror novel: 9.6 seconds.

Step 1 — denormalize into the table that does the WHEREs

We copied price and moq into the filter table — the one already serving every storefront query. Yes, denormalization. No, it's not a sin: it's a trade you make consciously and document.

Step 2 — a trigger keeps the mirror honest

One AFTER UPDATE trigger on the source table syncs the mirror columns. No cron drift, no "eventual consistency" surprises, no application-level sync bugs at 3 a.m.

Step 3 — partial indexes for real query shapes

We didn't index the whole table. We indexed what the storefront actually asks: in-stock rows per category ordered by price. Partial indexes are smaller, hotter in cache, and Postgres actually picks them.

All migrations idempotent, built with CREATE INDEX CONCURRENTLY — zero downtime on a live store.

Numbers

Catalog sort: 9,663 ms → 18 ms
One factory's page (36,000 products from a single supplier): 2,270 ms → 5 ms
Warm search over 389k products (FTS + trigram + pgvector cascade behind a Redis response cache): 6–15 ms

The iron rule that kept us honest

Every optimization ran against a control set of queries, and the top-20 results had to be byte-identical before and after. Speed bought by silently changing what customers see is not an optimization — it's a regression with good PR.

Verify, don't trust

Our search returns an open Server-Timing header on every request — open DevTools on opttoyschina.com and watch the stages yourself. Questions about the schema, the trigger, or the index shapes — comments are open.

Alibaba scores 51 on PageSpeed. Our full 389,000-product marketplace scores 93. The dirty secret is m-dot sites

OPTTOYSCHINA — Fri, 17 Jul 2026 10:26:13 +0000

Every number below links to a permanent Google PageSpeed Insights report — click and verify.

Every frontend engineer has quietly suspected this: the "mobile speed" of big e-commerce is a bit of a lie. You run the numbers on a giant — pretty scores. You open the actual site — something doesn't add up.

We build a B2B toy marketplace (389,000 products, 5,530 factories, multi-currency, search-by-photo), and along the way we ran every major B2B platform in the world through Google PageSpeed Insights. Same method, same day, permanent links saved.

Turns out the suspicion is true. And it's funnier than we thought.

The dirty secret: the m-dot

Mobile PSI scores, homepages, July 2026:

Platform	Score	What was actually measured
IndiaMART	98	⚠️ m.indiamart.com — a stripped-down mobile shell
our marketplace	93	the full site, 389k products
Made-in-China	86	⚠️ m.made-in-china.com — same trick
Ozon	70	full site
DHgate	65	full site
Alibaba	51	full site
Amazon	48	full site
eBay	42	full site
GlobalSources	30	full site

Notice the pattern? Everyone above 70 — except us — serves Google's mobile agent a separate m-dot site: a gutted shell with a bare menu and no real catalog. PSI honestly discloses it in a small banner ("Results for URL: m.…") — but who reads the banner?

So the industry recipe for mobile speed in 2026 is: hide your site, show Google a menu. The only way to post high numbers with your real site is to actually make it fast.

Here's how we did it — including the embarrassing parts: the "PSI lottery", a double-markup pricing bug, and a globe video that fell asleep forever.

Why we deliberately did NOT build a native app

Everyone told us to build an app. We refused — on purpose. Here's the math.

An app is invisible to Google. Every user has to be bought: app-install campaigns, social ads, store featuring. That's why e-commerce companies burn millions of dollars a year on Instagram and TikTok ads — their catalog lives in a black box that search engines can't see.

A fast full website is the opposite: all 389,000 product pages are indexed, every one of them is a free landing page. A wholesale buyer googles an obscure toy at 2 a.m. — and lands on our product card, in his currency, with a WhatsApp button. Zero ad spend on that acquisition. Multiply by the catalog size: the site IS the marketing department. The cheapest and fastest customer acquisition channel we know is a product page that loads in under a second and ranks.

But — and this was the hard requirement — the mobile web experience had to feel like an app, not like a compromise: sub-second paint (93/100 mobile on the FULL site), camera-based photo search right from the toolbar, prices in your local currency auto-detected, one-tap WhatsApp/Telegram to close the deal. No 200 MB download, no App Store gatekeeping, no "please sign up to view". One tap from a Google result or a shared link — straight into the catalog.

Google ranks Core Web Vitals. So for us speed isn't a vanity metric — it's the acquisition engine. That's also why the m-dot trick above is self-defeating: you show Google a fast shell, but the pages that could actually rank and sell live on the slow "real" site.

Boring architecture, fast results

Front: Astro SSR on Cloudflare Workers. Vanilla JS on the client. No React on the storefront: a product card is an HTML string from a template, not a hydrated component.
Back: Python/FastAPI + Postgres + Redis.
CDN: Cloudflare.

Nothing heroic. The speed came from discipline around three things: caching, the critical render path, and the database.

The forever-warm site: nobody ever waits for a render

Classic SSR pain: while the page builds on the server, the user stares at a blank screen. Classic cache pain: once a day it expires and some unlucky visitor eats a cold render.

We killed both with one construct — SWR (stale-while-revalidate) in the edge middleware:

Request comes in → serve the cached copy INSTANTLY, even if it's stale.
In the background (waitUntil), rebuild the page and store the fresh one.
s-maxage=86400 + Tiered Cache + Cache Reserve — the copy lives a day, regional PoPs pull from the upper tier, the reserve keeps a central copy.

Result: the phrase "cold start" is dead. FCP is a stable 1.4s in every run, from anywhere. We verify with external monitors in 7 regions (London, Sydney, Warsaw, Dallas, Amsterdam, Tokyo, Mumbai) — which double as free uptime monitoring and cache warmers.

Personalization vs. caching: the dilemma everyone solves wrong

A marketplace must show tenge in Almaty, som in Tashkent, yuan in China, dollars in Berlin. The usual answer is server-side geo rendering. Congratulations, your cache is dead: one copy per country, most of them cold.

Our answer: fully neutral SSR. One HTML for the whole world → one cache → always warm. On the client:

// the CDN already knows the geo — ask it for free
fetch('/cdn-cgi/trace') → country=KZ → sessionStorage
// prices in HTML are a neutral base; the client multiplies by the local rate

No flash of wrong currency (rates apply before prices paint), repeat visits read the country from sessionStorage instantly. Personalization lives — and so does the cache.

Killing the PSI lottery

The most maddening part: the score bounced — 76, 90, 97, 80 — same page. We identified the culprits by name from Lighthouse reports:

Lottery #1 — CLS. A "recently viewed" strip loaded late and shoved the grid down: CLS 0.098. The fix is boring and bulletproof: reserve the height (min-height + :not(:empty)), zero markup reshuffling. CLS is now 0.001–0.006 in every run.

Lottery #2 — the LCP element. Lighthouse alternated between the headline and the globe video poster — and when the poster travelled the network on a cold PoP, the score tanked. Fix: the mobile poster is inlined into the HTML as a 6 KB data-URI webp — zero network dependency, it paints on the first frame even on an ice-cold PoP. The 4 MB globe video only starts after window.load + idle, so it physically can't compete with the first screen.

HTML diet. 252 KB → 127 KB (41 gzipped): the photo-search modal (50 KB) moved to a separate deferred chunk. (We over-did it once, shipped the header CSS as a blocking file, caught FCP 1.4→1.8, and put the critical CSS back inline. Honesty included.)

Result: mobile 93-93-93-93 and desktop 99 (FCP 0.8s / LCP 0.9s / TBT 0). Honest caveat: 1 run in 5 still catches a 77 — the poster on a rare cold node. We know, we're fixing it, and we're not hiding it: that's the difference between a measurement and marketing.

The database: 389k products, 18 ms sorting

Sorting the catalog by price took 9,663 ms — the price lived in a JSON field of the main table while filters lived in another. The classic:

Denormalize price/moq into the filter table (the one already doing the WHEREs).
A trigger keeps the mirror in sync.
Partial indexes for the storefront's actual queries (idempotent migrations, CONCURRENTLY, zero downtime).

9,663 ms → 18 ms. A giant factory page (36,000 products from one supplier): 2,270 ms → 5 ms.

Search: Russian+English FTS + trigram typo tolerance + vector fallback + an anti-hallucination gate (so "doll" doesn't bring trucks). Hot queries hit a Redis cache of the full response: warm search over 389k products in 6–15 ms. Iron rule: the top-20 before and after any optimization must be identical on a control set — speed bought with relevance is a regression.

A living storefront that doesn't kill the cache

We wanted the homepage to breathe — a new slice of bestsellers every 5 minutes. The naive way (random offset per user) kills the API cache. Ours:

window = floor(now / 5min) % pool   // every user on Earth gets the same window

Everyone sees the same slice → Redis serves it from memory → the storefront is alive at zero cost. (Follow-up rake: the window must respect your anti-bot depth cap, or the block silently starves once in a while. Invariant: window ≤ min(pool, cap).)

Beyond speed: photo search and AI search

Search by photo — on the mobile WEB. Here's the part we're genuinely proud of. Camera search has always been a privilege of the giants' native apps: Alibaba has it in the app, Amazon has it in the app. On the mobile web, among B2B marketplaces, we couldn't find it at anyone. So we shipped it on the site itself: a wholesale buyer at a trade fair in Guangzhou — or standing in a competitor's shop — snaps a picture of a toy, and the platform finds it and its analogs across 389k products from 5,530 factories. No app install, no account wall — one tap from the toolbar. And it costs the speed budget nothing: the camera modal weighs 50 KB and loads as a deferred chunk. The feature exists; LCP never notices. This is the whole thesis in one feature: everything "only an app can do" — done on the web, indexed by Google, one link away.

AI search. "soft toys for toddlers under 3, wholesale" is understood by meaning, not keywords — FTS + vectors + that anti-hallucination gate. Typos are healed by trigrams.

Geo multi-currency (covered above — it coexists with caching) and WhatsApp/Telegram straight from the product card: a B2B deal starts in one tap.

Speed is money (not our numbers — sourced)

Deloitte × Google, "Milliseconds Make Millions" (web.dev case study): a 0.1s mobile speed improvement lifts retail conversions by +8.4% and average order value by +9.2%.
Google's industry benchmarks: going from 1s to 3s load raises bounce probability by 32%; more than half of mobile users abandon slow pages.
The classics: Amazon's 2006 finding that every extra 100 ms costs ~1% of sales; Akamai's retail report: −7% conversions per 100 ms of latency.

Now overlay that on our catalog: warm search in 6–15 ms, sorting in 18 ms, desktop LCP at 0.9s. These aren't sport records — they're the cash register.

The rakes nobody blogs about

Double markup. The backend marked prices up; the frontend marked them up again. The storefront quietly overcharged 15% vs. the admin panel until we reconciled one SKU digit-by-digit across every surface (card/PDP/cart/search, 4 currencies). Lesson: price is an invariant verified by a matrix, not "by eye".
Clobbering shared files. Two devs edit one JS file; the second deploy erases the first one's fix. Twice in one week. New law: every report states "started from version X".
Bump the version or die. Changed a static file's content? Change its query version. Otherwise the cache will faithfully serve the old file while you spend a week "fixing" what's already fixed.
The globe fell asleep forever. The hero video played 8 seconds — then the browser paused it (power saving), and the poster had already faded out: an eternal freeze-frame. Chrome does this more aggressively on older machines. Fix: self-healing (re-play on visibilitychange/focus; after 3 refusals bring the poster back) + a failure telemetry beacon, so we treat real machines with data instead of guesses.
iframe mobile emulation lies. Touch mechanics and coarse pointers don't emulate in an iframe — a "bug" visible only in DevTools may not exist on a real phone. Mobile behavior is verified by a human with a phone, period.

Receipts — permanent Google PSI reports (click and verify)

Our runs (mobile, one-day series): run 1 · run 2 · run 3 · run 4 — the honest floor · run 5 + desktop 99

Competitors (same day, same method): IndiaMART 98 — see the "Results for URL: m.indiamart.com" banner · Made-in-China 86 — same m-dot swap · Alibaba 51 — full www

Who we are: a small team behind *opttoyschina.com*. The scale, in numbers: 389,000 products · 5,530 factories · shipping to 58 countries · prices auto-detected by geo · a copy of the site warm in ~300 datacenters worldwide · uptime watched from 7 regions. No enterprise budget, no VC — just caching discipline, honest measurements, and 389,000 pages that rank. Don't take our word for any of it: paste opttoyschina.com into pagespeed.web.dev right now and run your own audit. Questions, arguments, and your own cases (store, marketplace — whatever hurts) — comments or DMs are open. If there's interest, we'll write up the 6 ms search, deterministic storefront rotation, and video failure telemetry as separate deep dives.

Update (Jul 21): several readers asked if we take on client work. We do now — a limited number of builds under **Prospects Digital: full-site 90+ PageSpeed marketplaces, search that sells (including camera photo search on the mobile web), and speed rescues for existing stores. Same rule as this article — every claim ships with a verifiable Google report. → opttoyschina.com/studio