Launching a Personal Website for a Global Audience: GitHub Pages, Cloudflare CDN, and DNS Strategy

Most personal websites are built for the wrong audience. Not the wrong people — the wrong geography. If your site is served from a single origin in one region, visitors on other continents pay for it in latency, and Google notices.

My site, wuhuajin.com, gets visitors from North America, Europe, and Asia. Getting it to load fast everywhere took three coordinated decisions: hosting on GitHub Pages, putting Cloudflare in front of it, and running a dual DNS setup across two providers. This article walks through each layer and the exact pitfalls I hit along the way.

Layer 1: Hosting on GitHub Pages

GitHub Pages is the most underrated free hosting tier for static sites. It gives you:

• Free HTTPS with automatic certificate renewal
• Unlimited bandwidth within fair-use limits
• A global CDN (Fastly) as the underlying edge
• Git-based deploys — pushing to main is your deployment

For a static site that builds locally (or in CI), it's genuinely production-grade. Two caveats cost me real debugging time:

The .nojekyll file. GitHub Pages runs Jekyll over your repository by default. Jekyll ignores files and folders that start with an underscore, and it silently mangles Markdown files without front matter. Until I added an empty .nojekyll file at the repo root, some article pages 404'd mysteriously after every deploy. The fix is one file and it's non-negotiable.

Path consistency. If your build generates URLs with an /html/ segment, every internal link must use it consistently. A mismatch between the feed's URLs and the actual file layout produces intermittent 404s that are painful to chase. I solved it by making the build script the single source of truth for both feed data and file output.

Layer 2: Cloudflare CDN in Front

GitHub Pages' edge is good, but I wanted more control: custom caching rules, analytics without third-party scripts, and protection for the custom domain. Cloudflare sits in front of the site and handles all of it.

The setup is deliberately simple — a free Cloudflare plan with the DNS proxied (orange-cloud). The wins:

• Caching: static assets are served from Cloudflare's edge cache, reducing origin load to nearly zero
• TTL control: long cache lifetimes for images and CSS, short ones for HTML so content updates propagate quickly
• Analytics: Cloudflare Web Analytics runs without cookies and without slowing the page — genuinely useful, privacy-friendly, and GDPR-compliant by default

One lesson: when you change a build or add new pages, don't fight the cache. Configure a cache-busting strategy (versioned filenames or a purge step) instead of setting everything to no-cache and losing the whole benefit.

Layer 3: Dual DNS — Alibaba Cloud + Cloudflare

This is the part people rarely write about: I run dual DNS resolution across Alibaba Cloud and Cloudflare.

Why two providers? Redundancy and control. If one DNS provider has an outage, the other still resolves the domain. For a site that monetizes via ads and subscriptions, a DNS failure is lost revenue, not just an inconvenience.

The practical setup:

• Alibaba Cloud is the registrar and the primary DNS authority (my domain's home region)
• Cloudflare is configured as the CDN and handles proxied traffic for www and the apex domain
• The two are coordinated so that DNS resolution and CDN proxying don't fight each other

The trade-off is operational complexity: you now have two dashboards to keep in sync, and a misconfiguration in either breaks resolution. It's only worth it once your site has real traffic — for a brand-new site, one competent DNS provider is the right call.

Analytics: Three Tools, Three Jobs

I run three analytics tools, and each has a distinct job:

Three tools is more than most sites need, but the overlap is intentional: each answers a different question, and they cross-check each other. Clarity in particular has caught usability problems (dead clicks, rage clicks, layout confusion) that no number of pageview charts would ever reveal.

For a privacy-sensitive touch, the site also runs a self-hosted visit counter at stats.wuhuajin.com — a Cloudflare Worker with a D1 database that increments on each page load. It's a small detail, but it means the footer view counts don't depend on any third-party analytics being enabled.

Compliance: GDPR for a Global Audience

If your visitors include the EU, compliance is part of the deployment, not an afterthought. My setup:

• Cookie consent banner (GDPR/CCPA) — appears before any non-essential cookies load
• Google Consent Mode v2 — analytics and ads respect the visitor's consent choice at the platform level
• Privacy policy, terms, about, and contact pages — the standard legal set, actually linked from the footer
• No cross-site tracking cookies beyond consented analytics

The practical effect: the site never drops a tracking cookie on a visitor who hasn't consented, and the consent state is respected by Google's ad and analytics stack. This isn't just legal hygiene — it's also a trust signal that shows up in how seriously readers and advertisers take the site.

The Launch Checklist I Wish I'd Had

Before you point your domain at a global audience, verify all of this in one pass:

• [ ] Empty .nojekyll at repo root (if using GitHub Pages)
• [ ] robots.txt and auto-generated sitemap.xml present and correct
• [ ] Custom 404 page with a real h1 and navigation
• [ ] HTTPS enforced end-to-end (origin + CDN + DNS)
• [ ] Cache-busting strategy for CSS/JS/assets
• [ ] Cookie consent + Consent Mode v2 wired up before any analytics/ads load
• [ ] Privacy policy and terms live and linked
• [ ] Analytics double-check: you can see traffic from at least two continents within a day of launching

The Bottom Line

A fast, compliant, global personal site is achievable with free or near-free infrastructure: GitHub Pages for hosting, Cloudflare for the CDN edge, dual DNS for resilience, and a consent-first analytics stack. None of it requires a server you manage yourself.

The hidden cost is coordination — every layer interacts with the others, and the debugging time goes into the seams: .nojekyll, path consistency, cache invalidation, DNS sync. Get those right once, and the whole stack runs for years with almost no maintenance.

This article covers the real deployment architecture of wuhuajin.com — GitHub Pages, Cloudflare CDN, dual DNS, and a consent-first analytics stack. If you're launching a site for a global audience, I'm happy to answer questions.

Originally published on wuhuajin.com.