Những điểm cần lưu ý chung về hiệu suất của HTML

Bước đầu tiên trong việc xây dựng một trang web 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 đối với một trang web là yêu cầu về tài nguyên HTML và việc đảm bảo HTML đến nhanh chóng với độ trễ tối thiểu là mục tiêu chính về hiệu suất.

Yêu cầu ban đầu đó đối với 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 sẽ giúp bạn có được Thời gian phản hồi của 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 nên tập trung vào khi nói đến tốc độ tải trang, nhưng TTFB cao sẽ gây khó khăn cho việc đạ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, có thể là 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).

Lệnh chuyển hướng làm giảm tốc độ tải trang vì lệnh này yêu cầu trình duyệt đưa ra một yêu cầu HTTP bổ sung tại vị trí mới để truy xuất tài nguyên. Có 2 loại lệnh chuyển hướng:

1. Lệnh chuyển hướng cùng nguồn hoàn toàn nằm trong nguồn của bạn. Bạn hoàn toàn có quyền kiểm soát các loại lệnh chuyển hướng này, vì logic quản lý các lệnh chuyển hướng này hoàn toàn nằm trên máy chủ web của bạn.
2. 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. Bạn thường không kiểm soát được các loại lệnh chuyển hướng này.

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 thường sử dụng lệnh chuyển hướng trên nhiều nguồn. Mặc dù bạn không kiểm soát được lệnh chuyển hướng từ nhiều nguồn, nhưng bạn vẫn nên kiểm tra để 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, trang này sẽ chuyển hướng đến trang HTTPS tương đương, hoặc một lệnh chuyển hướng từ nhiều nguồn đến nguồn gốc của bạn, nhưng sau đó kích hoạt lệnh chuyển hướng cùng nguồn gốc.

Lưu các phản hồi HTML vào bộ nhớ đệm

Rất khó lưu phản hồi HTML vào bộ nhớ đệm, 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 dấu vân tay riêng biệt trong tên tệp tương ứng. Dấu vân tay 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 cũ sau khi triển khai, vì tài liệu đó sẽ chứa các tham chiếu đến các tài nguyên phụ đã lỗi thời.

Tuy nhiên, thời gian tồn tại ngắn của bộ nhớ đệm (thay vì không lưu vào bộ nhớ đệm) có thể mang lại những lợi ích 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 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 kỳ bối cảnh nào và bạn có thể đặt thời gian thích hợp để lưu vào bộ nhớ đệm tài nguyên thành một số phút mà bạn cho là phù hợp. Năm phút cho các tài nguyên HTML tĩnh là một lựa chọn an toàn và đảm bảo rằng các bản cập nhật định kỳ sẽ không bị bỏ lỡ.

Nếu nội dung HTML của một trang được cá nhân hoá theo 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 vào bộ nhớ đệm nội dung vì nhiều lý do, bao gồm cả tính bảo mật và tính mới mẻ. Nếu trình duyệt của người dùng lưu phản hồi HTML vào bộ nhớ đệm, bạn sẽ không thể làm mất hiệu lực bộ nhớ đệm. Do đó, tốt nhất là bạn nên tránh hoàn toàn việc lưu vào bộ nhớ đệm HTML trong những trường hợp như vậy.

Một cách thận trọng để lưu vào bộ nhớ đệm HTML là sử dụng tiêu đề phản hồi ETag hoặc Last-Modified. Tiêu đề ETag (còn gọi là thẻ thực thể) là một 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 băm nội dung của tài nguyên:

ETag: "33a64df551425fcc55e4d42a148795d9f25f89d4"

Bất cứ khi nào tài nguyên thay đổi, bạn phải tạo một giá trị ETag mới. Trong các yêu cầu tiếp theo, trình duyệt sẽ gửi giá trị ETag thông qua tiêu đề yêu cầu If-None-Match. Nếu ETag trên máy chủ khớp với ETag do trình duyệt gửi, thì máy chủ sẽ phản hồi bằng một 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ù điều này vẫn gây ra độ trễ mạng, nhưng phản hồi 304 Not Modified nhỏ hơn rất 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 loại nhược điểm riêng. Giống như nhiều khía cạnh khác của việc phát triển web, việc đánh đổi và thoả hiệp là điều không thể tránh khỏi. Bạn phải tự quyết định xem việc bỏ thêm công sức để lưu 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 đảm bảo an toàn và không lưu vào bộ nhớ đệm nội dung HTML.

Đo lường thời gian phản hồi của máy chủ

