Kích thước đối tượng tối thiểu được khuyến nghị cho lợi ích hiệu suất gzip là gì?


31

Tôi đang làm việc để cải thiện thời gian hiển thị tốc độ trang và một trong những phương pháp là gzip nội dung từ máy chủ web.

Google khuyến nghị :

Lưu ý rằng gzipping chỉ có lợi cho các tài nguyên lớn hơn. Do chi phí và độ trễ của quá trình nén và giải nén, bạn chỉ nên tải các tệp gzip trên ngưỡng kích thước nhất định; chúng tôi khuyến nghị phạm vi tối thiểu trong khoảng từ 150 đến 1000 byte. Gzipping các tệp dưới 150 byte thực sự có thể làm cho chúng lớn hơn.

Chúng tôi phục vụ nội dung của chúng tôi thông qua Akamai , sử dụng mạng của họ cho proxy và CDN. Những gì họ đã nói với tôi:

Theo dõi câu hỏi của bạn về kích thước tối thiểu Akamai sẽ nén đối tượng được yêu cầu khi gửi nó cho người dùng cuối: Kích thước tối thiểu là 860 byte.

Phản hồi của tôi:

Lý do tại sao kích thước tối thiểu của Akamai là 860 byte? Và tại sao, ví dụ, đây không phải là trường hợp cho các tệp mà Akamai phục vụ cho Facebook? ( xem bên dưới ) Google khuyên bạn nên gzip mạnh hơn. Và điều đó có vẻ phù hợp trên trang web của chúng tôi, nơi các lượt truy cập thường xuyên nhất, cho đến nay, là các cuộc gọi AJAX <860 byte.Ảnh chụp màn hình tiêu đề Facebook tranh chấp tuyên bố của Akamai

Phản ứng của Akamai:

Lý do 860 byte là kích thước tối thiểu để nén là gấp đôi: (1) Chi phí nén của một đối tượng dưới 860 byte vượt xa mức tăng hiệu suất. (2) Dù sao, các đối tượng dưới 860 byte có thể được truyền qua một gói duy nhất, vì vậy không có lý do thuyết phục nào để nén chúng.

Vì vậy, tôi ở đây để kiểm tra thực tế. Là giới hạn 860 byte do kích thước gói là kết thúc của lý do này? Tại sao các trang web lưu lượng truy cập cao sẽ đẩy mức này xuống giới hạn 150 byte ... chỉ để tiết kiệm chi phí băng thông (vì CDN dựa trên phí của chúng trên băng thông được giảm tải từ nguồn gốc) hoặc có tăng hiệu suất khi làm như vậy không?


Cập nhật 7/9/12: Tôi đã hỏi Steve Souder nếu có hiệu suất tăng trong các phản hồi gzipping đã nhỏ hơn một gói và kích thước đối tượng tối thiểu được đề xuất cho lợi ích hiệu suất gzip và đây là phản hồi của anh ấy:

Cảm ơn email của bạn. Kích thước nằm trong khoảng từ 1-5K. Apache có một mặc định nhưng tôi quên nó là gì - đó sẽ là một hướng dẫn tốt.

Chúng tôi thực hiện nén trên thiết bị F5, vì vậy chúng tôi sẽ hạ nó xuống ~ 350 byte, vì có một số lượng lớn các cuộc gọi AJAX giữa đó và 1K. Các cuộc gọi AJAX có ít hơn 350 byte trên trang web của chúng tôi đều giảm khoảng 70 byte ... ít hơn so với khuyến nghị của Google ... vì vậy nó thực sự quay trở lại: biết trang web của bạn và điều chỉnh dựa trên mã của bạn .

Tôi sẽ quay lại bài đăng này sau khi bản cập nhật F5 chạy trong Sản xuất một thời gian. Tôi nghĩ rằng sẽ có ít lợi ích hiệu suất, nhưng chúng tôi sẽ giảm chi phí Akamai của chúng tôi một chút vì chúng đang phục vụ ít hơn.


@Steve, liên quan đến bản chỉnh sửa tháng 4, tôi đã thêm welp để làm rõ cảm giác, vì chuyên gia trong lĩnh vực này đã không trả lời câu hỏi nào. Tôi rất vui khi nghe lại từ ông Sounders nhưng ông cũng không biết câu trả lời dứt khoát.
utt73

Đối với "quay lại bài đăng này sau khi bản cập nhật F5 chạy trong Sản xuất một thời gian ", mặc dù tôi không làm việc với ứng dụng web cụ thể này nữa, chúng tôi đã thành công trong mục tiêu nhận được cả sự kiện tải trang trung bình () và Thời gian để Tương tác (TTI) dưới 2 giây và việc giảm nỗ lực tải này là một phần nhỏ trong số đó. Giảm số lượng cuộc gọi lưu lượng truy cập http, mở rộng bộ nhớ đệm trình duyệt, tối ưu hóa mã và các hoạt động tốt nhất về hiệu suất web khác đều được đóng góp.
utt73

Câu trả lời:


3

Bạn đang nói về lợi ích cho chi phí băng thông của mình, nhưng sau đó cũng so sánh hiệu suất của tải trang trong trình duyệt. Chúng là hai thứ khác nhau.

Bất cứ khi nào bạn gzip một yêu cầu, một cái gì đó phải thực sự nén (trong trường hợp của bạn, F5) và máy khách (hoặc proxy kỹ thuật) phải xử lý giải nén. Điều này có thể thêm độ trễ cho yêu cầu của bạn, tùy thuộc vào khả năng phần cứng ở cả hai đầu.

"Kích thước tối thiểu cho gzip" dựa trên thời gian cần thiết để nén / giải nén rằng dữ liệu nhỏ không hữu ích từ góc độ trải nghiệm trình duyệt web. Nếu bạn hoàn toàn nói về tiết kiệm băng thông, thì hãy tiếp tục và đặt mức tối thiểu của bạn ở mức thấp như bạn muốn, nhưng hãy biết rằng bạn có thể không mang lại cho người dùng cuối của bạn bất kỳ hiệu suất nào.

Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.