Tìm hiểu cách tối ưu hoá cho chỉ số Thời gian cho byte đầu tiên.
Thời gian tải 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ố trải nghiệm người dùng có ý nghĩa khác, chẳng hạn như Hiển thị nội dung đầu tiên (FCP) và Nội dung lớn nhất hiển thị (LCP). Điều này có nghĩa là các giá trị TTFB cao sẽ làm tăng thời gian cho các chỉ số theo sau.
Bạn nên đảm bảo máy chủ 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 chung, hầu hết các trang web nên cố gắng đạt được TTFB dưới 0,8 giây.
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 địa làm nguồn chính để quan sát TTFB vì nó 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 để nhận 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ế xuất hiện trong phần Khám phá nội dung người dùng thực tế của bạn đang trải nghiệm ở trên cùng:
Một tập hợp con của TTFB được hiển thị trong phần 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ả thực tế 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ó 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 ổ đĩa
- Số lần truy cập/không truy cập vào bộ nhớ đệm của máy chủ Edge (nếu đang 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 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à trường thực địa.
Trong trường này, 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 lớp học này, dữ liệu từ tiêu đề phản hồi Server-Timing sẽ được trực quan hoá 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:
Tiêu đề phản hồi Server-Timing được hiển thị trong thẻ mạng của Công cụ của Chrome cho nhà phát triển. Tại đây, Server-Timing được dùng để đo lường xem một 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 nguồn gốc.
Sau khi 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, 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 sẽ luôn là HTML, CSS và JavaScript, nhưng 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ỗi sản phẩm có cá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 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 dành riêng cho nền tảng
Nền tảng bạn sử dụng cho trang web 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 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ể về ngăn xếp bị hạn chế.
Lưu trữ, lưu trữ, lưu trữ
Trước khi cân nhắc các phương pháp tối ưu hoá khác, bạn nên cân nhắc việc lưu trữ trước tiên. Chúng tôi không thể cung cấp nhiều 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ó thể xử lý lưu lượng truy cập mà bạn gửi đến.
Máy chủ lưu trữ dùng chung thường có tốc độ chậm hơn. Nếu bạn đang chạy một trang web cá nhân nhỏ chủ yếu phân phát các tệp tĩnh, thì điều này có thể chấp nhận được. Một số kỹ thuật tối ưu hoá sau đây sẽ giúp bạn giảm TTFB xuống mức thấp 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 lưu trữ của bạn trở nên quan trọng để giảm TTFB trong trường hợp 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:
- Phiên bản ứ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 và không thể 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ó 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, 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 trong 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 một 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 có nên tuỳ chỉnh phần phụ trợ của thực thể ứng dụng của riêng bạn hay 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. Tuy nhiên, nếu bạn bắt đầu nhận thấy các giá trị TTFB dài ngay cả khi sử dụng 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 người dùng tốt nhất có thể.
Sử dụng Mạng phân phối nội dung (CDN)
Chủ đề sử dụng CDN đã được đề cập nhiều lần, nhưng có 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 vẫn có thể gặp phải TTFB cao trong thực tế.
CDN giải quyết vấn đề khoảng cách của người dùng với máy chủ gốc bằng cách sử dụng một mạng phân tán gồm các máy chủ lưu các 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 địa 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 các lợi ích khác ngoài máy chủ biên:
- Các nhà cung cấp CDN thường cung cấp 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 hàng xuất hiện 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 đàm phán TLS. Cụ thể, TLS 1.3 được thiết kế để quá trình đàm phán TLS diễn ra ngắn gọ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à "worker cạnh". Tính năng này sử dụng một API tương tự như API Worker 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 cạnh hoặc viết lại toàn bộ phản hồi.
- Các nhà cung cấp CDN rất giỏi trong việc tối ưu hoá để nén. Bạn khó có thể tự nén đúng cách và việc này 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 và phải được nén ngay lập tức.
- Các 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ờ đó mang lại tỷ lệ nén và thời gian phản hồi tốt nhất.
Mặc dù việc sử dụng CDN đòi hỏi nhiều nỗ lực từ nhỏ đến lớn, nhưng bạn vẫ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 đã 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 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 các tiêu đề HTTP Cache-Control thích hợp. Mặc dù 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 giảm nhiều 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 tăng hiệu suất đáng kể cho những trang web có lưu lượng truy cập cao, vì chỉ khách truy cập đầu tiên trong khoảng thời gian đó mới trải nghiệm độ trễ đầy đủ trở 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ủ 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 hiệu quả tốt nhất cho cả hai phương thức – thời gian lưu vào bộ nhớ đệm lâu nhưng cập nhật tức thì khi cần.
Ngay cả khi bạn định cấu hình bộ nhớ đệm đúng cách, bạn vẫn có thể bỏ qua vấn đề này bằng cách sử dụng các thông số chuỗi truy vấn duy nhất để đo lường số liệu phân tích. Mặc dù giống nhau nhưng những nội dung này có thể trông khác với CDN, vì vậy, phiên bản đã lưu vào bộ nhớ đệm sẽ không được sử dụng.
Nội dung cũ hoặc ít được truy cập cũng có thể không được lưu vào bộ nhớ đệm, 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, nhưng hãy 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 có thể đã cũ cũng sẽ tăng lên.
Ảnh hưở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 vào bộ nhớ đệm trước thường có hiệu suất tốt hơn.
Tránh chuyển hướng trang nhiều lần
Một yếu tố phổ biến gây ra TTFB cao là lệnh 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ể đặ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 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 mà bạn có quyền kiểm soát trực tiếp có thể giúp bạn đạt được TTFB tốt.
Có hai loại lệnh chuyển hướng:
- Lệnh chuyển hướng cùng nguồn gốc, trong đó lệnh chuyển hướng xảy ra hoàn toàn trên trang web của bạn.
- Lượt chuyển hướng giữa các nguồn gốc, trong đó lượt 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 gọn URL trên mạng xã hội) trước khi đến trang web của bạn.
Bạn nê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à điều bạn có thể kiểm soát trực tiếp. Bạn cần 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ì điều này có thể là do không đưa giao thức https:// vào (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 bị loại trừ một cách thích hợp trong URL.
Lệnh chuyển hướng giữa các 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, 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ể là lệnh chuyển hướng HTTP sang HTTPS. Một cách để khắc phục 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 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 giao thức HTTPS trong các lần truy cập sau này.
Sau khi áp dụng chính sách HSTS hiệu quả, bạn có thể tăng 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 mình vào danh sách tải trước HSTS.
Truyền mã đánh dấu đến trình duyệt
Các trình duyệt được tối ưu hoá để xử lý hiệu quả mã đánh dấu khi mã đánh dấu được 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 liên quan đế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 đoạn mã đánh dấu đó một 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 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 mọi thứ có thể để duy trì luồng đó để các bit mã đánh dấu ban đầu đó được truyền đi sớm nhất có thể. Nếu phần phụ trợ đang làm chậm mọi thứ, thì đó là 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 từng 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ộ để 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 khi mã đánh dấu đang được 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 hiển thị toàn bộ phản hồi trước khi gửi.
Một cách khác để đảm bảo việc truyền nhanh mã đánh dấu đến trình duyệt là dựa vào tính năng kết xuất tĩnh để tạo tệp HTML trong thời gian xây dựng. Khi có sẵn toàn bộ tệp, 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 động trong trải nghiệm người dùng), nhưng phương pháp này có thể hữu ích cho những trang không yêu cầu phải cá nhân hoá mã đánh dấu 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à 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 liệu 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 xác thực lại khi hết hạn 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ân phát tài nguyên đó từ bộ nhớ đệm trước tiên, sau đó sẽ 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 lượt tương tác trong tương lai.
- Nếu bạn có cá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 cũ trong khi xác thực lại có thể giúp TTFB của trang gần như tức thì. Tuy nhiên, phương thức này không hoạt độ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 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 luôn muốn truy cập vào mạng trước tiên để 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 nhiều đến trải nghiệm người dùng (chẳng hạn như một số 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 xác thực lại khi tài nguyên đã cũ.
- Sử dụng mô hình vỏ ứng dụng cho các ứng dụng do máy khách hiển thị. 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 tức thì từ bộ nhớ đệm của trình chạy dịch vụ, còn nội dung động của trang đượ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 đối với quá trình kết xuất
Bất kể phần phụ trợ của ứng dụng được tối ưu hoá tốt đến mức nào, máy chủ vẫn có thể cần 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ễ. Ảnh hưởng tiềm ẩn của việc này là một số tài nguyên quan trọng để kết xuất tiếp theo có thể bị trì hoãn, chẳng hạn như CSS hoặc trong một số trường hợp là JavaScript kết xuất mã đá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 đế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ể 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 để hiển thị 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à cung cấp chức năng trang cốt lõi nhanh hơn (JavaScript).
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ể gói gọn mọi thứ 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á để cố gắng đẩy nhanh tiến trình ở phía máy chủ.
Giống như khi tối ưu hoá mọi chỉ số, phương pháp này cũng tương tự: đ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 nguyên nhân, sau đó áp dụng các biện pháp tối ưu hoá khi có thể. Không phải kỹ thuật nào trong số này cũng phù hợp với trường hợp của bạn, nhưng một số kỹ thuật sẽ phù hợp. Như thường lệ, bạn cần theo dõi chặt chẽ dữ liệu trường và điều chỉnh khi cần để đảm bảo người dùng có trải nghiệm nhanh nhất có thể.
Hình ảnh chính của Taylor Vick, lấy từ Unsplash.