Tối ưu hoá thời gian cho byte đầu tiên

Tìm hiểu cách tối ưu hoá cho chỉ số Thời gian cho byte đầu tiên.

Jeremy Wagner

Barry Pollard

Thời gian dẫn đến byte đầu tiên (TTFB) là một chỉ số hiệu suất cơ bản trên web, đứng trước mọi chỉ số khác có ý nghĩa về trải nghiệm người dùng, chẳng hạn như Thời gian hiển thị nội dung đầu tiên (FCP) và Thời gian hiển thị nội dung lớn nhất (LCP). Điều này có nghĩa là giá trị TTFB cao sẽ làm tăng thêm thời gian cho các chỉ số theo sau giá trị đó.

Máy chủ của bạn nên phản hồi các yêu cầu điều hướng đủ nhanh để phân vị thứ 75 của người dùng 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 chỉ số TTFB là 0,8 giây trở xuống.

Điểm chính:

TTFB không phải là một chỉ số Các chỉ số quan trọng về trang web. Vì vậy, các trang web không nhất thiết phải đạt ngưỡng TTFB "tốt" miễn là ngưỡng này không cản trở khả năng đạt được hiệu suất tốt ở những chỉ số quan trọng.

Các trang web khác nhau về cách phân phối nội dung. Chỉ số TTFB thấp đóng vai trò quan trọng để khách hàng có thể nhận được mã đánh dấu càng sớm càng tốt. Tuy nhiên, nếu một trang web nhanh chóng phân phối mã đánh dấu ban đầu, nhưng mã đánh dấu đó lại yêu cầu JavaScript điền nội dung có ý nghĩa vào mã (như trường hợp Ứng dụng trang đơn (SPA)), thì việc đạt được TTFB thấp nhất có thể là điều đặc biệt quan trọng để quá trình hiển thị mã đánh dấu của ứng dụng có thể diễn ra sớm hơn.

Ngược lại, một trang web do máy chủ hiển thị và không yêu cầu nhiều công việc phía máy khách có thể có TTFB cao hơn, nhưng các giá trị FCP và LCP sẽ tốt hơn so với trải nghiệm hoàn toàn do ứng dụng hiển thị. Đây là lý do tại sao các ngưỡng TTFB là một "hướng dẫn cơ bản" và cần được cân nhắc với cách trang web của bạn phân phối nội dung cốt lõi.

Cách đo lường TTFB

Trước khi có thể tối ưu hoá TTFB, bạn cần phải quan sát mức độ ảnh hưởng của TTFB đến người dùng trang web của mình. 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 bị ảnh hưởng bởi các lệnh chuyển hướng, trong khi các công cụ trong phòng thí nghiệm thường được đo lường bằng URL cuối cùng, do đó thiếu độ trễ này.

PageSpeed Insights là một cách đơn giản để lấy cả thông tin hiện trường và 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 được hiển thị trong phần Khám phá những gì người dùng thực của bạn đang trải nghiệm trên cùng:

Một tập hợp con TTFB được hiển thị trong kiểm tra thời gian phản hồi của máy chủ:

Quá trình kiểm tra thời gian phản hồi của máy chủ trong Lighthouse không bao gồm thời gian tra cứu và chuyển hướng DNS, nên hoạt động này chỉ đại diện cho một tập hợp con của TTFB. Sự khác biệt lớn giữa dữ liệu người dùng thực và dữ liệu Lighthouse có thể cho thấy các vấn đề không rõ ràng trong quá trình chạy phòng thí nghiệm, chẳng hạn như lệnh chuyển hướng hoặc sự khác biệt về mạng.

Để tìm hiểu thêm về cách đo lường TTFB trong cả trường hợp và phòng thí nghiệm, hãy tham khảo trang chỉ số TTFB.

Tìm hiểu về TTFB cao nhờ 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 nhất là 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ư một nội dung mô tả mà con người có thể đọc được (thông qua desc).

