Vì sao Time to First Byte của bạn chậm và nên làm gì

Bắt đầu với việc TTFB thực sự đo gì

Time to First Byte, thường được viết tắt là TTFB, là khoảng thời gian từ lúc trình duyệt yêu cầu một tài nguyên đến khi nhận được byte đầu tiên của phản hồi.

Nghe có vẻ như đây là một chỉ số của máy chủ, nhưng nó không chỉ là chỉ số của máy chủ. TTFB bao gồm nhiều bước:

• Tra cứu DNS, nếu hostname chưa được phân giải
• Thiết lập kết nối TCP
• Thương lượng TLS cho HTTPS
• Thời gian yêu cầu di chuyển đến máy chủ hoặc CDN edge
• Xếp hàng và xử lý trên máy chủ
• Thời gian phản hồi quay lại trình duyệt

Vì vậy, TTFB cao có thể có nghĩa là backend của bạn chậm. Nó cũng có thể có nghĩa là người dùng ở xa origin, CDN của bạn cấu hình sai, cache liên tục bị miss, hoặc máy chủ mất quá nhiều thời gian để quyết định gửi gì.

Điều này quan trọng vì TTFB nằm gần đầu chuỗi tải trang. Nếu tài liệu HTML đến muộn, trình duyệt cũng phát hiện CSS, JavaScript, font và hình ảnh muộn. Bạn có thể tối ưu front-end rất tốt nhưng trang vẫn có cảm giác chậm nếu phản hồi tài liệu đầu tiên mất 1,5 giây.

TTFB như thế nào được xem là chậm?

Không có một con số phổ quát phù hợp với mọi trang, khu vực và kiến trúc. Dù vậy, các ngưỡng thực tế vẫn hữu ích.

Hướng dẫn của Google trên web.dev phân loại TTFB tốt là dưới 800 ms, từ 800–1800 ms cần cải thiện, và trên 1800 ms được xem là kém. Với một trang marketing được cache tốt và phục vụ gần người dùng, bạn thường có thể làm tốt hơn nhiều. Với một dashboard xác thực phức tạp có xử lý động, con số chấp nhận được có thể cao hơn, nhưng vẫn phải giải thích được.

Thói quen quan trọng là phân đoạn con số này. TTFB trung bình toàn cầu 900 ms có thể che giấu phản hồi 150 ms cho người dùng gần CDN edge và phản hồi 2200 ms cho người dùng ở khu vực khác. Tương tự, trang chủ của bạn có thể ổn trong khi các trang tìm kiếm, danh mục hoặc trang đã đăng nhập lại âm thầm gây khó chịu.

Đo ở nhiều hơn một nơi

Đừng chẩn đoán TTFB chỉ từ một lần chạy Lighthouse. Lighthouse hữu ích, nhưng đó là một bài kiểm tra từ một môi trường duy nhất. Nếu bạn mới bắt đầu diễn giải nó, hãy đọc một cách bình tĩnh về cách đọc báo cáo Lighthouse mà không hoảng sợ — bài học chính là tách tín hiệu trong phòng thí nghiệm khỏi thực tế ngoài hiện trường.

Với TTFB, bạn cần ít nhất ba góc nhìn:

1. Công cụ dành cho nhà phát triển của trình duyệt

Mở bảng Network, tải lại với cache bị vô hiệu hóa, và kiểm tra yêu cầu tài liệu chính. Phân tích thời gian sẽ hiển thị các pha DNS, kết nối, TLS, chờ và tải xuống. Pha “waiting” thường là điều mọi người gọi là thời gian backend, dù nó cũng có thể bao gồm độ trễ upstream.

2. Kiểm thử tổng hợp từ nhiều khu vực

Chạy kiểm thử từ các vị trí gần và xa người dùng của bạn. Nếu TTFB thấp ở một khu vực và cao ở khu vực khác, hãy nghi ngờ yếu tố địa lý, định tuyến CDN, vị trí origin hoặc mức độ phủ cache trước khi viết lại mã ứng dụng.

3. Giám sát người dùng thực hoặc log máy chủ

Dữ liệu thực tế cho biết người dùng thật trải nghiệm thế nào trên nhiều thiết bị, mạng và phiên truy cập. Log máy chủ có thể cho bạn biết origin tạo phản hồi nhanh đến đâu. Chênh lệch giữa TTFB quan sát từ client và thời gian xử lý ở origin thường là nơi các vấn đề CDN và mạng xuất hiện.

