Я работаю над улучшением времени отображения страницы, и один из методов - это распаковка содержимого с веб-сервера.
Обратите внимание, что gzipping полезен только для больших ресурсов. Из-за накладных расходов и задержек сжатия и распаковки вы должны только сжать файлы выше определенного порога размера; мы рекомендуем минимальный диапазон между 150 и 1000 байтов. Сжатие файлов размером менее 150 байт может фактически сделать их больше.
Мы обслуживаем наш контент через Akamai , используя их сеть для прокси и CDN. Что они сказали мне:
В ответ на ваш вопрос относительно минимального размера Akamai сжимает запрошенный объект при отправке его конечному пользователю: минимальный размер составляет 860 байт.
Мой ответ:
Какова причина (ы), почему минимальный размер Akamai составляет 860 байт? И почему, например, это не относится к файлам, которые Akamai обслуживает для Facebook? ( см. ниже ) Google рекомендует более агрессивно использовать gzip. И это представляется уместным на нашем сайте, где наиболее частыми обращениями, безусловно, являются вызовы AJAX, длина которых составляет <860 байт.
Ответ Акамаи:
Причины, по которым минимальный размер сжатия составляет 860 байт, двоякие: (1) издержки на сжатие объекта размером менее 860 байт превышают выигрыш в производительности. (2) В любом случае объекты размером до 860 байт могут передаваться через один пакет, поэтому нет веских причин для их сжатия.
Так что я здесь для проверки некоторых фактов. Является ли ограничение в 860 байт из-за размера пакета концом этого рассуждения? Зачем сайтам с высоким трафиком доводить это до предела в 150 байт ... просто для экономии затрат на пропускную способность (поскольку CDN основывают свои сборы на пропускной способности, выгруженной из источника), или при этом наблюдается увеличение производительности?
7/9/12 Обновление: я спросил Стива Соудерса , есть ли прирост производительности в ответах gzip, которые уже меньше, чем пакет, и каков рекомендуемый минимальный размер объекта для повышения производительности gzip, и это его ответ:
Спасибо за твое электронное письмо. Размер где-то между 1-5К. У Apache есть значение по умолчанию, но я забываю, что это такое - это было бы хорошим руководством.
Мы выполняем сжатие на устройстве F5, поэтому собираемся снизить его до ~ 350 байт, поскольку между ним и 1К есть приличное количество вызовов AJAX. Вызовы AJAX размером менее 350 байт на нашем веб-сайте занимают около 70 байт ... меньше, чем рекомендации Google ... поэтому кажется, что на самом деле нужно вернуться к: узнайте свой веб-сайт и настройте его в соответствии с вашим кодом .
Я вернусь к этому посту после того, как обновление F5 какое-то время будет запущено в Production. Я думаю, что выигрыш в производительности будет небольшим, но мы немного снизим наши расходы на Akamai, поскольку они служат меньше.
Ответы:
Вы говорите о преимуществах затрат на пропускную способность, а также сравниваете производительность загрузки страницы в браузере. Это две разные вещи.
Каждый раз, когда вы отправляете запрос, что-то должно фактически выполнять сжатие (в вашем случае, F5), а клиент (или технически прокси) должен обрабатывать декомпрессию. Это может добавить больше задержки к вашему запросу, в зависимости от того, насколько способно оборудование на обоих концах.
«Минимальный размер для gzip» основан на времени, необходимом для сжатия / распаковки такого небольшого объема данных, который не является полезным с точки зрения веб-браузера. Если вы просто говорите об экономии пропускной способности, тогда установите минимальный уровень, который вы хотели бы, но делайте это, зная, что вы, возможно, не дадите своим конечным пользователям никакого прироста производительности.
источник