Login

Next.js và các cách render: CSR, SSR, SSG, ISR khác nhau thế nào?

  • author-image

    Nguyễn Đình Cường

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

Khi mới học Next.js, bạn sẽ gặp một chuỗi từ viết tắt: CSR, SSR, SSG, ISR. Chúng đều trả lời cùng một câu hỏi: trang HTML được tạo ra ở đâu và vào lúc nào. Chọn đúng cách ảnh hưởng đến tốc độ tải, khả năng được tìm thấy trên công cụ tìm kiếm và chi phí vận hành.

CSR: render ở trình duyệt

Client-Side Rendering là cách ứng dụng React thuần chạy: máy chủ gửi một file HTML gần như trống cùng gói JavaScript, trình duyệt chạy JavaScript rồi mới vẽ nội dung. Ưu điểm là tương tác sau đó mượt, máy chủ đơn giản. Nhược điểm là lúc đầu người dùng có thể thấy trang trống một lúc, và nội dung không có sẵn trong HTML ban đầu nên bất lợi cho SEO và chia sẻ liên kết (dù các công cụ tìm kiếm hiện đại có thể chạy JavaScript, việc này không phải lúc nào cũng đáng tin).

SSR: render trên máy chủ mỗi yêu cầu

Server-Side Rendering tạo HTML đầy đủ trên máy chủ cho mỗi yêu cầu. Người dùng nhận trang có nội dung ngay, sau đó JavaScript "tiếp quản" (hydration) để trang tương tác được.

  • Hợp với: nội dung thay đổi theo người dùng hoặc theo từng yêu cầu, như bảng điều khiển cá nhân, kết quả tìm kiếm.
  • Đánh đổi: mỗi yêu cầu tốn tài nguyên máy chủ, thời gian phản hồi đầu tiên phụ thuộc vào tốc độ lấy dữ liệu.

SSG: dựng sẵn lúc build

Static Site Generation tạo trước các file HTML tại thời điểm build, sau đó phục vụ như file tĩnh, có thể đặt lên CDN. Cực nhanh và rẻ.

  • Hợp với: blog, tài liệu, trang giới thiệu, trang bán hàng ít thay đổi.
  • Đánh đổi: muốn cập nhật nội dung phải build lại, và khó với dữ liệu thay đổi liên tục hoặc cá nhân hóa.

ISR: tĩnh nhưng tự làm mới

Incremental Static Regeneration là lai giữa hai kiểu trên: trang được dựng tĩnh, nhưng sau một khoảng thời gian bạn quy định (hoặc khi bạn kích hoạt thủ công) nó được dựng lại ở nền. Người dùng luôn nhận trang tĩnh nhanh, còn nội dung vẫn được làm mới định kỳ. Cách này thích hợp cho trang sản phẩm hoặc bài viết có cập nhật thỉnh thoảng.

Trong App Router, mọi thứ trông thế nào?

Next.js hiện đại dùng App Router, nơi các component mặc định là Server Component, và bạn điều khiển cách render thông qua cách lấy dữ liệu và các tùy chọn đoạn (route segment). Đây là minh họa mang tính khái niệm, bạn cần đối chiếu tài liệu phiên bản bạn dùng vì các mặc định có thể thay đổi giữa các phiên bản:

// app/bai-viet/page.js
export const revalidate = 3600;   // làm mới tối đa mỗi giờ (kiểu ISR)

export default async function Page() {
  const res = await fetch('https://api.example.com/posts');
  const bai = await res.json();
  return (
    <ul>
      {bai.map(b => <li key={b.id}>{b.tieuDe}</li>)}
    </ul>
  );
}

Component này chạy trên máy chủ, có thể await trực tiếp dữ liệu, và kết quả gửi về trình duyệt dưới dạng HTML. Nếu cần tương tác như state hay sự kiện, bạn tách phần đó ra component riêng khai báo 'use client' ở đầu file.

Bảng so sánh nhanh

CáchHTML tạo lúc nàoTốc độNội dung động
CSRTrong trình duyệtTải đầu chậm hơnRất tốt
SSRMỗi yêu cầuPhụ thuộc máy chủRất tốt
SSGLúc buildRất nhanhHạn chế
ISRLúc build, làm mới định kỳRất nhanhKhá tốt

Cách chọn nhanh

  1. Nội dung công khai, ít đổi, cần SEO tốt: SSG.
  2. Nội dung công khai nhưng cập nhật theo giờ hoặc ngày: ISR.
  3. Nội dung theo từng người dùng hoặc thời gian thực: SSR, hoặc CSR cho phần tương tác phía sau đăng nhập.
  4. Bảng điều khiển nội bộ không cần SEO: CSR là đủ.

Trong thực tế, một ứng dụng Next.js thường kết hợp nhiều cách: trang chủ tĩnh, trang sản phẩm ISR, giỏ hàng CSR.

Những lưu ý khi triển khai

Dù chọn cách render nào, có vài điểm thực tế nên nhớ. Thứ nhất, nội dung ở dạng HTML ngay từ đầu giúp trình thu thập của công cụ tìm kiếm và trình xem trước liên kết trên mạng xã hội đọc dễ dàng, đây là lý do chính nhiều trang chọn SSR hoặc SSG. Thứ hai, hydration cần HTML từ máy chủ và kết quả render ban đầu ở trình duyệt khớp nhau, nếu bạn dùng giá trị như thời gian hiện tại hoặc số ngẫu nhiên trong lúc render, có thể gặp cảnh báo hydration mismatch. Thứ ba, hãy đo đạc thực tế bằng công cụ như Lighthouse thay vì đoán, vì chênh lệch tốc độ phụ thuộc rất nhiều vào dữ liệu và hạ tầng của bạn.

Kết luận

Đừng học thuộc từ viết tắt, hãy nhớ câu hỏi "HTML được tạo khi nào, ở đâu?". Với mỗi trang, trả lời câu hỏi đó rồi chọn cách phù hợp giữa tốc độ, độ tươi của dữ liệu và chi phí.

Nếu muốn thực hành Next.js từ đầu đến khi triển khai, bạn có thể xem các khóa học trên codebem.com.

author_photo
Nguyễn Đình Cường

0 comment