Tìm hiểu cách tối ưu hoá cho chỉ số Thời gian cho byte đầu tiên.
Xuất bản: Ngày 19 tháng 1 năm 2023, Lần cập nhật gần đây nhất: Ngày 28 tháng 11 năm 2025
Thời gian cho byte đầu tiên (TTFB) là một chỉ số hiệu suất web cơ bản, đứng trước mọi chỉ số quan trọng khác về trải nghiệm người dùng, chẳng hạn như Nội dung đầu tiên hiển thị (FCP) và Nội dung lớn nhất hiển thị (LCP). Điều này có nghĩa là giá trị TTFB cao sẽ làm tăng thời gian cho các chỉ số theo sau.
Máy chủ của bạn nên phản hồi các yêu cầu điều hướng đủ nhanh để 75% người dùng có trải nghiệm FCP trong ngưỡng "tốt". Theo hướng dẫn sơ bộ, hầu hết các trang web nên cố gắng đạt được TTFB từ 0,8 giây trở xuống.
Cách đo lường TTFB
Trước khi có thể tối ưu hoá TTFB, bạn cần quan sát xem chỉ số này ảnh hưởng như thế nào đến người dùng trang web của bạn. Bạn nên dựa vào dữ liệu thực tế làm nguồn chính để quan sát TTFB vì dữ liệu này chịu ảnh hưởng của lệnh chuyển hướng, trong khi các công cụ dựa trên phòng thí nghiệm thường được đo lường bằng URL cuối cùng, do đó bỏ lỡ độ trễ bổ sung này.
PageSpeed Insights là một cách để lấy cả thông tin thực tế và thông tin trong phòng thí nghiệm cho các trang web công khai có trong Báo cáo trải nghiệm người dùng trên Chrome.
TTFB cho người dùng thực tế được hiển thị trong phần Khám phá trải nghiệm của người dùng thực tế ở trên cùng:
Đối với dữ liệu trong phòng thí nghiệm, các vấn đề về TTFB sẽ xuất hiện trong thông tin chi tiết Độ trễ khi yêu cầu tài liệu:
Để tìm hiểu thêm về các cách đo lường TTFB trong cả thực tế và phòng thí nghiệm, hãy tham khảo trang chỉ số TTFB.
Tìm hiểu sự khác biệt giữa TTFB thực tế và TTFB trong phòng thí nghiệm
TTFB trong phòng thí nghiệm và TTFB thực tế có thể khác nhau vì một số lý do. Khi có sự khác biệt, bạn cần hiểu rõ lý do để có thể sử dụng hiệu quả dữ liệu trong phòng thí nghiệm nhằm cải thiện trải nghiệm người dùng.
Khi TTFB trong phòng thí nghiệm lớn hơn nhiều so với TTFB thực tế, điều này cho thấy môi trường phòng thí nghiệm bị hạn chế hơn so với trải nghiệm thông thường của người dùng. Đây không hẳn là một vấn đề, vì kết quả và đề xuất trong phòng thí nghiệm vẫn có giá trị, nhưng có thể phóng đại tác động và mức độ cải thiện.
Khi TTFB thực tế lớn hơn nhiều so với TTFB trong phòng thí nghiệm, điều này cho thấy các vấn đề không rõ ràng trong quá trình chạy trong phòng thí nghiệm, chẳng hạn như việc sử dụng bộ nhớ đệm phía máy chủ, lệnh chuyển hướng hoặc sự khác biệt về mạng. Trong trường hợp này, kết quả và đề xuất của phòng thí nghiệm có thể ít hữu ích hơn vì chúng bỏ lỡ một trong những vấn đề chính.
Để xem liệu tính năng lưu vào bộ nhớ đệm phía máy chủ có ảnh hưởng đến TTFB trong phòng thí nghiệm hay không, hãy thử kiểm tra các trang ít phổ biến hơn hoặc sử dụng các tham số URL khác nhau để lấy nội dung chưa lưu vào bộ nhớ đệm nhằm xem liệu TTFB có phù hợp hơn với TTFB tại trường hay không. Bạn cũng có thể bỏ qua tính năng lưu vào bộ nhớ đệm phía máy chủ bằng một tham số URL cụ thể. Hãy xem phần nội dung được lưu vào bộ nhớ đệm.
Đối với các lệnh chuyển hướng và sự khác biệt về mạng, số liệu phân tích về cách lưu lượng truy cập đến trang web của chúng tôi và nguồn gốc của lưu lượng truy cập đó có thể hữu ích trong việc chẩn đoán xem đó có phải là vấn đề tiềm ẩn hay không.
Gỡ lỗi TTFB cao trong trường bằng Server-Timing
Bạn có thể dùng tiêu đề phản hồi Server-Timing trong phần phụ trợ của ứng dụng để đo lường các quy trình phụ trợ riêng biệt có thể góp phần gây ra độ trễ cao. Cấu trúc của giá trị tiêu đề rất linh hoạt, chấp nhận tối thiểu một tên người dùng mà bạn xác định. Các giá trị không bắt buộc bao gồm giá trị thời lượng (thông qua dur), cũng như nội dung mô tả không bắt buộc mà con người có thể đọc được (thông qua desc).
Bạn có thể dùng Serving-Timing để đo lường nhiều quy trình phụ trợ của ứng dụng, nhưng có một số quy trình mà bạn nên đặc biệt chú ý:
- Truy vấn cơ sở dữ liệu
- Thời gian kết xuất phía máy chủ (nếu có)
- Tìm kiếm trên ổ đĩa
- Kết quả tìm kiếm trong bộ nhớ đệm của máy chủ biên (nếu sử dụng CDN)
Tất cả các phần của mục nhập Server-Timing đều được phân tách bằng dấu hai chấm và nhiều mục nhập có thể được phân tách bằng dấu phẩy:
// Two metrics with descriptions and values
Server-Timing: db;desc="Database";dur=121.3, ssr;desc="Server-side Rendering";dur=212.2
Bạn có thể đặt tiêu đề bằng ngôn ngữ mà bạn chọn cho phần phụ trợ của ứng dụng. Ví dụ: trong PHP, bạn có thể đặt tiêu đề như sau:
<?php
// Get a high-resolution timestamp before
// the database query is performed:
$dbReadStartTime = hrtime(true);
// Perform a database query and get results...
// ...
// Get a high-resolution timestamp after
// the database query is performed:
$dbReadEndTime = hrtime(true);
// Get the total time, converting nanoseconds to
// milliseconds (or whatever granularity you need):
$dbReadTotalTime = ($dbReadEndTime - $dbReadStartTime) / 1e+6;
// Set the Server-Timing header:
header('Server-Timing: db;desc="Database";dur=' . $dbReadTotalTime);
?>
Khi được đặt, tiêu đề này sẽ hiển thị thông tin mà bạn có thể sử dụng trong cả phòng thí nghiệm và thực tế.
Trong trường, mọi trang có tiêu đề phản hồi Server-Timing được đặt sẽ điền thuộc tính serverTiming trong Navigation Timing API:
// Get the serverTiming entry for the first navigation request:
performance.getEntries('navigation')[0].serverTiming.forEach(entry => {
// Log the server timing data:
console.log(entry.name, entry.description, entry.duration);
});
Trong phòng thí nghiệm, dữ liệu từ tiêu đề phản hồi Server-Timing được trực quan hoá trong bảng điều khiển Thời gian của thẻ Mạng trong Chrome DevTools:
Tại đây, Server-Timing được dùng để đo lường xem yêu cầu về tài nguyên có truy cập vào bộ nhớ đệm CDN hay không và mất bao lâu để yêu cầu truy cập vào máy chủ biên của CDN rồi đến máy chủ gốc.
Thời gian của máy chủ cũng xuất hiện trong kênh Mạng của bảng điều khiển Hiệu suất trong Chrome DevTools:
Sau khi xác định được rằng bạn có TTFB có vấn đề bằng cách phân tích dữ liệu hiện có, bạn có thể chuyển sang khắc phục vấn đề.
Cách tối ưu hoá TTFB
Khía cạnh khó khăn nhất khi tối ưu hoá TTFB là mặc dù ngăn xếp giao diện người dùng của web luôn là HTML, CSS và JavaScript, nhưng ngăn xếp phụ trợ có thể khác nhau đáng kể. Có nhiều ngăn xếp phụ trợ và sản phẩm cơ sở dữ liệu, mỗi loại đều có kỹ thuật tối ưu hoá riêng. Do đó, hướng dẫn này tập trung vào những nội dung áp dụng cho hầu hết các cấu trúc, thay vì chỉ tập trung vào hướng dẫn dành riêng cho ngăn xếp.
Hướng dẫn theo từng nền tảng
Nền tảng bạn sử dụng cho trang web có thể ảnh hưởng lớn đến TTFB. Ví dụ: hiệu suất của WordPress chịu ảnh hưởng của số lượng và chất lượng của trình bổ trợ, hoặc giao diện được sử dụng. Các nền tảng khác cũng chịu ảnh hưởng tương tự khi nền tảng được tuỳ chỉnh. Bạn nên tham khảo tài liệu về nền tảng của mình để biết lời khuyên dành riêng cho nhà cung cấp nhằm bổ sung cho lời khuyên chung về hiệu suất trong bài đăng này. Thông tin chi tiết của Lighthouse cũng bao gồm một số hướng dẫn cụ thể về ngăn xếp.
Lưu trữ, lưu trữ, lưu trữ
Trước khi xem xét các phương pháp tối ưu hoá khác, bạn nên cân nhắc dịch vụ lưu trữ trước tiên. Chúng tôi không thể đưa ra hướng dẫn cụ thể cho trường hợp này, nhưng nguyên tắc chung là đảm bảo rằng máy chủ lưu trữ trang web của bạn có khả năng xử lý lưu lượng truy cập mà bạn gửi đến.
Dịch vụ lưu trữ dùng chung thường chậm hơn. Nếu bạn đang điều hành một trang web cá nhân nhỏ chủ yếu phân phát các tệp tĩnh, thì có thể không sao. Hãy sử dụng một số kỹ thuật tối ưu hoá sau đây để giảm TTFB nhiều nhất có thể.
Tuy nhiên, nếu bạn đang chạy một ứng dụng lớn hơn với nhiều người dùng liên quan đến hoạt động cá nhân hoá, truy vấn cơ sở dữ liệu và các hoạt động chuyên sâu khác phía máy chủ, thì lựa chọn dịch vụ lưu trữ của bạn sẽ trở nên quan trọng để giảm TTFB trong thực tế.
Sau đây là một số điều cần lưu ý khi chọn nhà cung cấp dịch vụ lưu trữ:
- Phiên bản ứng dụng của bạn được phân bổ bao nhiêu bộ nhớ? Nếu ứng dụng của bạn không có đủ bộ nhớ, ứng dụng sẽ bị quá tải và gặp khó khăn trong việc phân phát trang nhanh nhất có thể.
- Nhà cung cấp dịch vụ lưu trữ của bạn có luôn cập nhật ngăn xếp phụ trợ không? Khi các phiên bản mới của ngôn ngữ phụ trợ ứng dụng, cách triển khai HTTP và phần mềm cơ sở dữ liệu được phát hành, hiệu suất của phần mềm đó sẽ cải thiện theo thời gian. Điều quan trọng là bạn phải hợp tác với một nhà cung cấp dịch vụ lưu trữ ưu tiên loại hoạt động bảo trì quan trọng này.
- Nếu bạn có các yêu cầu rất cụ thể về ứng dụng và muốn có quyền truy cập ở cấp thấp nhất vào các tệp cấu hình máy chủ, hãy hỏi xem việc tuỳ chỉnh phần phụ trợ của phiên bản ứng dụng có hợp lý hay không.
Có nhiều nhà cung cấp dịch vụ lưu trữ xử lý những việc này cho bạn, nhưng nếu bạn bắt đầu nhận thấy giá trị TTFB dài ngay cả ở các nhà cung cấp dịch vụ lưu trữ chuyên dụng, thì đó có thể là dấu hiệu cho thấy bạn cần đánh giá lại khả năng của nhà cung cấp dịch vụ lưu trữ hiện tại để có thể mang lại trải nghiệm tốt nhất có thể cho người dùng.
Sử dụng Mạng phân phối nội dung (CDN)
Chủ đề sử dụng CDN là một chủ đề quen thuộc, nhưng có lý do chính đáng: bạn có thể có một phần phụ trợ ứng dụng được tối ưu hoá rất tốt, nhưng người dùng ở xa máy chủ gốc vẫn có thể gặp phải TTFB cao trong thực tế.
CDN giải quyết vấn đề về khoảng cách giữa người dùng và máy chủ gốc bằng cách sử dụng một mạng lưới máy chủ phân tán lưu tài nguyên vào bộ nhớ đệm trên các máy chủ gần người dùng hơn về mặt vật lý. Các máy chủ này được gọi là máy chủ biên.
Nhà cung cấp CDN cũng có thể mang lại những lợi ích khác ngoài máy chủ biên:
- Các nhà cung cấp CDN thường có thời gian phân giải DNS cực nhanh.
- CDN có thể phân phát nội dung của bạn từ các máy chủ biên bằng các giao thức hiện đại như HTTP/2 hoặc HTTP/3.
- Cụ thể, HTTP/3 giải quyết vấn đề chặn đầu dòng có trong TCP (giao thức mà HTTP/2 dựa vào) bằng cách sử dụng giao thức UDP.
- CDN có thể cung cấp các phiên bản TLS hiện đại, giúp giảm độ trễ liên quan đến thời gian thương lượng TLS. Cụ thể, TLS 1.3 được thiết kế để giữ cho quá trình thương lượng TLS ngắn nhất có thể.
- Một số nhà cung cấp CDN cung cấp một tính năng thường được gọi là "edge worker", sử dụng một API tương tự như API Trình chạy dịch vụ để chặn các yêu cầu, quản lý phản hồi theo phương thức lập trình trong bộ nhớ đệm biên hoặc viết lại hoàn toàn phản hồi.
- Các nhà cung cấp CDN rất giỏi trong việc tối ưu hoá cho việc nén. Việc nén dữ liệu rất khó thực hiện đúng cách và có thể dẫn đến thời gian phản hồi chậm hơn trong một số trường hợp có mã đánh dấu được tạo động, phải được nén nhanh chóng.
- Ngoài ra, các nhà cung cấp CDN tự động lưu phản hồi nén vào bộ nhớ đệm cho tài nguyên tĩnh, giúp kết hợp tốt nhất tỷ lệ nén và thời gian phản hồi.
Mặc dù việc áp dụng CDN đòi hỏi nhiều nỗ lực từ nhỏ đến lớn, nhưng bạn nên ưu tiên tối ưu hoá TTFB nếu trang web của bạn chưa sử dụng CDN.
Sử dụng nội dung được lưu vào bộ nhớ đệm nếu có thể
CDN cho phép lưu nội dung vào bộ nhớ đệm tại các máy chủ biên nằm gần khách truy cập hơn về mặt vật lý, miễn là nội dung được định cấu hình bằng Cache-Control tiêu đề HTTP thích hợp. Mặc dù điều này không phù hợp với nội dung được cá nhân hoá, nhưng việc yêu cầu quay lại nguồn gốc có thể làm mất đi phần lớn giá trị của CDN.
Đối với những trang web thường xuyên cập nhật nội dung, ngay cả thời gian lưu vào bộ nhớ đệm ngắn cũng có thể giúp cải thiện đáng kể hiệu suất cho các trang web bận rộn, vì chỉ khách truy cập đầu tiên trong thời gian đó mới gặp phải độ trễ hoàn toàn khi quay lại máy chủ gốc, trong khi tất cả khách truy cập khác có thể sử dụng lại tài nguyên được lưu vào bộ nhớ đệm từ máy chủ biên. Một số CDN cho phép vô hiệu hoá bộ nhớ đệm trên các bản phát hành trang web, mang lại lợi ích của cả hai phương pháp: thời gian lưu vào bộ nhớ đệm dài nhưng cập nhật tức thì khi cần.
Ngay cả khi bộ nhớ đệm được định cấu hình chính xác, bạn vẫn có thể bỏ qua bộ nhớ đệm bằng cách sử dụng các tham số chuỗi truy vấn riêng biệt để đo lường số liệu phân tích. Những tham số này có thể khiến CDN coi các yêu cầu là nội dung khác nhau mặc dù chúng giống nhau, và do đó phiên bản lưu vào bộ nhớ đệm sẽ không được sử dụng.
Nội dung cũ hơn hoặc ít được truy cập hơn cũng có thể không được lưu vào bộ nhớ đệm, dẫn đến giá trị TTFB trên một số trang cao hơn các trang khác. Việc tăng thời gian lưu vào bộ nhớ đệm có thể làm giảm tác động của vấn đề này, nhưng xin lưu ý rằng thời gian lưu vào bộ nhớ đệm càng dài thì khả năng phân phát nội dung có thể đã cũ càng cao.
Tác động của nội dung được lưu vào bộ nhớ đệm không chỉ ảnh hưởng đến những người sử dụng CDN. Cơ sở hạ tầng máy chủ có thể cần tạo nội dung từ các lượt tra cứu cơ sở dữ liệu tốn kém khi không thể sử dụng lại nội dung đã lưu vào bộ nhớ đệm. Dữ liệu được truy cập thường xuyên hơn hoặc các trang được lưu trước vào bộ nhớ đệm thường có thể hoạt động hiệu quả hơn.
Tránh chuyển hướng trang nhiều lần
Một yếu tố phổ biến góp phần làm tăng TTFB là lượt chuyển hướng. Lệnh chuyển hướng xảy ra khi một yêu cầu điều hướng cho một tài liệu nhận được phản hồi thông báo cho trình duyệt rằng tài nguyên đó tồn tại ở một vị trí khác. Một lệnh chuyển hướng chắc chắn có thể làm tăng độ trễ không mong muốn cho một yêu cầu điều hướng, nhưng chắc chắn sẽ tệ hơn nếu lệnh chuyển hướng đó trỏ đến một tài nguyên khác dẫn đến một lệnh chuyển hướng khác, v.v. Điều này có thể ảnh hưởng đặc biệt đến những trang web nhận được lượng khách truy cập lớn từ quảng cáo hoặc bản tin, vì các trang web này thường chuyển hướng thông qua các dịch vụ phân tích cho mục đích đo lường. Việc loại bỏ các lệnh chuyển hướng trong tầm kiểm soát trực tiếp của bạn có thể giúp đạt được TTFB tốt.
Có hai loại lệnh chuyển hướng:
- Chuyển hướng cùng nguồn gốc, trong đó việc chuyển hướng diễn ra hoàn toàn trên trang web của bạn.
- Chuyển hướng khác nguồn gốc, trong đó quá trình chuyển hướng ban đầu xảy ra trên một nguồn gốc khác (chẳng hạn như từ dịch vụ rút ngắn URL trên mạng xã hội) trước khi đến trang web của bạn.
Hãy tập trung vào việc loại bỏ các lệnh chuyển hướng cùng nguồn gốc, vì đây là điều bạn có thể trực tiếp kiểm soát. Việc này bao gồm việc kiểm tra các đường liên kết trên trang web của bạn để xem có đường liên kết nào trả về mã phản hồi 302 hoặc 301 hay không. Thường thì điều này có thể là do không bao gồm giao thức https:// (vì vậy, trình duyệt mặc định là http://, sau đó chuyển hướng) hoặc do dấu gạch chéo ở cuối không được đưa vào hoặc loại trừ một cách thích hợp trong URL.
Các lệnh chuyển hướng khác nguồn gốc sẽ phức tạp hơn vì thường nằm ngoài tầm kiểm soát của bạn, nhưng hãy cố gắng tránh nhiều lệnh chuyển hướng nếu có thể, chẳng hạn như bằng cách sử dụng nhiều trình rút gọn đường liên kết khi chia sẻ đường liên kết. Đảm bảo URL được cung cấp cho nhà quảng cáo hoặc bản tin là URL cuối cùng chính xác, để không thêm một lệnh chuyển hướng khác vào các lệnh chuyển hướng mà các dịch vụ đó sử dụng.
Một nguồn quan trọng khác gây ra thời gian chuyển hướng có thể đến từ lệnh chuyển hướng HTTP sang HTTPS. Một cách để giải quyết vấn đề này là sử dụng tiêu đề Strict-Transport-Security (HSTS). Tiêu đề này thực thi HTTPS trong lần truy cập đầu tiên vào một nguồn gốc, sau đó yêu cầu trình duyệt truy cập ngay vào nguồn gốc đó thông qua giao thức HTTPS trong những lần truy cập sau.
Sau khi có chính sách HSTS phù hợp, bạn có thể đẩy nhanh tốc độ trong lần truy cập đầu tiên vào một nguồn gốc bằng cách thêm trang web của bạn vào danh sách tải trước HSTS.
Truyền mã đánh dấu đến trình duyệt
Trình duyệt được tối ưu hoá để xử lý mã đánh dấu một cách hiệu quả khi mã đánh dấu được truyền trực tuyến, tức là mã đánh dấu được xử lý theo từng phần khi đến từ máy chủ. Điều này rất quan trọng khi liên quan đến tải trọng đánh dấu lớn, vì điều này có nghĩa là trình duyệt có thể phân tích cú pháp các đoạn đánh dấu theo cách tăng dần, thay vì chờ toàn bộ phản hồi đến trước khi có thể bắt đầu phân tích cú pháp.
Mặc dù trình duyệt rất giỏi xử lý mã đánh dấu truyền trực tuyến, nhưng bạn cần làm mọi thứ có thể để duy trì luồng đó, nhờ đó, những đoạn mã đánh dấu ban đầu sẽ được gửi đi sớm nhất có thể. Nếu phần phụ trợ đang giữ lại mọi thứ, thì đó là một vấn đề. Vì có rất nhiều ngăn xếp phụ trợ, nên hướng dẫn này không thể đề cập đến mọi ngăn xếp và các vấn đề có thể phát sinh trong từng ngăn xếp cụ thể.
Ví dụ: React và các khung khác có thể hiển thị mã đánh dấu theo yêu cầu trên máy chủ đã sử dụng phương pháp đồng bộ để hiển thị phía máy chủ. Tuy nhiên, các phiên bản React mới hơn đã triển khai các phương thức máy chủ để truyền trực tuyến mã đánh dấu khi mã này đang được kết xuất. Điều này có nghĩa là bạn không cần phải đợi phương thức API máy chủ React kết xuất toàn bộ phản hồi trước khi gửi.
Một cách khác để đảm bảo mã đánh dấu được truyền trực tuyến đến trình duyệt một cách nhanh chóng là dựa vào kết xuất tĩnh, giúp tạo tệp HTML trong thời gian xây dựng. Khi có ngay tệp đầy đủ, máy chủ web có thể bắt đầu gửi tệp ngay lập tức và bản chất vốn có của HTTP sẽ dẫn đến việc truyền trực tuyến mã đánh dấu. Mặc dù phương pháp này không phù hợp với mọi trang trên mọi trang web (chẳng hạn như những trang yêu cầu phản hồi linh động trong trải nghiệm người dùng), nhưng phương pháp này có thể mang lại lợi ích cho những trang không yêu cầu mã đánh dấu được cá nhân hoá cho một người dùng cụ thể.
Sử dụng trình chạy dịch vụ
Service Worker API có thể tác động lớn đến TTFB cho cả tài liệu và tài nguyên mà tài liệu tải. Lý do là vì trình chạy dịch vụ đóng vai trò là proxy giữa trình duyệt và máy chủ. Tuy nhiên, việc TTFB của trang web có bị ảnh hưởng hay không còn tuỳ thuộc vào cách bạn thiết lập trình chạy dịch vụ và liệu chế độ thiết lập đó có phù hợp với các yêu cầu của ứng dụng hay không.
- Sử dụng chiến lược stale-while-revalidate cho các thành phần. Nếu một thành phần nằm trong bộ nhớ đệm của trình chạy dịch vụ, cho dù đó là tài liệu hay tài nguyên mà tài liệu yêu cầu, thì chiến lược stale-while-revalidate sẽ phân phát tài nguyên đó từ bộ nhớ đệm trước tiên, sau đó tải thành phần đó xuống ở chế độ nền và phân phát thành phần đó từ bộ nhớ đệm cho các hoạt động tương tác trong tương lai.
- Nếu bạn có tài nguyên tài liệu không thay đổi thường xuyên, thì việc sử dụng chiến lược stale-while-revalidate có thể khiến TTFB của trang gần như tức thì. Tuy nhiên, cách này không hiệu quả nếu trang web của bạn gửi mã đánh dấu được tạo linh động, chẳng hạn như mã đánh dấu thay đổi dựa trên việc người dùng có được xác thực hay không. Trong những trường hợp như vậy, bạn sẽ luôn muốn truy cập mạng trước tiên để tài liệu được cập nhật mới nhất có thể.
- Nếu tài liệu của bạn tải các tài nguyên không quan trọng và thay đổi theo tần suất nhất định, nhưng việc tìm nạp tài nguyên cũ sẽ không ảnh hưởng nhiều đến trải nghiệm người dùng (chẳng hạn như chọn hình ảnh hoặc các tài nguyên khác không quan trọng), thì bạn có thể giảm đáng kể TTFB cho các tài nguyên đó bằng cách sử dụng chiến lược stale-while-revalidate.
- Sử dụng mô hình giao diện ứng dụng cho các ứng dụng do ứng dụng khách kết xuất. Mô hình này phù hợp nhất với các SPA, trong đó "vỏ" của trang có thể được phân phối ngay lập tức từ bộ nhớ đệm của trình chạy dịch vụ, còn nội dung động của trang sẽ được điền sẵn và hiển thị sau trong vòng đời của trang.
Sử dụng 103 Early Hints cho các tài nguyên quan trọng đối với việc hiển thị
Cho dù phần phụ trợ của ứng dụng có được tối ưu hoá đến mức nào, thì máy chủ vẫn có thể phải thực hiện một lượng công việc đáng kể để chuẩn bị phản hồi, bao gồm cả công việc tốn kém (nhưng cần thiết) về cơ sở dữ liệu, khiến phản hồi điều hướng bị chậm trễ và không đến nhanh nhất có thể. Điều này có thể khiến một số tài nguyên quan trọng cho việc hiển thị sau đó bị trì hoãn, chẳng hạn như CSS hoặc (trong một số trường hợp) JavaScript hiển thị mã đánh dấu trên máy khách.
Tiêu đề 103 Early Hints là mã phản hồi sớm mà máy chủ có thể gửi đến trình duyệt trong khi phần phụ trợ đang bận chuẩn bị mã đánh dấu. Bạn có thể dùng tiêu đề này để gợi ý cho trình duyệt rằng có những tài nguyên quan trọng cho việc kết xuất mà trang nên bắt đầu tải xuống trong khi mã đánh dấu đang được chuẩn bị. Đối với các trình duyệt hỗ trợ, hiệu ứng này có thể giúp hiển thị tài liệu nhanh hơn (CSS) và tải trang nhanh hơn.
Một nhược điểm của 103 Early Hints là giống như việc lưu vào bộ nhớ đệm, chúng có thể che giấu TTFB "thực" của một trang web. Nếu cơ sở hạ tầng máy chủ chậm (do không đủ mạnh hoặc mã cần được tối ưu hoá), thì điều đó có thể ít rõ ràng hơn khi sử dụng 103 Early Hints vì TTFB có vẻ nhanh. Các trang web sử dụng 103 Early Hints nên cân nhắc việc đo lường thời gian thực tế của máy chủ (mặc dù Server-Timing hoặc finalResponseHeadersStart của PerformanceNavigationTiming API).
Kết luận
Vì có rất nhiều kiểu kết hợp ngăn xếp ứng dụng phụ trợ, nên không có bài viết nào có thể tóm tắt mọi thứ bạn có thể làm để giảm TTFB của trang web. Tuy nhiên, bạn có thể khám phá một số lựa chọn để thử và tăng tốc độ xử lý ở phía máy chủ.
Cũng như việc tối ưu hoá mọi chỉ số, phương pháp này phần lớn tương tự nhau: đo lường TTFB trong thực tế, sử dụng các công cụ trong phòng thí nghiệm để tìm hiểu kỹ nguyên nhân, sau đó áp dụng các biện pháp tối ưu hoá nếu có thể. Mặc dù một số kỹ thuật có thể không phù hợp với tình huống của bạn, nhưng một số kỹ thuật khác có thể phù hợp. Như thường lệ, bạn cần theo dõi chặt chẽ dữ liệu thực địa và điều chỉnh khi cần để đảm bảo trải nghiệm người dùng nhanh nhất có thể.