Những nguyên nhân thường gặp khiến TTFB chậm

HTML của bạn không được cache

Đây là vấn đề phổ biến nhất trên các trang nội dung và trang thương mại điện tử. Tài nguyên tĩnh được cache mạnh tay, nhưng tài liệu HTML — thứ trình duyệt cần đầu tiên — lại được tạo mới ở mỗi yêu cầu.

Đôi khi điều đó là cần thiết. Nhưng thường thì không.

Nếu một trang công khai chỉ thay đổi vài lần mỗi ngày, có lẽ nó không nên yêu cầu render cơ sở dữ liệu mới cho mọi khách truy cập ẩn danh. Hãy dùng full-page caching, edge caching, static generation, hoặc các mẫu stale-while-revalidate khi phù hợp.

Kiểm tra header phản hồi để tìm các tín hiệu như Cache-Control, CDN-Cache-Status, Age, Vary, và Set-Cookie. Một trang gửi cookie duy nhất cho từng khách truy cập có thể vô tình khiến chính nó không thể cache. Nếu bạn cần một cách thực tế để suy luận về lớp này, các thói quen gỡ lỗi tương tự trong hướng dẫn của chúng tôi về redirect và HTTP header trong production áp dụng trực tiếp cho công việc với TTFB.

CDN của bạn chỉ cache tài nguyên

Nhiều đội thêm CDN rồi cho rằng công việc hiệu năng đã xong. Nhưng nếu CDN chỉ phục vụ hình ảnh, CSS và JavaScript, yêu cầu HTML đầu tiên vẫn có thể phải đi toàn bộ đường đến một máy chủ origin duy nhất.

Điều đó có thể ổn với một trang doanh nghiệp địa phương có người dùng địa phương. Nó không ổn với một nhóm người dùng quốc tế. Người dùng càng xa origin, bạn càng phải trả nhiều độ trễ hơn trước cả khi công việc backend bắt đầu.

Cấu hình CDN tốt cho TTFB thường có nghĩa là:

• Cache HTML công khai khi an toàn
• Tôn trọng các quy tắc bypass có chủ đích cho trang xác thực hoặc cá nhân hóa
• Tránh các header Vary không cần thiết khiến cache bị chia quá nhỏ
• Dùng cache purging hoặc revalidation thay vì vô hiệu hóa cache hoàn toàn
• Xác nhận rằng các edge location thực sự đang phục vụ hit, chứ không chuyển tiếp mọi yêu cầu

CDN không phải phép màu. Nó là một lớp cache và định tuyến. Hãy đối xử với nó như vậy.

Máy chủ của bạn làm quá nhiều việc trước khi phản hồi

Một đường backend chậm có thể đến từ nhiều độ trễ nhỏ: truy vấn cơ sở dữ liệu, lệnh gọi API, render template, kiểm tra feature flag, xác thực, cá nhân hóa, ghi log và cold start.

Mẫu tệ nhất là công việc phụ thuộc nối tiếp. Ví dụ:

1. Lấy dữ liệu trang
2. Sau đó lấy sản phẩm liên quan
3. Sau đó lấy giá
4. Sau đó gọi dịch vụ đề xuất
5. Sau đó render HTML

Nếu mỗi bước phải chờ bước trước đó, TTFB tăng rất nhanh. Hãy song song hóa công việc độc lập, loại bỏ các lệnh gọi không quan trọng khỏi phản hồi đầu tiên, và cache các kết quả tốn kém.

Một quy tắc hữu ích: nếu người dùng không thể nhìn thấy hoặc dùng kết quả ngay lập tức, có lẽ nó không nên chặn byte đầu tiên.

Truy vấn cơ sở dữ liệu chậm hoặc khó đoán

Cơ sở dữ liệu thường gây vấn đề TTFB vì chúng hoạt động tốt trong môi trường phát triển nhưng kém dưới lưu lượng thật. Thiếu index, join lớn, truy vấn N+1, tranh chấp lock, và tập kết quả quá lớn đều xuất hiện dưới dạng “máy chủ chậm”.

Đừng đoán ở đây. Hãy thu thập thời gian truy vấn cho các yêu cầu chậm. Xem p95 và p99, không chỉ trung bình. Một trang thường phản hồi trong 120 ms nhưng thỉnh thoảng bị chặn 4 giây vẫn sẽ tạo trải nghiệm người dùng kém.

Các cách khắc phục phổ biến gồm:

