Trang chủ liên tục quay vòng tải nhưng sau khi làm mới lại nhanh hơn; phần văn bản đã hiển thị nhưng hình ảnh vẫn chưa xuất hiện; truy cập từ văn phòng hoàn toàn bình thường nhưng khách hàng sử dụng mạng di động lại phải chờ rất lâu. Tất cả đều có thể được gọi là “website chậm”, nhưng nguyên nhân có thể nằm ở những vị trí hoàn toàn khác nhau.

Khi website tải chậm, trước tiên hãy kiểm tra phân giải DNS và quá trình thiết lập kết nối, sau đó kiểm tra thời gian chờ đến byte đầu tiên, rồi mới kiểm tra hình ảnh, script, API và quá trình render của trình duyệt. Xác định thời gian bị dồn vào giai đoạn nào sẽ giúp判断 nên tối ưu đường truyền, máy chủ origin, bộ nhớ đệm hay mã frontend.

CDN07 khuyến nghị ghi lại một lần truy cập hoàn chỉnh trước khi thay đổi bất kỳ cấu hình nào. Ngay cả khi đã sử dụng CDN, vẫn cần kiểm tra theo đúng đường đi thực tế của request.

Website chậm ở đâu? Trước tiên hãy dùng hiện tượng để thu hẹp phạm vi kiểm tra

Đừng chỉ ghi nhận rằng “trang chủ mất 5 giây để tải”. Cùng một tổng thời gian tải có thể xuất phát từ những vấn đề hoàn toàn khác nhau.

Bảng này dùng để xác định điểm bắt đầu kiểm tra, không thể thay thế cho quá trình chẩn đoán. Màn hình trắng có thể xảy ra trước khi HTML được trả về, nhưng cũng có thể xảy ra sau khi các tài nguyên đã tải xong.

Trước khi kiểm tra, hãy ghi lại URL cụ thể, thời điểm xảy ra, khu vực, nhà mạng, thiết bị và trạng thái đăng nhập. Lặp lại bài kiểm tra vài lần trong cùng điều kiện, đồng thời lưu cả kết quả lỗi và kết quả chậm, thay vì chỉ chọn lần nhanh nhất.

Nếu chỉ trang sản phẩm chậm trong khi trang chủ và các tệp tĩnh hoạt động bình thường, phạm vi kiểm tra sẽ khác với trường hợp tất cả các trang đều chậm. Hãy xác định request bị ảnh hưởng trước để các bước tiếp theo có định hướng rõ ràng.

Cách ghi nhận thời gian DNS, thiết lập kết nối và byte đầu tiên

Công cụ dành cho nhà phát triển của trình duyệt có thể phân tách một request thành nhiều giai đoạn. Trước tiên cần phân biệt rõ các khái niệm sau:

Các giai đoạn này không đơn giản là những thành phần có thể cộng trực tiếp thành tổng thời gian tải trang. Hình ảnh, script và API có thể được request song song, đồng thời một số kết nối có thể được tái sử dụng; thời điểm trang hiển thị phụ thuộc vào các tài nguyên quan trọng và mối quan hệ phụ thuộc giữa chúng.

Với Chrome, có thể ghi nhận theo các bước sau:

1. Mở Developer Tools và chuyển đến bảng Network.
2. Xác nhận No throttling đang được chọn để tránh vô tình giữ lại cấu hình mô phỏng mạng yếu.
3. Khi cần kiểm tra chuỗi chuyển hướng, bật Preserve log rồi làm mới trang.
4. Tìm tài liệu chính có loại Document/Doc, sau đó nhấp vào Timing.
5. Ghi lại DNS, Connect, Waiting (TTFB) và Content Download, sau đó kiểm tra các request khác ảnh hưởng đến nội dung hiển thị đầu tiên.

Nếu muốn so sánh ảnh hưởng của cache trình duyệt, có thể bật Disable cache rồi kiểm tra thêm một lần. Điều này không đồng nghĩa với việc xóa cache CDN và cũng không có nghĩa DNS hay trạng thái kết nối đã được reset hoàn toàn. Nếu website sử dụng Service Worker, cũng cần kiểm tra xem phản hồi có được cung cấp bởi chương trình phía trình duyệt này hay không. Thao tác và giải thích các giai đoạn Network trong Chrome

DNS phân giải chậm: cần kiểm tra những thông tin nào?

