Khách hàng phàn nàn website của bạn mở chậm, nhưng khi bạn thử từ máy tính ở văn phòng thì lại thấy bình thường. Ai đúng? Thực ra cả hai đều đúng — tốc độ website phụ thuộc vào nơi người dùng đang đứng và đường mạng từ họ đến server. Một website host ở TP.HCM có thể nhanh với người ở thành phố đó nhưng ì ạch với khách ở Hà Nội, hay ngược lại.

Bài này hướng dẫn bạn đo tốc độ thật từ hai đầu đất nước và tìm ra điểm nghẽn — là do server phản hồi chậm, đường mạng vòng nhiều hop, hay website chưa hỗ trợ HTTP/2 hiện đại.

Đo nhanh ngay: nhập URL vào công cụ tổng quan website để xem tốc độ tải từ node Hà Nội và TP.HCM, kèm TTFB và trạng thái HTTP. Không cần đăng nhập.

Vì sao website chậm? TTFB, latency và HTTP version

Tốc độ cảm nhận của người dùng phụ thuộc vào nhiều tầng, nhưng ba nguyên nhân phổ biến nhất là:

Nguyên nhânBiểu hiệnCần kiểm traTTFB caoTrang "treo" trước khi bắt đầu hiển thịServer xử lý chậm, DB query nặng, thiếu cacheLatency caoCả TTFB và tải về đều chậm từ một vùngServer đặt xa, đường mạng nhiều hopChưa HTTP/2Nhiều request xếp hàng, không tận dụng multiplexingCần bật HTTP/2 trên server

TTFB (Time to First Byte) là khoảng thời gian từ lúc trình duyệt gửi request đến lúc nhận được byte đầu tiên của response. TTFB dưới 200ms là tốt; vượt 600ms là cần xem lại. TTFB cao thường chỉ thẳng vào vấn đề phía server (code, database, cache) hơn là đường mạng.

Còn latency (độ trễ) là thời gian tín hiệu đi từ người dùng đến server và ngược lại. Dù server nhanh đến mấy, người dùng ở xa vẫn thấy chậm nếu latency cao.

4 bước đo và tìm điểm nghẽn

Bước 1 — Đo TTFB và tốc độ từ node HN và HCM

Bước đầu tiên là có con số đo thật từ địa lý thật. Công cụ tổng quan website đặt node đo tại Hà Nội và TP.HCM — bạn sẽ thấy cùng một URL nhưng kết quả từ hai nơi có thể khác nhau đáng kể.

👉 Đo tốc độ: công cụ tổng quan website (TTFB, HTTP status, chuỗi redirect và meta từ node HN/HCM).

Ví dụ: shop.tencongty.vn host trên server đặt tại TP.HCM. Node HCM đo TTFB 180ms (ổn), nhưng node HN đo TTFB 480ms (cao). Rõ ràng là vấn đề khoảng cách địa lý — server không có node ở HN và chưa có CDN phân phối nội dung.

Lỗi hay gặp:

  • Chỉ đo từ máy của mình: mạng văn phòng hay cáp quang gia đình thường nhanh bất thường và gần server hơn người dùng thực tế. Đo từ node trung lập mới là con số đại diện.

  • Quên kiểm tra redirect: URL http://shop.tencongty.vn chuyển qua https:// rồi www. — mỗi redirect tốn thêm 50-200ms. Công cụ hiển thị chuỗi redirect để bạn phát hiện redirect thừa.

Bước 2 — Đo độ trễ mạng bằng ping

Sau khi có TTFB, bước tiếp theo là đo round-trip time (RTT) từ node đến server. RTT thấp (dưới 30ms trong nước, dưới 100ms quốc tế) là tốt; cao thì cần traceroute tiếp theo để tìm nguyên nhân.

👉 Ping: công cụ ping (đo RTT và tỉ lệ mất gói đến IP hoặc tên miền).

Ví dụ: ping đến server.tencongty.vn từ node HN thấy RTT trung bình 85ms — cao so với mức trong nước thông thường dưới 30ms. Đây là dấu hiệu server có thể đặt ở nước ngoài hoặc đường mạng đang đi vòng qua trạm trung gian xa.

Lỗi hay gặp:

  • Bỏ qua packet loss nhỏ (~3-5%): packet loss đều đặn dù nhỏ thường báo hiệu đường truyền có vấn đề, không phải chỉ là "ồn" tạm thời. Traceroute bước tiếp theo sẽ chỉ rõ hop nào bị drop gói.

  • Ping domain thay vì IP khi DNS chưa lan truyền: nếu vừa đổi DNS, hãy ping thẳng IP server để loại yếu tố phân giải DNS ra khỏi phương trình.

Bước 3 — Traceroute để tìm hop nghẽn

Khi ping cho RTT cao hoặc packet loss, traceroute liệt kê từng router trung gian (hop) mà gói tin đi qua, cùng độ trễ tại mỗi hop. Đây là cách xác định đường mạng đang bị nghẽn ở đâu.

👉 Traceroute: công cụ traceroute (xem từng hop, RTT tại mỗi hop, phát hiện điểm nhảy độ trễ đột ngột).

Ví dụ đọc kết quả:

