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
Jeremy Wagner

Thời gian trước byte đầu tiên (TTFB) là một chỉ số cơ bản về hiệu suất web đứng trước mọi chỉ số khác có ý nghĩa đối với 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)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ẽ thêm thời gian vào những 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 nhìn thấy FCP trong ngưỡng "tốt". Như một hướng dẫn sơ bộ, hầu hết các trang web nên cố gắng đạt được TTFB là 0,8 giây trở xuống.

Giá trị TTFB tốt là từ 0,8 giây trở xuống, giá trị kém lớn hơn 1,8 giây và bất kỳ giá trị nào giữa cần cải thiện

Cách đo lường TTFB

Trước khi có thể tối ưu hoá TTFB, bạn cần quan sát mức độ ảnh hưởng của TTFB đến người dùng trên trang web của bạn. Bạn nên coi dữ liệu thực tế làm nguồn chính để quan sát TTFB khi 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 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 đượ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:

Dữ liệu người dùng thực của PageSpeed Insights

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

Kiểm tra thời gian phản hồi của máy chủ

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

Tìm hiểu về chỉ số TTFB cao cùng với 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â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 là 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ả mà con người không bắt buộc đọc được (thông qua desc).

Serving-Timing có thể được dùng để đo lường nhiều quy trình phụ trợ của ứng dụng, nhưng bạn nên đặc biệt chú ý đến một số quy trình:

  • 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ỏ lỡ bộ nhớ đệm của 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ữ phụ trợ của ứng dụng mà bạn chọn. 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, bất kỳ trang nào có bộ 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, dữ liệu từ tiêu đề phản hồi Server-Timing sẽ được hiển thị trong bảng điều khiển thời gian của thẻ Mạng trong Công cụ của Chrome cho nhà phát triển:

Hình ảnh trực quan về các giá trị tiêu đề Thời gian máy chủ trong thẻ Mạng của Công cụ của Chrome cho nhà phát triển. Trong hình ảnh này, các giá trị tiêu đề Thời gian máy chủ đang đo lường xem máy chủ cạnh CDN có gặp phải lượt truy cập vào bộ nhớ đệm hoặc bỏ lỡ hay không, cũng như thời gian để truy xuất tài nguyên từ cạnh và máy chủ gốc.

Hiển thị tiêu đề phản hồi Server-Timing 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 về tài nguyên có nhấn vào bộ nhớ đệm CDN hay không và thời gian cần để yêu cầu đến máy chủ cạnh của CDN rồi đến nguồn gốc.

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

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

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ó rất nhiều ngăn xếp phụ trợ và sản phẩm cơ sở dữ liệu mà mỗi ngăn xếp 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á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 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ể ảnh hưởng rất nhiều đế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 trình bổ trợ 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 dành cho nền tảng của mình để biết lời khuyên cụ thể 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. 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 cụ thể dành riêng cho ngăn xếp.

Lưu trữ, lưu trữ, lưu trữ

Trước khi bạn xem xét các phương pháp tối ưu hoá khác, lưu trữ là yếu tố đầu tiên bạn nên cân nhắc. Không có nhiều thông tin về hướng dẫn cụ thể ở đâ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ỏ phân phát chủ yếu là các tệp tĩnh, thì có lẽ điều này không có vấn đề gì. Một số kỹ thuật tối ưu hoá sau đây sẽ giúp bạn giảm tỷ lệ 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 thao tác chuyên sâu khác phía máy chủ, thì lựa chọn lưu trữ của bạn trở nên 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 ứng dụng của bạn không có đủ bộ nhớ, ứng dụng sẽ gặp tình trạng rắc rối và khó phân phối các trang lên 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ợ của bạn không? Khi các phiên bản mới của ngôn ngữ phụ trợ ứng dụng, phương pháp 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 cải thiện theo thời gian. Điều quan trọng là bạn 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ó các yêu cầu rất cụ thể về ứng dụng và muốn có quyền truy cập ở mức thấp nhất vào tệp cấu hình máy chủ, hãy hỏi xem bạn có muốn tuỳ chỉnh phần phụ trợ phiên bản ứng dụng của riêng mình không.