DNS chậm có nghĩa là client có thể đã tiêu tốn thời gian ngay cả trước khi bắt đầu kết nối. Trước tiên hãy xác định domain chính của website bị chậm hay một domain khác được dùng cho hình ảnh, font, analytics và các tài nguyên khác.

Sau đó kiểm tra các bản ghi trong hệ thống quản lý domain: website có vừa được di chuyển hay không, CNAME có trỏ tới endpoint hiện tại hay không, A và AAAA có còn phù hợp với thiết kế triển khai hay không. A record tương ứng với địa chỉ IPv4, còn AAAA record tương ứng với địa chỉ IPv6, vì vậy cần kiểm tra riêng từng loại.

Trên môi trường Windows, macOS hoặc Linux có cài nslookup, có thể truy vấn bản ghi của domain mẫu như sau:

nslookup -type=A example.com
nslookup -type=AAAA example.com

Thay example.com bằng domain của bạn. Các truy vấn này không thay đổi cấu hình DNS mà chỉ hiển thị kết quả do dịch vụ DNS được lệnh sử dụng trả về, vì vậy kết quả có thể không giống hoàn toàn với trình duyệt sử dụng Secure DNS. Có thể tham khảo cách sử dụng tham số tại Tài liệu nslookup của BIND.

Trong kết quả, cần phân biệt địa chỉ của chính máy chủ DNS với kết quả truy vấn domain. Lấy được A hoặc AAAA record chỉ cho thấy truy vấn này đã trả về một địa chỉ; điều đó không thể tự nó chứng minh website đã được kết nối đúng với CDN. Nếu truy vấn timeout hoặc trả về không tồn tại, cũng cần kiểm tra lại chính tả domain, dịch vụ DNS và chuỗi bản ghi authoritative.

Việc các khu vực khác nhau trả về các địa chỉ IP khác nhau không nhất thiết là bất thường; cơ chế điều phối traffic của CDN có thể tạo ra các kết quả khác nhau. Ngược lại, cùng một địa chỉ IP cũng không chứng minh mọi người dùng đang đi qua cùng một đường mạng.

Nếu chỉ một mạng thường xuyên phân giải DNS chậm, trước tiên hãy giữ lại kết quả truy vấn từ môi trường đó và thực hiện so sánh. Nếu nhiều mạng đều gặp vấn đề, hãy kiểm tra dịch vụ DNS authoritative và chuỗi bản ghi. Không nên xóa CNAME do nhà cung cấp yêu cầu chỉ để “giảm một lần truy vấn DNS”.

Nếu trình duyệt không hiển thị thời gian DNS riêng biệt, điều này có thể liên quan đến cache hoặc việc tái sử dụng kết nối. Điều đó không có nghĩa là lần truy cập đầu tiên không phải chịu chi phí của quá trình DNS lookup.

Thiết lập kết nối chậm không đồng nghĩa máy chủ được cấu hình kém

Sau khi DNS hoàn tất, client vẫn cần thiết lập kết nối. Một kết nối HTTPS mới thông thường sử dụng HTTP/1.1 hoặc HTTP/2 có thể bao gồm kết nối TCP và TLS handshake; HTTP/3 sử dụng QUIC nên không thể áp dụng nguyên trạng cách phân tách thời gian dựa trên TCP.

Khi giai đoạn kết nối kéo dài bất thường, hãy ghi nhận địa chỉ từ xa, giao thức, mạng của người dùng và thời điểm xảy ra, sau đó kiểm tra xem có retry, packet loss, tắc nghẽn, giới hạn kết nối hoặc vấn đề cấu hình TLS hay không.

Có ba điểm khác biệt rất dễ bị bỏ qua.

Kết nối từ trình duyệt tới node CDN không giống với kết nối từ CDN tới máy chủ origin. Origin server là hệ thống backend thực sự lưu trữ nội dung hoặc chạy ứng dụng. Sau khi triển khai CDN, bản ghi trên trình duyệt thường chỉ cho thấy trực tiếp đoạn đường tới edge node; kết nối từ CDN về origin cần được đánh giá dựa trên dữ liệu phía máy chủ.

Ping đo một loại tương tác khác. Ping không phản ánh HTTPS handshake, hàng đợi xử lý ứng dụng, truy vấn cơ sở dữ liệu, tải tài nguyên hay thực thi script, vì vậy Ping thấp không đảm bảo trang sẽ tải nhanh.