Hop  1   3ms  router.vanphong.vn
Hop  2   9ms  10.0.x.x
Hop  3  14ms  hanoiix.vnpt.vn
Hop  4  16ms  core.fpt.vn
Hop  5 285ms  transit.overseas.net     <- nhay dot ngot o day
Hop  6 290ms  server.tencongty.vn

Hop 5 nhảy từ 16ms lên 285ms là điểm nghẽn. Tên overseas.net gợi ý gói tin đang đi ra nước ngoài — server có thể đặt ở nước ngoài hoặc routing bị vòng qua trạm trung gian quốc tế.

Lỗi hay gặp:

  • Lo lắng khi thấy * * * (timeout) ở vài hop: nhiều router ẩn mình theo thiết kế bảo mật, không phản hồi probe nhưng vẫn chuyển gói tin bình thường. Nếu hop tiếp theo vẫn phản hồi và RTT ổn thì không có vấn đề.

  • Chạy traceroute một lần rồi kết luận ngay: kết quả có thể thay đổi theo giờ do cân bằng tải. Nên đo vài lần ở thời điểm khác nhau để có bức tranh chính xác hơn.

Bước 4 — Kiểm tra HTTP/2 đã bật chưa

HTTP/2 cho phép gửi nhiều request song song trên một kết nối thay vì xếp hàng tuần tự. Trang có nhiều file CSS, JS và ảnh sẽ tải nhanh hơn rõ rệt khi bật HTTP/2 — thường cải thiện điểm Google PageSpeed 5-15 điểm chỉ từ bước này.

👉 Kiểm tra HTTP/2: công cụ kiểm tra HTTP/2 (xác nhận server hỗ trợ HTTP/2 hay HTTP/3 chưa).

Bật HTTP/2 thường chỉ cần thêm vài dòng vào cấu hình Nginx (listen 443 ssl http2) hoặc Apache (Protocols h2 http/1.1) — không cần thay đổi code ứng dụng.

Lỗi hay gặp:

  • Bật HTTP/2 trên Nginx nhưng quên bật HTTPS: HTTP/2 yêu cầu HTTPS. Nếu chưa có SSL thì phải cài SSL trước.

  • Test HTTP/2 từ DevTools nhưng kết quả hiển thị h1: một số proxy hoặc CDN phía trước có thể "hạ xuống" HTTP/1.1 dù origin server đã bật HTTP/2. Dùng công cụ bên ngoài để xác nhận thực tế.

Sau khi đo, kỳ vọng cải thiện thế nào?

Tốc độ website không có con số "đúng cho tất cả" vì phụ thuộc vào loại nội dung và quy mô. Nhưng một vài mốc thực tế để tham chiếu:

  • TTFB dưới 200ms từ node trong nước: tốt, không cần lo.

  • TTFB 200-600ms: chú ý — có thể cải thiện bằng cache (Redis, Nginx FastCGI cache) hoặc tối ưu query.

  • TTFB trên 600ms: cần xem lại nghiêm túc — server quá tải, thiếu cache, hoặc code có bottleneck.

  • Latency trong nước dưới 30ms: bình thường cho server đặt ở Việt Nam.

  • HTTP/2 bật: thường cải thiện rõ cho trang nhiều file mà không cần đụng code.

Sau khi điều chỉnh, hãy chạy lại đo tốc độ từ node HN/HCM để xác nhận. Đôi khi một thay đổi nhỏ — bật HTTP/2, thêm cache header, hoặc gộp vài request — đã giúp TTFB giảm một nửa.

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

TTFB là gì và bao nhiêu là ổn? TTFB (Time to First Byte) là thời gian từ lúc gửi request đến lúc nhận được byte đầu tiên. Dưới 200ms là tốt, 200-600ms nên cải thiện, trên 600ms cần xử lý. TTFB cao thường báo hiệu vấn đề phía server (xử lý, database, cache) hơn là đường mạng.

Website đo từ HN chậm nhưng HCM nhanh — làm sao? Nhiều khả năng server đặt tại hoặc gần TP.HCM. Giải pháp là dùng CDN có điểm hiện diện (PoP) tại Hà Nội để cache và phục vụ nội dung gần người dùng hơn, hoặc chuyển sang hosting có đặt server ở cả hai miền.

Traceroute thấy nhiều * * * thì có vấn đề không? Chưa chắc. Nhiều router ẩn mình theo thiết kế bảo mật, không phản hồi probe nhưng vẫn chuyển gói tin bình thường. Nếu hop cuối vẫn đến đích và RTT ổn thì * * * ở giữa không đáng lo.

Tôi cần HTTP/3 (QUIC) không? HTTP/3 giúp ích nhiều nhất với người dùng mạng di động hoặc đường truyền không ổn định. Bước ưu tiên là đảm bảo đã bật HTTP/2 — đó là cải thiện dễ nhất và rõ nhất cho phần lớn website trước khi nghĩ đến HTTP/3.

BKNS Tools — bộ công cụ đo tốc độ và chẩn đoán mạng miễn phí cho webmaster Việt. Tổng quan website · Ping · Traceroute · Kiểm tra HTTP/2 — không cần đăng nhập.