Có nhiều nhà cung cấp dịch vụ lưu trữ sẽ giúp bạn giải quyết những vấn đề này, nhưng nếu bạn bắt đầu thấy giá trị TTFB dài ngay cả trong 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 đến trải nghiệm tốt nhất 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ủ đề đã lỗi thời, nhưng vì lý do chính đáng: bạn có thể có phần phụ trợ ứng dụng được tối ưu hoá rất tốt, nhưng 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.

CDN giải quyết vấn đề về khoảng cách của người dùng so với máy chủ gốc bằng cách sử dụng một mạng máy chủ được phân phối giúp 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. Những máy chủ này được gọi là máy chủ cạnh.

Nhà cung cấp CDN cũng có thể cung cấp nhiều lợi ích khác ngoài các máy chủ gần nguồ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ủ biên bằng các giao thức hiện đại như HTTP/2 hoặc HTTP/3.
  • Đặc biệt, HTTP/3 giải quyết được vấn đề chặn dòng dữ liệu đầu cuối hiện 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 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úp quá trình thương lượng TLS (Bảo mật tầng truyền tải) ngắn nhất có thể.
  • Một số nhà cung cấp CDN cung cấp tính năng thường được gọi là "edge worker" (API worker), sử dụng API tương tự như Service Worker API để chặn 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 ghi lại toàn bộ các 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 ngay 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 động và phải được nén nhanh chóng.
  • Nhà cung cấp CDN cũng sẽ tự động lưu các phản hồi nén vào bộ nhớ đệm cho các tài nguyên tĩnh, giúp mang lại tỷ lệ nén và thời gian phản hồi phù hợp nhất.

Mặc dù việc sử dụng CDN cũng cần nhiều công sức từ đơn giản đến đáng kể, nhưng bạn nên ưu tiên tối ưu hoá TTFB của mình nếu trang web của bạn chưa sử dụng CDN.

