Server Timing Header

Server Timing Header là gì?

Server Timing Header là một tiêu đề HTTP (HTTP response header) do máy chủ gửi về trình duyệt, cung cấp dữ liệu thời gian chi tiết cho từng giai đoạn xử lý yêu cầu phía server — như kết nối cơ sở dữ liệu, truy vấn cache, render template, gọi API bên ngoài hoặc xử lý logic nghiệp vụ. Header này không ảnh hưởng đến nội dung trang, mà chỉ hỗ trợ giám sát và tối ưu hiệu năng.

Định dạng chuẩn theo W3C Server-Timing specification:
Server-Timing: db;dur=124.5;desc="Primary DB query", cache;dur=8.2;desc="Redis hit", render;dur=47.9

Mỗi phần sau dấu phẩy là một 'metric' gồm tên (key), thời gian thực thi (dur tính bằng mili giây), và mô tả tuỳ chọn (desc). Trình duyệt lưu thông tin này trong Performance API và hiển thị trong tab Network hoặc Timing của DevTools.

Tại sao quan trọng trong SEO?

Google và các công cụ tìm kiếm hiện đại đánh giá trải nghiệm người dùng (UX) như một yếu tố xếp hạng trực tiếp. Trong đó, tốc độ tải trang — đặc biệt là Time to First Byte (TTFB) — là tín hiệu quan trọng. Server Timing Header giúp xác định chính xác nguyên nhân làm chậm TTFB, thay vì chỉ đoán chừng từ tổng thời gian phản hồi.

Khi bạn biết rõ 70% TTFB đến từ truy vấn database chậm, bạn có thể tối ưu index, thêm cache hoặc tách service — chứ không phải tối ưu CSS thừa hay nén ảnh vô ích. Điều này giúp giảm thời gian chờ đầu vào (backend latency), từ đó cải thiện Core Web Vitals như INP và LCP — hai chỉ số Google dùng để phân loại trang 'tốt', 'trung bình', 'kém' về hiệu năng.

Lưu ý: Server Timing Header không phải yếu tố xếp hạng trực tiếp, nhưng là công cụ thiết yếu để đạt được các chỉ số xếp hạng liên quan đến hiệu năng — điều mà Google khẳng định rõ trong tài liệu chính thức.

Cách hoạt động

Khi trình duyệt gửi yêu cầu (ví dụ: GET /product/123), máy chủ xử lý qua nhiều bước: kiểm tra auth → đọc từ cache → truy vấn DB → render HTML → gửi phản hồi. Server Timing Header được thêm vào phần header của phản hồi HTTP trước khi thân trang được gửi đi.

Trình duyệt thu thập các metric từ header này, ghép với các sự kiện khác (DNS lookup, TCP handshake, TLS negotiation…) để xây dựng biểu đồ thời gian đầy đủ. Dữ liệu này khả dụng qua JavaScript qua performance.getEntriesByType('navigation') hoặc performance.getEntriesByName('navigation'), trong thuộc tính serverTiming.

Không cần cấu hình phía client: mọi trình duyệt hỗ trợ Server Timing (Chrome 65+, Edge 79+, Firefox 117+, Safari 16.4+) đều tự động ghi nhận và hiển thị nếu header tồn tại.

Hướng dẫn thực hiện

Dưới đây là các bước triển khai trên các nền tảng phổ biến:

1. Đo thời gian từng bước: Dùng microtime(true) (PHP), process.hrtime() (Node.js), hoặc time.time_ns() (Python) để đo chênh lệch trước/sau mỗi tác vụ.
2. Định dạng header đúng chuẩn: Ghép các metric thành chuỗi, đảm bảo độ dài tổng không vượt 8KB (giới hạn chung của header HTTP).
3. Gửi header trước khi xuất nội dung: Tránh lỗi “headers already sent” bằng cách kiểm tra trạng thái output buffer.

Ví dụ trên Node.js (Express):

app.get('/product/:id', (req, res) => {
  const startDB = process.hrtime.bigint();
  // ... truy vấn DB
  const endDB = process.hrtime.bigint();
  
  const dbDur = Number(endDB - startDB) / 1e6; // chuyển sang ms
  
  res.set('Server-Timing', 
    `db;dur=${dbDur.toFixed(1)};desc="PostgreSQL query", ` +
    `cache;dur=2.4;desc="Redis hit"`
  );
  
  res.send(html);
});

Lỗi thường gặp

• Header bị cắt ngang hoặc không hiển thị: Do độ dài vượt giới hạn — giải pháp: giới hạn tối đa 3–5 metric, loại bỏ mô tả dài hoặc metric không cần thiết.
• Thời gian hiển thị sai (âm hoặc >10s): Thường do dùng Date.now() thay vì hàm đo chênh lệch chính xác — sửa bằng process.hrtime() hoặc hrtime().
• Không thấy trong DevTools dù đã gửi header: Kiểm tra xem request có phải cached không — Server Timing chỉ có mặt ở phản hồi gốc (không có trong cache 304 hoặc từ Service Worker). Thử tắt cache trong tab Network hoặc dùng curl -I để kiểm tra raw header.

Ví dụ thực tế

Một trang danh mục sản phẩm trả về header sau:

Metric	dur (ms)	Mô tả
auth	12.3	Xác thực JWT token
cache	3.1	Cache Redis hit cho category tree
db	187.6	SELECT * FROM products WHERE category_id = ?
render	64.2	Render EJS template với 42 biến

Phân tích: 187.6ms chiếm ~65% tổng thời gian backend → ưu tiên tối ưu truy vấn DB (thêm index, phân trang, hoặc cache kết quả). Sau khi thêm index, db giảm còn 24.1ms — TTFB từ 240ms xuống còn 98ms. Đo lại Core Web Vitals: LCP cải thiện từ 3.2s → 1.9s, đạt mức 'tốt' theo tiêu chuẩn Google.

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

Server Timing Header có ảnh hưởng đến tốc độ tải trang không?

Không. Header chỉ thêm vài trăm byte vào phần header HTTP, không làm chậm quá trình truyền dữ liệu hay render. Chi phí đo thời gian cũng dưới 0.1ms — không đáng kể so với các tác vụ khác.

Có thể dùng Server Timing để theo dõi lỗi không?

Không trực tiếp. Server Timing chỉ ghi thời gian, không báo lỗi. Nhưng bạn có thể kết hợp với metric như error;dur=0;desc="DB connection failed" để đánh dấu — tuy nhiên trình duyệt sẽ không hiển thị khác biệt. Việc theo dõi lỗi nên dùng hệ thống logging riêng (ví dụ: Sentry, Datadog).

Server Timing có hoạt động với CDN hoặc reverse proxy không?

Tùy trường hợp. Nếu CDN (như Cloudflare, Vercel) hoặc reverse proxy (Nginx, Apache) không truyền lại header từ origin, metric sẽ mất. Một số CDN hỗ trợ forward header nếu bật tính năng Origin Shield hoặc cấu hình proxy_pass_request_headers on;. Nên kiểm tra bằng curl -I từ client thật.