Tìm hiểu cách tối ưu hoá cho chỉ số Thời gian cho byte đầu tiên.
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ố khác về trải nghiệm người dùng có ý nghĩa, 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ẽ cộng thêm thời gian vào các chỉ số theo sau nó.
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 qua FCP trong ngưỡng "tốt". Theo hướng dẫn ban đầu, hầu hết các trang web nên cố gắng đạt được TTFB là 0,8 giây trở xuống.
Cách đo lường TTFB
Trước khi có thể tối ưu hóa TTFB, bạn cần quan sát xem TTFB ảnh hưởng như thế nào đến người dùng trang web của bạn. Bạn nên coi dữ liệu thực địa làm nguồn chính để quan sát TTFB khi nó bị ảnh hưởng bởi các 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 đó thiếu độ trễ bổ sung này.
PageSpeed Insights là một cách để tải cả thông tin về 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 đầu tiên Khám phá những gì người dùng thực sự của bạn đang trải nghiệm:
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ủ:
Để tìm hiểu thêm các 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.
Gỡ lỗi TTFB cao trong trường bằng Server-Timing
Bạn có thể sử 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ó khả năng gây ra độ trễ cao. Cấu trúc của giá trị tiêu đề có tính linh hoạt, ít nhất có thể chấp nhận một tên người dùng do 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).
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 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 ổ đĩa
- Số lần truy cập/bỏ lỡ 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 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 đặt tiêu đề này, nó 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ó tập hợp tiêu đề phản hồi Server-Timing đều sẽ điền thuộc tính serverTiming vào 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ị trực quan 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 Server-Timing minh 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 cho một tài nguyên đã tới bộ nhớ đệm của CDN hay chưa và khoảng thời gian để yêu cầu đó gửi đến máy chủ biên của CDN và máy chủ gốc.
Một khi bạn xác định rằng bạn có TTFB có vấn đề bằng cách phân tích dữ liệu có sẵn, sau đó bạn có thể chuyển sang khắc phục vấn đề.
Cách tối ưu hoá TTFB
Khía cạnh thách thức lớ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 cơ sở dữ liệu, mỗi ngăn xếp và sản phẩm đề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 yếu tố áp dụng cho hầu hết kiến trúc, thay vì chỉ tập trung vào hướng dẫn 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 bạn sử dụng cho trang web của mình có thể ảnh hưởng rất 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 các 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 đó đượ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 từng nhà cung cấp nhằm bổ sung cho lời khuyên chung hơn 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ể về ngăn xếp bị giới hạn.
Lưu trữ, lưu trữ
Trước khi bạn cân nhắc các phương pháp tối ưu hoá khác, lưu trữ nên là yếu tố đầu tiên bạn cân nhắc. Không có nhiều hướng dẫn cụ thể có thể được đưa ra ở đâ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 trang web đó.
Lưu trữ dùng chung 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 các tệp tĩnh thì điều này có thể không gây ra vấn đề gì. Một số kỹ thuật tối ưu hoá sau đó sẽ giúp bạn hạn chế 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 có 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ì việc bạn lựa chọn lưu trữ trở nên quan trọng đối với việc hạ thấp TTFB trong lĩnh vực này.
Khi chọn một nhà cung cấp dịch vụ lưu trữ, bạn cần chú ý 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ớ, nó sẽ bị giật và gặp khó khăn trong việc phân phối các trang nhanh nhất có thể.
- Nhà cung cấp dịch vụ lưu trữ của bạn có cập nhật hệ thống 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 thức 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 hình 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 chương trình phụ trợ của phiên bản ứng dụng của riêng bạn có hợp lý hay không.
Có nhiều nhà cung cấp dịch vụ lưu trữ sẽ xử lý những vấn đề này cho bạn. Tuy nhiên, nếu bạn bắt đầu nhận thấy các giá trị TTFB dài ngay cả đối với những nhà cung cấp dịch vụ lưu trữ chuyên trách, thì đó có thể là một dấu hiệu cho thấy bạn cần đánh giá lại năng lực 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 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ủ đề phổ biến, nhưng vì một 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 người dùng ở xa máy chủ gốc của bạn có thể vẫn gặp phải TTFB cao trong lĩnh vực này.
CDN giải quyết vấn đề khoảng cách giữa người dùng và máy chủ gốc của bạn bằng cách sử dụng một mạng máy chủ phân phối lưu vào bộ nhớ đệm tài nguyên trên các máy chủ gần với người dùng của bạn hơn. Những máy chủ này được gọi là máy chủ cạnh.
Nhà cung cấp CDN có thể cũng mang lại lợi ích 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 rất 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 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 nói riêng đượ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", tính năng này sử dụng API tương tự như API của Service Worker API để 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 toàn bộ phản hồi.
- Nhà cung cấp CDN rất giỏi trong việc tối ưu hoá nén. Việc tự nén là một việc khó khăn và có thể làm chậm thời gian phản hồi trong một số trường hợp với mã đánh dấu được tạo linh động. Bạn phải 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, nhờ đó có được cách kết hợp tốt nhất giữa tỷ lệ nén và thời gian phản hồi.
Mặc dù việc sử dụng CDN đòi hỏi nhiều công sức từ đơn giản đến đáng kể, nhưng việc tối ưu hoá TTFB sẽ là ưu tiên hàng đầu nếu trang web của bạn chưa sử dụng TTFB.
Sử dụng nội dung được lưu vào bộ nhớ đệm nếu có thể
CDN cho phép nội dung được lưu 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 với 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ể làm mất nhiều giá trị của CDN.
Đối với các trang web thường xuyên cập nhật nội dung, chỉ cần một khoảng thời gian ngắn lưu vào bộ nhớ đệm cũng có thể đem lại 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 đó mới trải qua độ trễ hoàn toàn về 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ủ biên. Một số CDN cho phép vô hiệu hoá bộ nhớ đệm đối với các bản phát hành trên trang web, cho phép tối ưu cả hai lựa chọn: thời gian lưu vào bộ nhớ đệm lâu nhưng có thể cập nhật tức thì khi cần.
Ngay cả khi chức 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 thông qua việc sử dụng tham số chuỗi truy vấn duy nhất để đo lường Analytics. Những nội dung này có thể trông giống nội dung khác với CDN mặc dù giống nhau, do đó phiên bản được lưu trong bộ nhớ đệm sẽ không được sử dụng.
Nội dung cũ hơn hoặc ít truy cập hơn 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 cao hơn trên một số trang 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, xin 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ó thể cơ sở hạ tầng máy chủ cần phải tạo nội dung qua các hoạt động 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 hiệu quả hơn.
Tránh chuyển hướng trang nhiều lần
Một yếu tố chung tạo nên TTFB cao là lệnh chuyển hướng. Lệnh 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 biế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ể thêm độ trễ không mong muốn vào yêu cầu điều hướng, nhưng chắc chắn có thể trở nên tồi 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 biệt ảnh hưởng đến những trang web nhận được lượng lớn khách truy cập từ quảng cáo hoặc bản tin, vì những trang này 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 chuyển hướng dưới quyền 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 xảy ra hoàn toàn trên trang web của bạn.
- Chuyển hướng nhiều nguồn gốc, trong đó hoạt động 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ừ 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à việc bạn có quyền kiểm soát trực tiếp. Quá trình 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 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 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.
Chuyển hướng nhiều nguồn gốc phức tạp hơn vì những lần này 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ần chuyển hướng khi có thể (ví dụ: 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 đượ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ượt chuyển hướng từ HTTP đến HTTPS. Để giải quyết vấn đề này, bạn có thể 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 tới một 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ượt truy cập sau này.
Sau khi thiết lập chính sách HSTS phù hợp, bạn có thể đẩy nhanh tốc độ trong lần đầu tiên truy cập 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 trực tuyến mã đánh dấu đến trình duyệt
Các trình duyệt được tối ưu hoá để xử lý mã đánh dấu hiệu quả khi truyền trực tuyến, nghĩa 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 quan tâm đến tải trọng đánh dấu lớn, 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 trước khi phân tích cú pháp có thể bắt đầu.
Mặc dù các 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 quan trọng là bạn phải làm tất cả những gì có thể để giữ cho luồng dữ liệu hoạt động để những đoạn đánh dấu ban đầu đó được xử lý càng sớm càng tốt. Nếu phần phụ trợ vẫn đang hoạt động, thì đó là vấn đề. Vì có rất nhiều ngăn xếp phụ trợ, nên hướng dẫn này sẽ nằm ngoài phạm vi của hướng dẫn này để đề cập đến mọi ngăn xếp riêng lẻ cũng như 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ể kết xuất 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ủ để truyền mã đánh dấu khi đang hiển thị. Điều này có nghĩa là bạn không 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 đi.
Một cách khác để đảm bảo thẻ đánh dấu được truyền trực tuyến nhanh chóng đến trình duyệt là dựa vào tính năng kết xuất tĩnh, tính năng tạo 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 theo luồng. Mặc dù không phải trang nào cũ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 linh độ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 cá nhân hoá mã đánh dấu cho một người dùng cụ thể.
Sử dụng một trình chạy dịch vụ
API Service Worker có thể có ảnh hưở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 của hiện tượng này là vì 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 còn phụ thuộc vào cách bạn thiết lập trình chạy dịch vụ và liệu cách thiết lập đó có phù hợp với yêu cầu của ứng dụng hay không.
- Sử dụng chiến lược cũ trong khi xác thực lại cho các tài sả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 trước, sau đó sẽ tải thành phần đó xuống ở chế độ nền và phân phát từ bộ nhớ đệm cho các tương tác sau này.
- 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 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 một cách 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, để tài liệu luôn 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 thay đổi theo tần suất nào đó, nhưng việc tìm nạp tài nguyên cũ sẽ không ảnh hưởng đáng kể đế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—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 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 các SPA mà "shell" của trang có thể được phân phối ngay lập tức từ bộ nhớ đệm của Service worker, đồng thời nội dung động của trang được điền và hiển thị sau này trong vòng đời của trang.
Dùng 103 Early Hints cho các tài nguyên quan trọng cần kết xuất
Bất kể phần phụ trợ của ứng dụng được tối ưu hoá hiệu quả đến mức nào, máy chủ vẫn cần phải làm một lượng lớn công việc để 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) đối với cơ sở dữ liệu khiến phản hồi điều hướng bị chậm trễ trong thời gian 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 hiển thị tiếp theo có thể bị trì hoãn, chẳng hạn như CSS hoặc JavaScript (trong một số trường hợp) có thể hiển thị thẻ đánh dấu trên ứng dụng.
Tiêu đề 103 Early Hints là một mã phản hồi sớm mà máy chủ có thể gửi cho 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 biết rằng có các tài nguyên quan trọng cần hiển thị mà trang nên bắt đầu tải xuống trong quá trình chuẩn bị mã đánh dấu. Đối với các trình duyệt hỗ trợ, hiệu ứng có thể làm tăng tốc độ kết xuất tài liệu (CSS) và khả năng sử dụng chức năng chính của trang (JavaScript) nhanh hơn.
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ó bài viết nào có thể tóm lược mọi việc bạn có thể làm để giảm bớt 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ủ.
Giống như việc tối ưu hoá mọi chỉ số, cách tiếp cận cũng khá giống nhau: đo lường TTFB 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 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ố kỹ thuật sẽ khả thi. Như thường lệ, bạn cần phải theo dõi kỹ dữ liệu của trường và đ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.