Mỗi lần một trình duyệt gọi tới web của bạn mà phản hồi phải đi tới tận máy chủ gốc rồi quay về, người dùng ở xa phải trả giá bằng vài trăm mili-giây chờ đợi. Mạng biên (edge network) của Vercel xoá phần lớn khoảng chờ đó bằng cách giữ sẵn bản sao phản hồi tại điểm gần người dùng nhất. Đây là nền tảng giúp web Next.js triển khai trên Vercel cảm giác nhanh ở mọi nơi, chứ không chỉ nhanh ở nơi đặt máy chủ.
Edge cache nằm ở đâu trong vòng đời một request
Khi một request đến, nó chạm vào điểm hiện diện (PoP — Point of Presence, trạm trung chuyển của Vercel) gần người dùng nhất trước. Tại đây có hai khả năng:
- Cache HIT (trúng cache): phản hồi đã có sẵn và còn “tươi” — Vercel trả thẳng từ biên, không đánh thức hàm máy chủ. Đây là đường nhanh nhất.
- Cache MISS (trượt cache): chưa có bản lưu — request đi tiếp tới hàm (function) để dựng phản hồi, sau đó kết quả được lưu lại tại biên cho lần sau.
Bạn kiểm tra trạng thái này bằng header x-vercel-cache trong phản hồi: giá trị thường gặp là HIT, MISS, STALE (bản cũ đang được trả trong lúc làm mới ngầm) và PRERENDER (trang dựng sẵn lúc build). Mở DevTools tab Network, xem header này là cách nhanh nhất để biết trang của bạn có thật sự được cache hay không.
Hai từ khoá làm nên tốc độ: s-maxage và stale-while-revalidate
Edge cache Vercel điều khiển bằng header Cache-Control. Hai chỉ thị quan trọng nhất:
- s-maxage=N: phản hồi được coi là “tươi” trong N giây tại biên. Trong khoảng này, mọi người dùng nhận bản từ cache, hàm máy chủ không chạy.
- stale-while-revalidate=Z: hết hạn tươi rồi, trong Z giây tiếp theo Vercel vẫn trả ngay bản cũ (stale) cho người dùng, đồng thời âm thầm gọi hàm để lấy bản mới cập nhật vào cache. Người dùng không phải chờ — họ luôn nhận phản hồi tức thì, còn nội dung tự làm mới ở phía sau.
Đây chính là cơ chế khiến web cảm giác vừa nhanh vừa mới. Một ví dụ cấu hình hàm trả về JSON có cache tại biên:
// app/api/bang-gia/route.ts
export async function GET() {
return Response.json(data, {
headers: {
'Cache-Control': 'public, s-maxage=60, stale-while-revalidate=300',
},
});
}Cấu hình trên nghĩa là: phản hồi tươi trong 60 giây, sau đó còn được phục vụ “kiểu cũ” thêm 300 giây trong lúc làm mới ngầm.
Tách cache biên ra khỏi cache trình duyệt
Một điểm dễ nhầm: s-maxage dành cho cache dùng chung (biên/CDN), không phải cache trình duyệt. Vercel còn cho phép điều khiển riêng từng lớp:
| Header | Ai nghe theo |
|---|---|
Cache-Control | Trình duyệt (và mặc định cả CDN) |
CDN-Cache-Control | Cache biên Vercel và các CDN khác — trình duyệt bỏ qua |
Vercel-CDN-Cache-Control | Chỉ riêng cache Vercel — trình duyệt và CDN khác bỏ qua |
Theo tài liệu Vercel, nếu bạn chỉ đặt Cache-Control mà không có CDN-Cache-Control, Vercel sẽ cắt s-maxage và stale-while-revalidate trước khi gửi về trình duyệt. Nhờ vậy, ngay sau khi bạn deploy bản mới, người dùng nhận nội dung mới mà không phải chờ cache trình duyệt hết hạn — tránh cảnh “khách thấy bản cũ” rất hay gặp khi cấu hình cache ẩu.
ISR — cache nội dung động mà vẫn tự làm mới
ISR (Incremental Static Regeneration — tái tạo tĩnh tăng dần) là cách Next.js áp chính hai chỉ thị trên cho trang. Khi bạn đặt thời gian revalidate cho một trang, Vercel dựng sẵn HTML, lưu tại biên và tự dựng lại theo lịch — bản chất là s-maxage={revalidate}, stale-while-revalidate dài. Trang danh mục sản phẩm, bài blog, trang giá… đều hợp với ISR: nội dung không đổi từng giây nhưng cũng không nên tĩnh cứng.
Lưu ý điều kiện để biên cache được phản hồi của hàm (theo tài liệu Vercel): request phải là GET/HEAD, không có header Authorization, phản hồi không kèm set-cookie, và không vượt quá giới hạn dung lượng. Nội dung riêng theo từng người dùng (đã đăng nhập, có cookie phiên) sẽ không vào edge cache — đó là điều đúng đắn, vì cache chung không nên chứa dữ liệu cá nhân.
Edge cache Vercel khác Cloudflare CDN và cache WordPress thế nào
Ba thứ này hay bị gộp chung nhưng vai trò khác nhau:
- Edge cache Vercel gắn chặt với Next.js: ISR, header cache có mục tiêu, và logic dựng lại trang nằm trong cùng nền tảng triển khai. Bạn không tự cấu hình quy tắc CDN — Next.js sinh header, Vercel thực thi.
- Cloudflare CDN là lớp đứng trước mọi loại web (kể cả WordPress), bạn tự định nghĩa Page Rules, Cache Rules, mức cache theo đường dẫn. Chi tiết cấu hình xem ở bài hướng dẫn riêng bên dưới.
- Cache WordPress (như LiteSpeed Cache hay WP Rocket) sinh file HTML tĩnh từ PHP rồi phục vụ thay vì chạy lại WordPress — cùng triết lý “lưu phản hồi”, nhưng diễn ra ở tầng máy chủ gốc, không phải tại biên gần người dùng.
Trong thực tế vận hành web22.dev (chạy WordPress trên LiteSpeed cộng Cloudflare), Web22 thấy rõ điểm chung của mọi lớp cache: thứ giết tốc độ thường không phải thiếu cache, mà là cache bị vô hiệu vì một cookie, một header sai, hay một quy tắc invalidation (làm mới) lệch nhịp. Trên Vercel cũng vậy — đọc x-vercel-cache để biết mình thật sự đang HIT hay đang vô tình MISS mỗi request.
Vì sao edge cache làm tốt cho Core Web Vitals
Trả phản hồi từ biên rút ngắn TTFB (Time To First Byte — thời gian tới byte đầu tiên), kéo theo cải thiện LCP (Largest Contentful Paint — thời điểm phần tử lớn nhất hiện ra). Theo web.dev, ngưỡng “Good” năm 2026 vẫn là LCP ≤ 2,5 giây, INP ≤ 200 mili-giây, CLS ≤ 0,1, đo ở phân vị 75 (p75) của người dùng thật. Edge cache giúp trực tiếp ở vế LCP; còn INP và CLS phụ thuộc nhiều vào JavaScript và bố cục — cache không cứu được, nên đừng kỳ vọng nó giải quyết mọi thứ.
Câu hỏi thường gặp
Edge cache Vercel có miễn phí không?
Cache trên mạng biên có sẵn cho mọi deployment và domain trên Vercel, không phụ thuộc gói. Khác biệt giữa các gói nằm ở giới hạn dùng và các tính năng nâng cao, không phải ở việc có được cache hay không.
Vì sao trang của tôi luôn MISS dù đã đặt s-maxage?
Thường do phản hồi kèm set-cookie, có header Authorization, hoặc bị đặt no-store/private ở đâu đó. Kiểm tra header x-vercel-cache và rà lại các điều kiện cache của tài liệu Vercel.
Đặt s-maxage bao lâu là hợp lý?
Tuỳ tốc độ thay đổi nội dung. Trang gần như tĩnh có thể để vài giờ; trang giá hay tồn kho nên ngắn hơn và dựa vào stale-while-revalidate để vừa nhanh vừa kịp cập nhật.
Nếu bạn muốn rà soát toàn bộ chiến lược cache và đo lại Core Web Vitals cho một dự án thật, dịch vụ tối ưu hiệu năng web của Web22 có thể giúp bạn dựng cấu hình chuẩn từ đầu.