Bạn đang xây website bằng Next.js nhưng không chắc nên dùng SSR, SSG, ISR hay Edge Runtime? Nếu chọn sai, website có thể chậm, cache khó kiểm soát, chi phí server tăng và team debug rất mệt.
Bài này giúp bạn tối ưu Next.js production performance theo cách thực dụng: chọn cách render theo loại trang, dữ liệu động, SEO, TTFB, cache và khả năng vận hành. Mình sẽ không biến mọi thứ thành một công thức cứng, vì Next.js mạnh nhất khi bạn biết phối hợp nhiều chiến lược đúng chỗ.
Tóm tắt nhanh
- SSG hợp trang ít đổi, cần tốc độ và CDN cache tốt.
- SSR hợp dữ liệu cá nhân hóa hoặc cần cập nhật theo request, nhưng phải kiểm soát TTFB và độ trễ backend.
- ISR hợp nội dung thay đổi định kỳ như blog, category, landing page theo chiến dịch.
- Edge Runtime hợp logic nhẹ cần chạy gần người dùng, không phải thay thế cho mọi backend phức tạp.
- Hiệu năng production tốt nhất thường đến từ chiến lược kết hợp: mỗi loại trang dùng một cách render khác nhau.
Next.js production performance là gì?
Next.js production performance là khả năng website phản hồi nhanh, render ổn định, cache đúng và giữ trải nghiệm tốt khi chạy thật với lượt truy cập, dữ liệu và quy trình deploy thực tế. Nó không chỉ là điểm Lighthouse trên máy local.
Google Search Central dùng Core Web Vitals để đánh giá trải nghiệm trang, gồm LCP, INP và CLS [1]. Với Next.js, cách render ảnh hưởng trực tiếp đến LCP và TTFB; JavaScript phía trình duyệt và hydration ảnh hưởng đến INP; layout và ảnh ảnh hưởng đến CLS.
Next.js App Router hỗ trợ nhiều mô hình render và cache, gồm render tĩnh, render động, streaming, data cache và full route cache [2]. Sức mạnh này cũng là nguồn phức tạp: nếu team không thống nhất quy tắc, mỗi route có thể hoạt động khác nhau khi lên production.
Bạn đang đọc bài viết thuộc chuyên mục Lập trình của VietnamTutor — nơi mình ưu tiên các quyết định code có tác động thật đến vận hành website.
Khi nào nên dùng SSG?
SSG phù hợp với trang nội dung ít thay đổi, cần tốc độ cao, SEO tốt và cache CDN đơn giản. Nếu dữ liệu có thể build trước, SSG thường là lựa chọn dễ vận hành nhất.
Static rendering giúp HTML được tạo trước và có thể phục vụ nhanh từ cache. Những trang hợp SSG gồm homepage ít đổi, landing page evergreen, trang dịch vụ, tài liệu, bài blog hoặc trang category được cập nhật theo lịch.
Điểm cần chú ý là thời gian build và độ mới của dữ liệu. Nếu site có hàng chục nghìn trang hoặc dữ liệu đổi liên tục, build toàn bộ mỗi lần deploy có thể trở thành điểm nghẽn. Khi đó, ISR hoặc cách render kết hợp sẽ hợp hơn.
Khi nào nên dùng SSR?
SSR phù hợp khi HTML cần dữ liệu mới theo request, dữ liệu phụ thuộc user, cookie, quyền truy cập hoặc trạng thái backend. Nhưng SSR cũng làm TTFB phụ thuộc trực tiếp vào server và database.
Ví dụ hợp SSR: dashboard đăng nhập, báo giá theo tài khoản, trang tồn kho cần cập nhật tức thời, trang kết quả tìm kiếm cá nhân hóa hoặc nội dung bị chi phối bởi vị trí/cookie. Nếu dùng SSR cho mọi route chỉ vì “dữ liệu mới”, bạn có thể tự đẩy tải về server nhiều hơn cần thiết.
web.dev nhấn mạnh TTFB bao gồm cả thời gian server xử lý trước khi trả byte đầu tiên [3]. Với SSR, phần này thường tăng nếu query chậm, API backend xa, hoặc route không cache được. Vì vậy, SSR cần khả năng quan sát tốt: log độ trễ, tracing API, cache dữ liệu phù hợp và kiểm soát query.
Khi nào nên dùng ISR?
ISR phù hợp khi bạn muốn tốc độ gần static nhưng vẫn cập nhật nội dung theo chu kỳ hoặc theo trigger. Đây là lựa chọn rất hợp cho content site, trang category, landing page chiến dịch và catalog không cần realtime tuyệt đối.
Next.js hỗ trợ Incremental Static Regeneration để cập nhật nội dung tĩnh sau khi build, thay vì phải rebuild toàn bộ site mỗi lần dữ liệu đổi [4]. Với website doanh nghiệp, ISR thường là điểm cân bằng tốt: người dùng nhận trang nhanh, team vẫn cập nhật nội dung được.
Điểm cần quyết định là độ trễ chấp nhận được. Tin tức nóng, tồn kho realtime hoặc giá cá nhân hóa không nên phụ thuộc hoàn toàn vào ISR. Nhưng trang dịch vụ, bài blog, guide, case study, category sản phẩm ít đổi thì rất hợp.
Edge Runtime nên dùng ở đâu?
Edge Runtime phù hợp với logic nhẹ cần chạy gần người dùng, như chuyển hướng, chia nhánh A/B, kiểm tra đăng nhập đơn giản, cá nhân hóa nhẹ hoặc phản hồi API nhỏ. Nó không nên được xem là nơi thay thế toàn bộ backend phức tạp.
Next.js có Edge Runtime với một tập API web tiêu chuẩn và một số giới hạn so với Node.js runtime [5]. Nếu code cần API Node.js gốc, thư viện nặng, kết nối database phức tạp hoặc xử lý CPU dài, Edge có thể không phù hợp.
Với người dùng Việt Nam, Edge có thể giúp khi bạn cần logic gần người dùng trước khi request về máy chủ gốc. Nhưng nếu database vẫn nằm xa hoặc API chính vẫn chậm, Edge chỉ tối ưu được một phần. Đừng dùng Edge để che một backend không được đo lường.
Bảng quyết định cho production
Chiến lược tốt nhất thường là kết hợp: SSG cho trang ổn định, ISR cho nội dung đổi định kỳ, SSR cho dữ liệu động và Edge cho logic nhẹ gần người dùng. Đừng ép toàn bộ website vào một mô hình render.
| Loại route | Chiến lược nên cân nhắc | Lý do |
|---|---|---|
| Trang dịch vụ, giới thiệu, chính sách | SSG | Nhanh, dễ cache, ít đổi |
| Blog, case study, category | ISR | Cần cập nhật nhưng không realtime |
| Dashboard, tài khoản, báo giá riêng | SSR | Dữ liệu phụ thuộc người dùng hoặc request |
| Chuyển hướng, định tuyến theo vị trí, A/B test nhẹ | Edge Runtime | Cần quyết định gần người dùng |
| Tìm kiếm/bộ lọc phức tạp | SSR hoặc API + tương tác phía trình duyệt | Phụ thuộc độ mới dữ liệu và UX |
Mình khuyên team nên viết một chính sách render trong repo: route nào tĩnh, route nào động, cache TTL bao lâu, khi nào được dùng Edge, khi nào phải đo TTFB trước khi merge. Chính sách này giúp hiệu năng không phụ thuộc vào cảm tính của từng developer.
Nếu dự án của bạn đang dùng WordPress/headless hoặc website doanh nghiệp có nhiều landing page, hãy nối bài này với quyết định hosting. Bạn có thể đọc thêm Tăng tốc WordPress: 10 bước cải thiện hiệu năng website và Redis Object Cache WordPress để thấy cache backend ảnh hưởng production ra sao.
Nguồn tham khảo
- Google Search Central: Core Web Vitals
- Next.js Docs: Caching in App Router
- web.dev: Optimize Time to First Byte
- Next.js Docs: Incremental Static Regeneration
- Next.js Docs: Edge Runtime
Các câu hỏi thường gặp
Tối ưu hiệu năng Next.js production nên bắt đầu từ đâu?
Nên bắt đầu từ danh sách route: route nào tĩnh, động, có thể cache, hoặc phụ thuộc người dùng. Sau đó đo TTFB, LCP, INP và dung lượng JavaScript trước khi tối ưu sâu.
SSG có luôn nhanh hơn SSR không?
Thường SSG dễ nhanh hơn vì HTML có thể cache tốt, nhưng không phù hợp mọi dữ liệu. Nếu trang cần cá nhân hóa hoặc realtime, SSR hoặc mô hình kết hợp sẽ hợp hơn.
ISR phù hợp website nào?
ISR phù hợp blog, landing page, category, catalog ít đổi và nội dung cập nhật theo chu kỳ. Nó không phù hợp dữ liệu cần realtime tuyệt đối như giá cá nhân hóa hoặc tồn kho nhạy cảm.
Edge Runtime có làm website luôn nhanh hơn không?
Không luôn. Edge giúp logic nhẹ chạy gần người dùng, nhưng nếu backend hoặc database vẫn chậm, hiệu năng tổng thể vẫn có thể kém. Cần đo end-to-end.
Có nên dùng SSR cho toàn bộ website Next.js không?
Không nên mặc định. SSR cho toàn bộ route có thể tăng TTFB và tải server. Nên dùng chiến lược kết hợp để route tĩnh dùng SSG/ISR, route động mới dùng SSR.
Hiệu năng Next.js khi chạy thật không đến từ việc chọn một chữ viết tắt duy nhất. Nó đến từ quyết định đúng cho từng route, cache rõ ràng, đo TTFB/LCP/INP thật và giữ kiến trúc đủ đơn giản để team vận hành lâu dài.