Lưu ý: Nếu không thể đo lường độ trễ của phần phụ trợ bằng Server-Timing, thì giải pháp thay thế phù hợp có thể là sử dụng tính năng Giám sát hiệu suất ứng dụng (APM) để phát hiện và chẩn đoán các vấn đề về hiệu suất của phụ trợ.

Bạn có thể sử 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 hiển thị phía máy chủ, nếu có
• Tìm kiếm ổ đĩa
• Số lần truy cập/bỏ qua bộ nhớ đệm trên máy chủ Edge (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ữ lựa chọn của phần phụ trợ ứ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 - $dbReadStarTime) / 1e+6;

// Set the Server-Timing header:
header('Server-Timing: db;desc="Database";dur=' . $dbReadTotalTime);
?>

Khi bạn đặt tiêu đề này, tiêu đề sẽ hiển thị thông tin mà bạn có thể sử dụng trong cả phòng thí nghiệm và trong trường.

Trong trường này, mọi trang có đặt tiêu đề phản hồi Server-Timing sẽ điền sẵ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 này, dữ liệu từ tiêu đề phản hồi Server-Timing sẽ hiển thị trong bảng thời gian của thẻ Mạng trong Công cụ của Chrome cho nhà phát triển:

Tiêu đề phản hồi của Server-Timing được trực quan hoá trong thẻ mạng của Công cụ của Chrome cho nhà phát triển. Ở đây, Server-Timing được dùng để đo lường xem một yêu cầu cấp tài nguyên đã đến bộ nhớ đệm CDN hay chưa và thời gian để yêu cầu đến được máy chủ cạnh của CDN, sau đó đến điểm gốc.

Sau khi đã xác định rằng TTFB có vấn đề bằng cách phân tích dữ liệu có sẵn, bạn có thể chuyển sang bước khắc phục vấn đề.

Các cách tối ưu hoá TTFB

Khía cạnh khó khăn nhất trong việc 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 các ngăn xếp phụ trợ có thể thay đổi đáng kể. Có nhiều ngăn xếp phụ trợ và sản phẩm chứa cơ sở dữ liệu, trong đó mỗi ngăn xếp và sản phẩm chứa cơ sở dữ liệu đều có kỹ thuật tối ưu hoá riêng. Do đó, hướng dẫn này sẽ tập trung vào những gì áp dụng cho hầu hết cấu trúc, thay vì chỉ tập trung vào hướng dẫn dành riêng cho từng ngăn xếp.

Hướng dẫn dành riêng cho nền tảng

Nền tảng mà bạn sử dụng cho trang web của mình có thể tác động rất lớn đến TTFB. Ví dụ: hiệu suất của WordPress bị ảnh hưởng bởi số lượng và chất lượng của plugin hoặc chủ đề được sử dụng. Các nền tảng khác cũng bị ảnh hưởng tương tự khi nền tảng này được tuỳ chỉnh. Bạn nên tham khảo tài liệu về nền tảng của bạn để biết lời khuyên riêng cho từng nhà cung cấp nhằm bổ sung cho những lời khuyên chung về hiệu suất trong bài đăng này. Quy trình kiểm tra Lighthouse để giảm thời gian phản hồi của máy chủ cũng bao gồm một số hướng dẫn hạn chế dành riêng cho ngăn xếp.

Dịch vụ lưu trữ, lưu trữ, máy chủ lưu trữ

Thậm chí trước khi bạn xem xét các phương pháp tối ưu hóa khác, lưu trữ nên là điều đầu tiên bạn cân nhắc. Không có nhiều thông tin hướng dẫn cụ thể có thể được cung cấp ở đâ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.

Lưu trữ chia sẻ thường sẽ chậm hơn. Nếu bạn đang chạy một trang web cá nhân nhỏ và chủ yếu phân phát tệp tĩnh, thì có thể bạn đang chạy một trang web tối ưu hoá. Sau đó, một số kỹ thuật tối ưu hoá sẽ giúp bạn giảm bớt lượng TTFB đó nhiều nhất có thể.

