CDN thay đổi hiệu suất website đến không ngờ: Nhanh hơn ở đâu và cần đo chỉ số nào?

CDN

Nguyễn Trọng Nhân

1616

15-09-2026

Tốc độ website không còn là câu chuyện “tải được hay không tải được”. Với một website kinh doanh, chỉ cần trang phản hồi chậm hơn vài giây, người dùng có thể thoát ra trước khi kịp xem nội dung, sản phẩm hoặc form đăng ký.

Vấn đề là nhiều doanh nghiệp vẫn nhìn hiệu suất website theo cách khá đơn giản: server có ổn không, code có lỗi không, điểm PageSpeed có cao không. Những chỉ số đó cần thiết, nhưng chưa đủ. Khi website bắt đầu dùng CDN, đường đi của request thay đổi, dữ liệu có thể được phục vụ từ máy chủ biên thay vì server gốc, và nếu không theo dõi đúng lớp CDN này, bạn sẽ rất khó biết website nhanh lên hoặc chậm đi vì đâu.

Bài viết này của Bizfly Cloud sẽ đi từ flow cơ bản của một website không dùng CDN, sau đó so sánh với website có CDN để thấy rõ CDN thay đổi hiệu suất website như thế nào và vì sao việc monitoring CDN lại quan trọng.

CDN đóng vai trò gì trong hiệu suất website? 

CDN không đơn thuần là một lớp “tăng tốc” đặt trước website. Về bản chất, CDN thay đổi cách nội dung được phân phối đến người dùng cuối. Thay vì để mọi request đi thẳng về server gốc, CDN đưa một phần nội dung ra các máy chủ biên gần người dùng hơn.

Điều này đặc biệt quan trọng với các website có nhiều ảnh, file CSS, JavaScript, video, tài liệu tải xuống hoặc lượng truy cập đến từ nhiều khu vực khác nhau. Khi được cấu hình đúng, CDN có thể giảm thời gian truyền dữ liệu, giảm tải cho server gốc và giúp website ổn định hơn trong các giai đoạn traffic tăng mạnh.

Tuy nhiên, CDN chỉ phát huy tác dụng khi được dùng đúng. Nếu cache rule sai, TTL quá ngắn, cache hit thấp hoặc nội dung động bị cache nhầm, CDN không những không cải thiện hiệu suất mà còn khiến việc xử lý sự cố phức tạp hơn.

>>> Đọc thêm cùng Bizfly Cloud: CDN là gì?

>>> Có thể bạn quan tâm: Top 5 CDN quốc tế cho các blogger tăng tốc website hiệu quả

Khi website không sử dụng CDN, request đi như thế nào?

Trước khi nhìn vào CDN, cần hiểu đường đi cơ bản của một request khi website chưa có CDN. Đây là flow quen thuộc của hầu hết website truyền thống: trình duyệt gửi yêu cầu, server gốc xử lý và phản hồi được trả ngược lại cho người dùng.

Có thể hình dung quá trình này gồm 5 bước chính:

1. Browser time - request: Trình duyệt chuẩn bị request, phân giải DNS nếu cần, thiết lập kết nối và gửi yêu cầu đến server của website.
2. Transport time - request: Request đi qua Internet để đến trung tâm dữ liệu hoặc cloud nơi website đang được lưu trữ. Thời gian này phụ thuộc vào khoảng cách địa lý, chất lượng mạng, tuyến truyền và độ ổn định của kết nối.
3. Back-end time: Server gốc nhận request, xử lý logic ứng dụng, truy vấn database, gọi API nội bộ hoặc thực hiện các tác vụ cần thiết trước khi tạo phản hồi. Đây là phần thường được theo dõi bằng APM, log server, database monitoring hoặc hạ tầng cloud.
4. Transport time - response: Sau khi server xử lý xong, response được gửi ngược lại qua Internet về trình duyệt người dùng. Nếu file lớn hoặc đường truyền xa, thời gian phản hồi có thể tăng lên đáng kể.
5. Browser time - response: Trình duyệt tải dữ liệu, phân tích HTML, CSS, JavaScript, render giao diện và hiển thị nội dung cho người dùng.

Ở mô hình này, các công cụ RUM thường giúp theo dõi trải nghiệm phía người dùng, APM theo dõi backend, còn network và infrastructure monitoring theo dõi máy chủ, tài nguyên, database hoặc kết nối. Nhưng phần transport time giữa người dùng và server gốc nhiều khi chỉ được suy luận gián tiếp, chứ không phải lúc nào cũng nhìn thấy rõ.

Đó là lý do một website có thể gặp tình trạng “server vẫn ổn, backend không lỗi, nhưng người dùng vẫn thấy chậm”. Vấn đề có thể nằm ở đường truyền, khoảng cách mạng, dung lượng tài nguyên hoặc lượng request đổ về origin quá nhiều.

Khi website sử dụng CDN, flow thay đổi ra sao?

