Dùng Bộ nhớ đệm HTTP để ngăn các yêu cầu không cần thiết về mạng

Việc tìm nạp tài nguyên qua mạng vừa chậm vừa tốn kém:

• Phản hồi lớn đòi hỏi nhiều lượt khứ hồi giữa trình duyệt và máy chủ.
• Trang của bạn sẽ không tải cho đến khi tất cả tài nguyên quan trọng của trang được tải xuống hoàn toàn.
• Nếu một người đang truy cập vào trang web của bạn bằng gói dữ liệu di động có giới hạn, thì mọi yêu cầu mạng không cần thiết đều gây lãng phí tiền của họ.

Làm cách nào để tránh các yêu cầu mạng không cần thiết? Bộ nhớ đệm HTTP của trình duyệt là tuyến phòng thủ đầu tiên của bạn. Đây không nhất thiết là phương pháp mạnh mẽ hoặc linh hoạt nhất và bạn có quyền kiểm soát hạn chế đối với thời gian hoạt động của các phản hồi được lưu vào bộ nhớ đệm, nhưng phương pháp này hiệu quả, được hỗ trợ trong tất cả trình duyệt và không đòi hỏi nhiều công sức.

Hướng dẫn này trình bày những kiến thức cơ bản về cách triển khai bộ nhớ đệm HTTP hiệu quả.

Khả năng tương thích với trình duyệt

Thực tế là không có một API nào được gọi là Bộ nhớ đệm HTTP. Đây là tên gọi chung cho một tập hợp các API nền tảng web. Các API đó được hỗ trợ trong tất cả trình duyệt:

Cache-Control

ETag

Last-Modified

Cách hoạt động của Bộ nhớ đệm HTTP

Tất cả yêu cầu HTTP mà trình duyệt đưa ra trước tiên đều được định tuyến đến bộ nhớ đệm của trình duyệt để kiểm tra xem có phản hồi hợp lệ nào được lưu vào bộ nhớ đệm có thể dùng để thực hiện yêu cầu hay không. Nếu có kết quả trùng khớp, phản hồi sẽ được đọc từ bộ nhớ đệm, giúp loại bỏ cả độ trễ mạng và chi phí dữ liệu mà quá trình chuyển dữ liệu gây ra.

Hành vi của Bộ nhớ đệm HTTP được kiểm soát bằng cách kết hợp tiêu đề của yêu cầu và tiêu đề phản hồi. Trong trường hợp lý tưởng, bạn sẽ có quyền kiểm soát cả mã cho ứng dụng web (sẽ xác định tiêu đề của yêu cầu) và cấu hình của máy chủ web (sẽ xác định tiêu đề phản hồi).

Hãy tham khảo bài viết Lưu HTTP vào bộ nhớ đệm của MDN để biết thông tin tổng quan chi tiết hơn về khái niệm này.

Tiêu đề của yêu cầu: Giữ nguyên giá trị mặc định (thường là vậy)

Có một số tiêu đề quan trọng cần được đưa vào các yêu cầu gửi đi của ứng dụng web, nhưng trình duyệt hầu như luôn đảm nhận việc đặt các tiêu đề đó thay cho bạn khi đưa ra yêu cầu. Các tiêu đề của yêu cầu ảnh hưởng đến việc kiểm tra độ mới, chẳng hạn như If-None-Match và If-Modified-Since, sẽ xuất hiện dựa trên mức độ hiểu biết của trình duyệt về các giá trị hiện tại trong Bộ nhớ đệm HTTP.

Đây là tin vui, nghĩa là bạn có thể tiếp tục thêm các thẻ như <img src="my-image.png"> vào HTML và trình duyệt sẽ tự động xử lý việc lưu vào bộ nhớ đệm HTTP cho bạn mà không cần tốn thêm công sức.

Tiêu đề phản hồi: Định cấu hình máy chủ web

Phần quan trọng nhất trong quá trình thiết lập lưu vào bộ nhớ đệm HTTP là các tiêu đề mà máy chủ web thêm vào mỗi phản hồi gửi đi. Tất cả các tiêu đề sau đây đều ảnh hưởng đến hành vi lưu vào bộ nhớ đệm hiệu quả:

• Cache-Control. Máy chủ có thể trả về một lệnh Cache-Control để chỉ định cách thức và thời gian mà trình duyệt cũng như các bộ nhớ đệm trung gian khác nên lưu phản hồi riêng lẻ vào bộ nhớ đệm.
• ETag. Khi trình duyệt tìm thấy một phản hồi đã hết hạn trong bộ nhớ đệm, trình duyệt có thể gửi một mã thông báo nhỏ (thường là hàm băm của nội dung tệp) đến máy chủ để kiểm tra xem tệp có thay đổi hay không. Nếu máy chủ trả về cùng một mã thông báo, thì tệp đó giống nhau và không cần tải lại.
• Last-Modified. Tiêu đề này có cùng mục đích với ETag, nhưng sử dụng chiến lược dựa trên thời gian để xác định xem tài nguyên có thay đổi hay không, trái ngược với chiến lược dựa trên nội dung của ETag.

