Pracuję nad poprawieniem czasu wyświetlania szybkości strony, a jedną z metod jest gzipowanie zawartości z serwera WWW.
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.
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.
Odpowiedzi:
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.
źródło