Nếu phản hồi không được lưu vào bộ nhớ đệm, thời gian phản hồi của máy chủ sẽ phụ thuộc rất 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 cung cấp phản hồi được tạo động (chẳng hạn như 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 thời gian tính toán đáng kể ở phần phụ trợ. Việc hiển thị một biểu tượng tải và sau đó tìm nạp tất cả dữ liệu ở phía máy khách sẽ 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ó khả năng khó dự đoán. Việc giảm thiểu nỗ lực phía máy khách thường dẫn đến việc cải thiện các chỉ số lấy người dùng làm trung tâm.

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 đã sử dụng trên máy chủ thông qua việc sử dụng 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 cho từng chỉ số. Sau đó, dữ liệu này có thể được thu thập từ người dùng trong trường bằng Navigation Timing API và được phân tích để xem người dùng có gặp phải tình trạng chậm trễ hay không. Trong đoạn mã trước đó, tiêu đề phản hồi bao gồm 2 thời gian:

• Thời gian xác thực người dùng (auth) là 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 có thể xem xét cơ sở hạ tầng lưu trữ 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ễ bị ảnh hưởng bởi TTFB cao và các giải pháp chuyên dụng có thời gian phản hồi nhanh hơn có thể tốn kém 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 nhằm tải xuống nhanh hơn. Các thuật toán nén được sử dụng rộng rãi nhất là gzip và Brotli. Brotli giúp cải thiện khoảng 15% đến 20% so với gzip.

Hầu hết nhà cung cấp dịch vụ lưu trữ web thường tự động thiết lập tính năng nén, nhưng bạn cần cân nhắc một số điều quan trọng nếu có thể tự định cấu hình hoặc điều chỉnh chế độ cài đặt nén:

1. Sử dụng Brotli nếu có thể. Như đã đề cập trước đó, Brotli mang đến một điểm cải tiến khá đáng chú ý so với gzip và Brotli được hỗ trợ trong tất cả các trình duyệt chính. 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 rằng gzip được dùng làm phương án dự phòng, vì mọi phương pháp nén đều tốt hơn là không nén.
2. 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 tốt, hoặc đôi khi thậm chí không nén được. Tính hiệu quả của mọi loại nén dữ liệu đề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ể xử lý để tìm ra nhiều bit dữ liệu có thể nén hơn. Tệp càng lớn thì mức độ nén càng hiệu quả. Tuy nhiên, đừng gửi các tài nguyên có kích thước quá lớn chỉ vì chúng có thể được nén hiệu quả hơn. Các tài nguyên lớn (chẳng hạn như JavaScript và CSS) mất nhiều thời gian hơn đáng kể để 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 đó, đồng thời có thể thay đổi thường xuyên hơn ngay cả khi chỉ thay đổi một chút, vì mọi thay đổi đều dẫn đến một băm tệp khác.
3. Tìm hiểu về tính năng nén linh động so với nén tĩnh. Nén linh động và nén tĩnh là các phương pháp khác nhau về thời điểm cần nén một tài nguyên. Tính năng nén linh động sẽ nén một tài nguyên vào thời điểm tài nguyên đó đượ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, tính năng nén tĩnh sẽ nén các tệp trước thời gian, không yêu cầu thực hiện nén tại thời điểm yêu cầu. Tính năng nén tĩnh sẽ loại bỏ độ trễ liên quan đến chính quá trình nén. Độ trễ này 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) phải được nén tĩnh, trong khi các tài nguyên HTML (đặc biệt nếu chúng được tạo động cho người dùng đã xác thực) phải được nén động.

Việc tự nén đúng cách là một việc khó khăn, và thường thì tốt nhất là bạn nên để Mạng phân phối nội dung (CDN) (sẽ được thảo luận trong phần tiếp theo) xử lý việc này cho bạn. Tuy nhiên, việc nắm rõ những khái niệm này có thể giúp bạn nhận biết liệu nhà cung cấp dịch vụ lưu trữ của bạn 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 ra cơ hội cải thiện chế độ cài đặt nén để 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 lưới máy chủ phân tán giúp lưu vào bộ nhớ đệm các tài nguyên từ máy chủ gốc của bạn, 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 về mặt vật lý. Khoảng cách vật lý đến người dùng giúp giảm thời gian khứ hồi (RTT), trong khi các hoạt động tối ưu hoá như HTTP/2 hoặc HTTP/3, 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. Trong một số trường hợp, việc sử dụng CDN có thể cải thiện đáng kể TTFB của trang web.

Kiểm tra kiến thức của bạn

Tiếp theo: Tìm hiểu về đường dẫn quan trọng

Giờ đây, khi đã nắm được 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ẽ có thể đảm bảo rằng trang web có thể tải nhanh nhất có thể – nhưng đó chỉ là bước khởi đầu trong việc tìm hiểu về hiệu suất web. Tiếp theo, chúng ta sẽ tìm hiểu lý thuyết đằng sau đường 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à tài nguyên chặn phân tích cú pháp, cũng như vai trò của các tài nguyên này trong việc hiển thị ban đầu một trang trong trình duyệt nhanh nhất có thể.