Một số máy chủ web có hỗ trợ tích hợp sẵn để đặt các tiêu đề đó theo mặc định, trong khi một số máy chủ khác bỏ qua hoàn toàn các tiêu đề trừ phi bạn định cấu hình rõ ràng. Thông tin chi tiết cụ thể về cách định cấu hình tiêu đề sẽ khác nhau tuỳ thuộc vào máy chủ web mà bạn sử dụng. Bạn nên tham khảo tài liệu của máy chủ để biết thông tin chính xác nhất.

Để giúp bạn tiết kiệm thời gian tìm kiếm, dưới đây là hướng dẫn định cấu hình một số máy chủ web phổ biến:

• Sao lưu nhanh
• Apache
• nginx
• Firebase Hosting
• Netlify

Việc bỏ qua tiêu đề phản hồi Cache-Control không vô hiệu hoá tính năng lưu vào bộ nhớ đệm HTTP! Thay vào đó, trình duyệt sẽ đoán hành vi lưu vào bộ nhớ đệm nào phù hợp nhất với một loại nội dung nhất định. Có thể bạn muốn có nhiều quyền kiểm soát hơn so với những gì được cung cấp, vì vậy, hãy dành thời gian để định cấu hình tiêu đề phản hồi.

Bạn nên sử dụng giá trị tiêu đề phản hồi nào?

Có hai trường hợp quan trọng mà bạn nên đề cập khi định cấu hình tiêu đề phản hồi của máy chủ web.

Lưu vào bộ nhớ đệm trong thời gian dài cho các URL có phiên bản

Khi phản hồi các yêu cầu về URL chứa thông tin "vân tay số" hoặc thông tin phiên bản và nội dung không bao giờ thay đổi, hãy thêm Cache-Control: max-age=31536000 vào phản hồi của bạn.

Việc đặt giá trị này sẽ cho trình duyệt biết rằng khi cần tải cùng một URL vào bất kỳ lúc nào trong vòng một năm tới (31.536.000 giây; giá trị được hỗ trợ tối đa), trình duyệt có thể sử dụng ngay giá trị trong Bộ nhớ đệm HTTP mà không cần phải gửi yêu cầu mạng đến máy chủ web của bạn. Thật tuyệt vời! Bạn đã ngay lập tức có được độ tin cậy và tốc độ nhờ tránh được mạng!

Các công cụ xây dựng như webpack có thể tự động hoá quy trình chỉ định dấu vân tay băm cho URL của thành phần.

Xác thực lại máy chủ cho các URL không có phiên bản

Rất tiếc, không phải URL nào bạn tải cũng được tạo phiên bản. Có thể bạn không thể thêm bước xây dựng trước khi triển khai ứng dụng web, vì vậy, bạn không thể thêm hàm băm vào URL của thành phần. Ngoài ra, mọi ứng dụng web đều cần có tệp HTML. Những tệp đó (gần như!) sẽ không bao giờ chứa thông tin về phiên bản, vì không ai muốn sử dụng ứng dụng web của bạn nếu họ cần nhớ rằng URL cần truy cập là https://example.com/index.34def12.html. Vậy bạn có thể làm gì với những URL đó?

Đây là một trường hợp mà bạn cần phải chấp nhận thất bại. Chỉ riêng việc lưu vào bộ nhớ đệm HTTP là chưa đủ mạnh để tránh hoàn toàn mạng. (Đừng lo, bạn sẽ sớm tìm hiểu về trình chạy dịch vụ, công cụ này sẽ hỗ trợ chúng ta lật ngược thế cờ.) Tuy nhiên, bạn có thể thực hiện một vài bước để đảm bảo các yêu cầu mạng diễn ra nhanh chóng và hiệu quả nhất có thể.

Các giá trị Cache-Control sau đây có thể giúp bạn tinh chỉnh vị trí và cách lưu URL không có phiên bản vào bộ nhớ đệm:

• no-cache. Thao tác này hướng dẫn trình duyệt rằng trình duyệt phải xác thực lại với máy chủ mỗi lần trước khi sử dụng phiên bản đã lưu vào bộ nhớ đệm của URL.
• no-store. Thao tác này hướng dẫn trình duyệt và các bộ nhớ đệm trung gian khác (như CDN) không bao giờ lưu trữ bất kỳ phiên bản nào của tệp.
• private. Trình duyệt có thể lưu tệp vào bộ nhớ đệm nhưng bộ nhớ đệm trung gian thì không.
• public. Phản hồi có thể được lưu trữ trong bất kỳ bộ nhớ đệm nào.

