Áp chính sách theo tài nguyên, không theo máy chủ
Lập danh mục các URL đại diện trước khi thay đổi header: trang chủ, trang nội dung, application shell, CSS, JavaScript, ảnh, font, API, đăng nhập, tài khoản, thanh toán và tải về. Với mỗi URL, ghi lại liệu phản hồi có công cộng hay cá nhân hóa, liệu URL có thay đổi khi byte thay đổi, và bao lâu thì một sửa lỗi phải đến được khách truy cập.
Tạo một ma trận chính sách từ bản kiểm kê đó. Một tài sản công cộng định danh theo nội dung cần quy tắc khác so với HTML ở địa chỉ ổn định. Các phản hồi không có Cache-Control vẫn có thể bị cache theo heuristic, nên quy tắc tường minh dễ kiểm tra hơn.
Khoảng thời gian một phản hồi lưu trữ có thể được tái sử dụng; max-age cho giá trị này theo giây.
Sử dụng chính xác các thuật ngữ Cache-Control
Cache-Control chỉ dẫn cho trình duyệt và các bộ đệm chia sẻ cách lưu trữ và tái sử dụng phản hồi. max-age=N cho phép tái sử dụng trong khi còn tươi. s-maxage=N thiết lập thời hạn tươi cho cache chia sẻ và ghi đè max-age ở đó, nhưng trình duyệt bỏ qua s-maxage. public cho phép bất kỳ bộ đệm nào lưu; private cho phép trình duyệt lưu nhưng ngăn lưu trong cache chia sẻ.
no-cache cho phép lưu nhưng yêu cầu xác thực tới origin trước khi tái sử dụng. no-store nghĩa là các bộ đệm không được lưu phản hồi, nhưng không phải là biện pháp bảo vệ riêng tư hoàn chỉnh. Dùng must-revalidate khi việc phục vụ nội dung đã hết hạn là không chấp nhận được; trong trường hợp origin không sẵn sàng, hệ thống có thể trả về 504 thay vì một bản sao lỗi thời.
Nó loại bỏ việc lưu trữ thay vì chỉ yêu cầu kiểm tra; chỉ dùng cho các phản hồi thực sự không được lưu.
Phiên bản hóa tài sản bất biến trước khi gán thời hạn dài
URL tài sản có phiên bản bao gồm fingerprint nội dung hoặc phiên bản phát hành, ví dụ app.4f2c.js. Khi byte của tài sản thay đổi, công bố một URL khác và cập nhật tham chiếu trong HTML. Cache sẽ thấy một tài nguyên mới, vì vậy khách sẽ tải tài sản mới mà không cần phải invalidation tới mọi trình duyệt.
Đối với một biểu diễn sẽ không thay đổi trong suốt thời hạn tươi của nó, Cache-Control: max-age=31536000, immutable là một mẫu thực tế. immutable báo cho các client hỗ trợ không thực hiện revalidate có điều kiện khi còn tươi. Không áp dụng nó hoặc max-age một năm cho một tệp có thể thay đổi cùng-URL. Giữ lại các tài sản fingerprinted trước đó trong khi HTML bị cache có thể vẫn tham chiếu đến chúng.
HTML chọn URL tài sản, vì vậy thứ tự phát hành phải giữ lại thế hệ được tham chiếu.
Giữ HTML luôn cập nhật bằng xác thực, không bằng cache lâu
HTML thường có URL ổn định thân thiện với con người và thay đổi theo nội dung, tham chiếu tài sản, feature flag hoặc thông báo bảo mật. Một mẫu HTML công cộng thận trọng là Cache-Control: no-cache kết hợp với ETag và Last-Modified khi nền tảng của bạn có thể tạo chúng chính xác. Trình duyệt lưu body nhưng sẽ gửi yêu cầu có điều kiện trước khi tái sử dụng; nếu không đổi thì server trả 304 Not Modified mà không có body.
ETag nhận dạng phiên bản tài nguyên. Trên một phản hồi đã hết tươi, trình duyệt có thể gửi ETag trong If-None-Match; nếu trùng, server trả 304, nếu không sẽ gửi biểu diễn mới. Hướng dẫn RFC ưu tiên cả ETag và Last-Modified trên một phản hồi 200 khi có thể. no-cache không hứa hẹn xác thực khi người dùng điều hướng Back hoặc Forward vì trình duyệt có thể khôi phục snapshot lịch sử phiên.
ETag phải thay đổi khi biểu diễn thay đổi; kiểm tra nó trên các origin và môi trường triển khai khác nhau.
Tách biệt phân phối công cộng và các phản hồi cá nhân hóa/nhạy cảm
Một cache chia sẻ, như CDN, có thể tái sử dụng một phản hồi cho nhiều người dùng. Không để nó tái sử dụng HTML hoặc dữ liệu API đặc thù tài khoản cho nhiều người dùng. Với nội dung cá nhân hóa có thể tồn tại trong trình duyệt, private và no-cache là khởi điểm hợp lý: nó ngăn lưu trong cache chia sẻ và yêu cầu xác thực.
Với các phản hồi không nên lưu, dùng no-store và rà soát mã ứng dụng, quy tắc CDN, service worker, bộ nhớ trình duyệt, log và trang lỗi. Header thôi không cấu thành chương trình riêng tư, tuân thủ hay bảo mật thanh toán hoàn chỉnh. Hãy để đội bảo mật, bảo mật dữ liệu và thanh toán có trình độ đánh giá các luồng nhạy cảm và các yêu cầu áp dụng.
Kiểm tra đăng nhập, đăng xuất, chuyển tài khoản và thay đổi quyền với cache trình duyệt và CDN đã ấm.
Triển khai thay đổi cache như một bản phát hành có thể đảo ngược
Chụp trạng thái header và hành vi body cơ sở cho yêu cầu chưa cache và yêu cầu lặp lại. Trong staging, triển khai tài sản có phiên bản trước, sau đó HTML tham chiếu chúng, và kiểm tra HTML cũ được cache với origin mới. Kiểm tra cả đường thẳng tới origin và qua CDN nếu cả hai tồn tại. Header trong DevTools Network nên hiển thị chính sách mong muốn và hành vi lặp lại.
Giữ một manifest phát hành của URL tài sản, quy tắc header và phiên bản cấu hình. Nếu một phát hành kết hợp các file client không tương thích, phục hồi HTML tương thích và hành vi ứng dụng, nhưng không ghi đè một file fingerprinted đã công bố. Trỏ lại HTML về thế hệ biết là tốt và giữ cả hai thế hệ trong khi HTML được cache có thể yêu cầu chúng. Một purge trên cache chia sẻ không thể buộc mọi trình duyệt loại bỏ một phản hồi đang còn tươi.
Biến lỗi kiểm tra header, 404 tài sản và mismatch phiên bản thành các thay đổi cho checklist phát hành tiếp theo.