Chuyển hướng ở điểm vào cũng tiêu tốn thời gian. Từ HTTP chuyển sang HTTPS, sau đó từ domain gốc sang www và cuối cùng chuyển tới trang ngôn ngữ có thể tạo ra nhiều response trước khi HTML cuối cùng được trả về. Hãy kiểm tra xem từng lần chuyển hướng có thực sự cần thiết hay không, đồng thời để các liên kết nội bộ trỏ trực tiếp tới đích chính xác.

Trong trường hợp một số nhà mạng hoặc giờ cao điểm bị chậm rõ rệt, hãy so sánh cùng URL trong các khoảng thời gian gần nhau thay vì lấy kết quả từ mạng cố định ban ngày so với mạng di động buổi tối. Với các dịch vụ phục vụ nhiều khu vực, có thể kết hợp phương pháp tối ưu truy cập website quốc tế cho người dùng tại Trung Quốc đại lục để xây dựng các bài kiểm tra đối chiếu giữa nhiều mạng khác nhau.

TTFB cao: làm thế nào để phân biệt vấn đề mạng và vấn đề origin

TTFB là thời gian đến byte đầu tiên, tức chỉ số thể hiện thời gian chờ trước khi byte đầu tiên của phản hồi bắt đầu tới. Tuy nhiên, điểm bắt đầu đo thời gian có thể khác nhau giữa các công cụ.

TTFB ở cấp độ điều hướng trang có thể bao gồm DNS, kết nối và các giai đoạn khác trước khi nhận byte đầu tiên; trong Chrome Network, Waiting (TTFB) phản ánh thời gian chờ sau khi request được gửi và cũng bao gồm thời gian round-trip của mạng. Trước khi so sánh hai con số, cần xác nhận chúng sử dụng cùng một cách định nghĩa. Định nghĩa TTFB của web.dev

Vì vậy, việc thấy TTFB là 1 giây không có nghĩa máy chủ đã mất 1 giây để thực thi code. Với request đi qua CDN, khoảng thời gian này còn có thể bao gồm xử lý tại edge, request về origin và các proxy trung gian.

So sánh tệp tĩnh công khai với request động

Trong cùng một khoảng thời gian, hãy so sánh trang ứng dụng với một tệp tĩnh công khai có dung lượng nhỏ.

Nếu tệp tĩnh tải nhanh nhưng một API cụ thể liên tục phải chờ lâu, hãy ưu tiên kiểm tra quá trình xử lý ứng dụng của API đó, truy vấn cơ sở dữ liệu, lời gọi dịch vụ bên ngoài và hàng đợi. Tuy nhiên, hai loại request này có thể sử dụng cache hoặc backend khác nhau, vì vậy vẫn cần dùng log để xác nhận.

Nếu nhiều loại request đều chậm, hãy kiểm tra mạng, proxy và tài nguyên origin mà chúng cùng đi qua. Đừng chỉ kiểm tra trang chủ rồi kết luận toàn bộ hệ thống đều có vấn đề.

Sau khi triển khai CDN, hãy kiểm tra request có thực sự được phục vụ từ cache hay không

CDN có thể lưu các response phù hợp để cache tại các node phân phối. Khi cache hit, một phần request không cần truy cập origin thêm lần nữa; khi cache miss hoặc cần xác thực lại, request có thể tiếp tục đi về origin. Có thể tham khảo Nguyên lý cache và phân phối CDN để hiểu cách hoạt động cơ bản.

Kiểm tra đường đi của request chậm, quy tắc cache, response header và log. Các trường thể hiện trạng thái cache khác nhau tùy sản phẩm; ý nghĩa cụ thể cần tham khảo tài liệu của từng nhà cung cấp. Việc không nhìn thấy một response header quen thuộc không đủ để kết luận rằng không có cache.

Tài nguyên công khai và dữ liệu cá nhân phải được xử lý riêng. Không nên bật shared cache cho toàn bộ website chỉ để giảm TTFB đối với trạng thái đăng nhập, giỏ hàng hoặc thông tin tài khoản. Quy tắc cache phải phù hợp với phạm vi xác thực và nội dung response. Giải thích về HTTP caching và shared caching

Sử dụng request ID để đối chiếu log trên trình duyệt và phía máy chủ

Khi có thể, hãy sử dụng request ID để liên kết log của edge, Web server và ứng dụng. Nếu không có ID thống nhất, ít nhất hãy đối chiếu thời gian, đường dẫn và mã trạng thái.

