Який рекомендований мінімальний розмір об'єкта для переваг продуктивності gzip?


31

Я працюю над покращенням швидкості відображення швидкості сторінки, і один із методів - це збирати вміст із веб-сервера.

Google рекомендує :

Зауважте, що gzipping корисний лише для більших ресурсів. Через надмірні затримки та затримку стиснення та декомпресії вам слід лише gzip-файли, що перевищують певний поріг розміру; ми рекомендуємо мінімальний діапазон між 150 і 1000 байтами. Файли зі збиванням файлів нижче 150 байт можуть насправді збільшити їх.

Ми обслуговуємо наш вміст через Akamai , використовуючи їх мережу для проксі і CDN. Що вони мені сказали:

Здійснюючи запитання щодо мінімального розміру, Akamai стисне запитуваний об’єкт при відправці його кінцевому користувачеві: Мінімальний розмір - 860 байт.

Моя відповідь:

Що є причиною того, чому мінімальний розмір Akamai становить 860 байт? І чому, наприклад, це не так для файлів, які Akamai служать для Facebook? ( див. нижче ) Google рекомендує більш агресивно використовувати gzip. І це здається доречним на нашому веб-сайті, де на сьогодні найчастіші хіти - це дзвінки AJAX, які становлять <860 байт.Скріншот заголовків Facebook, що спростовують твердження Акамая

Відповідь Акамая:

Причина: 860 байт - мінімальний розмір для стиснення вдвічі: (1) Накладні витрати на стиснення об'єкта під 860 байтів переважають над збільшенням продуктивності. (2) Об'єкти під 860 байтів можуть передаватися через один пакет у будь-якому випадку, тому немає вагомих причин стискати їх.

Тому я тут для перевірки фактів. Чи кінцем цього міркування є межа 860 байт через розмір пакета? Чому сайти з високим трафіком підштовхують це до обмеження в 150 байт ... просто для економії витрат на пропускну здатність (оскільки CDN базує свої витрати на пропускній здатності, завантаженій з походження), або є підвищення продуктивності при цьому?


7/9/12 Оновлення: Я запитав Стіва Суудерса, чи є збільшення продуктивності у відповідях на gzipping, які вже менші, ніж пакет, і який рекомендований мінімальний розмір об'єкта для переваг продуктивності gzip, і це його відповідь:

Дякую за ваш електронний лист. Розмір десь від 1 до 5 КК. У Apache за замовчуванням, але я забуваю, що це таке - це було б гарним посібником.

Ми робимо стиснення на пристрої F5, тому ми знизимо його до ~ 350 байт, оскільки між цим і 1К є пристойна кількість дзвінків AJAX. Виклики AJAX, які на нашому веб-сайті мають менше 350 байт, знижуються приблизно на 70 байт ... менше, ніж рекомендації Google ... тому, здається, справді відмовляєтесь: знайте свій веб-сайт та налаштовуйте, виходячи з вашого коду .

Я повернусь до цієї посади після того, як оновлення F5 буде запущено у виробництві на деякий час. Я думаю, що користь від продуктивності буде невеликою, але ми знизимо наші витрати на Akamai, оскільки вони служать менше.


@Steve, щодо квітневої редакції я додав привітання, щоб уточнити почуття, оскільки експерт у цій галузі не відповів на жодне запитання. Я був радий почути відповідь від містера Саунджера, але і він не знав остаточної відповіді.
utt73

Що стосується "повернення до цієї публікації після запуску оновлення F5 у виробництві на деякий час ", хоча я вже не працюю з цим конкретним веб-додатком, ми досягли успіху в нашій цілі отримати як середнє подія завантаження сторінки (), так і час на Інтерактивний (TTI) нижче 2 секунд, і це зменшення зусиль корисного навантаження було однією невеликою частиною цього. Сприяло зменшенню кількості дзвінків на трафік http, розширенню кешування браузера, оптимізації коду та інших найкращих практичних веб-практик.
utt73

Відповіді:


3

Ви говорите про переваги ваших витрат на пропускну здатність, але потім порівнюєте продуктивність завантаження сторінки в браузері. Це дві різні речі.

Щоразу, коли ви gzip запит, щось має насправді робити стиснення (у вашому випадку F5), і клієнт (або технічно проксі) повинен обробляти декомпресію. Це може додати більше затримок у вашому запиті, залежно від того, наскільки здатне обладнання на обох кінцях.

"Мінімальний розмір для gzip" базується на часі, необхідному для стиснення / декомпресії, що невелика кількість даних не є корисною з точки зору роботи веб-браузера. Якщо ви суто говорите про економію пропускної здатності, тоді вперед і встановіть свій мінімум на мінімальному рівні, але хочете, знаючи, що ви не можете давати кінцевим користувачам жодних прибутків.

Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.