Tóm tắt các giải pháp xử lý lỗi màn hình trắng do cache khi phát hành frontend

Bài viết này chủ yếu giới thiệu một số giải pháp để xử lý lỗi màn hình trắng khi phát hành frontend do trình duyệt lưu cache. Ngoài ra, bài viết còn đề cập đến tối ưu quy trình phát hành bằng Jenkins và phương án sử dụng mã phiên bản để giảm thiểu các vấn đề về cache. Mỗi giải pháp đều có ưu điểm và nhược điểm riêng, cần lựa chọn và điều chỉnh theo tình hình thực tế.

I. Tối ưu cấu hình cốt lõi (tiền đề là yêu cầu truy cập trang web có thể đến được máy chủ)

Phương án 1: Cấu hình toàn cục không lưu cache cho dự án frontend

Nguyên lý hoạt động: Trong cấu hình máy chủ H5 thêm header phản hồi Cache-Control: no-cache hoặc max-age=0 để vô hiệu hóa việc cache tài nguyên tĩnh.
Ưu điểm: Có thể giải quyết tối đa vấn đề cache khi phát hành ở đầu ra máy chủ.
Nhược điểm: Người dùng sẽ tải lại toàn bộ giao diện khi chuyển đổi trang, ảnh hưởng đến tốc độ tải frontend và dễ gây áp lực băng thông khi có lượng truy cập cao.

Phương án 2: Sửa lỗi cache tài nguyên index.html – Cấm cache tệp index.html

Ưu điểm: Ứng dụng đơn trang có thể thiết lập mẫu trang chủ không được cache, trình duyệt người dùng luôn tải mẫu trang mới từ máy chủ, tránh sử dụng mẫu cũ.
Nhược điểm: Do không cache trang chủ, mỗi lần truy cập đều tải lại từ máy chủ nên thời gian tải vào hệ thống sẽ lâu hơn.

Phương án 3: Thêm tham số ETag và Last-Modified vào tài nguyên index.html

server {
listen 8080;
root /var/www/web/;
location /index.html {
etag on;
if_modified_since exact;
add_header Cache-Control “public, max-age=0”;
expires modified +1y;
try_files $uri /index.html;
}
location / {
try_files $uri $uri/ /index.html;
}
}

• ETag: Là định danh duy nhất do máy chủ tạo ra cho mỗi tài nguyên (như giá trị hash hoặc mã phiên bản), thay đổi nội dung sẽ thay đổi giá trị này.

• Last-Modified: Thời gian chỉnh sửa cuối cùng của tài nguyên do máy chủ cung cấp.
  Nguyên lý hoạt động:
  Lần đầu trình duyệt yêu cầu tài nguyên, máy chủ phản hồi với ETag và Last-Modified. Các yêu cầu sau, trình duyệt sẽ gửi If-None-Match và If-Modified-Since. Máy chủ sẽ ưu tiên kiểm tra ETag, nếu phù hợp sẽ trả về mã 304 và trình duyệt sử dụng bản cache cũ.
  Ưu điểm: Phát hiện thay đổi nội dung ở cấp độ byte hoặc dấu thời gian của hệ thống file, tận dụng cache hiệu quả và giảm tải cho máy chủ.
  Nhược điểm:

• Nếu nhiều máy chủ có sự không nhất quán về thuộc tính file hoặc dấu thời gian có thể gây lỗi ETag/Last-Modified.

• Với các hệ thống phân phối như Jenkins có thể xử lý bằng cách dùng chung bản build, còn với k8s hoặc môi trường khác nên dùng hệ thống file phân tán hoặc công cụ đồng bộ.

• Mỗi lần kiểm tra ETag đều cần CPU để xử lý, tuy nhiên với tải hiện tại thì có thể bỏ qua.

• Phụ thuộc quá nhiều vào cache trình duyệt, nếu cache lỗi mà vẫn vượt qua kiểm tra có thể gây lỗi không xác định.

Gợi ý: có thể dùng lệnh curl -I https://tên-miền để kiểm tra header phản hồi.

II. Tối ưu quy trình phát hành bằng Jenkins

Nguyên lý hoạt động:
Mỗi lần Jenkins phát hành, không xóa file JS phiên bản cũ mà thêm file JS mới vào cùng thư mục. Khi người dùng vẫn dùng phiên bản JS cũ đã cache sẽ không bị lỗi 404. Trình duyệt sẽ tự cập nhật JS mới khi phát hiện sự thay đổi.

Ưu điểm:

• Tránh lỗi trắng màn hình do JS không tải được sau khi phát hành.

Nhược điểm:

• Người dùng dùng JS cũ không thể sử dụng tính năng mới, nếu frontend và backend không đồng bộ có thể gây lỗi khi thao tác.

• Nếu người dùng không kích hoạt cơ chế cập nhật thì sẽ không nhận được phiên bản mới.

• Sau nhiều lần phát hành, thư mục chứa JS sẽ ngày càng lớn và làm chậm máy chủ, cần định kỳ xóa bớt file cũ.

Ví dụ script dọn dẹp: (chỉ mang tính tham khảo, không copy trực tiếp vì dữ liệu rất quan trọng):

Lệnh trên giữ lại 2 phiên bản mới nhất.

III. Sử dụng mã phiên bản

Cập nhật phiên bản từ backend

Nguyên lý hoạt động:
Backend cung cấp một API công khai trả về mã phiên bản hiện tại. Frontend tạo ID thiết bị duy nhất và lưu trong trình duyệt. Sau khi tải xong index.html nhưng trước khi chạy JS, frontend gửi yêu cầu kiểm tra mã phiên bản đến backend. Nếu không khớp, frontend sẽ dùng Service Worker và workbox-webpack-plugin để xóa cache và tải lại JS mới.

Ưu điểm:

• Có thể theo dõi thiết bị nào đang dùng phiên bản cũ qua log backend.

• Có thể kiểm soát việc làm mới của người dùng thông qua việc cập nhật mã phiên bản trong cơ sở dữ liệu.

• Có thể xác định người dùng cụ thể đang dùng mã phiên bản nào.

Nhược điểm:

• Cần nhiều công sức để triển khai và kiểm thử.

• Mỗi lần phát hành cần cập nhật thủ công mã phiên bản (hoặc tích hợp vào Jenkins để tự động cập nhật).

Tổng kết

Trên đây là các giải pháp xử lý lỗi trắng màn hình do cache khi phát hành frontend. Tùy theo môi trường và quy mô dự án mà lựa chọn phương án phù hợp. Bạn có thể tìm đọc thêm các bài viết liên quan tại Script House (脚本之家) hoặc tham khảo phần liên kết bên dưới. Hy vọng bài viết này giúp bạn tránh được các sự cố không mong muốn khi triển khai hệ thống frontend!