Jaki jest zalecany minimalny rozmiar obiektu dla korzyści wydajności gzip?


31

Pracuję nad poprawieniem czasu wyświetlania szybkości strony, a jedną z metod jest gzipowanie zawartości z serwera WWW.

Google zaleca :

Pamiętaj, że gzipping jest korzystny tylko dla większych zasobów. Z powodu narzutu i opóźnień związanych z kompresją i dekompresją pliki gzip powinny być otwierane tylko powyżej określonego rozmiaru; zalecamy minimalny zakres od 150 do 1000 bajtów. Pliki zgzipujące poniżej 150 bajtów mogą faktycznie zwiększyć je.

Obsługujemy nasze treści za pośrednictwem Akamai , wykorzystując ich sieć jako serwer proxy i CDN. Co mi powiedzieli:

W odpowiedzi na pytanie dotyczące minimalnego rozmiaru Akamai skompresuje żądany obiekt podczas wysyłania go do użytkownika końcowego: Minimalny rozmiar to 860 bajtów.

Moja odpowiedź:

Jaki jest powód, dla którego minimalny rozmiar Akamai wynosi 860 bajtów? I dlaczego na przykład tak nie jest w przypadku plików, które Akamai obsługuje na Facebooku? ( patrz poniżej ) Google zaleca bardziej agresywne gzip. I wydaje się to właściwe na naszej stronie, gdzie zdecydowanie najczęściej odwiedzane są wywołania AJAX o wielkości <860 bajtów.Nagłówek Facebooka zrzut ekranu kwestionujący oświadczenie Akamai

Odpowiedź Akamai:

Powód, dla którego 860 bajtów ma minimalny rozmiar do kompresji, jest dwojaki: (1) Narzut związany z kompresowaniem obiektu poniżej 860 bajtów przewyższa wzrost wydajności. (2) Obiekty o rozmiarze poniżej 860 bajtów mogą być przesyłane przez pojedynczy pakiet, więc nie ma ważnego powodu, aby je skompresować.

Więc jestem tu, żeby sprawdzić fakty. Czy limit 860 bajtów ze względu na rozmiar pakietu to koniec tego rozumowania? Dlaczego witryny o dużym natężeniu ruchu miałyby to obniżać do limitu 150 bajtów ... tylko po to, aby zaoszczędzić na kosztach przepustowości (skoro sieci CDN opierają swoje opłaty na przepustowości odciążonej od źródła), czy też osiąga to wzrost wydajności?


Aktualizacja z 9.09.12: Zapytałem Steve'a Soudersa, czy nastąpił wzrost wydajności w odpowiedziach gzipping, które są już mniejsze niż pakiet i jaki jest zalecany minimalny rozmiar obiektu dla korzyści wydajności gzip, a to jest jego odpowiedź:

Dziękuję za Twój e-mail. Rozmiar jest gdzieś pomiędzy 1-5K. Apache ma wartość domyślną, ale zapominam, co to jest - to byłby dobry przewodnik.

Kompresujemy na urządzeniu F5, więc obniżymy go do ~ 350 bajtów, ponieważ między tą a 1K jest sporo połączeń AJAX. Wszystkie wywołania AJAX, które mają mniej niż 350 bajtów w naszej witrynie, mają około 70 bajtów ... mniej niż zalecenia Google ... więc naprawdę wydaje się, że wracają do: znajomości witryny i dostosowania w oparciu o kod .

Wrócę do tego postu, gdy aktualizacja F5 będzie działać przez pewien czas w dziale produkcyjnym. Wydaje mi się, że poprawa wydajności będzie niewielka, ale obniżymy nieco nasze koszty Akamai, ponieważ służą mniej.


@ Steve, odnośnie kwietniowej edycji dodałem welp, aby wyjaśnić uczucia, ponieważ ekspert w tej dziedzinie nie odpowiedział na żadne pytanie. Z przyjemnością usłyszałem odpowiedź od pana Soundersa, ale on również nie znał ostatecznej odpowiedzi.
utt73

Jeśli chodzi o „powrót do tego postu po tym, jak aktualizacja F5 działa przez pewien czas w dziale produkcyjnym ”, chociaż nie współpracuję już z tą konkretną aplikacją internetową, udało nam się osiągnąć zarówno średnie zdarzenie ładowania strony (), jak i czas do Interactive (TTI) poniżej 2 sekund, a to zmniejszenie wysiłku użytecznego było jedną małą jego częścią. Przyczyniło się to do zmniejszenia liczby wywołań ruchu HTTP, rozszerzenia buforowania przeglądarki, optymalizacji kodu i innych najlepszych praktyk dotyczących wydajności sieci.
utt73

Odpowiedzi:


3

Mówisz o korzyściach związanych z kosztami przepustowości, ale także porównujesz wydajność ładowania strony w przeglądarce. To dwie różne rzeczy.

Za każdym razem, gdy zgłaszasz żądanie, coś musi faktycznie kompresować (w twoim przypadku F5), a klient (lub technicznie proxy) musi obsługiwać dekompresję. Może to zwiększyć opóźnienie żądania, w zależności od tego, jak sprawny jest sprzęt na obu końcach.

„Minimalny rozmiar gzip” opiera się na czasie potrzebnym na kompresję / dekompresję tak niewielkiej ilości danych, które nie są pomocne z punktu widzenia przeglądarki internetowej. Jeśli mówisz wyłącznie o oszczędnościach przepustowości, to ustaw minimum na tak niskie, jak chcesz, ale rób to wiedząc, że być może nie zapewnisz użytkownikom końcowym żadnego wzrostu wydajności.

Korzystając z naszej strony potwierdzasz, że przeczytałeś(-aś) i rozumiesz nasze zasady używania plików cookie i zasady ochrony prywatności.
Licensed under cc by-sa 3.0 with attribution required.