Dùng nội dung được lưu vào 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ủ biên được đặt 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 quay lại nguồn gốc có thể phủ định 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, ngay cả một thời gian lưu vào bộ nhớ đệm ngắn cũng có thể dẫn đến mức tăng hiệu suất đáng kể cho các trang web bận vì chỉ khách truy cập đầu tiên trong thời gian đó mới trải qua độ trễ hoàn toàn khi quay lại máy chủ gốc, trong khi tất cả các khách truy cập khác có thể sử dụng lại tài nguyên đã lưu trong bộ nhớ đệm từ máy chủ cạnh. Một số mạng phân phối nội dung (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 khai thác tối đa cả hai lợi ích: thời gian lưu vào bộ nhớ đệm trong thời gian dài nhưng cập nhật tức thì khi cần.

Ngay cả khi tính năng 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 điều 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. Các báo cáo này có thể trông giống nội dung khác 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ể khiế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ể làm giảm tác động của vấn đề này. Tuy nhiên, hãy lưu ý rằng thời gian lưu vào bộ nhớ đệm tăng lên sẽ làm tăng khả năng phân phát nội dung có thể đã lỗi thời.

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 trong bộ nhớ đệm thường có thể hoạt động tốt hơn.

Tránh chuyển hướng nhiều trang

Một yếu tố đóng góp phổ biến cho TTFB cao là chuyển hướng. Chuyển hướng xảy ra khi 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 vào yêu cầu điều hướng, nhưng cũng có thể tệ hơn nếu việc 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 lượng lớn khách truy cập qua quảng cáo hoặc bản tin, vì họ thường chuyển hướ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 dưới 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 hợp lý.

Có hai loại chuyển hướng:

  • Lệnh chuyển hướng cùng nguồn gốc, trong đó lệnh chuyển hướng hoàn toàn xảy ra trên trang web của bạn.
  • Lệnh chuyển hướng nhiều nguồn gốc, trong đó lệnh chuyển hướng ban đầu xảy ra trên một nguồn gốc khác (ví dụ: từ một dịch vụ rút ngắn URL 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à vấn đề bạn sẽ có quyền kiểm soát trực tiếp. Điều này sẽ 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 trong số đó 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, 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 thêm vào hoặc loại trừ một cách thích hợp trong URL.

Việc chuyển hướng giữa nhiều nguồn gốc sẽ phức tạp hơn vì việc này 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ể, chẳng hạn như bằng cách sử dụng nhiều trình rút ngắn đường liên kết khi chia sẻ đường liên kết. Hãy đảm bảo URL cung cấp cho nhà quảng cáo hoặc bản tin là URL cuối cùng chính xác, để tránh 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ể bắt nguồn từ các lệnh chuyển hướng HTTP-to-HTTPS. Bạn có thể giải quyết vấn đề này bằng cách 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 đó 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 các lượt truy cập sau này.

Khi đã thiết lập chính sách HSTS hiệu quả, bạn có thể đẩy nhanh tiến độ trong lần truy cập đầu tiên tới 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 trực tiếp mã đánh dấu tới trình duyệt

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

Mặc dù trình duyệt rất tốt trong việc xử lý mã đánh dấu truyền 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 đó sao cho các đoạn đánh dấu ban đầu đó sẽ được chuyển đến sớm nhất có thể. Nếu hệ thống phụ trợ đang trì hoãn mọi thứ thì đó chính là vấn đề. Do có rất nhiều ngăn xếp phụ trợ, nên phạm vi của hướng dẫn này sẽ không bao gồm việc đề cập đến từng ngăn xếp riêng lẻ và 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ể 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ộ để 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ủ để đánh dấu truyền trực tuyến khi đang được 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 máy chủ React hiển thị 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 tính năng hiển thị tĩnh, tính năng này 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, cá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 việc đá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 đòi hỏi 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 một người dùng cụ thể.

Sử dụng một trình chạy dịch vụ

Service Worker API có thể có tác động lớn đến TTFB đối với cả tài liệu và tài nguyên tải. Lý do là vì một trình chạy dịch vụ đóng vai trò như một proxy giữa trình duyệt và máy chủ – nhưng việc có ảnh hưởng đến TTFB trên trang web của bạn hay không phụ thuộc vào cách bạn thiết lập trình chạy dịch vụ và liệu thiết lập đó có phù hợp với yêu cầu của bạn đối với ứng dụng hay không.

  • Sử dụng chiến lược cũ trong khi xác thực lại cho thành phần. Nếu một nội dung nằm trong bộ nhớ đệm của trình chạy dịch vụ (có thể là tài liệu hay tài nguyên mà tài liệu yêu cầu), 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 trước tiên, sau đó tải nội dung đó xuống trong nền và phân phát nội dung từ bộ nhớ đệm cho các lượt 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, việc sử dụng chiến lược cũ 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 không hiệu quả nếu trang web của bạn gửi mã đánh dấu được tạo động, chẳng hạn như mã đánh dấu mà 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 nhấn mạng trước để tài liệu 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 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ư 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ể 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 kiến trúc trình chạy dịch vụ phát 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 tiếp cận 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. Kết quả của việc sử dụng mẫu Service worker này là điều hướng của bạn sẽ khá nhanh, trong khi các phần tải 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 trên mọi trang web, nhưng thời gian của TTFB cho các tài nguyên tài liệu có thể gần như ngay lập tức đối với các trang web có thể sử dụng.
  • Sử dụng mô hình giao diện ứng dụng cho các ứng dụng do ứng dụng kết xuất. Mô hình này phù hợp nhất với SPA nơi "khung" 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ụ, đồng thời nội dung động của trang sẽ được điề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 về lượt hiển thị

Bất kể phần phụ trợ ứng dụng của bạn được tối ưu hoá tốt đến mức nào, máy chủ vẫn có thể phải làm một lượng lớn công việc để chuẩn bị phản hồi, trong đó có cả công việc tốn kém (nhưng 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 quan trọng về việc hiển thị tiếp theo có thể bị trễ, chẳng hạn như CSS hoặc (trong một số trường hợp) là JavaScript hiển thị mã đánh dấu trên ứng dụng.

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. Có thể sử dụng tiêu đề này để 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 quả 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 trang cốt lõi (JavaScript) nhanh hơn.

Kết luận

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

Cũng giống như việc tối ưu hoá từng chỉ số, phương pháp tiếp cận phần lớn tương tự: đ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, sau đó áp dụng các 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ể hữu ích cho trường hợp của bạn, nhưng một số kỹ thuật sẽ khả thi. Như thường lệ, bạn sẽ cần theo dõi chặt chẽ dữ liệu trường của mình và thực hiện điều chỉnh nếu 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 từ Unsplash.