Пороги сжатия HTTP: оптимальные конфигурации для веб-хостинга

Пороги сжатия HTTP определяют размер, на который ваш сервер сжимает контент, и таким образом напрямую контролируют TTFB, загрузку процессора и пропускную способность. В этом руководстве я покажу вам конкретные пороги, уровни и настройки заголовков для быстрой доставки, а также четкое разделение между динамическим и статическим сжатием. Компрессия.

Центральные пункты

Сначала я кратко изложу самые важные настройки, чтобы вы могли целенаправленно приступить к работе и избежать лишней траты циклов процессора. Я полагаюсь на четкие пороги, подходящие уровни и чистые заголовки, чтобы браузеры, прокси и CDN работали правильно. Я различаю динамические ответы и активы сборки и держу под строгим контролем сжатие за скачок. Я минимизирую TTFB с помощью умеренных уровней сжатия во время выполнения и получаю максимальную скорость из предварительно сжатых файлов. Я регулярно проверяю показатели и корректирую ограничения в зависимости от реальной нагрузки, сочетания файлов и задержек, чтобы ваша система работала заметно эффективнее. быстрее завещание.

• Порог 512-1024 B, стандартный 1024 B
• Хлебные палочки 3-4 динамические, 9-11 статические
• Gzip 5-6 в качестве запасного варианта
• MIME Только текстовые ресурсы
• Vary и ETag для кодировки

Что такое пороги сжатия HTTP?

Пороговое значение определяет размер, при превышении которого ответ сжимается, и предотвращает искусственное раздувание крошечных файлов за счет избыточных заголовков; именно в этом случае Безубыточность-соображения. При очень маленьких ответах кодирование содержимого может увеличить полезную нагрузку и одновременно потребовать затрат процессора. Поэтому я обычно устанавливаю нижний предел в 1024 байта или 512 байт для высокочастотных API с большим количеством маленьких ответов. Меньшие пороговые значения увеличивают степень сжатия, но они увеличивают TTFB и CPU, когда динамический контент сильно меняется. Большие пороги экономят вычислительное время, но рискуют потерять потенциал при работе с файлами HTML, CSS или JSON среднего размера и хорошего качества. Сокращение прибыль.

Brotli против Gzip: выбор и уровни

Brotli часто достигает на 15-21 процент лучших показателей, чем Gzip, для текстовых ресурсов, но требует больше процессорных затрат на запрос, что я учитываю при динамических ответах и умеренных уровнях. подушка. Для сжатия во время выполнения я использую Brotli уровня 3-4, для предварительно упакованных активов - уровня 9-11. Для устаревших клиентов или сильно изменяющегося контента я использую Gzip уровня 5-6. HTTP/2 и HTTP/3 выигрывают от хорошего сжатия, при условии, что буферы и точки смыва на сервере установлены правильно и поток не задерживается. Если вы хотите провести более глубокое сравнение, вы можете найти больше информации в моей статье Сравнение Gzip и Brotli дополнительные практические ценности и соображения, которые делают выбор в повседневной жизни облегчить.

Установите пороговые значения: Защитные ограждения и безубыточность

Я начинаю с 1024 байт в качестве базового порога, потому что тогда накладные расходы на заголовки явно компенсируются, а использование процессора остается разумным, особенно при работе с HTML и JSON, которые сильно различаются. сгущать оставьте. В сетях с очень низкой задержкой и большим количеством минимальных ответов API может быть полезно использовать 512 байт. Сжатие редко имеет смысл при объеме меньше 512 байт, поскольку затраты на администрирование часто превышают снижение полезной нагрузки. В случае сильно загруженных машин я временно повышаю порог, пока в резервуарах процессора снова не появятся буферы. Такая постепенная регулировка позволяет поддерживать низкий уровень TTFB и сохранять Стабильность всей системы.

Сжимайте типы MIME особым образом