Nếu trình duyệt chờ rất lâu nhưng thời gian xử lý của ứng dụng lại ngắn, vẫn còn những thành phần ngoài log ứng dụng cần kiểm tra. Nếu bản thân log ứng dụng đã cho thấy thời gian xử lý dài, hãy tiếp tục kiểm tra truy vấn cơ sở dữ liệu, API bên ngoài hoặc các tác vụ tính toán.

Nếu tải trên origin tăng bất thường, cũng cần kiểm tra xem các request ứng dụng có đang đi vòng qua điểm vào CDN dự kiến hay không. Nếu đã sử dụng CDN nhưng vẫn tồn tại các đường truy cập trực tiếp khác, có thể tiếp tục tham khảo hướng kiểm tra việc lộ địa chỉ IP origin và bảo vệ truy cập. Không nên chỉ dựa vào việc tải tăng để kết luận đã xảy ra tấn công.

HTML trả về nhanh nhưng tại sao hình ảnh và toàn bộ trang vẫn chậm?

HTML trả về nhanh chỉ cho thấy request tài liệu chính hoạt động tốt. Phần nội dung hiển thị đầu tiên vẫn có thể phải chờ hình ảnh, CSS, JavaScript hoặc API của ứng dụng.

Khi kiểm tra các tài nguyên quan trọng, trước tiên hãy xem hai mốc thời gian: request bắt đầu lúc nào và mất bao lâu kể từ khi bắt đầu.

Nếu một hình ảnh quan trọng trong phần đầu trang bắt đầu tải rất muộn, vấn đề có thể nằm ở việc phát hiện tài nguyên hoặc quan hệ phụ thuộc. Ví dụ, nếu phải chờ JavaScript chạy xong mới chèn hình ảnh vào trang, việc giảm kích thước hình ảnh chỉ cải thiện phần tải xuống mà không loại bỏ được thời gian chờ trước đó.

Nếu nội dung chính trong vùng nhìn thấy là một hình ảnh lớn, hãy kiểm tra xem trình duyệt có thể phát hiện hình ảnh đủ sớm hay không. Không nên áp dụng máy móc cơ chế lazy loading dành cho hình ảnh nằm ngoài vùng nhìn thấy. LCP (Largest Contentful Paint) có thể dùng để quan sát thời điểm nội dung chính trong vùng nhìn thấy được hiển thị, nhưng điều đó không có nghĩa mọi chức năng đã sẵn sàng để sử dụng. Hướng dẫn tối ưu tài nguyên hiển thị ban đầu và LCP

Nếu tài nguyên bắt đầu tải đúng lúc nhưng mất nhiều thời gian mới hoàn tất, hãy kiểm tra:

• Độ phân giải và định dạng hình ảnh có phù hợp với kích thước hiển thị thực tế hay không;
• Tài nguyên văn bản có sử dụng phương thức nén phù hợp hay không;
• Có đang tải cùng lúc quá nhiều tệp chưa cần thiết cho phần hiển thị đầu tiên hay không;
• Domain tài nguyên có sử dụng cấu hình CDN và cache như dự kiến hay không.

Nếu tài nguyên đã tải xong nhưng trang vẫn phản hồi chậm, hãy chuyển sang bảng Performance để kiểm tra script và quá trình render. Khi JavaScript chiếm dụng main thread của trình duyệt trong thời gian dài, người dùng vẫn có thể không nhìn thấy nội dung kịp thời hoặc không thể thao tác trên trang, ngay cả khi tốc độ truyền tệp đã được cải thiện.

Cũng cần kiểm tra riêng font, analytics và script hỗ trợ khách hàng của bên thứ ba. Việc đưa website chính lên CDN không có nghĩa các domain độc lập này cũng tự động được tối ưu.

Dùng curl để kiểm tra lại: chính xác request đang tốn thời gian ở đâu

Trình duyệt phù hợp để quan sát các dependency của toàn bộ trang, trong khi curl phù hợp để kiểm tra lại một URL cụ thể. Lệnh dưới đây có thể sử dụng trong Shell phổ biến trên Linux hoặc macOS để kiểm tra một request GET thông thường:

curl -sS -o /dev/null \
  --connect-timeout 10 --max-time 30 \
  -w 'status=%{http_code}\ndns=%{time_namelookup}\nconnect=%{time_connect}\ntls=%{time_appconnect}\nready=%{time_pretransfer}\nfirst_byte=%{time_starttransfer}\ntotal=%{time_total}\n' \
  'https://www.example.com/'