Tuy nhiên, nếu đ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 phía máy chủ chuyên sâu khác, thì lựa chọn lưu trữ là yếu tố tối quan trọng để giảm TTFB trong lĩnh vực này.

Khi chọn nhà cung cấp dịch vụ lưu trữ, bạn cần lưu ý một số điều sau:

• Thực thể ứng dụng của bạn được phân bổ bao nhiêu bộ nhớ? Nếu không có đủ bộ nhớ, ứng dụng của bạn sẽ gặp khó khăn trong việc phân phát các trang nhanh nhất có thể.
• Nhà cung cấp dịch vụ lưu trữ có luôn cập nhật ngăn xếp phụ trợ cho bạn không? Khi chúng tôi phát hành các phiên bản mới của ngôn ngữ phụ trợ ứng dụng, phương thức triển khai HTTP và phần mềm cơ sở dữ liệu, hiệu suất của phần mềm đó sẽ được cải thiện theo thời gian. Điều quan trọng là phải hợp tác với nhà cung cấp dịch vụ lưu trữ ưu tiên loại bảo trì quan trọng này.
• Nếu bạn 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 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ủa riêng bạn có hợp lý hay không.

Lưu ý: Nếu bạn không biết chắc về hiệu suất TTFB của người dùng thực của nhà cung cấp dịch vụ lưu trữ so với các đối thủ cạnh tranh, hãy truy cập ismyhostfastyet.com để tìm hiểu thông tin này.

Có nhiều nhà cung cấp dịch vụ lưu trữ sẽ đảm nhiệm 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ả trong các nhà cung cấp dịch vụ lưu trữ chuyên trách, thì đó có thể là dấu hiệu cho thấy bạn có thể cần phải đá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ể cung cấp trải nghiệm người dùng tốt nhất có thể.

Sử dụng Mạng phân phối nội dung (CDN)

Chủ đề Cách sử dụng CDN rất hiệu quả, nhưng vì 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 của bạn vẫn có thể gặp phải TTFB cao trong trường hợp này.

CDN giải quyết vấn đề về độ gần của người dùng so với máy chủ gốc của bạn bằng cách sử dụng một mạng máy chủ được phân phối, lưu tài nguyên vào bộ nhớ đệm trên các máy chủ ở gần người dùng của bạn hơn. Những 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 nhiều lợi ích khác ngoài các máy chủ biên:

• Nhà cung cấp CDN thường đưa ra thời gian phân giải DNS cực nhanh.
• CDN có thể sẽ phân phát nội dung của bạn từ các máy chủ gần nguồn bằng cách sử dụ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 (mà HTTP/2 dựa vào) bằng cách sử dụng giao thức UDP.
• CDN cũng 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. 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 gọi là "nhân viên cạnh tranh". Tính năng này sử dụng API tương tự như API của API Worker để 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 cạnh hoặc viết lại hoàn toàn phản hồi.
• Nhà cung cấp CDN rất hiệu quả trong việc tối ưu hoá để nén. Việc nén rất khó tự thực hiện, 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 nhất định với mã đánh dấu được tạo theo kiểu động. Quá trình này phải được nén nhanh chóng.
• Nhà cung cấp CDN cũng sẽ tự động lưu nội dung phản hồi nén vào bộ nhớ đệm cho các tài nguyên tĩnh, giúp kết hợp tỷ lệ nén và thời gian phản hồi một cách hiệu quả nhất.

Mặc dù bạn cần nhiều công sức để sử dụng CDN, từ nhỏ đến đáng kể, 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 trong bộ nhớ đệm khi có thể

CDN cho phép lưu nội dung vào bộ nhớ đệm tại các máy chủ gần nguồn dữ liệu thực tế nằm gần khách truy cập hơn, miễn là nội dung được định cấu hình bằng tiêu đề HTTP Cache-Control 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 phải quay lại nguồn gốc có thể phủ nhận phần lớn giá trị của CDN.