Khi CDN được đưa vào hệ thống, trình duyệt không nhất thiết phải đi thẳng đến server gốc cho mọi tài nguyên. Request có thể được chuyển đến một máy chủ CDN edge gần người dùng hơn. Từ đây, có hai tình huống quan trọng cần phân biệt: CDN đã có nội dung trong cache hoặc CDN chưa có nội dung trong cache.

Sự khác biệt giữa hai tình huống này quyết định website nhanh hơn nhiều, nhanh hơn một phần hay gần như không cải thiện đáng kể.

Tình huống 1: CDN edge đã có nội dung trong cache

Đây là tình huống lý tưởng nhất. Người dùng yêu cầu một file ảnh, CSS, JavaScript hoặc tài nguyên tĩnh mà CDN đã lưu sẵn tại edge. Khi đó, CDN không cần gọi về server gốc.

Flow sẽ diễn ra như sau:

1. Browser time - request: Trình duyệt chuẩn bị và gửi request đến CDN edge gần nhất thay vì đi thẳng về server gốc.

2. Transport time - request: Request chỉ cần di chuyển một đoạn ngắn hơn trên Internet để đến máy chủ CDN gần khu vực người dùng.

3. Edge time: CDN edge kiểm tra cache, tìm thấy nội dung phù hợp và chuẩn bị phản hồi ngay tại edge.

4. Transport time - response: Response được trả về từ CDN edge đến trình duyệt, thường nhanh hơn so với việc phải đi đến server gốc ở xa.

5. Browser time - response: Trình duyệt tải, phân tích và hiển thị nội dung.

Ở tình huống này, hiệu suất được cải thiện vì hai lý do chính. Thứ nhất, server gốc không phải xử lý request đó. Thứ hai, dữ liệu được trả về từ vị trí gần người dùng hơn, nên thời gian truyền tải ngắn hơn.

Đây cũng là lý do các tài nguyên tĩnh như ảnh, CSS, JavaScript, font chữ, file tải xuống hoặc video thumbnail thường là nhóm nên được đưa lên CDN đầu tiên.

Tình huống 2: CDN edge chưa có nội dung trong cache

Không phải lúc nào CDN cũng có sẵn nội dung. Nếu tài nguyên chưa từng được request, cache đã hết hạn, vừa bị purge hoặc rule không cho phép cache, CDN sẽ phải gọi về server gốc để lấy dữ liệu.

Flow khi đó sẽ như sau:

1. Browser time - request Trình duyệt gửi request đến CDN edge gần nhất.

2. Transport time - request Request đi đến CDN edge, sau đó CDN tiếp tục gửi request về server gốc thông qua tuyến mạng tối ưu.

3. Back-end time Server gốc nhận request, xử lý dữ liệu và tạo response như mô hình thông thường.

4. Transport time - response Response được gửi từ server gốc về CDN edge, sau đó CDN trả tiếp về trình duyệt người dùng.

5. Browser time - response Trình duyệt tải nội dung, phân tích và hiển thị trang.

Trong tình huống này, CDN vẫn có thể giúp cải thiện hiệu suất nếu nhà cung cấp CDN có tuyến truyền tốt, tối ưu TCP, HTTP/2, HTTP/3 hoặc routing hiệu quả. Tuy nhiên, mức cải thiện sẽ không rõ bằng cache hit. Nếu phần lớn request đều là cache miss, website vẫn phụ thuộc nhiều vào server gốc.

Đây là điểm nhiều đội kỹ thuật dễ bỏ qua. Họ bật CDN, thấy website có vẻ nhanh hơn, nhưng không theo dõi cache hit ratio, không biết tài nguyên nào đang được phục vụ từ edge, tài nguyên nào vẫn quay về origin. Khi có sự cố, rất khó xác định vấn đề nằm ở CDN, origin hay trình duyệt.

Từ hai tình huống trên, chúng ta có thể thấy CDN có thể tạo ra sự khác biệt lớn về performance của website và thay đổi cách bạn theo dõi trang web của mình.

Bởi vì, trong khi bạn vẫn có thể nhìn thấy cùng một số liệu về tốc độ trước và sau, họ không giải thích được những gì xảy ra ở phần giữa, điều này khiến bạn sẽ gặp phải điểm mù.

Bạn có thể gặp phải sự chậm trễ đột ngột (hoặc tăng tốc đột ngột) trong thời gian tải trang tổng thể mà không hề có sự thay đổi những số liệu về back-end hay browser, điều này khiến cho việc khắc phục sự cố gặp khó khăn.

Điều này đã chỉ ra một lỗ hổng lớn trong chiến lược giám sát chung của bạn và mình hy vọng khoảng trống này đồng thời sẽ khuyến khích bạn tìm hiểu cách hoạt động của CDN và cách giám sát nó. Trong những bài viết tiếp theo, mình sẽ theo dõi thực tế CDN cùng với các phần còn lại của các hệ thống, và sẽ giúp bạn biết được những chỉ số quan trọng nào (KPIs)  của mỗi hệ thống mà bạn cần phải thu thập được và tập trung vào.

>> Có thể bạn quan tâm: 6 cách tăng tốc website WordPress dễ thực hiện với hiệu quả không ngờ

Bizfly Cloud via blogs.akamai.com