Edge-Side Includes (ESI)
Tiêu chuẩn để chèn nội dung động tại tầng CDN, giúp tăng tốc độ tải và giảm tải máy chủ gốc.
Edge-Side Includes (ESI) là gì?
Edge-Side Includes (ESI) là một tiêu chuẩn mở, được thiết kế để chèn nội dung động vào trang web ngay tại tầng CDN (Content Delivery Network), thay vì chờ máy chủ gốc xử lý toàn bộ. Nó hoạt động như một ngôn ngữ đánh dấu đơn giản — tương tự HTML — cho phép phân chia trang thành các phần độc lập: phần tĩnh (cache được lâu) và phần động (cập nhật thường xuyên như giỏ hàng, tên người dùng, khuyến mãi theo khu vực). Khi trình duyệt yêu cầu trang, CDN đọc thẻ ESI, lấy riêng từng phần từ các nguồn khác nhau, sau đó ghép lại thành trang hoàn chỉnh trước khi gửi về người dùng.
Tại sao quan trọng trong SEO?
ESI ảnh hưởng trực tiếp đến ba yếu tố then chốt của Technical SEO: tốc độ tải trang, khả năng index, và hiệu suất trên thiết bị di động. Khi phần lớn nội dung được cache ở CDN, thời gian phản hồi (TTFB) giảm rõ rệt — thường xuống dưới 100ms với các CDN hỗ trợ ESI đầy đủ như Akamai, Fastly hoặc Cloudflare Enterprise. Điều này giúp bot Google thu thập trang nhanh hơn, đặc biệt với site có nhiều nội dung cá nhân hóa hoặc cập nhật theo thời gian thực. Ngoài ra, ESI giúp duy trì điểm Core Web Vitals cao (như LCP và CLS ổn định) vì phần động không làm chậm render toàn trang. Một số báo cáo kiểm thử thực tế cho thấy site áp dụng ESI đúng cách cải thiện tốc độ tải trang trung bình 35–60% trên phân khúc người dùng quốc tế.
Cách hoạt động
ESI hoạt động theo cơ chế phân tầng: trình duyệt gửi yêu cầu → CDN nhận request → kiểm tra header và nội dung HTML → phát hiện thẻ <esi:include> → gửi yêu cầu riêng lẻ tới các endpoint được chỉ định (có thể là máy chủ gốc, microservice hoặc edge function) → chờ phản hồi → ghép kết quả vào vị trí tương ứng → trả trang hoàn chỉnh. Toàn bộ quá trình xảy ra trong vài mili giây, không cần chờ máy chủ gốc xử lý toàn bộ trang. Các thẻ ESI cơ bản gồm: <esi:include>, <esi:choose>, <esi:when>, <esi:otherwise> và <esi:comment>. CDN chỉ thực thi ESI nếu được bật tường minh — không tự động kích hoạt dù HTML chứa thẻ.
Hướng dẫn thực hiện
Triển khai ESI đòi hỏi sự phối hợp giữa cấu hình CDN, code backend và kiểm thử kỹ thuật. Dưới đây là các bước bắt buộc:
- Đảm bảo CDN hỗ trợ ESI: Kiểm tra tài liệu nhà cung cấp (Akamai hỗ trợ đầy đủ từ 2003; Fastly bật mặc định; Cloudflare yêu cầu gói Enterprise và bật qua Ruleset Engine).
- Thiết lập header bắt buộc: Máy chủ gốc phải trả về
Surrogate-Control: content="ESI/1.0"hoặcCache-Control: public, surrogate-control="ESI/1.0"để CDN nhận diện và xử lý ESI. - Viết thẻ ESI trong HTML: Đặt thẻ
<esi:include src="https://api.example.com/user-badge"></esi:include>tại vị trí cần chèn. Lưu ý:srcphải là URL có thể truy cập từ CDN, không phải localhost hay domain bị chặn. - Đảm bảo endpoint được include trả dữ liệu sạch: Không kèm thẻ HTML ngoài, không redirect, không yêu cầu cookie/session — vì CDN không truyền cookie mặc định (trừ khi cấu hình
Surrogate-Control: include="Set-Cookie"). - Kiểm thử bằng công cụ: Dùng
curl -Iđể xác minh headerSurrogate-Control; kiểm tra response HTML có còn nguyên thẻ ESI (nghĩa là CDN chưa xử lý) hoặc đã biến mất/thay bằng nội dung (đã xử lý thành công).
Lỗi thường gặp
- Thẻ ESI vẫn hiển thị nguyên trong HTML: Thường do thiếu header
Surrogate-Control, hoặc CDN chưa bật tính năng ESI. Cách khắc phục: kiểm tra lại header phản hồi và cấu hình CDN. - Phần được include trả về 404 hoặc timeout: Nguyên nhân phổ biến là URL trong
srckhông tồn tại, bị chặn bởi firewall, hoặc endpoint không hỗ trợ HTTP/1.1 (một số CDN cũ không xử lý HTTP/2 cho ESI). Giải pháp: kiểm tra log CDN, dùngcurltừ IP CDN để mô phỏng. - Nội dung cá nhân hóa bị cache sai: Ví dụ badge người dùng A xuất hiện cho người dùng B. Xảy ra khi endpoint không trả header
Vary: CookiehoặcVary: Authorization, khiến CDN cache chung cho mọi người. Khắc phục: thêmVaryphù hợp và kiểm tra cache key trong CDN dashboard. - ESI làm chậm hơn so với không dùng: Thường do endpoint chậm (>500ms), hoặc gọi nối tiếp nhiều
<esi:include>mà không song song. Giải pháp: giới hạn tối đa 3–4 include/trang; dùng<esi:choose>để bỏ qua khi không cần thiết.
Ví dụ thực tế
Một trang sản phẩm điện máy tại Việt Nam có cấu trúc: phần mô tả sản phẩm (cache 7 ngày), phần giá (cache 1 giờ), phần đánh giá (cache 15 phút), và phần khuyến mãi theo khu vực (cache 5 phút). Với ESI, toàn bộ trang được lưu ở CDN, nhưng mỗi phần được cập nhật độc lập. Kết quả đo thực tế sau triển khai:
| Chỉ số | Trước ESI | Sau ESI | Thay đổi |
|---|---|---|---|
| TTFB trung bình (VN) | 840 ms | 112 ms | ↓ 87% |
| Tỷ lệ cache hit tại CDN | 42% | 93% | ↑ 51 điểm |
| Thời gian crawlbot thu thập (1.000 trang) | 47 phút | 19 phút | ↓ 59% |
Câu hỏi thường gặp
ESI có thay thế được JavaScript phía client không?
Không. ESI chạy ở tầng CDN, trước khi trang đến trình duyệt — nên nó không phụ thuộc vào JS, không gây block render, và an toàn với bot. JavaScript phía client (ví dụ: fetch + innerHTML) chỉ chạy sau khi HTML tải xong, làm chậm LCP và dễ bị chặn bởi adblock/cors. ESI phù hợp cho nội dung cần hiển thị ngay, còn JS client dành cho tương tác sau khi trang đã hiện.
ESI có tương thích với WordPress hoặc Shopify không?
WordPress không hỗ trợ ESI sẵn — cần plugin tùy chỉnh hoặc cấu hình reverse proxy (Varnish/Nginx) kết hợp CDN. Shopify không hỗ trợ ESI trực tiếp, nhưng một số đối tác CDN (Fastly) cung cấp giải pháp tích hợp qua Edge Dictionary và ESI-like logic. Với nền tảng SaaS, khả năng triển khai phụ thuộc vào mức độ kiểm soát server và CDN — tùy trường hợp.
Có cần thay đổi cách đo lường hiệu quả SEO sau khi dùng ESI?
Có. Bạn cần theo dõi thêm các chỉ số: tỷ lệ cache hit tại CDN, số lần gọi ESI thành công/thất bại (qua log CDN), và thời gian xử lý ESI trung bình. Công cụ như Google Search Console vẫn báo chính xác, nhưng nếu thấy tăng đột biến số trang được index trong thời gian ngắn, đó thường là dấu hiệu ESI đang giúp bot thu thập hiệu quả hơn — cần kiểm tra kỹ chất lượng nội dung được include để tránh duplicate hoặc thin content.