• Thêm hoặc sửa index
• Loại bỏ mẫu truy vấn N+1
• Cache dữ liệu đọc nhiều
• Phân trang các truy vấn lớn
• Chuyển truy vấn báo cáo hoặc phân tích ra khỏi thời điểm xử lý request
• Đặt timeout hợp lý cho các lệnh gọi downstream

Ứng dụng của bạn có cold start

Các nền tảng serverless và containerized có thể rất tốt, nhưng cold start có thể làm hại TTFB khi lưu lượng tăng đột biến hoặc các khu vực bị cấp thiếu tài nguyên.

Nếu yêu cầu đầu tiên sau thời gian idle chậm hơn nhiều so với các yêu cầu sau đó, hãy điều tra cold start. Bạn có thể cần provisioned concurrency, bundle nhỏ hơn, ít phụ thuộc khởi động hơn, function được làm ấm, hoặc một dạng triển khai khác cho các route nhạy cảm với độ trễ.

Đây không phải là lập luận chống lại serverless. Đây là lập luận chống lại việc giả vờ rằng mô hình runtime là vô hình.

Redirect đang lãng phí yêu cầu đầu tiên

Một redirect thêm một chu kỳ request-response nữa trước khi trình duyệt nhận được tài liệu cuối cùng. Một redirect từ http:// sang https:// có thể không tránh được với liên kết cũ, nhưng các chuỗi redirect là lãng phí.

Các chuỗi phổ biến gồm:

• http://example.com → https://example.com → https://www.example.com
• chuẩn hóa trailing slash sau khi chuẩn hóa giao thức
• redirect theo địa lý hoặc ngôn ngữ trước khi tra cứu cache
• liên kết chiến dịch cũ đi qua nhiều URL

Hãy sửa liên kết nguồn khi có thể, gộp các quy tắc redirect, và làm cho URL canonical đi thẳng. Thời gian redirect không phải lúc nào cũng được báo cáo là TTFB cho yêu cầu cuối cùng, nhưng người dùng vẫn phải trả giá cho nó.

Một trình tự gỡ lỗi thực tế

Khi TTFB có vẻ chậm, hãy dùng thứ tự này. Nó tránh sai lầm phổ biến là tối ưu mã ứng dụng trước khi xác nhận hành vi cache và định tuyến.

Bước 1: Kiểm tra tài liệu chính, không chỉ toàn bộ trang

Tìm yêu cầu cho tài liệu HTML. Ghi lại tổng TTFB và phân tích thời gian. Lặp lại với và không có cache của trình duyệt. Kiểm tra một trang công khai, một trang động và một trang đã đăng nhập nếu có liên quan.

Bước 2: So sánh các khu vực

Chạy cùng một URL từ nhiều vị trí địa lý. Nếu các khu vực chậm tương quan với khoảng cách đến origin, hãy ưu tiên CDN và edge caching. Nếu mọi khu vực đều chậm, hãy xem xét xử lý backend và năng lực origin.

Bước 3: Kiểm tra header phản hồi

Tìm cache header, cookie, Age, trạng thái CDN và Vary. Thiếu header Age hoặc cache miss lặp lại là manh mối. Header Vary: Cookie rộng trên HTML công khai thường là thứ giết cache.

Bước 4: Kiểm tra thời gian ở origin

Thêm instrumentation thời gian máy chủ. Header Server-Timing có thể phơi bày các pha backend như thời gian cơ sở dữ liệu, thời gian render và thời gian API upstream. Ngay cả các nhãn đơn giản cũng hữu ích:

Server-Timing: db;dur=82, render;dur=41, api;dur=210

Giờ đây timing trong trình duyệt có thể cho thấy máy chủ đã dành 300 ms cho công việc thật, hay độ trễ xảy ra trước khi yêu cầu đến ứng dụng của bạn.

Bước 5: Sửa độ trễ lớn nhất đã được xác nhận

Điều này nghe có vẻ hiển nhiên, nhưng các đội thường sửa thứ quen thuộc thay vì thứ đã được đo. Nếu cache miss chiếm ưu thế, hãy sửa caching. Nếu cơ sở dữ liệu chiếm ưu thế, hãy sửa truy vấn. Nếu TLS và thiết lập kết nối chiếm ưu thế với người dùng toàn cầu, hãy sửa định tuyến, độ phủ CDN hoặc địa lý origin.