Thay địa chỉ bằng trang của bạn. -o /dev/null loại bỏ nội dung tải xuống; -sS ẩn thanh tiến trình nhưng vẫn giữ thông tin lỗi; hai tham số timeout lần lượt giới hạn thời gian chờ ở giai đoạn kết nối và toàn bộ thao tác. Trên Windows, cần sử dụng curl.exe, đích đầu ra và cú pháp xuống dòng phù hợp với Shell tương ứng, không thể sao chép nguyên đoạn lệnh nhiều dòng này.

Đơn vị thời gian trong kết quả là giây. Các tên như dns, connect, tls chỉ là nhãn dễ đọc, tương ứng với các trường curl nằm trong dấu ngoặc nhọn. Phần lớn chúng là thời gian tích lũy tính từ lúc bắt đầu thao tác, vì vậy không thể cộng trực tiếp với nhau. Tài liệu chính thức về các trường timing của curl

Dưới đây là một ví dụ dùng để minh họa, không phải kết quả đo thực tế từ khách hàng CDN07:

Giả sử không có phản hồi tạm thời như 103, đối với một request HTTPS HTTP/1.1 hoặc HTTP/2 thông thường, được thiết lập mới, không qua proxy và không có redirect, có thể dựa vào các mốc thời gian liền kề để hỗ trợ判断: kết nối TCP mất khoảng 0.08 giây, TLS handshake khoảng 0.13 giây, khoảng thời gian từ khi hoàn tất chuẩn bị truyền tải đến khi nhận byte đầu tiên khoảng 1.20 giây, và khoảng thời gian sau byte đầu tiên khoảng 0.08 giây.

Dữ liệu này cho thấy bước tiếp theo nên ưu tiên kiểm tra mạng, proxy, request về origin và quá trình xử lý ứng dụng sau khi request được gửi. 1.20 giây vẫn không phải là thời gian thực thi của máy chủ.

Mã trạng thái cũng phải được xem xét cùng lúc. HTTP 200 không đảm bảo nội dung trả về là đúng trang mong đợi; 301 hoặc 302 cho thấy cần kiểm tra chuỗi chuyển hướng và lệnh này không tự động follow redirect; với 403, 502 hoặc 504, trước tiên cần xử lý vấn đề truy cập hoặc upstream tương ứng. Trong trường hợp lỗi hoặc timeout, không được coi dữ liệu timing chưa hoàn chỉnh là một mẫu bình thường.

curl không tiếp tục tải hình ảnh trong trang và cũng không thực thi JavaScript. Vì vậy, kết quả curl nhanh không chứng minh toàn bộ trang cũng tải nhanh.

Cách xác minh tối ưu hóa thực sự có hiệu quả, thay vì chỉ thay đổi điều kiện kiểm tra

Sau khi thay đổi cấu hình, hãy kiểm tra lại bằng cùng URL, cùng trạng thái đăng nhập và điều kiện mạng tương đương. Ghi rõ cache trình duyệt có được bật hay không, đồng thời tiếp tục kiểm tra trạng thái và nội dung phản hồi.

Tập trung so sánh những giai đoạn trước đó vốn bị chậm: DNS có nhanh hơn không, thời gian chờ byte đầu tiên có được cải thiện không, các hình ảnh quan trọng có bắt đầu tải sớm hơn không. Đừng chỉ nhìn tổng thời gian giảm bao nhiêu, vì thay đổi có thể đến từ cache trình duyệt hoặc biến động mạng tạm thời.

Với những website có khác biệt rõ rệt giữa các khu vực, ít nhất hãy bao phủ các mạng mà người dùng chính đang sử dụng. Với vấn đề trên thiết bị di động, hãy tái hiện bằng điện thoại thực tế. Mô phỏng mạng yếu trên trình duyệt máy tính để bàn giúp kiểm soát biến số, nhưng không thể hoàn toàn đại diện cho đường đi thực tế của một nhà mạng cụ thể hoặc hiệu năng của điện thoại.

Khi chuyển vấn đề cho bộ phận hỗ trợ kỹ thuật, hãy chuẩn bị URL, thời điểm xảy ra, khu vực và nhà mạng, thông tin trình duyệt và thiết bị, ảnh chụp Timing cùng request ID. Sau khi xuất HAR hoặc log, vẫn cần kiểm tra và loại bỏ token, dữ liệu cá nhân và các thông tin nhạy cảm khác; không nên chỉ dựa vào cơ chế ẩn dữ liệu mặc định của công cụ.

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

