Bước đầu tiên để tạo một trang web có tốc độ tải nhanh là nhận được phản hồi kịp thời từ máy chủ cho HTML của một trang. Khi bạn nhập một URL vào thanh địa chỉ của trình duyệt, trình duyệt sẽ gửi một yêu cầu GET đến máy chủ để truy xuất URL đó. Yêu cầu đầu tiên cho một trang web là cho một tài nguyên HTML và việc đảm bảo HTML đến nhanh với độ trễ tối thiểu là một mục tiêu hiệu suất chính.
Yêu cầu ban đầu cho HTML đó sẽ trải qua một số bước, mỗi bước mất một khoảng thời gian. Việc giảm thời gian dành cho mỗi bước giúp bạn Thời gian cho byte đầu tiên (TTFB) nhanh hơn. Mặc dù TTFB không phải là chỉ số duy nhất mà bạn cần tập trung vào tốc độ tải trang, nhưng chỉ số TTFB cao khiến khó đạt được ngưỡng "tốt" được chỉ định cho các chỉ số như Thời gian hiển thị nội dung lớn nhất (LCP) và Thời gian hiển thị nội dung đầu tiên (FCP).
Giảm thiểu số lần chuyển hướng
Khi một tài nguyên được yêu cầu, máy chủ có thể phản hồi bằng một lệnh chuyển hướng, với lệnh chuyển hướng vĩnh viễn (phản hồi 301 Moved Permanently) hoặc lệnh chuyển hướng tạm thời (phản hồi 302 Found).
Các lệnh chuyển hướng làm chậm tốc độ tải trang vì trình duyệt cần thực hiện thêm một yêu cầu HTTP tại vị trí mới để truy xuất tài nguyên. Có 2 loại lệnh chuyển hướng:
- Lệnh chuyển hướng cùng nguồn gốc xảy ra hoàn toàn trong nguồn gốc của bạn. Các loại lệnh chuyển hướng này hoàn toàn nằm trong tầm kiểm soát của bạn, vì logic để quản lý các loại lệnh chuyển hướng đó nằm hoàn toàn trên máy chủ web của bạn.
- Lệnh chuyển hướng nhiều nguồn gốc do một nguồn gốc khác khởi tạo. Những loại chuyển hướng này thường nằm ngoài tầm kiểm soát của bạn.
Lệnh chuyển hướng nhiều nguồn gốc thường được quảng cáo, dịch vụ rút ngắn URL và các dịch vụ khác của bên thứ ba sử dụng. Mặc dù việc chuyển hướng nhiều nguồn gốc nằm ngoài tầm kiểm soát của bạn, nhưng bạn vẫn nên kiểm tra để đảm bảo rằng mình tránh nhiều lệnh chuyển hướng. Ví dụ: có một quảng cáo liên kết đến một trang HTTP mà lần lượt chuyển hướng đến một trang HTTP tương đương với HTTPS hoặc một lệnh chuyển hướng nhiều nguồn gốc đến điểm gốc của bạn, nhưng sau đó lại kích hoạt lệnh chuyển hướng cùng nguồn gốc.
Lưu phản hồi HTML vào bộ nhớ đệm
Việc lưu các phản hồi HTML vào bộ nhớ đệm rất khó vì phản hồi có thể bao gồm các đường liên kết đến các tài nguyên quan trọng khác như CSS, JavaScript, hình ảnh và các loại tài nguyên khác. Các tài nguyên này có thể bao gồm một vân tay số duy nhất trong tên tệp tương ứng. Vân tay số này sẽ thay đổi dựa trên nội dung của tệp. Điều này có nghĩa là tài liệu HTML được lưu vào bộ nhớ đệm của bạn có thể trở nên lỗi thời sau khi triển khai, vì tài liệu này chứa tham chiếu đến các tài nguyên phụ đã lỗi thời.
Tuy nhiên, thời gian lưu vào bộ nhớ đệm ngắn (thay vì không lưu vào bộ nhớ đệm) có thể mang lại các lợi ích, chẳng hạn như cho phép lưu một tài nguyên vào bộ nhớ đệm tại CDN, giảm số lượng yêu cầu được phân phát từ máy chủ gốc và trong trình duyệt, cho phép xác thực lại tài nguyên thay vì tải xuống lại. Phương pháp này phù hợp nhất với nội dung tĩnh không thay đổi trong bất cứ ngữ cảnh nào. Bạn có thể đặt thời điểm thích hợp để lưu tài nguyên vào bộ nhớ đệm trong khoảng thời gian tính bằng phút mà bạn cho là phù hợp. 5 phút đối với tài nguyên HTML tĩnh là một điều an toàn và đảm bảo rằng các bản cập nhật định kỳ không được bỏ qua.
Nếu nội dung HTML của trang được cá nhân hoá theo một cách nào đó (chẳng hạn như đối với người dùng đã xác thực), thì rất có thể bạn không muốn lưu nội dung vào bộ nhớ đệm vì những vấn đề khác nhau, bao gồm cả tính bảo mật và độ mới. Nếu một phản hồi HTML được trình duyệt của người dùng lưu vào bộ nhớ đệm, thì bạn không thể vô hiệu hoá bộ nhớ đệm đó. Do đó, tốt nhất bạn nên tránh lưu HTML hoàn toàn vào bộ nhớ đệm trong những trường hợp như vậy.
Một phương pháp thận trọng để lưu HTML vào bộ nhớ đệm có thể là sử dụng các tiêu đề phản hồi ETag hoặc Last-Modified. Tiêu đề ETag (còn gọi là thẻ thực thể) là giá trị nhận dạng duy nhất đại diện cho tài nguyên được yêu cầu, thường bằng cách sử dụng hàm băm của nội dung tài nguyên:
ETag: "33a64df551425fcc55e4d42a148795d9f25f89d4"
Bất cứ khi nào tài nguyên thay đổi, một giá trị ETag mới phải được tạo. Đối với các yêu cầu tiếp theo, trình duyệt sẽ gửi giá trị ETag thông qua tiêu đề của yêu cầu If-None-Match. Nếu ETag trên máy chủ khớp với tài nguyên do trình duyệt gửi, thì máy chủ sẽ phản hồi bằng phản hồi 304 Not Modified và trình duyệt sẽ sử dụng tài nguyên từ bộ nhớ đệm. Mặc dù vấn đề này vẫn gây ra độ trễ mạng, nhưng phản hồi 304 Not Modified sẽ nhỏ hơn nhiều so với toàn bộ tài nguyên HTML.
Tuy nhiên, độ trễ mạng liên quan đến việc xác thực lại độ mới của tài nguyên vẫn là một hạn chế riêng. Giống như nhiều khía cạnh khác của quá trình phát triển web, việc đánh đổi và xâm phạm là điều không thể tránh khỏi. Bạn có thể tìm hiểu xem nỗ lực thêm vào bộ nhớ đệm HTML theo cách này có đáng hay không, hoặc tốt nhất là bạn nên lưu giữ nội dung HTML theo cách này và không bận tâm đến việc lưu nội dung HTML vào bộ nhớ đệm.
Đo lường thời gian phản hồi của máy chủ
Nếu một phản hồi không được lưu vào bộ nhớ đệm, thì thời gian phản hồi của máy chủ phụ thuộc nhiều vào nhà cung cấp dịch vụ lưu trữ và ngăn xếp ứng dụng phụ trợ của bạn. Một trang web phân phát phản hồi được tạo động (ví dụ: tìm nạp dữ liệu từ cơ sở dữ liệu) có thể có TTFB cao hơn so với một trang web tĩnh có thể được phân phát ngay lập tức mà không cần đáng kể thời gian tính toán trên phần phụ trợ. Việc hiển thị một vòng quay tải rồi sau đó tìm nạp tất cả dữ liệu ở phía máy khách sẽ giúp chuyển nỗ lực từ một môi trường phía máy chủ dễ dự đoán hơn sang một môi trường phía máy khách có thể khó dự đoán. Việc giảm thiểu nỗ lực phía máy khách thường giúp cải thiện các chỉ số tập trung vào người dùng.
Nếu người dùng gặp phải TTFB chậm trong trường, bạn có thể hiển thị thông tin về thời gian dành cho máy chủ thông qua tiêu đề phản hồi Server-Timing:
Server-Timing: auth;dur=55.5, db;dur=220
Giá trị của tiêu đề Server-Timing có thể bao gồm nhiều chỉ số, cũng như thời lượng của mỗi chỉ số. Sau đó, dữ liệu này có thể được thu thập từ người dùng trong trường bằng cách sử dụng Navigation Timing API và được phân tích để xem liệu người dùng có bị trễ hay không. Trong đoạn mã trước đó, tiêu đề phản hồi bao gồm hai dấu thời gian:
- Thời gian xác thực một người dùng (
auth) mất 55,5 mili giây. - Thời gian truy cập cơ sở dữ liệu (
db) là 220 mili giây.
Bạn cũng nên xem lại cơ sở hạ tầng lưu trữ của mình và xác nhận rằng bạn có đủ tài nguyên để xử lý lưu lượng truy cập mà trang web của bạn đang nhận được. Các nhà cung cấp dịch vụ lưu trữ dùng chung thường dễ gặp phải chỉ số TTFB cao và các giải pháp chuyên biệt cung cấp thời gian phản hồi nhanh hơn có thể tốn kém chi phí hơn.
Nén
Các phản hồi dựa trên văn bản như HTML, JavaScript, CSS và hình ảnh SVG phải được nén để giảm kích thước truyền qua mạng để tải xuống nhanh hơn. Các thuật toán nén thông dụng nhất là gzip và Brotli. Brotli giúp cải thiện khoảng 15% đến 20% so với gzip.
Tính năng nén thường được hầu hết các nhà cung cấp dịch vụ lưu trữ web thiết lập tự động, nhưng có một số điều quan trọng cần cân nhắc nếu bạn đang ở khả năng định cấu hình hoặc tự chỉnh sửa các chế độ cài đặt nén:
- Sử dụng Brotli nếu có thể. Như đã đề cập trước đó, Brotli đã cải tiến khá nhiều so với gzip và Brotli được hỗ trợ trong tất cả các trình duyệt chính. Hãy sử dụng Brotli khi có thể, nhưng nếu trang web của bạn được nhiều người dùng sử dụng trên các trình duyệt cũ, hãy đảm bảo dùng gzip để dự phòng, vì khi nén thì vẫn tốt hơn là không nén.
- Kích thước tệp có vai trò quan trọng. Các tài nguyên rất nhỏ (dưới 1 KiB) không nén quá tốt hoặc đôi khi thậm chí không nén. Hiệu quả của mọi kiểu nén dữ liệu phụ thuộc vào việc có một lượng lớn dữ liệu mà thuật toán nén có thể hoạt động để tìm thêm các bit dữ liệu có thể nén được hơn. Tệp càng lớn thì hoạt động nén càng hiệu quả. Tuy nhiên, đừng dùng tài nguyên quá lớn vì thực tế là chúng có thể được nén hiệu quả hơn. Các tài nguyên lớn (ví dụ: JavaScript và CSS) sẽ mất nhiều thời gian hơn để phân tích cú pháp và đánh giá sau khi trình duyệt giải nén các tài nguyên đó và có thể thay đổi thường xuyên hơn ngay cả khi chúng chỉ thay đổi một chút, vì mọi thay đổi sẽ dẫn đến một hàm băm tệp khác.
- Tìm hiểu về nén động và nén tĩnh. Nén động và tĩnh là các phương pháp khác nhau để xác định thời điểm nén tài nguyên. Tính năng nén động sẽ nén một tài nguyên tại thời điểm được yêu cầu và đôi khi là mỗi lần tài nguyên được yêu cầu. Mặt khác, phương thức nén tĩnh nén các tệp trước và không cần thực hiện quá trình nén tại thời điểm yêu cầu. Phương thức nén tĩnh sẽ loại bỏ độ trễ liên quan đến quá trình nén, vốn có thể làm tăng thời gian phản hồi của máy chủ trong trường hợp nén động. Các tài nguyên tĩnh (chẳng hạn như JavaScript, CSS và hình ảnh SVG) sẽ được nén tĩnh, trong khi các tài nguyên HTML (đặc biệt nếu được tạo theo phương thức động cho người dùng đã xác thực) sẽ được nén động.
Rất khó để tự nén thành công và tốt nhất bạn nên để Mạng phân phối nội dung (CDN) – điều được thảo luận trong phần tiếp theo – xử lý vấn đề này cho bạn. Tuy nhiên, việc biết những khái niệm này có thể giúp bạn xác định liệu nhà cung cấp dịch vụ lưu trữ của mình có đang sử dụng tính năng nén đúng cách hay không. Kiến thức đó có thể giúp bạn tìm các cơ hội cải thiện chế độ cài đặt nén để chúng mang lại lợi ích tối đa cho trang web của bạn.
Mạng phân phối nội dung (CDN)
Mạng phân phối nội dung (CDN) là một mạng máy chủ phân phối có chức năng lưu tài nguyên vào bộ nhớ đệm từ máy chủ gốc, sau đó phân phát các tài nguyên đó từ các máy chủ gần nguồn ở gần người dùng của bạn hơn. Khoảng cách thực tế với người dùng giúp làm giảm thời gian trọn vòng (RTT), trong khi các tính năng tối ưu hoá như HTTP/2 hoặc HTTP/3, việc lưu vào bộ nhớ đệm và nén cho phép CDN phân phát nội dung nhanh hơn so với khi nội dung được tìm nạp từ máy chủ gốc của bạn. Việc sử dụng CDN có thể cải thiện đáng kể TTFB của trang web trong một số trường hợp.
Kiểm tra kiến thức
Loại chuyển hướng nào hoàn toàn thuộc quyền kiểm soát của bạn?
Tiêu đề Server-Timing có thể chứa nhiều chỉ số.
Loại máy chủ nào có khả năng thực sự gần với người dùng cuối của bạn nhất?
Tiếp theo: Tìm hiểu lộ trình quan trọng
Giờ đây, khi bạn đã quen với một số yếu tố cần cân nhắc về hiệu suất liên quan đến HTML của trang web, bạn đã sẵn sàng hơn trong việc đảm bảo rằng HTML có thể tải nhanh nhất có thể. Tuy nhiên, đó mới chỉ là khởi đầu của quá trình tìm hiểu hiệu suất của web. Tiếp theo, chúng ta sẽ đề cập đến lý thuyết về đường dẫn kết xuất quan trọng. Mô-đun này mô tả các khái niệm chính như tài nguyên chặn hiển thị và chặn phân tích cú pháp, cũng như vai trò của chúng trong việc tải lượt hiển thị ban đầu của một trang trong trình duyệt nhanh nhất có thể.