Công việc front-end vẫn quan trọng. Font, hình ảnh và JavaScript ảnh hưởng đến những gì xảy ra sau khi HTML đến. Nhưng chúng không thay thế được một phản hồi đầu tiên nhanh. Nếu bạn cũng đang xử lý hiệu năng render, web fonts vẫn là một trong những cải thiện dễ đạt nhất trên nhiều trang vì chúng ảnh hưởng đến tốc độ văn bản trở nên dùng được sau khi tài liệu đến.

Những cách khắc phục thường hiệu quả

Cache HTML công khai ở edge

Với trang marketing, tài liệu, blog, landing page và trang danh mục, edge caching thường là cải thiện TTFB lớn nhất. Dùng TTL ngắn nếu nội dung thay đổi thường xuyên. Dùng stale-while-revalidate nếu nội dung hơi cũ vẫn chấp nhận được trong khi cache làm mới ở nền.

Hãy cẩn thận với cá nhân hóa. Nếu một trang thay đổi theo tiền tệ, ngôn ngữ, trạng thái đăng nhập hoặc nhóm thử nghiệm, hãy định nghĩa rõ các biến thể đó. Biến thể vô tình theo từng người dùng sẽ phá hủy hiệu quả cache.

Chuyển công việc không quan trọng ra khỏi request path

Gửi email, làm giàu dữ liệu phân tích, tạo đề xuất, gọi webhook và ghi log nặng hiếm khi nên chặn byte đầu tiên. Đưa chúng vào hàng đợi hoặc chạy sau khi phản hồi đã bắt đầu.

Giảm chuỗi phụ thuộc backend

Song song hóa các lệnh gọi độc lập. Cache phản hồi từ API chậm. Đặt timeout. Thiết kế nội dung dự phòng cho các dịch vụ hữu ích nhưng không thiết yếu.

Một widget đề xuất chậm không nên làm trễ toàn bộ trang sản phẩm.

Đưa compute đến gần người dùng hơn

Nếu người dùng của bạn toàn cầu và origin chỉ ở một khu vực, độ trễ là vấn đề mang tính cấu trúc. CDN caching có thể che phần lớn vấn đề này với nội dung công khai. Với nội dung động, hãy cân nhắc triển khai theo khu vực, edge rendering cho các route phù hợp, hoặc chuyển API đến gần nhóm người dùng hơn.

Giữ redirect thật đơn giản

Canonicalize URL trong một hop. Cập nhật liên kết nội bộ để người dùng và crawler đi thẳng đến đích cuối cùng. Kiểm tra các URL chiến dịch cũ và các lần migration nền tảng. Redirect dễ bị bỏ qua vì chúng vô hình khi hoạt động đúng, nhưng chúng vẫn tốn thời gian.

Không nên làm gì

Đừng chạy theo một con số TTFB hoàn hảo cho mọi route. Một báo cáo đã xác thực có tính toán thật sẽ không hoạt động giống một bài blog được cache.

Đừng dùng TTFB trung bình làm chỉ số duy nhất. Percentile quan trọng. Địa lý quan trọng. Loại trang quan trọng.

Đừng cho rằng có CDN nghĩa là HTML của bạn đã được cache. Hãy xác minh.

Và đừng xem TTFB là tách biệt khỏi quyết định sản phẩm. Cá nhân hóa, thử nghiệm, tồn kho thời gian thực và dịch vụ bên thứ ba đều có chi phí độ trễ. Một số đáng giá. Một số chỉ là thói quen.

<!-- tool-cta:start -->

💡 Hãy thử điều này: Khi chẩn đoán TTFB, Get Headers hiển thị trạng thái bộ nhớ đệm, thời gian máy chủ và các chuyển hướng, những yếu tố thường giải thích độ trễ đến từ đâu.

<!-- tool-cta:end -->

Phiên bản bình tĩnh của kế hoạch

TTFB chậm thường có thể khắc phục được khi bạn ngừng xem nó như một “vấn đề máy chủ” mơ hồ. Đo yêu cầu tài liệu. Phân đoạn theo khu vực và loại trang. Kiểm tra header. So sánh timing phía client với timing ở origin. Sau đó sửa nút thắt lớn nhất đã được xác nhận.

Hầu hết trang web không cần kiến trúc kỳ lạ. Chúng cần ít cache miss có thể tránh hơn, ít công việc backend chặn hơn, redirect sạch hơn, và một ý niệm rõ hơn về những gì bắt buộc phải xảy ra trước khi byte đầu tiên được gửi.