Hãy xem Phụ lục: Sơ đồ quy trình Cache-Control để hình dung quy trình quyết định(các) giá trị Cache-Control cần sử dụng. Cache-Control cũng có thể chấp nhận danh sách các lệnh được phân tách bằng dấu phẩy. Xem Phụ lục: Ví dụ về Cache-Control.

Việc đặt ETag hoặc Last-Modified cũng có thể giúp ích. Như đã đề cập trong phần Tiêu đề phản hồi, ETag và Last-Modified đều phục vụ cùng một mục đích: xác định xem trình duyệt có cần tải lại tệp đã lưu vào bộ nhớ đệm đã hết hạn hay không. Bạn nên sử dụng ETag vì thuộc tính này chính xác hơn.

Việc đặt ETag hoặc Last-Modified giúp yêu cầu xác thực lại hiệu quả hơn nhiều bằng cách cho phép yêu cầu đó kích hoạt tiêu đề của yêu cầu If-Modified-Since hoặc If-None-Match được đề cập trong phần Tiêu đề yêu cầu.

Khi một máy chủ web được định cấu hình đúng cách thấy các tiêu đề của yêu cầu đến đó, máy chủ này có thể xác nhận xem phiên bản tài nguyên mà trình duyệt đã có trong Bộ nhớ đệm HTTP có khớp với phiên bản mới nhất trên máy chủ web hay không. Nếu có kết quả trùng khớp, thì máy chủ có thể phản hồi bằng phản hồi HTTP 304 Not Modified, tương đương với "Này, hãy tiếp tục sử dụng những gì bạn đã có!" Có rất ít dữ liệu cần chuyển khi gửi loại phản hồi này, vì vậy, phản hồi này thường nhanh hơn nhiều so với việc phải thực sự gửi lại bản sao của tài nguyên thực tế được yêu cầu.

Tóm tắt

Bộ nhớ đệm HTTP là một cách hiệu quả để cải thiện hiệu suất tải vì nó giúp giảm các yêu cầu mạng không cần thiết. Tính năng này được hỗ trợ trong tất cả trình duyệt và không mất quá nhiều công sức để thiết lập.

Bạn nên bắt đầu bằng các cấu hình Cache-Control sau:

• Cache-Control: no-cache cho các tài nguyên cần được xác thực lại với máy chủ trước mỗi lần sử dụng.
• Cache-Control: no-store cho những tài nguyên không bao giờ được lưu vào bộ nhớ đệm.
• Cache-Control: max-age=31536000 cho tài nguyên theo phiên bản.

Ngoài ra, tiêu đề ETag hoặc Last-Modified có thể giúp bạn xác thực lại các tài nguyên đã hết hạn trong bộ nhớ đệm một cách hiệu quả hơn.

Tìm hiểu thêm

Nếu bạn muốn tìm hiểu thêm ngoài những kiến thức cơ bản về cách sử dụng tiêu đề Cache-Control, hãy xem hướng dẫn Các phương pháp hay nhất về lưu vào bộ nhớ đệm và những điều cần lưu ý về max-age của Jake Archibald.

Hãy xem bài viết Love your cache (Yêu thích bộ nhớ đệm) để biết hướng dẫn về cách tối ưu hoá việc sử dụng bộ nhớ đệm cho khách truy cập cũ.

Phụ lục: Các mẹo khác

Nếu có thêm thời gian, bạn có thể tham khảo thêm các cách sau để tối ưu hoá việc sử dụng Bộ nhớ đệm HTTP:

• Sử dụng URL nhất quán. Nếu bạn phân phát cùng một nội dung trên nhiều URL, thì nội dung đó sẽ được tìm nạp và lưu trữ nhiều lần.
• Giảm thiểu tỷ lệ rời bỏ. Nếu một phần của tài nguyên (chẳng hạn như tệp CSS) cập nhật thường xuyên, trong khi phần còn lại của tệp thì không (chẳng hạn như mã thư viện), hãy cân nhắc việc tách mã cập nhật thường xuyên thành một tệp riêng biệt và sử dụng chiến lược lưu vào bộ nhớ đệm trong thời gian ngắn cho mã cập nhật thường xuyên và chiến lược lưu vào bộ nhớ đệm trong thời gian dài cho mã không thay đổi thường xuyên.
• Hãy xem lệnh stale-while-revalidate mới nếu chính sách Cache-Control của bạn chấp nhận một mức độ lỗi thời nhất định.

Phụ lục: Sơ đồ quy trình Cache-Control

Phụ lục: Cache-Control ví dụ