Я сжимаю только текстовые MIME, такие как text/html, text/css, application/javascript, application/json и image/svg+xml, потому что они могут использоваться для избыточности. Выигрыши перетаскивание. Я оставляю бинарное содержимое, такое как image/*, application/pdf или font/woff2, нетронутым, так как эффект от этого небольшой или отрицательный. Для шрифтов я использую непосредственно WOFF2, поскольку он уже эффективно кодирует, и дальнейшее сжатие не имеет смысла. Я веду явные разрешительные списки и избегаю подстановочных знаков, чтобы бинарные файлы случайно не попали в кодировщик. Таким образом я сохраняю цепочку сжатия чистой и предотвращаю Коррупция из-за неправильной классификации.

Статика и динамика: чистое разделение

Я заранее упаковываю статические активы в процессе сборки или на границе CDN в форматы .br и .gz и позволяю серверу использовать эти варианты напрямую. доставить. Для динамических ответов я устанавливаю умеренные уровни и сохраняю буферы достаточно маленькими, чтобы первый блок байт проходил быстро. Важно сжимать только один хоп в цепочках прокси, чтобы не происходило двойного сжатия. Я могу отключить сжатие на Origin, если CDN уже сделал это и правильно разделил его через Vary. Такое разделение экономит процессор и обеспечивает постоянную Время реагирования даже под нагрузкой.

Управление заголовками и кэширование

Я всегда отправляю Vary: Accept-Encoding, чтобы кэши правильно различали варианты и не было промахов, замедляющих работу пользователей или фальсифицирующих активы; этот заголовок имеет вид решительный. Для статических файлов я задаю кодировку содержимого (br/gzip) плюс длину содержимого, в то время как динамические потоки часто работают с кодировкой передачи: chunked. ETags должны быть специфичными для кодировки, иначе кэш будет выдавать неверные версии. Я также устанавливаю длительные TTL кэша для предварительно сжатых активов и защищаю их с помощью управления кэшем: public, immutable, если хэши файлов находятся в имени. Я даю компактную отправную точку здесь: Настройка сжатия HTTP, который покажет вам самые важные строительные блоки в Последовательность показывает.

HTTP/2 и HTTP/3: промывка и буфер

При использовании HTTP/2 и HTTP/3 я обращаю внимание на ранние точки смыва, чтобы критические HTML и CSS не задерживали начало рендеринга. задержка. Слишком большие буферы могут замедлить мультиплексирование, поскольку один поток доминирует в планировании, а другой контент ждет. Я делаю первые блоки сжатия небольшими и отправляю быстро, затем увеличиваю размер блока для длинных файлов. Brotli показывает хорошие показатели при умеренных накладных расходах, если для динамических ответов используется уровень 3-4. При этом интерактивность остается высокой, а большие пакеты - эффективными. термоусадка.

Практика: Apache, Nginx, Caddy

Я начинаю с умеренных уровней и порога в 1024 байта, а затем систематически проверяю TTFB и CPU вместо того, чтобы вслепую устанавливать максимальные скорости. обеспечить соблюдение. Для Apache я активирую mod_deflate или mod_brotli и определяю только нужные типы MIME. В Nginx я устанавливаю gzip_min_length 1024 и Brotli в положение on, комбинируя это с brotli_static для предварительно сжатых файлов. Caddy предлагает простые переключатели с кодировками gzip zstd br; динамические пути с низкими уровнями я обрабатываю отдельно. По опыту, стоит взглянуть на Загрузка процессора и уровень сжатия, поскольку сочетание доли динамических ответов и количества ядер часто превышает предел. устанавливает.

Apache Пример (mod_deflate/mod_brotli):

AddOutputFilterByType DEFLATE text/html text/css application/javascript application/json image/svg+xml
 SetOutputFilter DEFLATE
 DeflateCompressionLevel 6
 DeflateBufferSize 64k


<IfModule mod_brotli.c
 AddOutputFilterByType BROTLI_COMPRESS text/html text/css application/javascript application/json image/svg+xml
 BrotliCompressionQuality 4
 BrotliWindowSize 22

Nginx Пример:

gzip включен;
gzip_min_length 1024;
gzip_types text/plain text/css application/json application/javascript image/svg+xml;
gzip_comp_level 5;

brotli включен;
brotli_comp_level 4;
brotli_static on;
brotli_types text/plain text/css application/json application/javascript image/svg+xml;

Мониторинг и устранение неисправностей

Я измеряю TTFB, загрузку процессора на одного рабочего и размер передачи по типам, чтобы понять, где сжатие помогает, а где оно необходимо. вредит. Если после активации TTFB увеличивается, я снижаю уровень или повышаю порог. Если возникают странные эффекты, я сначала проверяю, нет ли двойного сжатия, отсутствующих заголовков Vary или неправильно распознанных типов MIME. Я также обращаю внимание на политики CDN и WAF, поскольку второй хоп со сжатием смещает нагрузку и часто ухудшает время до первого байта. Для первоначальной проверки достаточно таких инструментов, как WebPageTest и Browser-DevTools. Аудит полностью.

Точки измерения и рекомендуемые значения

Я придерживаюсь нескольких четких параметров, чтобы конфигурация оставалась управляемой и при этом достигала высокого уровня качества. Эффект показывает. В следующей таблице приведены полезные пороговые значения, уровни и инструкции по кэшированию. Она охватывает типичные веб-стеки с HTML, CSS, JS, JSON, SVG и шрифтами. Настройте порог в зависимости от нагрузки, загрузки процессора и доли динамических ответов. Начните с консервативных значений, измерьте и итеративно перемещайте ползунки с небольшим шагом. Шаги.

Ресурс	Порог (байт)	Динамический (уровень)	Статика (уровень)	Подсказка для кэша
HTML	1024	Бр 3–4 / Гз 5–6	Br 9-11 (предварительно сжатые)	Длинный TTL для имен хэшей
CSS/JS	1024	Редкая динамика	Br 9-11 (предварительно сжатые)	неизменяемые, варианты на хэш
JSON (API)	512-1024	Бр 3–4 / Гз 5–6	необычно	Сохранять согласованность заголовков
SVG	1024	Редкая динамика	Бр 9–11	Запросы на испытательный полигон
Шрифты (WOFF2)	нет	нет	нет	Не сжимайте дальше
Изображения (PNG/JPEG/WEBP)	нет	нет	нет	Отдельная оптимизация
PDF	нет	нет	нет	Избегайте кодирования

Zstd в контексте: когда это имеет смысл, когда нет

Я оцениваю Zstd независимо, потому что он обладает превосходными Пропускная способность с хорошим сжатием. Однако в браузерной среде поддержка неоднородна, поэтому я обычно не использую Zstd в качестве основной кодировки для конечных пользователей. Между внутренними сервисами или на магистральном маршруте CDN Zstd может быть очень полезен для сохранения эффективности трафика Origin CDN. На границе я придерживаюсь Brotli (для текста) и Gzip в качестве запасного варианта до тех пор, пока широко поддерживаемая клиентская база не обеспечит корректное согласование вариантов. В Caddy я оставляю Zstd опционально активным, но приоритет отдаю Переговоры Brotli перед Gzip, чтобы сбалансировать совместимость и производительность.

Запросы, загрузки и предварительно сжатые файлы

Большие загружаемые файлы (например, PDF-файлы, CSV) я проверяю отдельно. Для бинарных данных я обычно отключаю кодировку содержимого и передаю идентификационные данные (личность), чтобы запросы на диапазон работали правильно, а возобновление загрузки оставалось стабильным. Для статических текстовых файлов с вариантами .br/.gz я слежу за тем, чтобы сервер выбирал правильный вариант в зависимости от запроса клиента и чтобы длина содержимого, кодировка содержимого и ETag были согласованы. Для частичных запросов к сжатым вариантам диапазоны байт для сжатый длина - если стек не справляется с этим надежно, я передаю несжатую версию для запросов диапазона. Это смягчает крайние случаи и предотвращает некорректные перезапуски.

Безопасность: сжатие и утечка данных

Я принимаю во внимание побочные каналы, связанные с компрессией, такие как BREACH. Если ответы отражают секретно-зависимое содержимое (токены, идентификаторы сессий) рядом с входными данными, которые могут контролироваться злоумышленником, я выборочно отключаю сжатие или развязываю секреты (набивка, разделение на отдельные несжатые поля). Для путей входа и оплаты имеет смысл отключать сжатие с помощью заголовков или правил. Куки с установленными заголовками cookie не критичны, важно то, что Ответить-payload. Поэтому у меня есть готовые фильтры, нацеленные на путь, MIME или определенные шаблоны, чтобы легко применять эвристику.

Цепочки CDN и прокси: одно сжатие на один переход

Я четко определяю, в какой момент происходит сжатие: Либо на Край (CDN) или на Origin, но не в обоих случаях. Если CDN сжимает, я опускаю кодировку содержимого на Origin и отправляю Vary: Accept-Encoding, чтобы Edge собрал правильные варианты. Если Origin должен доставить предварительно сжатые активы (.br/.gz), я настраиваю Edge на отправку этих файлов в CDN. Прозрачный и не преобразует его снова. Если я хочу строго предотвратить преобразования промежуточными прокси (например, для соответствия требованиям), я устанавливаю Cache-Control: no-transform - тогда я планирую сжатие именно в месте происхождения. Для отладки я отмечаю, в каком месте Компрессия и хранить метрики отдельно для каждого хопа.

Потоковая передача, SSE, gRPC и WebSockets

Для событий, отправленных сервером (SSE), и подобных потоков я избегаю высоких уровней и большой буфера; в противном случае задержка заметно возрастает. Я использую небольшие блоки, частые промывки и более деактивированное сжатие, если интерактивность имеет приоритет. gRPC использует собственное сжатие сообщений и работает через HTTP/2 - здесь я избегаю дополнительного кодирования HTTP-контента, чтобы избежать дублирования. То же самое относится и к WebSockets: дефлейт каждого сообщения может быть полезен, но я включаю его только для действительно текстовых каналов и наблюдаю за тем. CPU-Эффект точный.

Сервер приложений: Установите специальные настройки уровня приложений

Я предпочитаю управлять пороговыми значениями в краевом/обратном прокси, но когда кадры сжимаются, я устанавливаю согласованные значения, чтобы ничего не работало друг против друга.

• Node.js/ExpressЯ установил порог в 1024 байта и умеренные уровни. Статический обработчик обслуживает предварительно сжатые статические активы напрямую, я сжимаю только динамические маршруты для текстовых MIME.
• Зайти на сайтЯ выбираю четкий разрешенный список MIME для каждого обработчика и пропускаю сжатие при размере менее 1 КБ. Для длинных потоков я поддерживаю небольшой объем записи, чтобы не перегружать первый paint. задержка.
• Java/TomcatЯ использую compressionMinSize 1024 и веду список MIME в явном виде; бинарные типы не учитываются.

Tomcat Пример (коннектор server.xml):

<Connector port="8080" protocol="HTTP/1.1"
    compression="on"
    compressionMinSize="1024"
    noCompressionUserAgents=""
    compressableMimeType="text/html,text/css,application/javascript,application/json,image/svg+xml"
    URIEncoding="UTF-8" />

Важно: Если восходящий прокси (Nginx, Caddy) уже сжимает, я отключаю сжатие на уровне приложений, чтобы Дублирование работы и пусть ответственность несет только один слой.

Адаптивные пороги и управление нагрузкой

Я мыслю категориями политики, а не жесткими ценностями. При высокой нагрузке на процессор я поднимаю Порог временно (например, с 1024 до 2048 байт) или снижаю уровень Brotli (например, с 4 до 2) для динамических ответов. Если нагрузка падает, я снова увеличиваю значения. Это можно контролировать с помощью флага функции, переменных Env или простой перезагрузки. На узлах с небольшим количеством CPU я оставляю сжатие для наиболее важных MIME (HTML/JSON), в то время как CSS/JS почти полностью предварительно сжимаются из хранилища/CDN. Это Расстановка приоритетов сохраняет стабильность TTFB, а не переходит в пик.

Тестовый учебник: быстрая проверка

Я проверяю эффект с помощью нескольких воспроизводимых действий:

• Переговоры: curl -I -H „Accept-Encoding: br“ https://example.com - проверка Content-Encoding, Vary и Content-Length.
• Обратная связь: curl -I -H „Accept-Encoding: gzip“ - ожидается gzip? ETag отличается от Brotli?
• Без сжатияcurl -I -H „Accept-Encoding: identity“ - Сравните разницу в размере и TTFB.
• диапазон: curl -I -H „Range: bytes=0-1023“ - правильно ли сервер принимает поддиапазоны, и соответствует ли Content-Range?
• DevToolsСравните размер „По сети“ и „Размер ресурса“, чтобы определить реальный Сбережения посмотреть.

Краткое резюме

Для начала установите порог в 1024 байта, проверьте TTFB и CPU и точно настройте параметры с помощью небольших Корректировки после. Используйте Brotli 3-4 для динамического контента и 9-11 для предварительно сжатых активов, а Gzip 5-6 оставьте в качестве запасного варианта. Сжимайте только текстовые MIME-файлы и доставляйте предварительно сжатые файлы напрямую, чтобы обеспечить легкость и долговечность сборки. Обратите внимание на Vary: Accept-Encoding, Content-Encoding и ETags, специфичные для кодировки, чтобы кэши работали корректно. Правильно настроенные пороги сжатия HTTP позволяют заметно ускорить доставку, не нагружая машину лишней вычислительной работой. блок.