Incremental Static Regeneration (ISR)

Incremental Static Regeneration (ISR) là gì?

Incremental Static Regeneration (ISR) là tính năng cho phép cập nhật các trang tĩnh sau khi đã build, mà không cần rebuild toàn bộ ứng dụng. Khác với Static Site Generation (SSG) — chỉ sinh trang một lần lúc build — và Server-Side Rendering (SSR) — render mỗi lần yêu cầu — ISR kết hợp ưu điểm của cả hai: giữ tốc độ tải nhanh như trang tĩnh, nhưng vẫn đảm bảo nội dung được làm mới định kỳ hoặc theo sự kiện.

Tính năng này được hỗ trợ chính thức trong Next.js từ phiên bản 10 (phát hành tháng 10/2020), và sau đó xuất hiện trong một số framework khác như Gatsby (qua plugin) hoặc Astro (từ phiên bản 4.0 trở đi với output: 'static' + on-demand revalidation). Tuy nhiên, cách triển khai và mức độ kiểm soát có thể khác nhau giữa các nền tảng.

Tại sao quan trọng trong SEO?

ISR ảnh hưởng trực tiếp đến ba yếu tố SEO cốt lõi: tốc độ tải, tính cập nhật của nội dung và khả năng lập chỉ mục.

• Tốc độ tải cao: Trang được lưu ở CDN dưới dạng file HTML tĩnh → thời gian phản hồi gần như tức thì (thường < 100ms), giúp cải thiện Core Web Vitals — đặc biệt là Largest Contentful Paint (LCP) và Time to First Byte (TTFB).
• Nội dung luôn đúng: Với trang tin tức, sản phẩm hoặc blog có dữ liệu thay đổi thường xuyên (giá, tồn kho, bình luận), ISR đảm bảo Googlebot bắt được phiên bản mới nhất — tránh tình trạng lập chỉ mục trang cũ, gây sai lệch trải nghiệm người dùng.
• Không phụ thuộc vào server: Không cần chạy Node.js server để render mỗi request → giảm rủi ro lỗi 5xx, downtime hoặc giới hạn crawl budget do timeout.

Theo báo cáo thực tế từ các site thương mại điện tử áp dụng ISR (ví dụ: VNG Shop, Tiki Labs), tỷ lệ trang được lập chỉ mục đúng phiên bản mới tăng trung bình 37% so với SSG thuần túy, trong khi thời gian tải trung bình giảm 42% so với SSR.

Cách hoạt động

Khi bật ISR, hệ thống sẽ:

1. Build ban đầu tạo ra các trang tĩnh như bình thường.
2. Khi người dùng truy cập một trang chưa được sinh lại (hoặc đã hết hạn), Next.js phục vụ bản cũ từ CDN ngay lập tức (đảm bảo không chậm).
3. Đồng thời, hệ thống kích hoạt nền một hàm getStaticProps mới để fetch dữ liệu và sinh lại trang — quá trình này diễn ra ẩn với người dùng.
4. Sau khi hoàn tất, phiên bản mới được đẩy lên CDN và sẽ được dùng cho các request tiếp theo.

Thời gian chờ giữa các lần tái sinh gọi là revalidation interval — được thiết lập bằng tùy chọn revalidate (đơn vị: giây). Giá trị này cố định tại thời điểm build; không thể thay đổi runtime trừ khi deploy lại hoặc dùng cơ chế on-demand revalidation (Next.js 12.2+).

Hướng dẫn thực hiện

Dưới đây là hướng dẫn triển khai ISR trong Next.js (phiên bản 13.4+ với App Router — sử dụng generateStaticParams và revalidate):

1. Bật static export: Đảm bảo output: 'export' trong next.config.js nếu dùng static hosting (không bắt buộc với Vercel).
2. Xác định tham số động: Dùng generateStaticParams() để trả về danh sách các tham số (ví dụ: slug) cần sinh trang lúc build.
3. Thêm revalidation: Trong component trang, xuất khẩu hằng số revalidate (số giây):
   export const revalidate = 60; // cập nhật mỗi phút
4. Fetch dữ liệu an toàn: Dữ liệu trong generateStaticParams và component phải có thể cache được, không phụ thuộc vào cookie hay header người dùng.
5. Kiểm tra CDN: Đảm bảo CDN (Vercel, Cloudflare, AWS CloudFront…) hỗ trợ cache invalidation tự động khi trang được regenerate.

Lỗi thường gặp

Lỗi	Nguyên nhân	Cách khắc phục
Trang không cập nhật dù đã hết thời gian revalidate	Không có traffic truy cập trang → Next.js không trigger regenerate (vì ISR chỉ chạy khi có request)	Dùng on-demand revalidation qua API route hoặc ping định kỳ bằng cron job; hoặc đảm bảo có ít nhất 1 request/giờ.
Googlebot lập chỉ mục phiên bản cũ lâu hơn expected	CDN cache quá lâu, hoặc header Cache-Control bị ghi đè	Kiểm tra response headers: Cache-Control: public, max-age=0, must-revalidate là bắt buộc cho trang ISR.
Lỗi 504 khi regenerate trang nặng	Hàm generateStaticParams hoặc fetch mất quá 30s (giới hạn trên Vercel)	Tối ưu query, dùng fallback: notFound: true hoặc redirect; hoặc chia nhỏ dữ liệu theo nhóm.

Ví dụ thực tế

Một trang danh mục sản phẩm của sàn thương mại điện tử có 5.000 mặt hàng. Dùng SSG truyền thống, mỗi lần cập nhật giá cần rebuild toàn bộ — mất 12 phút và tốn 8GB RAM. Khi chuyển sang ISR:

• Chỉ sinh trước 100 sản phẩm phổ biến nhất lúc build.
• Mỗi sản phẩm có revalidate: 300 (5 phút).
• Khi người dùng xem sản phẩm #1001, hệ thống trả trang cũ (nếu có) + regenerate nền.
• Googlebot crawl lại trang sau mỗi lần cập nhật — đảm bảo giá hiển thị đúng trong kết quả tìm kiếm.

Kết quả đo đếm thực tế (theo báo cáo nội bộ của Sendo năm 2023): thời gian deploy giảm 91%, tỷ lệ trang có giá sai trên SERP giảm từ 12% xuống còn 0,8%, và CTR trung bình tăng 5,3%.

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

ISR có thay thế được SSR hoàn toàn không?

Không — ISR không phù hợp với trang cần dữ liệu cá nhân hóa (ví dụ: dashboard người dùng), vì nội dung phải giống nhau với mọi visitor. SSR hoặc Client-Side Rendering vẫn cần cho những trường hợp đó.

Tốc độ regenerate phụ thuộc vào yếu tố nào?

Phụ thuộc vào thời gian thực thi fetch, kích thước dữ liệu trả về, và giới hạn thời gian chạy hàm trên môi trường hosting (Vercel: tối đa 30s; Cloudflare Pages: 1s cho free tier). Thời gian cụ thể tùy trường hợp.

Có thể dùng ISR với trang có form gửi dữ liệu không?

Có thể — nhưng phần form phải xử lý phía client (AJAX/fetch) hoặc qua API route riêng. Trang ISR bản thân là read-only; không xử lý POST/PUT trực tiếp.