React Server Components, Explained for Bangkok Business Owners
22 April 2026 · by Yunmin Shin
What Are React Server Components?
React Server Components (RSC) are components that run only on the server — never in the browser. They can query a database directly, read files, or call internal APIs, then send the resulting HTML to the user's browser. No JavaScript for that component ships to the client at all.
This is a fundamental shift from how React worked for its first decade. Previously, every React component ran in the browser, meaning the browser had to download and execute the code for the entire page before anything became interactive. Now, the parts of your page that are just "show data" — a clinic's list of treatments, a restaurant's menu, a real estate listing's details — can be rendered entirely on the server and sent down as plain HTML.
Why Does This Matter for a Bangkok Business Specifically?
Think of your website as a restaurant kitchen. Client components are the dishes handed to every table — your customer's browser has to receive, unpack, and "cook" them before anything is usable. Server components are the kitchen itself: customers never see it, they just get the finished plate. The less your customer's phone has to do to produce the finished page, the faster it arrives.
This matters for three concrete reasons, all sharper in the Thai market than in a typical Western market:
-
Faster load times on the hardware people actually use. Thai mobile traffic skews heavily toward mid-range Android devices on 4G, sometimes over a LINE LIFF in-app browser with a more constrained JavaScript engine than a full Chrome tab. Every kilobyte of JavaScript a server component avoids sending is a kilobyte that device doesn't have to parse and execute before a patient can tap "Book Now."
-
Better indexing on Google.co.th. Search engines see fully rendered HTML immediately instead of waiting for client-side JavaScript to run before content appears. For a clinic or restaurant competing for "near me" searches and Google Maps visibility, that's a direct advantage — Google needs to actually see your treatment list or menu, not a loading skeleton, to rank you for it.
-
Simpler, more secure data access. A server component can query Postgres or Supabase directly — pulling a clinic's live appointment availability, for instance — without exposing a public API endpoint that a competitor's scraper (or a bad actor) could hit directly. Fewer endpoints means a smaller attack surface.
What's the Difference Between Server and Client Components?
Server components are the default in the Next.js App Router. They cannot use browser APIs, React state (useState), or effects (useEffect) — they're pure render functions that produce HTML from data.
Client components are marked with "use client" at the top of the file. They run in the browser and handle interactivity: a booking form, a photo gallery lightbox, a LINE contact button, a filter dropdown on a real estate listing page. Anything the user touches needs to be a client component somewhere in the tree.
// app/treatments/page.tsx — server component (default, no "use client")
export default async function TreatmentsPage() {
const treatments = await db.query.treatments.findMany();
return (
<div>
{treatments.map((t) => (
<TreatmentCard key={t.id} treatment={t} />
))}
</div>
);
}
// components/BookingForm.tsx — client component, needs interactivity
"use client";
export function BookingForm({ treatmentId }: { treatmentId: string }) {
const [selectedTime, setSelectedTime] = useState<string | null>(null);
// ...form logic
}
A well-structured Next.js app uses server components for the majority of a page — fetching and displaying the treatment list, the menu, the listing details — and drops in client components only where interactivity is actually required, like the booking form itself. This pattern minimizes the JavaScript bundle while keeping the page fully functional.
What About Bilingual Thai/English Content?
Most clinic, restaurant, and real estate sites we build serve both Thai and English (sometimes Korean or Chinese) speaking customers. Server components are a natural fit for this: the server already knows the user's locale (from the URL path, a cookie, or Accept-Language), so it can render the correct language's HTML directly — no client-side flash of the wrong language while a translation library loads, and no extra JavaScript bundle for the translation logic shipped to every visitor.
How Do Server Components Handle Loading States?
A server component still has to wait on its data — the treatment list still has to come back from Postgres before it can render. Wrap slow-loading sections in <Suspense> with a fallback so the rest of the page (navigation, hero content, the LINE contact button) appears instantly while the slower part streams in behind it:
export default function TreatmentsPage() {
return (
<div>
<ClinicHeader />
<Suspense fallback={<TreatmentListSkeleton />}>
<TreatmentList />
</Suspense>
</div>
);
}
This matters more on a Bangkok mobile connection than it does on a fast wifi network in a demo. Streaming means a patient on 4G sees a usable page shell within a second, with the treatment list filling in a moment later, rather than a blank white screen until every query on the page resolves. Use a skeleton that matches the real layout — a few grey placeholder cards, not a spinner — so the page doesn't visibly "jump" once the real content streams in.
How Does This Affect Your Website Project?
If you're commissioning a new site or web app, insist on a Next.js build that uses the App Router with server components as the default, not an afterthought bolted onto an old pages-router or client-rendered SPA architecture. You can verify the difference yourself with Google PageSpeed Insights — a server-components-first site consistently scores higher on both load speed and SEO-relevant metrics than an equivalent client-rendered build.
At Bluewich, this is the default architecture on every project, and it's also what runs the clinic, restaurant, and real estate sites we operate ourselves — we're not recommending an approach we haven't already put into production and watched hold up under real Bangkok mobile traffic.
Ready to Build Something Fast?
Get a free quote. We reply within 24 hours.
Ready to build something fast and scalable?
Get a free project quote. We reply within 24 hours.
Get a Free Quote →