Tại sao website mở lần đầu chậm nhưng lần thứ hai lại nhanh?

Điều này có thể liên quan đến cache trình duyệt, cache CDN, cache DNS, tái sử dụng kết nối hoặc quá trình warm-up của ứng dụng. So sánh xem hai request có thực sự được gửi hay không, phản hồi đến từ đâu và những giai đoạn nào đã được rút ngắn để phân biệt nguyên nhân. Không thể chỉ dựa vào việc truy cập lại nhanh hơn để kết luận cấu hình CDN là chính xác.

TTFB vượt quá 1 giây có nghĩa là hiệu năng máy chủ không đủ phải không?

Không nhất thiết. Trước tiên hãy xác nhận cách đo, sau đó kiểm tra mạng, proxy, request về origin và log ứng dụng. Nếu thời gian xử lý của ứng dụng rất ngắn, nâng cấp máy chủ có thể không cải thiện bottleneck chính; nếu truy vấn chậm hoặc thời gian chờ trong queue đáng kể, cần tập trung xử lý backend.

Ping thấp nhưng website tải chậm có bình thường không?

Có thể xảy ra vì hai phép đo này đánh giá những thứ khác nhau. Hãy tiếp tục kiểm tra request HTTPS, thời gian đến byte đầu tiên, dung lượng tài nguyên và quá trình thực thi script; Ping thấp không thể loại trừ các vấn đề ở những giai đoạn này.

Đã sử dụng CDN nhưng website vẫn chậm, có nên đổi nhà cung cấp không?

Trước tiên hãy xác nhận request chậm có thực sự đi qua CDN hay không, nội dung có phù hợp để cache hay không, việc request về origin có chậm hay không và các tác vụ frontend có đang chặn quá trình hiển thị hay không. Chỉ khi vấn đề liên tục tập trung tại node phân phối hoặc đường mạng tương ứng và có bằng chứng từ các phép so sánh trong cùng điều kiện thì mới nên tiếp tục so sánh các phương án khác.

Website chỉ chậm ở một số khu vực, làm thế nào để xác định nguyên nhân?

Trong các khoảng thời gian gần nhau, sử dụng cùng URL để so sánh các mạng khác nhau, đồng thời ghi lại kết quả phân giải, địa chỉ từ xa, mã trạng thái và thời gian của từng giai đoạn. Cũng cần xác nhận request sử dụng IPv4 hay IPv6. Một lần đo tốc độ từ một khu vực khác không đủ để xác định nguyên nhân lâu dài, và cũng không thể chỉ dựa vào chênh lệch khu vực để kết luận website đang bị chặn.

Xóa cache có giúp website luôn nhanh hơn không?

Không. Xóa cache trình duyệt có thể khiến lần truy cập tiếp theo phải tải lại tệp, còn xóa cache CDN có thể làm tăng traffic về origin. Chỉ nên xử lý phạm vi cần thiết khi nghi ngờ nội dung hoặc trạng thái cache bất thường, sau đó xác minh kết quả.

Bắt đầu tối ưu tốc độ website từ đâu?

Khi kiểm tra, hãy nhớ bốn điểm sau:

• Trước tiên xác định request cụ thể và giai đoạn tiêu tốn thời gian, sau đó mới quyết định nên thay đổi thành phần nào.
• Thời gian đến byte đầu tiên chậm cần được đánh giá cùng với bằng chứng từ mạng và phía máy chủ, không nên trực tiếp quy cho máy chủ.
• Ngay cả khi HTML trả về nhanh, vẫn phải kiểm tra các tài nguyên quan trọng và quá trình render của trình duyệt.
• Hiệu quả sau khi triển khai CDN phải được xác minh trong cùng điều kiện, không thể chỉ dựa vào một lần kiểm tra tốc độ.

Bước tiếp theo, trước tiên hãy mở bảng Network và lưu lại bản ghi Timing của một request chậm, sau đó dùng curl để kiểm tra lại chính URL đó. Nếu vấn đề tập trung ở quá trình xử lý của origin, hãy tiếp tục kiểm tra log ứng dụng; nếu vấn đề tập trung ở việc phân phối nội dung hoặc truy cập giữa các khu vực, có thể tham khảo phương án triển khai dịch vụ CDN chống DDoS của CDN07 để đánh giá cấu hình và hướng tối ưu dựa trên đường đi thực tế của request.