Nén HTTP: Vì sao file tải xuống nhỏ hơn nội dung trình duyệt đọc?

Một file JavaScript có thể lớn khi mở trong trình soạn thảo nhưng chỉ cần truyền một lượng dữ liệu nhỏ hơn qua mạng. Một nguyên nhân là nén HTTP: máy chủ gửi dạng nén, trình duyệt giải nén để sử dụng. Hiểu cơ chế này giúp đọc đúng số liệu hiệu năng và tránh kết luận “đã bật nén là website sẽ nhanh”.

1. Nén đường truyền không làm mất mã nguồn

gzip và Brotli là các lựa chọn nén không mất dữ liệu được dùng cho nội dung web. Trình duyệt khôi phục nội dung để xử lý, không loại bỏ chức năng của mã JavaScript. Nén cũng không đồng nghĩa với minify: minify thay đổi cách biểu diễn mã, còn nén HTTP thay đổi dạng dữ liệu được truyền.

Theo tài liệu Content-Encoding của MDN, header này mô tả cách nội dung đã được mã hóa để bên nhận giải mã. Content-Type vẫn mô tả kiểu nội dung, chẳng hạn HTML hoặc JSON.

2. Ba header cần phân biệt

Ví dụ minh họa, không phải kết quả đo của một website cụ thể:

Request:
Accept-Encoding: gzip, br

Response:
Content-Type: text/html; charset=utf-8
Content-Encoding: br
Vary: Accept-Encoding

br là tên mã hóa của Brotli. Danh sách client gửi không phải mệnh lệnh bắt server chọn thuật toán đầu tiên. Accept-Encoding tham gia quá trình thương lượng; khả năng và cấu hình server cũng quyết định kết quả.

3. Không phải tài nguyên nào cũng nên nén thêm

HTML, CSS, JavaScript và JSON thường là những ứng viên đáng đo. Ngược lại, JPEG hoặc ZIP vốn đã được nén; nén thêm có thể không tiết kiệm và còn tăng kích thước. Với phản hồi rất nhỏ, cần cân nhắc chi phí xử lý so với số byte giảm được.

Không có một tỷ lệ tiết kiệm áp dụng cho mọi website. Một file chứa nhiều đoạn lặp khác với dữ liệu vốn ít dư thừa. Ví dụ giả định 500 KB còn 120 KB chỉ mô tả một phép so sánh, không phải cam kết rằng mọi file sẽ giảm tương tự.

4. Đọc số liệu trong trình duyệt theo đúng ngữ cảnh

1. Mở DevTools, chọn Network rồi tải lại một trang được phép kiểm tra.
2. Chọn request HTML, CSS hoặc JavaScript và xem request headers cùng response headers.
3. Kiểm tra phản hồi có Content-Encoding hay không.
4. Phân biệt kích thước truyền với kích thước nội dung sau giải nén; tên cột và cách hiển thị tùy công cụ.
5. Ghi lại mã trạng thái, nguồn cache và điều kiện mạng để lần đo sau có thể so sánh.

Một tài nguyên lấy từ memory cache hoặc disk cache không phản ánh một lần tải đầy đủ qua mạng. Phản hồi 304 cũng không mang lại phép so sánh tương đương với phản hồi 200 có body. Nếu cần đo lần tải mới, dùng tùy chọn bỏ qua cache của công cụ và kiểm tra lại trạng thái thực tế, kể cả ảnh hưởng của service worker.

5. Cache phải phân biệt đúng phiên bản

Khi cùng URL có các phản hồi khác nhau dựa trên khả năng giải nén của client, cache cần chọn đúng phiên bản. Vary: Accept-Encoding biểu thị sự phụ thuộc đó cho cache HTTP. Nó không có nghĩa phản hồi được phép lưu công khai; chính sách lưu trữ vẫn là vấn đề riêng.

Nếu website có CDN hoặc reverse proxy, hãy kiểm tra ở đường truy cập người dùng thực sự sử dụng. Kết quả tại origin không đủ để chứng minh phản hồi sau CDN có cùng kiểu nén. Một tầng trung gian có thể thay đổi cách phân phối tài nguyên.

6. Đánh giá hiệu quả thay vì chỉ kiểm tra công tắc

Quy trình thực hành nên ghi nhận ba nhóm số liệu: byte truyền, thời gian phản hồi và tài nguyên máy chủ. Với tài nguyên tĩnh, có thể xem xét tạo sẵn bản nén nếu hệ thống hỗ trợ. Với phản hồi động, cần cân bằng chi phí nén với lợi ích truyền tải; không tự động chọn mức nén cao nhất.

• Đo cùng URL, cùng phiên bản nội dung và điều kiện cache tương đương.
• Kiểm tra nhiều lần thay vì kết luận từ một request.
• Xác nhận nội dung vẫn được trình duyệt giải mã và sử dụng bình thường.
• Không kỳ vọng nén giải quyết truy vấn chậm, JavaScript chạy lâu hoặc ảnh có kích thước hiển thị không phù hợp.

Nén HTTP là một phần của tối ưu hiệu năng. Kết quả hữu ích không chỉ là xuất hiện header gzip hoặc br, mà là giảm dữ liệu cần truyền mà không tạo thêm chi phí hay lỗi làm trải nghiệm xấu đi.