Đối với các trang web thường xuyên cập nhật nội dung, thì ngay cả thời gian lưu vào bộ nhớ đệm ngắn cũng có thể giúp tăng hiệu suất đáng kể cho các trang web bận rộn vì chỉ khách truy cập đầu tiên trong thời gian đó phải 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 đã lưu vào bộ nhớ đệm từ máy chủ cạnh. 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 cho phép tận dụng tối đa cả hai cách: thời gian lưu bộ nhớ đệm dài, nhưng tính năng cập nhật tức thì khi cần.

Ngay cả khi việc lưu vào bộ nhớ đệm được định cấu hình chính xác, bạn vẫn có thể bỏ qua việc này 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 video này có thể trông giống nội dung khác nhau với CDN mặc dù 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 cũng có thể không được lưu vào bộ nhớ đệm. Điều này có thể dẫn đến giá trị TTFB trên một số trang cao hơn so với các trang khác. Việc tăng thời gian lưu vào bộ nhớ đệm có thể giảm tác động của điều này, nhưng xin lưu ý rằng khi thời gian lưu vào bộ nhớ đệm tăng lên, khả năng phân phát nội dung lỗi thời sẽ cao hơn.

Tác động của nội dung được lưu vào bộ nhớ đệm không chỉ ảnh hưởng đến 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 trong bộ nhớ đệm thường có thể hoạt động tốt 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 dẫn đến TTFB cao là chuyển hướng. Chuyển hướng xảy ra khi yêu cầu điều hướng 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 yêu cầu điều hướng, nhưng chắc chắn sẽ tệ hơn nếu hoạt động 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ể đặc biệt ảnh hưởng đến những trang web nhận được nhiều khách truy cập từ quảng cáo hoặc bản tin, vì các trang web này thường chuyển hướng qua các dịch vụ phân tích nhằm mục đích đo lường. Việc loại bỏ các lệnh chuyển hướng thuộc quyền kiểm soát trực tiếp của bạn có thể giúp bạn đạt được chỉ số 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 xảy ra hoàn toàn trên trang web của bạn.
• Lệnh chuyển hướng nhiều nguồn gốc, trong đó ban đầu lượt chuyển hướng xảy ra trên một nguồn khác (ví dụ: từ mộ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.

Bạn muốn 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à hoạt động mà bạn sẽ có quyền kiểm soát trực tiếp. Bạn sẽ phải kiểm tra các đường liên kết trên trang web của mình để xem liệu có đường liên kết nào dẫn đến mã phản hồi 302 hoặc 301 hay không. Thông thường, đây có thể là kết quả của việc không bao gồm lược đồ https:// (vì vậy, các trình duyệt mặc định là http:// rồi chuyển hướng) hoặc do dấu gạch chéo ở cuối không được đưa vào hoặc bị loại trừ một cách phù hợp trong URL.

Lệnh chuyển hướng nhiều nguồn gốc phức tạp hơn vì thường nằm ngoài tầm kiểm soát của bạn. Tuy nhiên, bạn nên cố gắng tránh nhiều lượt chuyển hướng nếu có thể (ví dụ: bằng cách sử dụng nhiều công cụ rút ngắ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 đến những URL mà các dịch vụ đó sử dụng.

Một nguồn thời gian chuyển hướng quan trọng khác có thể đến từ lệnh chuyển hướng HTTP- sang-HTTPS. Một cách mà bạn có thể giải quyết vấn đề này là sử dụng tiêu đề Strict-Transport-Security (HSTS). Tiêu đề này sẽ thực thi HTTPS trong lần truy cập đầu tiên vào nguồn gốc, sau đó sẽ yêu cầu trình duyệt truy cập ngay vào nguồn gốc thông qua lược đồ HTTPS trong các lần truy cập sau này.

Khi đã có sẵn chính sách HSTS tốt, bạn có thể đẩy nhanh tiến độ trong lần đầu truy cập 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.

Thận trọng: Hãy cẩn thận khi triển khai HSTS, vì việc thiết lập một chính sách quá linh hoạt mà không thử nghiệm đầy đủ có thể khiến trang web của bạn bị hỏng.

Truyền trực tuyến thẻ đánh dấu tới trình duyệt

Các trình duyệt được tối ưu hoá để xử lý thẻ đánh dấu một cách hiệu quả khi được phát trực tuyến, nghĩa là thẻ đánh dấu được xử lý theo từng phần khi được chuyển đến từ máy chủ. Điều này rất quan trọng khi tải trọng đánh dấu lớn lo ngại, vì nó có nghĩa là trình duyệt có thể phân tích cú pháp các phần đánh dấu tăng dần, thay vì đợi toàn bộ phản hồi đến trước khi phân tích cú pháp có thể bắt đầu.

Mặc dù trình duyệt rất hiệu quả trong việc xử lý mã đánh dấu phát trực tuyến, nhưng điều quan trọng là bạn phải làm tất cả những gì có thể để duy trì luồng dữ liệu đó để những đoạn đánh dấu đầu tiên đó được xử lý càng sớm càng tốt. Nếu phần phụ trợ đang làm phiền mọi thứ thì đó là một vấn đề. Do có rất nhiều ngăn xếp phụ trợ, nên hướng dẫn này sẽ không đề cập đến mọi ngăn xếp riêng lẻ cũng như những 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ể kết xuất mã đánh dấu theo yêu cầu trên máy chủ đã sử dụng một phương pháp đồng bộ cho quá trình kết xuất 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 trong quá trình hiển thị. Điều này có nghĩa là bạn không cần phải đợi phương thức API của máy chủ React kết xuất toàn bộ phản hồi trước khi được gửi đi.

Lưu ý: Không phải môi trường thời gian chạy ngôn ngữ nào cũng có thể tận dụng tính năng kết xuất phía máy chủ truyền trực tuyến. Các môi trường thời gian chạy JavaScript như Deno và Node.js hỗ trợ ngay lập tức, nhưng các nền tảng khác có thể không hỗ trợ. Hãy kiểm tra xem đây có phải là trường hợp của bạn hay không, cũng như xem bạn có thể làm gì để nâng cấp hoặc chuyển đổi thời gian chạy để đạt được hiệu suất hiển thị phía máy chủ tốt hơn.

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 phương pháp kết xuất tĩnh tạo ra các tệp HTML trong thời gian xây dựng. Khi tệp đầy đủ có sẵn ngay lập tức, 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 đánh dấu luồng. Mặc dù 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 động trong trải nghiệm người dùng), nhưng phương pháp này có thể có lợi cho những trang không yêu cầu mã đánh dấu để cá nhân hoá cho từng 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 đối với cả tài liệu và tài nguyên mà chúng tải. Lý do là vì một trình chạy dịch vụ hoạt động như một proxy giữa trình duyệt và máy chủ, nhưng liệu có tác động đến TTFB của trang web hay không phụ thuộc vào cách bạn thiết lập trình chạy dịch vụ, và cá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 lỗi thời trong khi xác thực lại 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ụ – 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 cũ trong khi xác thực lại sẽ phục vụ tài nguyên đó từ bộ nhớ đệm đầu tiên, sau đó tải thành phần đó xuống trong nền và phân phát từ bộ nhớ đệm cho các hoạt động tương tác sau này.
  • Nếu bạn có các tài nguyên tài liệu không thay đổi thường xuyên, việc sử dụng chiến lược lỗi thời trong khi xác thực lại có thể làm cho TTFB của một trang gần như ngay lập tức. Tuy nhiên, cách này sẽ không hiệu quả nếu trang web của bạn gửi mã đánh dấu được tạo tự động, chẳng hạn như mã đánh dấu sẽ 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 vào mạng đầu tiên, để tài liệu càng mới càng tốt.
  • Nếu tài liệu của bạn tải các tài nguyên không quan trọng thay đổi với 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 lớn đến trải nghiệm người dùng (chẳng hạn như việc chọn hình ảnh hoặc các tài nguyên khác không quan trọng), thì TTFB cho các tài nguyên đó có thể được giảm đáng kể bằng cách sử dụng chiến lược lỗi thời trong khi xác thực lại.
• Sử dụng cấu trúc trình chạy dịch vụ truyền trực tuyến nếu có thể. Kiến trúc trình chạy dịch vụ này sử dụng phương pháp mà trong đó các phần của tài nguyên tài liệu được lưu trữ trong bộ nhớ đệm của trình chạy dịch vụ và kết hợp với các phần nội dung trong quá trình yêu cầu điều hướng. Ảnh hưởng cuối cùng của việc sử dụng mẫu trình chạy dịch vụ này là quá trình điều hướng của bạn sẽ khá nhanh, trong khi các phần tải trọng HTML nhỏ hơn được tải xuống từ mạng. Mặc dù mẫu trình chạy dịch vụ này không hoạt động cho mọi trang web, nhưng thời gian TTFB cho tài nguyên tài liệu có thể gần như tức thì đối với các trang web có thể sử dụng nó.
• Sử dụng mô hình giao diện ứng dụng cho các ứng dụng kết xuất từ ứng dụng. Mô hình này phù hợp nhất với SPA, trong đó "giao diện" của trang có thể được phân phối tức thì từ bộ nhớ đệm của trình chạy dịch vụ, đồng thời nội dung động của trang được điền và hiển thị sau đó trong vòng đời của trang.

Dùng 103 Early Hints cho các tài nguyên quan trọng về kết xuất

Cho dù phần phụ trợ ứng dụng của bạn được tối ưu hoá đến mức nào, thì máy chủ vẫn cần 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ả những công việc tốn kém (nhưng vẫn cần thiết) đối với cơ sở dữ liệu làm chậm trễ phản hồi điều hướng đến nhanh nhất có thể. Ảnh hưởng tiềm ẩn của việc này là một số tài nguyên thiết yếu về kết xuất sau đó có thể bị trễ, chẳng hạn như CSS hoặc JavaScript (trong một số trường hợp) 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 tới trình duyệt trong khi phần phụ trợ đang bận chuẩn bị mã đánh dấu. Tiêu đề này có thể được sử dụng để gợi ý cho trình duyệt rằng có các tài nguyên quan trọng về hiển thị mà trang nên bắt đầu tải xuống trong khi đang chuẩn bị đánh dấu. Đối với các trình duyệt hỗ trợ, hiệu ứng có thể là kết xuất tài liệu (CSS) nhanh hơn và khả năng sử dụng chức năng cốt lõi của trang (JavaScript) nhanh hơn.

Lưu ý: Nếu trang web của bạn không xử lý nhiều trên phần phụ trợ để chuẩn bị mã đánh dấu (ví dụ: trang web tĩnh), thì 103 Early Hints có thể sẽ không giúp ích được nhiều. Phương pháp này có xu hướng hoạt động hiệu quả nhất cho các trang web cần nhiều thời gian phụ trợ đáng kể trước khi có thể gửi mã đánh dấu đến người dùng.

Kết luận

Vì có rất nhiều cách kết hợp ngăn xếp ứng dụng phụ trợ, nên không có một bài viết nào trình bày được mọi việc bạn có thể làm để giảm chỉ số TTFB của trang web. Tuy nhiên, đây là một số lựa chọn mà bạn có thể khám phá để thử và giúp mọi thứ hoạt động nhanh hơn một chút ở phía máy chủ.

Giống như việc tối ưu hoá mọi chỉ số, phương pháp tiếp cận phần lớn tương tự như: đo lường TTFB của bạn tại hiện trường, sử dụng các công cụ trong phòng thí nghiệm để xem chi tiết nguyên nhân và sau đó áp dụng biện pháp tối ưu hoá nếu có thể. Không phải mọi kỹ thuật đơn lẻ ở đây đều có thể khả thi cho trường hợp của bạn, nhưng một số sẽ có thể áp dụng được. Như thường lệ, bạn sẽ 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ể.

Hình ảnh chính của Taylor Vick, lấy trên Unsplash.