What tech stack was used for this project?

React 18 with Vite for the build tooling, Puppeteer for static prerendering, Tailwind CSS for styling, and a hand-rolled seeded random number generator for the deterministic daily numbers feature. No backend, database, or Node server runs in production -- the output is static HTML/CSS/JS served through Cloudflare on an HK VPS.

Why Vite instead of Next.js for this project?

The site has no logins, no per-request data, and nothing that changes between one visitor and the next on a given day. Next.js earns its keep when you need SSR, API routes, or a Node runtime. Here that would have added server complexity for no benefit, so we used Vite's static build plus Puppeteer prerendering to get the same SEO-friendly HTML without running a server process.

How did you keep PageSpeed scores high with heavy Chinese fonts?

By subsetting Noto Sans SC down to the 6,000 most common characters (roughly 8MB to 2MB), using font-display: swap so the page never blocks on the font, preloading only the Regular weight, and self-hosting the files behind Cloudflare instead of relying on Google Fonts, which is blocked in mainland China. Everything besides the font stayed under 200KB combined.

Can KayFreyTech build a similar bilingual or China-targeting site for my business?

Yes. We handle IDN/Punycode domains, Simplified Chinese typography and font optimization, dual Google + Baidu SEO setup, and Puppeteer-based static prerendering as a standard part of our stack. [Get a free quote](https://kayfreytech.xyz/get-quote/) and tell us about your target market.

How long did this project take from brief to launch?

The 37-page site -- including the design system, font optimization, deterministic number generator, and Baidu-specific SEO setup -- was built and launched in a focused multi-week sprint. Most of that time went into font/performance tuning and the two rounds of design iteration after the first version tested poorly with real users, not into raw page count.

Building a Bilingual Chinese Lottery Site with React & Vite

When we were asked to build a Chinese lottery reference site at a Punycode domain (xn--jor23ybuq47er4m.com, which displays as a Chinese character domain in browsers), we knew this would not be a typical React project. The brief covered a bilingual audience, a design language with strong cultural expectations, and two search engines to satisfy instead of one.

Here is how we tackled the unique challenges of building a lottery reference platform targeting the Chinese-speaking market.

Why React and Vite Instead of Next.js

The site has no user accounts, no per-request data, and no server-side logic beyond generating a deterministic number from a date. That ruled out Next.js from the start -- we did not need SSR, API routes, or a Node runtime sitting on the server just to serve HTML that never changes between requests.

**Vite's dev server** starts in under a second and reloads instantly on save, which matters when you are iterating on 37 pages of content and tweaking a red-gold design system dozens of times a day.

**Static output**: `vite build` produces plain HTML/CSS/JS that we prerender with Puppeteer and drop straight onto an Nginx root. No Node process to keep alive, no cold starts, no server bill beyond the VPS itself.

**Smaller framework footprint**: React + Vite without a meta-framework kept our shipped JS bundle small, which matters more than usual here because a large share of visitors are on mobile connections in mainland China where Google's CDN edges are not reachable.

**Full control over prerendering**: Puppeteer prerendering let us decide exactly what HTML search engines see, which became important once we started tuning specifically for Baidu (see below).

None of this means Next.js is wrong for other projects -- for a site with logins, checkout flows, or live data, we would reach for it. For a static reference site read by two very different search engines, a lighter stack won.

The IDN Domain Challenge

International Domain Names (IDN) use Punycode encoding to represent non-ASCII characters in DNS. Our domain contains Chinese characters, which means:

The canonical URL in sitemap.xml must use the Punycode form (xn--jor23ybuq47er4m.com).

Internal links can use either form, but we standardized on Punycode for consistency.

Some SEO tools do not handle IDN domains well, so we had to verify indexing manually via Google Search Console and Baidu Webmaster Tools.

SSL certificates work fine with IDN domains through Cloudflare, which handles the encoding transparently.

Noto Sans SC Font Optimization

Chinese fonts are massive. Noto Sans SC (Simplified Chinese) is over 8MB for all weights. Loading this naively would destroy PageSpeed scores. Our optimization strategy:

1. Subset the font

We only include the most common 6,000 characters plus our specific lottery terminology. This reduces the font file from 8MB to about 2MB.

2. Use font-display: swap

The page renders immediately with system fonts, then swaps in Noto Sans SC once loaded. Users see content instantly with a brief font flash.

3. Preload the primary weight

We preload the Regular (400) weight in the HTML head and lazy-load Bold (700) only when needed. Most lottery content uses regular weight.

4. Self-host via Google Fonts CSS

Instead of loading from Google Fonts CDN (which is blocked in mainland China), we self-host the font files on our server and proxy through Cloudflare.

Red-Gold Chinese Design System

Lottery sites in the Chinese market follow strong design conventions. Red represents luck and prosperity. Gold represents wealth. We built a design system around these cultural expectations:

**Primary color**: Chinese red (#DC2626) with gold (#F59E0B) accents.

**Background**: Deep red gradients transitioning to dark backgrounds for readability.

**Typography**: Noto Sans SC with generous line-height (1.8) for Chinese character readability.

**Icons**: Chinese cultural motifs (dragons, coins, lanterns) instead of Western lottery imagery.

**Number display**: Large, bold lottery numbers in gold on red backgrounds, matching the visual language users expect from Chinese lottery platforms.

Deterministic Number Generator

The site generates daily lucky numbers for various lottery games. These numbers must be deterministic -- the same date always produces the same numbers -- so that users see consistent results regardless of when they load the page or which server (if we ever scale to multiple) handles the request.

We implemented a seeded random number generator using the current date as the seed. The algorithm combines a simple hash function with a linear congruential generator:

Seed = year * 10000 + month * 100 + day.

Each lottery game uses a different offset to produce unique numbers.

The range is constrained to match each game's valid number pool (e.g., 1-49 for Mark Six, 1-35 for Shuang Se Qiu).

This approach means no backend is needed for number generation. The entire site is static and can be pre-rendered.

Working Without a Backend

The no-backend decision shaped everything downstream, and it came with real trade-offs we had to weigh with the client upfront:

**Upside**: zero server maintenance, no database to back up, no API to secure, and hosting cost limited to a single small VPS behind Cloudflare.

**Upside**: the deterministic generator means the "daily numbers" feature works identically whether the page was prerendered at midnight or served from cache six hours later -- there is no drift between what Puppeteer captured and what a live visitor sees.

**Trade-off**: if the client ever wants real user accounts, saved preferences, or a comments section, that is a separate build, not an incremental feature. We were upfront that this architecture is a ceiling as much as a foundation.

**Trade-off**: content updates (new articles, zodiac copy) require a rebuild and redeploy rather than a CMS save button. For a site updated a few times a week, that is an acceptable cost; for a newsroom, it would not be.

Baidu SEO Considerations

Ranking on Baidu requires different strategies than Google. Key differences we addressed:

**Meta keywords tag**: Still used by Baidu, unlike Google. We include relevant Chinese keywords on every page.

**Baidu Webmaster Tools**: Submitted sitemap and verified ownership separately from Google Search Console.

**Content freshness**: Baidu heavily favors fresh content. We update daily lucky numbers and add new articles regularly.

**Page speed on Chinese networks**: We host on an HK VPS with good connectivity to mainland China, plus Cloudflare for global CDN.

**Simplified Chinese only**: No Traditional Chinese variant. Mainland users expect Simplified, and mixing variants hurts ranking.

Performance Engineering and Core Web Vitals

Because the audience skews mobile and often on slower connections, we treated PageSpeed as a hard requirement, not a nice-to-have:

**Image budget**: every illustration and icon is served as WebP, sized for its actual display dimensions, with lazy-loading below the fold.

**JS bundle**: kept lean by avoiding a meta-framework and by code-splitting per-page routes so the homepage does not pay for zodiac-page logic it does not use.

**Font is the real bottleneck**: as noted above, everything else on the page (images, JS, CSS) stayed under 200KB combined -- the Chinese font was the only asset large enough to move the Largest Contentful Paint metric on its own.

**Prerendered HTML**: because every page ships as static HTML with the Puppeteer prerender step, there is no client-side render blocking before content appears -- the browser paints real markup on first byte, not a loading spinner waiting on JavaScript.

**Target**: Performance, Accessibility, Best Practices and SEO scores in the 90s across both mobile and desktop Lighthouse runs, checked after every deploy rather than assumed.

Site Architecture: 37 Pages

The site covers multiple lottery games and fortune telling methods:

**8 lottery game pages**: Shuang Se Qiu, Da Le Tou, Qi Xing Cai, Pai Lie 3/5, 3D, Kuai Le 8, Mark Six.

**12 zodiac pages**: Daily horoscope and lucky numbers for each Chinese zodiac sign.

**8 articles**: Educational content about lottery strategies and fortune telling.

**4 fortune telling method pages**: Ba Zi, Zi Wei Dou Shu, Mei Hua Yi Shu, Liu Yao.

**Core pages**: Homepage, about, disclaimer, privacy policy, sitemap.

Each page is pre-rendered via Puppeteer for SEO, producing fully static HTML that both Google and Baidu can index without executing JavaScript.

Lessons Learned

1. Test on Chinese browsers

QQ Browser and UC Browser handle CSS differently from Chrome. We tested on both and found minor layout issues with flexbox gap.

2. Font loading is the biggest performance bottleneck

Everything else (images, JS, CSS) was under 200KB. The Chinese font dominated load time until we optimized it.

3. Cultural design conventions matter

Our first design iteration used a modern minimalist approach. User feedback was clear: it did not feel like a legitimate lottery site. The red-gold redesign immediately improved engagement metrics.

4. Verify indexing manually on IDN domains

Standard rank trackers and some SEO dashboards mishandle Punycode domains, showing zero data even after both Google Search Console and Baidu Webmaster Tools confirmed pages were indexed. We learned to trust the search console data directly rather than third-party tooling for this project.

Conclusion

Building for the Chinese market requires attention to cultural design norms, font optimization, and dual search engine strategy. React and Vite made the development fast and the static-first architecture kept hosting simple, but the real work was in understanding how Baidu, Chinese browsers, and Chinese users differ from the Google-first, Chrome-first assumptions baked into most web tooling.

Need a bilingual or China-facing website built the same way -- static-first, prerendered for SEO, tuned for the search engines your audience actually uses? Get a free quote and we will walk through the architecture that fits your project.