Login

Xu hướng render web: SSR, SSG, Islands và Server Components

  • author-image

    Nguyễn Đình Cường

  • blog-tag
  • blog-comment 0 comment
  • created-date 09 Nov, 2026
blog-thumbnail

Trước đây câu hỏi render web khá đơn giản: server trả HTML hoặc trình duyệt tự dựng bằng JavaScript. Giờ đây có cả một thực đơn lựa chọn, từ SSR, SSG đến Islands và Server Components. Hiểu bức tranh chung giúp bạn chọn đúng cách cho từng trang thay vì chạy theo thuật ngữ.

Bốn cách tiếp cận cơ bản

  • CSR (Client-Side Rendering): server gửi trang gần như trống cùng JavaScript, trình duyệt dựng nội dung. Tương tác tốt nhưng lần tải đầu có thể chậm, và SEO cần cẩn thận.
  • SSR (Server-Side Rendering): server dựng HTML mỗi lần có yêu cầu. Nội dung hiện sớm, tốt cho SEO, nhưng tốn tài nguyên máy chủ.
  • SSG (Static Site Generation): HTML được dựng sẵn lúc build. Cực nhanh và rẻ khi phân phối qua CDN, hợp nội dung ít thay đổi.
  • ISR/revalidation: dựng lại trang tĩnh định kỳ hoặc theo yêu cầu, kết hợp lợi thế của tĩnh và động.

Vấn đề của hydration

Với SSR truyền thống, sau khi nhận HTML, trình duyệt còn phải tải toàn bộ JavaScript và "hydrate", tức gắn lại logic để trang tương tác được. Với trang nhiều nội dung tĩnh, đây là sự lãng phí lớn: bạn tải mã cho cả những phần không bao giờ thay đổi.

Islands architecture: hòn đảo tương tác

Ý tưởng: trang chủ yếu là HTML tĩnh, chỉ những "hòn đảo" cần tương tác (nút thích, giỏ hàng, bộ lọc) mới được gửi JavaScript. Phần còn lại không cần mã phía trình duyệt. Kết quả là ít JavaScript hơn, tải nhanh hơn, phù hợp blog, trang tài liệu, trang marketing.

<!-- Minh họa khái niệm -->
<article>
  <h1>Bài viết</h1>
  <p>Nội dung tĩnh, không cần JavaScript.</p>

  <!-- Chỉ phần này cần tương tác -->
  <nut-thich client:visible></nut-thich>
</article>

Cú pháp như client:visible mô phỏng cách một số framework đánh dấu thành phần chỉ nạp khi hiện ra trên màn hình, tên cụ thể tùy framework.

Server Components

Server Components cho phép một số thành phần giao diện chỉ chạy trên máy chủ: chúng truy cập dữ liệu trực tiếp, kết quả gửi về dưới dạng đã dựng, và mã của chúng không đi vào gói JavaScript phía người dùng. Những phần cần tương tác vẫn là thành phần client. Cách chia này giảm kích thước gói và đơn giản hóa việc lấy dữ liệu.

// Minh họa: thành phần chạy trên máy chủ, lấy dữ liệu trực tiếp
async function DanhSachBaiViet() {
  const baiViet = await layBaiVietTuDB();
  return (
    <ul>
      {baiViet.map((b) => (
        <li key={b.id}>{b.tieuDe}</li>
      ))}
    </ul>
  );
}

Cách chọn theo loại trang

Loại trangGợi ý
Blog, tài liệu, trang giới thiệuSSG hoặc Islands
Trang sản phẩm thay đổi vừa phảiSSG kèm làm mới định kỳ
Trang cá nhân hóa, dữ liệu theo người dùngSSR hoặc Server Components
Ứng dụng nội bộ nhiều tương tácCSR là đủ

Các tiêu chí cần cân nhắc

  1. Mức độ cần SEO và tốc độ hiển thị đầu tiên.
  2. Tần suất thay đổi dữ liệu và nhu cầu cá nhân hóa.
  3. Chi phí và độ phức tạp vận hành máy chủ.
  4. Kỹ năng của đội ngũ và độ trưởng thành của framework.

Hãy đo bằng các chỉ số như thời gian hiển thị nội dung chính và độ trễ tương tác thay vì cảm tính.

Câu hỏi thường gặp

Có phải dùng Server Components mới là hiện đại?

Không. Chọn theo nhu cầu: trang tĩnh dùng SSG vẫn rất tốt, ứng dụng nội bộ dùng CSR vẫn hoàn toàn ổn.

Làm sao biết mình render đúng cách?

Đo các chỉ số như thời gian hiển thị nội dung chính, độ trễ tương tác và kích thước JavaScript bằng công cụ như Lighthouse, rồi so sánh các phương án.

Kết luận

Xu hướng chung là gửi ít JavaScript hơn và render đúng chỗ cho đúng nội dung. Bạn không cần dùng mọi kỹ thuật, chỉ cần hiểu chúng để chọn cách đơn giản nhất đáp ứng nhu cầu của từng trang.

Nếu muốn học web hiện đại từ HTML, CSS đến React và Next.js, mời bạn xem các khóa học tại codebem.com.

author_photo
Nguyễn Đình Cường

0 comment