Hướng dẫn SSG vs SSR vs ISR Next.js: đọc đúng App Router để khỏi “tưởng nhanh mà chậm”
· Tác giả: Trường — Founder Webchốt
Liên quan: Tìm hiểu vì sao Webchốt chọn thiết kế web bán hàng bằng Next.js.
Đội kỹ thuật thường mâu thuẫn với marketing: bên muốn trang cập nhật liên tục, bên lại cố ép static để Lighthouse lên điểm. Hướng dẫn SSG vs SSR vs ISR Next.js dưới đây dùng ngôn ngữ thực dự án chứ không chỉ là bảng màu trong slide. Bạn sẽ biết chỗ nào nên đẩy HTML lên CDN, chỗ nào phải render theo cookie, chỗ nào nên ISR để không phải build lại cả site mỗi khi chỉnh một dòng báo giá. Kinh nghiệm từ các site Webchốt triển khai cho SME Việt Nam cho thấy sai lầm phổ biến không phải do framework mà do chọn sai layer cache cho từng URL cụ thể. Nội dung hướng về đội vừa chuyển từ WordPress sang Next.js hoặc đang gom microservice landing page về một monorepo.
Render strategy ảnh hưởng trực tiếp đường cong Core Web Vitals trên báo cáo thực tế của shop online | Nguồn: webchot.com
Rendering strategy là gì trong đầu một architect Next.js hiện đại
Rendering strategy là quyết định thời điểm CPU sinh ra HTML và ai được phép cache bản đó. Với Next.js App Router, câu hỏi không còn là chọn framework mà là chọn per-route default: route marketing có thể static, route account phải dynamic, route blog nên ISR. Khi bạn gom mọi thứ vào một kiểu render cho tiện, CDN vẫn phục vụ nhanh nhưng RUM lại kêu LCP vì ảnh hero gắn payload cá nhân hoặc vì server component kéo query nặng mỗi request. Bản hướng dẫn SSG vs SSR vs ISR Next.js này gắn trực tiếp với KPI mà Webchốt cam kết khi bàn giao: Lighthouse 100/100 trên trang chuẩn marketing, LCP khoảng 0.8s trên profile lab, bundle client gọn hơn 100KB gzip cho phần above-the-fold nếu không có widget bên thứ ba nặng. Stack thực chiến gồm Next.js 16, TypeScript chặt, Tailwind v4, hosting edge Vercel hoặc tương đương và Supabase khi cần auth realtime.
Giai đoạn discovery nên có sơ đồ traffic: Organic chiếm bao nhiêu phần, có campaign paid spike không, và CMS đổi bài giờ nào. Với catalog dịch vụ và gói triển khai web của Webchốt bạn có thể so sánh mức đầu tư phù hợp cỡ doanh nghiệp nhỏ; phần pricing cấu hình linh hoạt giúp ước lượng module trước khi cam kết scope.
Các nhóm render chính: SSG cố định, SSR theo request, ISR cân hai thế giới
SSG (Static Site Generation) build ra HTML và JSON định sẵn; request chỉ đọc file từ edge nên chi phí rẻ và ổn định. SSR (Server-Side Rendering) chạy hàm render trước khi HTML trả về trình duyệt và có thể đọc header cookie; phù hợp gated content hoặc pricing theo nhóm khách nhưng tốn CPU. ISR giữ skeleton giống SSG nhưng cho phép tái validate sau một khoảng thời gian hoặc khi webhook CMS gọi on-demand.
- Điểm 1: SSG hợp landing, trang FAQ tĩnh, policy, và các URL marketing ít nhân danh đăng nhập.
- Điểm 2: SSR không nên bọc full site; chỉ nên bọc các segment cần dữ liệu request-scoped và giữ phần còn lại static reuse.
- Điểm 3: ISR thích hợp blog tin, danh mục sản phẩm có cập nhật định kỳ, hoặc bảng tính giá versioning vài giờ một lần.
- Điểm 4: Client-side fetch không thay SSR nếu SEO cần HTML đầy đủ; chú chỉ là lớp bổ sung sau khi shell đã tốt.
Bảng so sánh tiêu chí vận hành và SEO cho SSG, SSR và ISR
Bảng dưới tóm tắt trade-off hay dùng khi họp giữa dev, SEO và chủ budget. Chi tiết có thể mở rộng trong workshop nội bộ hoặc khi bạn đặt lịch consult với Webchốt để chốt RACI.
| Tiêu chí | SSG full | SSR động | ISR có revalidate |
|---|---|---|---|
| TTFB và cache edge | Rất thấp, hit CDN cao | Cao hơn, phụ thuộc runtime | Thấp giữa các lần revalidate |
| Fresness nội dung | Cần redeploy để đổi | Luôn mới nhất theo backend | Mới trong giới hạn time window hoặc sau webhook |
| Độ phù hợp SEO crawl | Tốt nếu build đầy đủ path | Tốt khi không phụ thuộc hydration trống | Tốt, lưu ý stale không quá xa business |
| Chi phí hạ tầng | Biên lợi nhuận host lớn | Scale theo concurrency | Chi phí vừa, thêm webhook/batch |
Sau bảng, quyết định cuối thường là phân chia route: storefront marketing SSG và ISR, checkout và account SSR có cache ngắn hoặc no-store đúng chuẩn PCI và session. Việc dùng thư viện UI phải tránh mang cả dashboard admin vào cùng bundle marketing; tách subdomain hoặc app route group giúp Lighthouse không bị kéo bởi chart nặng. Nếu bạn thích bắt đầu từ khối có sẵn, khối template Next.js của Webchốt được tách sẵn layer marketing và portal nội bộ nhẹ.
Quy trình năm bước chọn chiến lược render cho từng URL
- Bước 1: Liệt kê persona truy cập route: crawler Google, khách chưa login, khách đã login, hay API partner. Viết ra header hoặc cookie nào thay đổi markup— nếu có thì không nên cache public lâu.
- Bước 2: Đo tần suất thay đổi dữ liệu từ CMS hoặc ERP. Dữ liệu đổi mỗi phút ⇒ nghiêng SSR hoặc client stream nhỏ; đổi mỗi ngày ⇒ ISR với giây hợp lý hoặc on-demand trong giờ ra bài PR.
- Bước 3: Chọn boundary server component và client component. UI tương tác bản đồ, carousel rich nên lazy; hero text và FAQ nên render server để crawler đọc được mà không cần chờ hydration.
- Bước 4: Cấu hình cache header và tag invalidation một cách explicit. Sai bước này dễ có bug “Khách A thấy giá của Khách B” hoặc ngược lại thấy bản stale quá lâu.
- Bước 5: Load test trước khi peak campaign: SSR route phải có autoscale queue; ISR route kiểm tra thundering herd lúc hết TTL. Chuẩn bị playbook rollback static nếu API nguồn sập.
Vòng lặp này lặp theo sprint; không có chốt một lần cho cả đời dự án vì SKU hoặc compliance thay đổi.
Chi phí tham khảo và cách Webchốt gói dịch vụ theo mức độ động
Khi báo giá, Webchốt phân nhánh Starter từ khoảng 5 đến 8 triệu cho site marketing chủ yếu SSG và ISR blog ngắn; Business cỡ mười lăm triệu trở lên multi-page và CMS Sanity hoặc Strapi với ISR phân tầng; Pro cho e-commerce và module auth phức tạp SSR kết hợp edge middleware. Chi phí thực không chỉ là giờ viết JSX mà còn telemetry RUM và giờ infra review cache. Startup F&B và tiệm spa TP.HCM thường ưu tiên ISR cho menu và giờ làm việc, SSG cho trang giới thiệu và ảnh phòng. Bài toán logistics B2B thường cần SSR cho dashboard báo giá theo nhóm khách còn brochure vẫn SSG để không treo Lighthouse.
Đội muốn tự chủ nội dung nên học playbook “đổi bài ISR”: marketing xuất bản trên CMS, webhook chạy revalidation path và Slack báo staging pass. Chi tiết các gói nằm trong trang dich vụ của Webchốt; bạn có thể ghép module công cụ kế toán miễn phí làm sidebar trust cho landing dịch vụ mà không cần SPA nặng.
Sai lầm phổ biến khi đọc hướng dẫn SSG SSR ISR nhưng triển khai vẫn lệch
Nhiều team hiểu lý thuyết nhưng vẫn vấp phải thực địa CDN và cookie staging.
- Sai lầm 1: Gắn fetch no-store lên layout gốc khiến toàn microsite SSR hóa không cần thiết và bill Vercel tăng trong đợt sale— nên chia route group và default static an toàn.
- Sai lầm 2: Quên chỉnh revalidate ISR sau khi marketing đặt SLA “bài tin phải lên trong 60 giây” khiến PR kêu trời vì vẫn thấy bản cũ trên CDN toàn cầu.
- Sai lầm 3: Embed script marketing nặng lên hero SSG làm CLS vượt ngưỡng dù HTML tĩnh rất nhẹ.
- Sai lầm 4: Không có monitoring phân route; khi LCP spike, team chỉ rollback toàn repo thay vì cô lập route SSR có query N+1 phía server component.
FAQ — hướng dẫn ssg vs ssr vs isr next js
SSG và prerender của App Router có cần generateStaticParams cho mọi slug không?
Không bắt buộc tùy vào có bao nhiêu path trong build window. Marketing site vài chục URL nên enumerate hết trong generateStaticParams hoặc dùng file-based route tĩnh. Blog có hàng ngàn slug có thể chọn ISR với fallback block hoặc sinh subset hot post trước rồi on-demand các bài ít đọc. Import đường dẫn thiếu sẽ dẫn tới runtime error hoặc miss cache nếu config sai nên backlog nên có test snapshot.
SSR có làm SEO yếu hơn SSG không?
Đúng nghĩa kỹ thuật thì không, miễn HTML đầy đủ không phụ thuộc chờ hydration quá xa timeout của bot. Sai lầm là SSR chậm vì backend database xa region crawl khiến crawl budget tiêu hao và snippet đôi khi không kịp cập nhật. Chuẩn hóa region deploy gần user và crawler chính, kèm header cache thích hợp cho khối không cá nhân hóa, thường giảm rủi ro đó.
ISR và stale-while-revalidate của CDN có trùng ý không?
Gần như đồng nhất về mặt trải nghiệm người dùng nhưng cơ chế kích hoạt khác nhau: ISR của Next được framework điều phối tại compute layer, CDN vẫn có thể thêm lá SWR của riêng nhà mạng. Chiến lược là đặt số không lệch nhau để không có khoảng thời gian user nhìn hai phiên bản khác trong cùng session.
Edge runtime thay được SSR Node trọn vẹn không?
Với một số use case được: rewrite header nhẹ, A/B deterministic, và fetch JSON nhỏ. Với workload nặng kết database lớn hoặc lib native, edge có giới hạn CPU và package size nên vẫn cần Node route riêng. Splitting theo path giảm rủi ro cold start.
Có nên migration dứt điểm Pages Router sang App Router chỉ để dùng server component?
Chỉ khi lợi ích render và DX vượt chi phí regression test. Nhiều dự án hybrid sống song song một thời gian: marketing App Router, legacy dashboard Pages. Kế hoạch migration cần checklist fetch cache và layout nesting để không phá SEO đang ổn.
Liên Hệ Webchốt
Nếu bạn cần người đồng hành dịch bảng lý thuyết SSG SSR ISR thành backlog cụ thể— pull request, story point và tiêu chí nghiệm thu RUM— hãy nhắn Webchốt. Hướng dẫn SSG vs SSR vs ISR Next.js trong bài vẫn có giới hạn vì mỗi domain data khác nhau; call thực tế với log production mới chốt được số revalidate hay route nào phải dynamic. Webchốt làm việc remote 100%, bàn giao source code thuộc khách, cam kết bảo hành mười hai tháng và hoàn tiền một trăm phần trong bảy ngày nếu không đạt phạm vi đã ký. Kênh nhanh nhất là Zalo đồng số máy hoặc email dưới đây; kèm screenshot Lighthouse hiện tại và URL staging để anh Trường feedback trong một vòng họp ngắn.
- Hotline / Zalo: 0905 151 701 — gặp anh Trường (founder/dev).
- Chat Zalo: zalo.me/0905151701 — phản hồi nhanh.
- Email: hi@webchot.com — phản hồi <12h làm việc.
- Studio: 262/1/93 Phan Anh, Phường Phú Thạnh, TP.HCM (T2–T7, 9h–18h).
Tham khảo thêm: 17 template Next.js · 10 dịch vụ web chuyên sâu · bảng giá Webchốt 2026 · 12 công cụ kế toán/tài chính miễn phí.
Reference: Next.js docs · web.dev Core Web Vitals.
