Cải thiện hiệu suất bằng cách sử dụng mạng phân phối nội dung.
Mạng phân phối nội dung (CDN) cải thiện hiệu suất của trang web bằng cách sử dụng một mạng lưới máy chủ được phân phối để phân phối tài nguyên đến người dùng. Vì CDN giúp giảm tải của máy chủ nên chi phí của máy chủ cũng giảm và rất phù hợp để xử lý các đợt tăng đột biến về lưu lượng truy cập. Bài viết này thảo luận cách hoạt động của CDN và cung cấp hướng dẫn dựa trên nền tảng về cách chọn, định cấu hình và tối ưu hoá chế độ thiết lập CDN.
Tổng quan
Mạng phân phối nội dung bao gồm một mạng máy chủ được tối ưu hoá để phân phối nội dung nhanh chóng cho người dùng. Mặc dù CDN được cho là nổi tiếng nhất để phân phối nội dung được lưu vào bộ nhớ đệm, nhưng CDN cũng có thể cải thiện việc phân phối nội dung không thể lưu vào bộ nhớ đệm. Nói chung, càng nhiều trang web của bạn được phân phối qua CDN thì càng tốt.
Nhìn chung, lợi ích về hiệu suất của CDN bắt nguồn từ một số nguyên tắc: máy chủ CDN nằm gần người dùng hơn máy chủ gốc nên có độ trễ thời gian trọn vòng (RTT) ngắn hơn; việc tối ưu hoá mạng cho phép CDN phân phối nội dung nhanh hơn so với việc nội dung được tải "trực tiếp" từ máy chủ gốc; cuối cùng, bộ nhớ đệm CDN loại bỏ yêu cầu đi đến máy chủ gốc.
Phân phối tài nguyên
Mặc dù điều này nghe có vẻ không trực quan, nhưng việc sử dụng CDN để phân phối tài nguyên (kể cả tài nguyên không thể lưu vào bộ nhớ đệm) thường sẽ nhanh hơn so với việc để người dùng tải tài nguyên "trực tiếp" từ máy chủ của bạn.
Khi CDN được dùng để phân phối tài nguyên từ điểm gốc, một kết nối mới sẽ được thiết lập giữa ứng dụng và một máy chủ CDN ở gần. Phần còn lại của hành trình (nói cách khác là hoạt động chuyển dữ liệu giữa máy chủ CDN và nguồn gốc) diễn ra qua mạng của CDN – thường bao gồm các kết nối hiện có, liên tục với nguồn gốc. Lợi ích của việc này gấp đôi: chấm dứt kết nối mới càng gần người dùng càng tốt loại bỏ các chi phí thiết lập kết nối không cần thiết (việc thiết lập kết nối mới tốn kém và đòi hỏi nhiều khứ hồi); sử dụng kết nối được khởi động trước cho phép dữ liệu được truyền ngay lập tức với thông lượng tối đa có thể.
Một số CDN cải thiện điều này hơn nữa bằng cách định tuyến lưu lượng truy cập đến điểm gốc thông qua nhiều máy chủ CDN trải rộng trên Internet. Kết nối giữa các máy chủ CDN diễn ra trên các tuyến đáng tin cậy và được tối ưu hoá cao, thay vì các tuyến do Giao thức cổng nối biên (BGP) xác định. Mặc dù BGP là giao thức định tuyến trên thực tế của Internet, nhưng các quyết định định tuyến của BGP không phải lúc nào cũng theo hiệu suất. Do đó, các tuyến do BGP xác định có thể kém hiệu quả hơn so với các tuyến được tinh chỉnh giữa các máy chủ CDN.
Chức năng lưu vào bộ nhớ đệm
Việc lưu tài nguyên vào bộ nhớ đệm trên các máy chủ của CDN giúp bạn không cần yêu cầu đi khắp nơi đến nguồn gốc để được phân phát. Do đó, tài nguyên được phân phối nhanh hơn; cũng giảm tải cho máy chủ gốc.
Thêm tài nguyên vào bộ nhớ đệm
Phương pháp phổ biến nhất để điền sẵn bộ nhớ đệm CDN là sử dụng tài nguyên "lấy" (pull) của CDN khi cần thiết – đây được gọi là "lấy nguồn gốc". Lần đầu tiên khi một tài nguyên cụ thể được yêu cầu từ bộ nhớ đệm, CDN sẽ yêu cầu tài nguyên đó từ máy chủ gốc và lưu phản hồi vào bộ nhớ đệm. Bằng cách này, nội dung của bộ nhớ đệm được tích hợp theo thời gian khi có yêu cầu thêm tài nguyên không được lưu vào bộ nhớ đệm.
Xoá tài nguyên khỏi bộ nhớ đệm
CDN sử dụng tính năng giải phóng bộ nhớ đệm để định kỳ xoá các tài nguyên không hữu ích khỏi bộ nhớ đệm. Ngoài ra, chủ sở hữu trang web có thể sử dụng quy trình xoá hoàn toàn để xoá tài nguyên một cách rõ ràng.
Xoá bộ nhớ đệm
Bộ nhớ đệm có dung lượng lưu trữ hữu hạn. Khi bộ nhớ đệm gần hết dung lượng, bộ nhớ đệm sẽ tạo chỗ trống cho các tài nguyên mới bằng cách xoá những tài nguyên chưa được truy cập gần đây hoặc những tài nguyên chiếm nhiều dung lượng. Quá trình này được gọi là loại bỏ bộ nhớ đệm. Tài nguyên bị loại khỏi một bộ nhớ đệm không nhất thiết có nghĩa là tài nguyên đó đã bị loại khỏi tất cả bộ nhớ đệm trong mạng CDN.
Đẩy mạnh
Xoá hoàn toàn (còn được gọi là "vô hiệu hoá bộ nhớ đệm") là cơ chế xoá tài nguyên khỏi bộ nhớ đệm của CDN mà không cần phải chờ tài nguyên đó hết hạn hoặc bị loại bỏ. Hàm này thường được thực thi thông qua API. Việc xoá hoàn toàn rất quan trọng trong những trường hợp cần rút lại nội dung (ví dụ: sửa lỗi chính tả, lỗi về giá hoặc tin bài không chính xác). Hơn hết, nó cũng có thể đóng vai trò quan trọng trong chiến lược lưu vào bộ nhớ đệm của một trang web.
Nếu CDN hỗ trợ gần như xoá hoàn toàn tức thì, thì việc xoá hoàn toàn có thể được sử dụng như một cơ chế để quản lý việc lưu nội dung động vào bộ nhớ đệm: lưu nội dung động vào bộ nhớ đệm bằng TTL dài, sau đó xoá hoàn toàn tài nguyên mỗi khi được cập nhật. Bằng cách này, bạn có thể tối đa hoá thời lượng lưu vào bộ nhớ đệm của một tài nguyên động, mặc dù không biết trước khi nào tài nguyên sẽ thay đổi. Kỹ thuật này đôi khi được gọi là "lưu vào bộ nhớ đệm dựa trên tính năng chờ đợi".
Khi sử dụng tính năng xoá hoàn toàn trên quy mô lớn, tính năng này thường được dùng kết hợp với một khái niệm như "thẻ bộ nhớ đệm" hoặc "khoá bộ nhớ đệm thay thế". Cơ chế này cho phép chủ sở hữu trang web liên kết một hoặc nhiều giá trị nhận dạng bổ sung (đôi khi còn gọi là "thẻ") với tài nguyên đã lưu vào bộ nhớ đệm. Sau đó, các thẻ này có thể được sử dụng để tiến hành dọn dẹp với mức độ chi tiết cao. Ví dụ: bạn có thể thêm thẻ "chân trang" vào tất cả tài nguyên (ví dụ:
/about,/blog) chứa chân trang trang web của bạn. Khi chân trang được cập nhật, hãy hướng dẫn CDN của bạn xoá hoàn toàn tất cả tài nguyên được liên kết với thẻ "chân trang".
Tài nguyên lưu được vào bộ nhớ đệm
Việc một tài nguyên có được lưu vào bộ nhớ đệm hay không và cách lưu trữ tùy thuộc vào việc tài nguyên đó ở chế độ công khai hay riêng tư, tĩnh hay động.
Tài nguyên riêng tư và công khai
Tài nguyên riêng tư
Tài nguyên riêng tư chứa dữ liệu dành cho một người dùng, do đó CDN không được lưu vào bộ nhớ đệm. Tài nguyên riêng tư được biểu thị trong tiêu đề
Cache-Control: private.Tài liệu công khai
Tài nguyên công khai không chứa thông tin riêng của người dùng nên được CDN lưu vào bộ nhớ đệm. Một tài nguyên có thể được CDN coi là có thể lưu vào bộ nhớ đệm nếu không có tiêu đề
Cache-Control: no-storehoặcCache-Control: private. Khoảng thời gian tài nguyên công khai có thể được lưu vào bộ nhớ đệm phụ thuộc vào tần suất nội dung thay đổi.
Nội dung động và nội dung tĩnh
Nội dung động
Nội dung động là nội dung thay đổi thường xuyên. Các ví dụ về loại nội dung này là phản hồi của API và trang chủ cửa hàng. Tuy nhiên, việc nội dung này thay đổi thường xuyên không nhất thiết ngăn việc lưu nội dung này vào bộ nhớ đệm. Trong thời gian có lưu lượng truy cập lớn, việc lưu các phản hồi này vào bộ nhớ đệm trong khoảng thời gian rất ngắn (ví dụ: 5 giây) có thể làm giảm đáng kể tải trên máy chủ gốc, trong khi vẫn có tác động tối thiểu đến độ mới của dữ liệu.
Nội dung tĩnh
Nội dung tĩnh hiếm khi thay đổi, nếu có. Hình ảnh, video và thư viện tạo phiên bản thường là ví dụ về loại nội dung này. Vì nội dung tĩnh không thay đổi, nội dung đó phải được lưu vào bộ nhớ đệm với Thời gian tồn tại dài (TTL) – ví dụ: 6 tháng hoặc 1 năm.
Chọn CDN
Hiệu suất thường là một yếu tố được cân nhắc hàng đầu khi chọn CDN. Tuy nhiên, các tính năng khác mà CDN cung cấp (ví dụ: các tính năng bảo mật và phân tích), cũng như mức giá, dịch vụ hỗ trợ và quy trình làm quen của CDN đều là những yếu tố quan trọng cần cân nhắc khi chọn CDN.
Hiệu suất
Ở cấp độ cao, chiến lược hiệu suất của CDN có thể được cân nhắc về sự đánh đổi giữa việc giảm thiểu độ trễ và tối đa hoá tỷ lệ truy cập vào bộ nhớ đệm. Các CDN có nhiều điểm hiện diện (PoP) có thể có độ trễ thấp hơn nhưng có thể gặp phải tỷ lệ truy cập bộ nhớ đệm thấp hơn do lưu lượng truy cập được chia tách trên nhiều bộ nhớ đệm hơn. Ngược lại, những CDN có ít PoP hơn có thể nằm cách xa người dùng hơn về mặt địa lý, nhưng có thể đạt được tỷ lệ truy cập vào bộ nhớ đệm cao hơn.
Kết quả của sự đánh đổi này là một số CDN sử dụng phương pháp lưu vào bộ nhớ đệm theo bậc: các PoP ở gần người dùng (còn gọi là "bộ nhớ đệm cạnh") được bổ sung các PoP trung tâm có tỷ lệ truy cập vào bộ nhớ đệm cao hơn. Khi bộ nhớ đệm ở cạnh không tìm thấy tài nguyên, bộ nhớ đệm đó sẽ chuyển sang PoP trung tâm để tìm tài nguyên. Phương pháp này đánh đổi độ trễ lớn hơn một chút để có nhiều khả năng phân phát tài nguyên từ bộ nhớ đệm CDN - mặc dù không nhất thiết phải là bộ nhớ đệm cạnh.
Sự đánh đổi giữa việc giảm thiểu độ trễ và tối đa hoá tỷ lệ truy cập vào bộ nhớ đệm là một dải. Không có phương pháp cụ thể nào là tốt hơn mọi phương pháp; tuy nhiên, tuỳ thuộc vào tính chất của trang web và cơ sở người dùng của trang web, bạn có thể thấy rằng một trong những phương pháp này mang lại hiệu suất tốt hơn đáng kể so với phương pháp còn lại.
Ngoài ra, bạn cũng nên lưu ý rằng hiệu suất của CDN có thể thay đổi đáng kể tuỳ thuộc vào khu vực địa lý, thời gian trong ngày và thậm chí là các sự kiện đang diễn ra. Mặc dù bạn nên tự nghiên cứu về hiệu suất của CDN, nhưng rất khó để dự đoán hiệu suất chính xác bạn sẽ đạt được từ CDN.
Ảnh hưởng đối với thời gian hiển thị nội dung lớn nhất (LCP)
Như đã trình bày trước đó trong bài viết này, mục đích chính của CDN là giảm độ trễ bằng cách phân phối tài nguyên cho các máy chủ gần với người dùng hơn về mặt địa lý. Do đó, lợi ích chính của CDN là cải thiện hiệu suất tải. Đặc biệt, Thời gian đến byte đầu tiên (TTFB) của tài nguyên có thể được cải thiện đáng kể khi đưa CDN vào kiến trúc phía máy chủ của trang web.
Mặc dù TTFB không phải là chỉ số hiệu suất tập trung vào người dùng, nhưng TTFB này là một chỉ số quan trọng để chẩn đoán các vấn đề về Thời gian hiển thị nội dung lớn nhất (LCP) (đây là chỉ số tập trung vào người dùng).
CDN đặc biệt hiệu quả trong việc cải thiện LCP vì chúng có thể cải thiện cả việc phân phối tài liệu (bằng cách giảm TTFB trong việc thiết lập kết nối và lưu tài liệu vào bộ nhớ đệm) và cải thiện việc phân phối mọi tài nguyên tĩnh cần thiết để kết xuất phần tử LCP.
Các tính năng khác
CDN thường cung cấp nhiều tính năng bên cạnh giải pháp CDN cốt lõi của họ. Các tính năng thường được cung cấp bao gồm: cân bằng tải, tối ưu hoá hình ảnh, truyền video trực tuyến, điện toán biên và các sản phẩm bảo mật.
Cách thiết lập và định cấu hình CDN
Tốt nhất là bạn nên dùng CDN để phân phát toàn bộ trang web. Nhìn chung, bạn cần đăng ký với nhà cung cấp CDN, sau đó cập nhật bản ghi DNS CNAME để trỏ đến nhà cung cấp CDN. Ví dụ: bản ghi CNAME của www.example.com có thể trỏ đến example.my-cdn.com. Do sự thay đổi DNS này, lưu lượng truy cập đến trang web của bạn sẽ được định tuyến thông qua CDN.
Nếu không thể sử dụng CDN để phân phát tất cả tài nguyên, bạn có thể định cấu hình CDN để chỉ phân phát một nhóm nhỏ tài nguyên, ví dụ: chỉ phân phát các tài nguyên tĩnh. Bạn có thể thực hiện việc này bằng cách tạo một bản ghi CNAME riêng. Bản ghi này sẽ chỉ dùng cho những tài nguyên mà CDN phải phân phát. Ví dụ: bạn có thể tạo bản ghi static.example.com CNAME trỏ đến example.my-cdn.com. Bạn cũng sẽ cần phải viết lại URL của tài nguyên đang được CDN phân phát để trỏ đến miền con static.example.com mà bạn đã tạo.
Mặc dù CDN của bạn sẽ được thiết lập tại thời điểm này, nhưng cấu hình có thể sẽ không hiệu quả. Hai phần tiếp theo của bài viết này sẽ giải thích cách tận dụng tối đa CDN của bạn bằng cách tăng tỷ lệ truy cập bộ nhớ đệm và bật các tính năng hiệu suất.
Cải thiện tỷ lệ truy cập bộ nhớ đệm
Cách thiết lập CDN hiệu quả sẽ phân phát nhiều tài nguyên nhất có thể từ bộ nhớ đệm. Chỉ số này thường được đo bằng tỷ lệ lượt truy cập vào bộ nhớ đệm (CHR). Tỷ lệ lượt truy cập vào bộ nhớ đệm được định nghĩa là số lượt truy cập vào bộ nhớ đệm chia cho tổng số yêu cầu trong một khoảng thời gian nhất định.
Bộ nhớ đệm mới khởi tạo sẽ có CHR là 0 nhưng điều này sẽ tăng lên khi bộ nhớ đệm được điền sẵn các tài nguyên. CHR ở mức 90% là mục tiêu tốt cho hầu hết các trang web. Nhà cung cấp CDN của bạn phải cung cấp cho bạn số liệu phân tích và báo cáo liên quan đến CHR của bạn.
Khi tối ưu hoá CHR, điều đầu tiên cần xác minh là tất cả các tài nguyên có thể lưu vào bộ nhớ đệm đều được lưu vào bộ nhớ đệm và lưu vào bộ nhớ đệm trong một khoảng thời gian chính xác. Đây là quy trình đánh giá đơn giản mà tất cả các trang web nên thực hiện.
Nhìn chung, cấp độ tối ưu hoá CHR tiếp theo là tinh chỉnh chế độ cài đặt CDN để đảm bảo rằng các phản hồi tương đương về mặt logic của máy chủ không được lưu vào bộ nhớ đệm riêng biệt. Đây là tình trạng kém hiệu quả thường gặp do tác động của các yếu tố như tham số truy vấn, cookie và tiêu đề yêu cầu đối với việc lưu vào bộ nhớ đệm.
Đánh giá ban đầu
Hầu hết các CDN sẽ cung cấp số liệu phân tích bộ nhớ đệm. Ngoài ra, bạn cũng có thể sử dụng các công cụ như WebPageTest và Lighthouse để nhanh chóng xác minh rằng tất cả tài nguyên tĩnh của một trang đang được lưu vào bộ nhớ đệm trong đúng khoảng thời gian. Bạn có thể thực hiện việc này bằng cách kiểm tra tiêu đề Bộ nhớ đệm HTTP của từng tài nguyên. Việc lưu tài nguyên vào bộ nhớ đệm bằng Thời gian tồn tại (TTL) tối đa phù hợp sẽ tránh được các lượt tìm nạp nguồn không cần thiết trong tương lai, nhờ đó làm tăng CHR.
Ít nhất, một trong các tiêu đề này thường cần được đặt để CDN lưu vào bộ nhớ đệm:
Cache-Control: max-age=Cache-Control: s-maxage=Expires
Ngoài ra, mặc dù điều này không ảnh hưởng đến việc một tài nguyên có được CDN lưu vào bộ nhớ đệm hay không, nhưng bạn cũng nên đặt lệnh Cache-Control: immutable.Cache-Control: immutable cho biết rằng tài nguyên "sẽ không được cập nhật trong suốt thời gian làm mới". Do đó, trình duyệt sẽ không xác thực lại tài nguyên khi phân phối tài nguyên từ bộ nhớ đệm của trình duyệt, do đó loại bỏ yêu cầu không cần thiết đối với máy chủ. Rất tiếc, chỉ Firefox và Safari hỗ trợ lệnh này – các trình duyệt dựa trên Chromium không hỗ trợ lệnh này. Sự cố này theo dõi hỗ trợ Chromium dành cho Cache-Control: immutable. Việc gắn dấu sao vấn đề này có thể giúp khuyến khích người dùng hỗ trợ tính năng này.
Để xem nội dung giải thích chi tiết hơn về việc lưu HTTP vào bộ nhớ đệm, hãy tham khảo bài viết Ngăn chặn các yêu cầu mạng không cần thiết nhờ bộ nhớ đệm HTTP.
Tinh chỉnh
Giải thích đơn giản về cách hoạt động của bộ nhớ đệm CDN là URL của một tài nguyên được dùng làm khoá để lưu vào bộ nhớ đệm và truy xuất tài nguyên từ bộ nhớ đệm. Trong thực tế, điều này vẫn hoàn toàn đúng, nhưng hơi phức tạp do tác động của các yếu tố như tiêu đề yêu cầu và tham số truy vấn. Do đó, việc viết lại URL yêu cầu là một kỹ thuật quan trọng để vừa tăng tối đa CHR vừa đảm bảo phân phát đúng nội dung cho người dùng. Phiên bản CDN được định cấu hình đúng cách tạo ra sự cân bằng giữa việc lưu vào bộ nhớ đệm quá chi tiết (gây ảnh hưởng đến CHR) và việc lưu vào bộ nhớ đệm không đủ chi tiết (dẫn đến việc cung cấp thông tin phản hồi không chính xác cho người dùng).
Tham số truy vấn
Theo mặc định, CDN xem xét các tham số truy vấn khi lưu tài nguyên vào bộ nhớ đệm. Tuy nhiên, những điều chỉnh nhỏ để xử lý tham số truy vấn có thể có tác động đáng kể đến CHR. Ví dụ:
Tham số truy vấn không cần thiết
Theo mặc định, CDN sẽ lưu vào bộ nhớ đệm
example.com/blogvàexample.com/blog?referral_id=2zjkriêng biệt ngay cả khi chúng có thể là cùng một tài nguyên cơ bản. Bạn có thể khắc phục vấn đề này bằng cách điều chỉnh cấu hình của CDN để bỏ qua tham số truy vấnreferral\_id.Thứ tự tham số truy vấn
CDN sẽ lưu
example.com/blog?id=123&query=dogsvào bộ nhớ đệm riêng biệt vớiexample.com/blog?query=dogs&id=123. Đối với hầu hết các trang web, thứ tự tham số truy vấn không quan trọng, vì vậy, việc định cấu hình CDN để sắp xếp các tham số truy vấn (do đó chuẩn hoá URL được dùng để lưu phản hồi của máy chủ vào bộ nhớ đệm) sẽ làm tăng CHR.
Thay đổi
Tiêu đề phản hồi Vary thông báo cho bộ nhớ đệm rằng phản hồi của máy chủ tương ứng với một URL cụ thể có thể thay đổi tuỳ thuộc vào tiêu đề được đặt trong yêu cầu (ví dụ: tiêu đề của yêu cầu Accept-Language hoặc Accept-Encoding). Do đó, nó hướng dẫn CDN lưu vào bộ nhớ đệm riêng biệt các phản hồi này. Tiêu đề Vary không được các CDN hỗ trợ rộng rãi và có thể dẫn đến việc tài nguyên có thể lưu vào bộ nhớ đệm không được phân phát từ bộ nhớ đệm.
Mặc dù tiêu đề Vary có thể là một công cụ hữu ích, nhưng việc sử dụng không phù hợp sẽ ảnh hưởng đến CHR. Ngoài ra, nếu bạn sử dụng Vary, việc chuẩn hoá tiêu đề của yêu cầu sẽ giúp cải thiện CHR. Ví dụ: nếu không chuẩn hoá các tiêu đề của yêu cầu Accept-Language: en-US và Accept-Language: en-US,en;q=0.9 sẽ dẫn đến hai mục bộ nhớ đệm riêng biệt, mặc dù nội dung của chúng có thể giống hệt nhau.
Bánh quy
Cookie được đặt theo yêu cầu qua tiêu đề Cookie; cookie được đặt trên các phản hồi qua tiêu đề Set-Cookie. Bạn nên tránh sử dụng tiêu đề Set-Cookie khi không cần thiết vì bộ nhớ đệm thường sẽ không lưu các phản hồi của máy chủ có chứa tiêu đề này vào bộ nhớ đệm.
Các tính năng về hiệu suất
Phần này thảo luận về các tính năng hiệu suất thường được CDN cung cấp trong các dịch vụ sản phẩm cốt lõi. Nhiều trang web quên bật các tính năng này, do đó bỏ lỡ các chiến thắng dễ dàng về hiệu suất.
Nén
Tất cả các câu trả lời dựa trên văn bản phải được nén bằng gzip hoặc Brotli. Nếu bạn có lựa chọn, hãy chọn Brotli thay vì gzip. Brotli là một thuật toán nén mới hơn và so với gzip có thể đạt tỷ lệ nén cao hơn.
Có hai loại hỗ trợ CDN khi nén Brotli: "Brotli từ nguồn gốc" và "nén Brotli tự động".
Nguồn gốc Brotli
Brotli từ nguồn gốc là khi CDN phân phối tài nguyên được Brotli nén theo nguồn gốc. Mặc dù đây có vẻ là một tính năng mà tất cả CDN đều có thể hỗ trợ ngay, nhưng CDN đòi hỏi CDN phải lưu vào bộ nhớ đệm nhiều phiên bản (nói cách khác là phiên bản được nén bằng gzip và phiên bản được nén bằng Brotli) của tài nguyên tương ứng với một URL nhất định.
Nén Brotli tự động
Quá trình nén Brotli tự động là khi tài nguyên được Brotli nén bằng CDN. CDN có thể nén cả tài nguyên có thể lưu vào bộ nhớ đệm và tài nguyên không thể lưu trong bộ nhớ đệm.
Lần đầu tiên một tài nguyên được yêu cầu, nó được phân phát bằng cách nén "đủ tốt" - ví dụ: Brotli-5. Kiểu nén này có thể áp dụng cho cả tài nguyên có thể lưu vào bộ nhớ đệm và tài nguyên không thể lưu trong bộ nhớ đệm.
Trong khi đó, nếu một tài nguyên có thể lưu vào bộ nhớ đệm, CDN sẽ sử dụng xử lý ngoại tuyến để nén tài nguyên ở cấp độ nén mạnh hơn nhưng chậm hơn nhiều – ví dụ: Brotli-11. Sau khi quá trình nén này hoàn tất, phiên bản nén nhiều hơn sẽ được lưu vào bộ nhớ đệm và dùng cho các yêu cầu tiếp theo.
Các phương pháp nén hay nhất
Các trang web muốn tối đa hoá hiệu suất nên áp dụng chế độ nén Brotli ở cả máy chủ gốc và CDN. Tính năng nén Brotli tại điểm gốc sẽ giảm thiểu kích thước truyền của các tài nguyên không thể phân phát từ bộ nhớ đệm. Để tránh sự chậm trễ trong việc cung cấp các yêu cầu, điểm gốc phải nén tài nguyên động bằng cách sử dụng mức nén khá thận trọng - ví dụ: Brotli-4; tài nguyên tĩnh có thể được nén bằng cách sử dụng Brotli-11. Nếu nguồn gốc không hỗ trợ Brotli, có thể sử dụng gzip-6 để nén các tài nguyên động; gzip-9 có thể được sử dụng để nén các tài nguyên tĩnh.
TLS 1.3
TLS 1.3 là phiên bản mới nhất của Bảo mật tầng truyền tải (TLS), giao thức mật mã mà HTTPS sử dụng. TLS 1.3 mang lại hiệu suất và quyền riêng tư tốt hơn so với TLS 1.2.
TLS 1.3 rút ngắn quá trình bắt tay TLS từ hai lượt khứ hồi xuống còn một. Đối với các kết nối sử dụng HTTP/1 hoặc HTTP/2, việc rút ngắn quá trình bắt tay TLS thành một trọn vòng sẽ giúp giảm 33% thời gian thiết lập kết nối một cách hiệu quả.
HTTP/2 và HTTP/3
HTTP/2 và HTTP/3 đều mang lại lợi ích về hiệu suất so với HTTP/1. Trong 2 phiên bản này, HTTP/3 mang lại nhiều lợi ích hiệu suất tiềm năng hơn. HTTP/3 chưa được chuẩn hoá đầy đủ nhưng sẽ được hỗ trợ rộng rãi khi điều này xảy ra.
HTTP/2
Nếu CDN của bạn chưa bật HTTP/2 theo mặc định, bạn nên cân nhắc việc bật giao thức này. HTTP/2 mang lại nhiều lợi ích về hiệu suất so với HTTP/1 và được tất cả các trình duyệt chính hỗ trợ. Các tính năng hiệu suất của HTTP/2 bao gồm: ghép kênh, ưu tiên luồng và nén tiêu đề.
Ghép kênh
Ghép kênh được cho là tính năng quan trọng nhất của HTTP/2. Phương thức ghép kênh cho phép một kết nối TCP duy nhất phân phát nhiều cặp yêu cầu – phản hồi cùng một lúc. Điều này giúp loại bỏ hao tổn tài nguyên thiết lập kết nối không cần thiết; do số lượng kết nối mà trình duyệt có thể mở tại một thời điểm nhất định bị giới hạn, điều này cũng ngụ ý rằng trình duyệt hiện có thể yêu cầu song song nhiều tài nguyên của trang hơn. Phương pháp ghép kênh về mặt lý thuyết sẽ loại bỏ nhu cầu tối ưu hoá HTTP/1 như phép nối và hình sprite. Tuy nhiên, trên thực tế, các kỹ thuật này vẫn phù hợp vì các tệp lớn hơn sẽ nén tốt hơn.
Mức độ ưu tiên của sự kiện phát trực tiếp
Tính năng ghép kênh cho phép sử dụng nhiều luồng đồng thời; tính năng ưu tiên luồng cung cấp một giao diện để thông báo mức độ ưu tiên tương đối của từng luồng này. Điều này giúp máy chủ gửi các tài nguyên quan trọng nhất trước – ngay cả khi chúng không được yêu cầu trước.
Mức độ ưu tiên của luồng được trình duyệt biểu thị qua cây phần phụ thuộc và chỉ là tuyên bố về lựa chọn ưu tiên: nói cách khác, máy chủ không bắt buộc phải đáp ứng (hoặc thậm chí xem xét) các mức độ ưu tiên mà trình duyệt cung cấp. Tính năng ưu tiên luồng sẽ trở nên hiệu quả hơn khi có nhiều trang web được phân phát thông qua CDN.
Việc triển khai CDN về mức độ ưu tiên tài nguyên HTTP/2 rất khác nhau. Để xác định xem CDN của bạn có hỗ trợ đầy đủ và đúng cách tính năng ưu tiên tài nguyên HTTP/2 hay không, hãy tham khảo bài viết HTTP/2 có nhanh không?.
Mặc dù việc chuyển phiên bản CDN sang HTTP/2 chủ yếu là do việc bật/tắt công tắc, nhưng điều quan trọng là bạn phải kiểm thử kỹ lưỡng sự thay đổi này trước khi bật trong phiên bản chính thức. HTTP/1 và HTTP/2 sử dụng các quy ước giống nhau cho tiêu đề yêu cầu và phản hồi - nhưng HTTP/2 sẽ không hề dễ dàng khi không tuân thủ các quy ước này. Do đó, các phương pháp không đặc tả như bao gồm các ký tự không phải ASCII hoặc ký tự viết hoa trong tiêu đề có thể bắt đầu gây ra lỗi khi HTTP/2 được bật. Nếu điều này xảy ra, trình duyệt sẽ không thể tải tài nguyên xuống. Lần tải xuống không thành công sẽ hiển thị trong thẻ "Mạng" của Công cụ cho nhà phát triển. Ngoài ra, thông báo lỗi "ERR_HTTP2_PROTOCOL_ERROR" sẽ xuất hiện trong bảng điều khiển.
HTTP/3
HTTP/3 là sự kế thừa cho HTTP/2. Kể từ tháng 9 năm 2020, tất cả các trình duyệt chính đều có hỗ trợ thử nghiệm cho HTTP/3 và một số CDN hỗ trợ giao thức này. Hiệu suất là lợi ích chính của HTTP/3 so với HTTP/2. Cụ thể, HTTP/3 loại bỏ việc chặn nội tuyến ở cấp độ kết nối và giảm thời gian thiết lập kết nối.
Loại bỏ tính năng chặn dòng tiêu đề
HTTP/2 giới thiệu chế độ ghép kênh, một tính năng cho phép sử dụng một kết nối duy nhất để truyền đồng thời nhiều luồng dữ liệu. Tuy nhiên, với HTTP/2, một gói bị bỏ qua sẽ chặn tất cả các luồng trên một kết nối (hiện tượng được gọi là chặn đầu dòng). Với HTTP/3, một gói bị bỏ chỉ chặn một luồng duy nhất. Sự cải thiện này phần lớn là kết quả của việc HTTP/3 sử dụng UDP (HTTP/3 sử dụng UDP qua QUIC) thay vì TCP. Điều này khiến HTTP/3 đặc biệt hữu ích cho việc chuyển dữ liệu qua mạng bị nghẽn hoặc bị mất.
Giảm thời gian thiết lập kết nối
HTTP/3 sử dụng TLS 1.3 và do đó chia sẻ các lợi ích về hiệu suất của nó: việc thiết lập kết nối mới chỉ yêu cầu một lượt khứ hồi duy nhất và việc tiếp tục kết nối hiện tại không cần bất kỳ lượt khứ hồi nào.
HTTP/3 sẽ có tác động lớn nhất đến người dùng có kết nối mạng kém: không chỉ vì HTTP/3 xử lý tình trạng mất gói tin tốt hơn so với phiên bản trước, mà còn vì việc tiết kiệm thời gian tuyệt đối nhờ thiết lập kết nối 0-RTT hoặc 1-RTT sẽ lớn hơn trên các mạng có độ trễ cao.
Tối ưu hoá hình ảnh
Dịch vụ tối ưu hoá hình ảnh CDN thường tập trung vào việc tối ưu hoá hình ảnh có thể được áp dụng tự động để giảm kích thước chuyển hình ảnh. Ví dụ: xoá dữ liệu EXIF, áp dụng tính năng nén không tổn hao và chuyển đổi hình ảnh sang các định dạng tệp mới hơn (ví dụ: WebP). Hình ảnh chiếm khoảng 50% tổng số byte truyền tải của trang web trung gian, vì vậy, việc tối ưu hoá hình ảnh có thể làm giảm đáng kể kích thước trang.
Giảm thiểu
Rút gọn sẽ xoá các ký tự không cần thiết khỏi JavaScript, CSS và HTML. Bạn nên giảm kích thước tại máy chủ gốc thay vì CDN. Chủ sở hữu trang web có nhiều thông tin liên quan hơn về đoạn mã cần giảm bớt, do đó, thường có thể sử dụng kỹ thuật giảm kích thước mã mạnh mẽ hơn so với kỹ thuật mà CDN sử dụng. Tuy nhiên, nếu không thể giảm thiểu mã tại điểm gốc, thì giảm thiểu bằng CDN là một giải pháp thay thế phù hợp.
Kết luận
- Sử dụng CDN: CDN phân phối tài nguyên nhanh chóng, giảm tải trên máy chủ gốc và rất hữu ích để xử lý các trường hợp lưu lượng truy cập tăng đột biến.
- Lưu nội dung vào bộ nhớ đệm thường xuyên nhất có thể: Cả nội dung tĩnh và động đều có thể và nên được lưu vào bộ nhớ đệm – mặc dù có thời lượng khác nhau. Định kỳ kiểm tra trang web của bạn để đảm bảo rằng bạn đang lưu nội dung vào bộ nhớ đệm một cách tối ưu.
- Bật các tính năng hiệu suất CDN: Các tính năng như Brotli, TLS 1.3, HTTP/2 và HTTP/3 giúp cải thiện hiệu suất hơn nữa.