CDNPerformanceThailand

CDN Configuration for Fast Websites in Thailand

13 May 2026 · by Yunmin Shin

What Is a CDN and Why Does Location Matter for Thailand?

A Content Delivery Network (CDN) is a distributed network of servers that caches your site's static files — images, CSS, JavaScript, fonts — and serves them from whichever server is physically closest to the visitor.

Without one, a Thai user visiting a site hosted on a US East Coast server waits for data to travel roughly 15,000 kilometers and back, adding 150–300ms of latency before any computation even starts. With a CDN that has a Point of Presence (PoP) in Bangkok or Singapore, that same trip drops to a few hundred kilometers — often under 20ms.

This isn't a marginal optimization for a Bangkok business. Picture someone standing outside a clinic they found on Google Maps, pulling up the site on 4G to check today's promotion or book a slot before they walk in. If the page takes three seconds to become interactive, they're inside before it finishes loading, or they've bounced to a competitor's listing instead. A CDN PoP close to Bangkok is the difference between those two outcomes for a meaningful share of visitors.

What CDN Should Thai Websites Use?

Cloudflare is the most widely used CDN globally and has a PoP in Bangkok itself. Its free plan already covers most small and medium Bangkok business sites — unlimited bandwidth, DDoS protection, SSL, and basic caching included. For a clinic or restaurant site, this is usually the right default: Thai users get single-digit-millisecond latency to cached content, and there's no billing surprise as traffic grows.

Vercel Edge Network is built into every Vercel deployment, with a Singapore edge node in range. If a Next.js site is already on Vercel, both static assets and cached pages are served from the edge automatically, with no separate CDN to configure. This is the setup Bluewich runs for most client and self-operated sites, since it removes an entire layer of infrastructure to maintain.

AWS CloudFront with a Singapore origin makes sense for larger applications already living in AWS — an e-commerce platform with heavy backend processing, for example. It offers more configuration surface than Cloudflare but requires more setup and ongoing tuning, which is rarely worth it for a typical clinic, restaurant, or real estate listing site.

How Do You Configure Cache Headers Correctly?

The CDN can only cache what your server tells it to. Set Cache-Control deliberately, not by accident:

# Static assets (images, fonts, JS, CSS with hashed filenames)
Cache-Control: public, max-age=31536000, immutable

# HTML pages (revalidate frequently — content changes)
Cache-Control: public, max-age=0, must-revalidate

# API responses (do not cache unless intentional)
Cache-Control: private, no-store

Next.js sets sensible defaults for static assets automatically. For pages and API routes, be explicit: export const revalidate = 3600 for a treatment price list that changes occasionally, or export const dynamic = "force-static" for a fully static page like an "about the clinic" or location page that almost never changes. A booking availability endpoint, by contrast, should almost always be no-store — serving a stale "available" slot that was just booked by someone else is a worse experience than a slightly slower response.

How Do You Purge the Cache?

When a clinic updates a treatment price, a restaurant changes its menu, or a promotion goes live, the CDN needs to serve the new version immediately rather than the cached one for the next several hours.

Cloudflare exposes a cache purge API — trigger it from your revalidation workflow when content changes:

curl -X POST "https://api.cloudflare.com/client/v4/zones/{zone_id}/purge_cache" \
  -H "Authorization: Bearer {token}" \
  --data '{"files":["https://yoursite.com/treatments/filler-package"]}'

On Vercel, revalidatePath and revalidateTag handle this for Next.js's own caching layer without a separate purge call — call revalidatePath("/treatments/filler-package") from the Server Action that updates the price, and the next visitor gets fresh content immediately.

What About Images Specifically?

Images are typically 60–80% of a page's total byte weight, and clinic and restaurant sites are especially image-heavy — before/after galleries, treatment photos, menu shots, interior photos for a "near me" search result. Beyond CDN delivery, optimize before the CDN ever sees the file:

Convert to WebP or AVIF (30–50% smaller than JPEG at comparable quality)
Serve images at the dimensions they're actually displayed at, not the original upload size — a before/after photo shot on a phone at 4000px wide has no business being served full-size in a 400px-wide gallery thumbnail
Lazy-load anything off-screen, particularly below-the-fold gallery images

Next.js's <Image> component handles all of this automatically when paired with Vercel's or Cloudflare's image transformation — resizing, format conversion, and lazy loading with no manual pipeline to maintain.

Why Does This Matter More on Thai Mobile Networks?

Over 70% of Thai web traffic is mobile, much of it on mid-range Android devices over 4G rather than flagship phones on fiber-backed Wi-Fi. That combination — a slower device parsing the page and a less reliable connection fetching it — compounds every millisecond a CDN or a bloated image saves or costs. A site that feels merely adequate on a developer's laptop and office Wi-Fi can feel genuinely slow to the actual customer standing on a Bangkok street checking Google Maps for the nearest clinic. Testing on a real mid-range device over mobile data, not just Chrome DevTools' network throttling, is the only way to know whether the CDN and caching setup is actually working for the people who matter.