Стоил ли сжимать http ответ

миллиард с половиной экзабайт всратого JS/CSS, которые все смузисайты с собой таскают - сжимаются еще на стороне CDN. нормальные сайты для нормальных пацанов - читаются в lynx, и не нуждаются в требующих сжатия смузихлёбских костылях

/thread

Тебя смузи в детстве покусал?

Посмотрел ответы серверов со своей прошлой работы. Ответы не сжаты, хотя размеры главных страниц - 1 и 1.5 Мб, и это одни из самых высоконагруженных страниц в рунете.

Почему - не знаю, gzip сжимает в 5 раз.

Возможно, есть какие-то технические причины. Допустим, не все клиенты поддерживают, хотя в это поверить сложно. Спросить больше некого.

Стоил ли сжимать http ответ gzip nginx’ом?

It depends.

Картинки и так сжатые

Не всегда.

а json?

Как настроишь.

Посмотрел ютуб не сжимает ничего.

А зачем?

Кто вообще сжимает?

Я.

сжимать что-то - это разменивать ооочень дорогую полосу пропускания на не очень дорогой ресурс цпу.

ergo - если ваш гигабитный (не меньше же?) аплинк уже налит процентов на 80 - сжимать. в противном случае - не сжимать.

ну и да, мудрость веков гласит «хуже преждевременной оптимизации может быть только преждевременная эякуляция».

Если экономия на исходящем трафике больше, чем затраты на процессорное время для сжатия, то стоит. Непонятно, о чём тут рассуждать, вопрос сравнения двух денежных сумм.

Если экономия на исходящем трафике больше, чем затраты на процессорное время для сжатия, то стоит. Непонятно, о чём тут рассуждать, вопрос сравнения двух денежных сумм.

Всё не так просто, мне кажется. Это также вопрос того, насколько быстро страница отобразится у пользователя. А это влияет на SEO и субъективное ощущение удовольствия у пользователя, что, в свою очередь, также значительно влияет на выручку.

да нет, у меня там просто один ответик есть JSON, который около 60KB весит. Как бы о юзере думаю, но 60 кило вроде не много

Это также вопрос того, насколько быстро страница отобразится у пользователя.

Зависит от того как быстро загрузятся JS ассеты, которые всё равно грузят с CDN.

с собой таскают

А где, бл, его ещё таскать, по отдельности что ль?

всратого JS/CSS

Или газеты читай в туалете деревянном, дед

firkax, ты залогиниться забыл

Это также вопрос того, насколько быстро страница отобразится у пользователя.

Хорошее замечание, но, мне кажется, тут уже невозможно угадать. Я бы предположил, что в большинстве случаев сжатие для клиента лучше, поскольку ресурсов на декомпрессию надо мало (думаю, куда меньше, чем на парсинг CSS и выполнение JS), а вот медленный интернет — обычное дело. Я вот сейчас сижу в офисе, и если выключить WiFi, то можно временами наблюдать переключение на 2G и даже полную потерю сигнала иногда. Конечно, для меня предпочтительнее хорошее сжатие страниц.

Как бы о юзере думаю, но 60 кило вроде не много

Возвращаясь к вопросу о преждевременной оптимизации. А юзеру надо батарейку тратить на разжатие? а те полторы миллисекунды, которые юрер выиграет - сделают его счастливее? а можно ли уменьшить json, например просто переименовав в нем поля? А убрав переносы строки и прочее?

Посмотрел ютуб не сжимает ничего.

У тебя неправильный Ютуб

Content-Encoding: br

Кто вообще сжимает?

Все.

Стоил

Стоил

Тему можно отметить как решённую?

Окстись, никакой «преждевременной эякуляции» не существует, ибо цель соития - оплодотворение, для которого и пол минуты хватает.

Настроить сжатие только нужных типов MIME и всё.

Если есть статика, то можно один раз сжать в gz и br и положить рядом с исходными.

Смотри в дока параметры gzip_types, gzip_proxied, gzip_comp_level, gzip_static, brotli, brotli_types, brotli_comp_level, brotli_static.

За поддержку предварительно сжатых файлов отвечают параметры brotli_static и gzip_static.

Ну и не забудь включить соответствующие модули.

https://nginx.org/en/docs/http/ngx_http_gzip_module.html

Доку по http_brotli_filter_module не нашёл, но в репах Debian модуль такой есть.

Вроде как делают поддержку zstd, но тему эту давно не копал.

Посмотрел ютуб не сжимает ничего

Это как вы определили? Там же черным по белому написано в заголовках content-encoding br.

Вообще очень удивлюсь, если хоть мало-мальски приличная контора не будет пользоваться технологиями экономии моего трафика. Давно считал, что жрать пользовательский трафик без стыда - стыд и позор для контор.

В век мобильного инета, сжимать стоит.

Стоил ли сжимать http ответ gzip nginx’ом?

Сжатие может 1) сэкономить исходящий трафик и 2) ускорить передачу данных. Второе требуется не всегда и не всем, нужно понимать суть задачи и экспериментировать. Для экономии трафика достаточно убедиться, что у сервера есть запас по CPU, а коэффициенты сжатия по всем сжимаемым локейшенам адеквантые.

Картинки и так сжатые

Разумеется, сжимать стоит только всякую дичь вроде bmp и tiff

а json?

От размеров зависит: огромные портянки точно стоит сжимать, а для коротких ответов gzip малоэффективен. Но если сжатие для мелочи всё-таки требуется, лучше менять формат сериализации на что-то со схемой, вроде protobuf, flatbuffers и т.п.

Посмотрел ютуб не сжимает ничего

Плохо смотрел, всё он сжимает. Хинт: если пользуешься curl, не забывай про --compressed

Посмотрел ютуб не сжимает ничего.

С чего вдруг? В http/2 бинарные данные и сжатые заголовки.

Стоил ли сжимать http ответ gzip nginx’ом?

Да, стоит.

Картинки и так сжатые, а json?

JSON обязательно нужно сжимать

Посмотрел ютуб не сжимает ничего.

Плохо смотрел. Сжимает.

Кто вообще сжимает?

Все разумные люди сжимают. Это даёт плюсы и не даёт минусов.

Посмотрел ютуб не сжимает ничего. Кто вообще сжимает?

Зачем сжимать уже сжатый кодеками трафик?

Он про JSON ответы (API) от Youtube.

Content-Encoding: br

Где?

$: curl -LIs https://youtube.com | grep -i content
content-type: application/binary
x-content-type-options: nosniff
content-length: 0
content-security-policy: require-trusted-types-for 'script';report-uri /cspreport
content-type: text/html; charset=utf-8
x-content-type-options: nosniff
content-length: 0
content-security-policy: require-trusted-types-for 'script'

https://0x0.st/8n01.png

Я вот сейчас сижу в офисе, и если выключить WiFi, то можно временами наблюдать переключение на 2G и даже полную потерю сигнала иногда.
2G

Жуть, всяческие аналоговые пиликающие мопеды и то побыстрее, были у нас объекты которые на 2G робили, работа через ssh уже пошаговуха.

Какой-то странный вопрос, абстрактный http ответ сжимать не надо. Картинки сжимать гзипом не надо, надо другими хорошими кодеками и оптимизаторами. Скрипты очень даже неплохо бы сжать, как и статический html/json/xml. Динамический контент обычно лучше не сжимать чтобы сэкономить процессор сервера.

огромные портянки точно стоит сжимать, а для коротких ответов gzip малоэффективен

Дык в том же nginx можно настроить минимальный размер ответа, с которого начинается сжатие.

В заголовках запроса клиент пишет какие форматы сжатия умеет, странно это не использовать.

Да я потом уже понял, что проверял curl’ом, и забыл явно Accept-Encoding указать. Как только указал, сразу оказалось, что оно сжимается (но почему-то только gzip, хотя я перечислил и более новые методы сжатия).

Попробуй еще useragent от браузера указать.

curl -v --compressed https://www.youtube.com -A "Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:141.0) Gecko/20100101 Firefox/141.0" > /dev/null
...
< content-encoding: br
...

На модемном соединении очень большой смысл имело. Сейчас уже нет конечно.

да нет, у меня там просто один ответик есть JSON, который около 60KB весит.

Тогда займись лучше чем-нибудь полезным. А это — можно сжимать, можно не сжимать, как-то пофиг практически. Ты чем-то не тем заморочился, учитывая специфику.

P.S. Но я бы включил сжатие, да. На таком нагрузка на серверный проц не будет заметна. Впрочем, и юзеры тоже вряд ли заметят изменение в любую сторону.

На модемном соединении очень большой смысл имело. Сейчас уже нет конечно.

Это точно неверно. Из-за таких «широких жестов», например, когда приезжаешь в ЮВА, где все каналы связи раз в 10 уже, чем дома, всё начинает просто нереально медленно и криво работать.

Я когда-то работал удалённо в разных частях мира, типа Шри-Ланки, и это была пытка. Банальный Слак, который не более, чем IRC, начинал жутко глючить, постоянно терять полученные и отправленные сообщения, дичайшим образом перепутывать их порядок, и т.д.

Да и без ЮВА. Все эти «а забьём на оптимизацию по размеру» приводит к тому, что какой-нибудь банальный образ докера для nginx внутри компании начинает весить несколько Гб, и создаёт заметную ощутимую задержку при раскатке, потому что даже на сверхбыстрых каналах, когда вся компания начинает гонять туда-сюда многогиговые образы, всё начинает ощутимо притормаживать. Не говоря уж о том, что надо хранить несколько версий каждого образа в истории, и оно всё моментально забивает хранилища любого размера.

Это уже к сжатию страниц не относится, но также является следствием мышления «а зачем экономить - каналы же широкие, гигабайт туда, гигабайт сюда - никакой разницы!»

Тем не менее надо смотреть будет ли выигрыш. В одном случае:

-просто передача-

в другом

сжатие на сервере + передача + разжатие на клиенте.

Многое зависит от нагрузки на сервер. Может оказаться, что сервер не потянет нагрузку со сжатием.

Наверное, Accept-Encoding не хватало.

$ curl -vLs -H 'Accept-Encoding: gzip, deflate, br' https://www.youtube.com 2>&1 | grep -i encoding 
* [HTTP/2] [1] [accept-encoding: gzip, deflate, br]
> Accept-Encoding: gzip, deflate, br
< content-encoding: gzip
$ 

Многое зависит от нагрузки на сервер. Может оказаться, что сервер не потянет нагрузку со сжатием.

Многое зависит от кошелька: а не придется ли вам платить за трафик, копейка рубль бережёт. Программистам нужно специально выдавать компы и связь ниже среднего, чтоб мозг включали и писали бы качественные программы, а не комбайны всего в контейнерах.

Вам когда-нибудь приходилось ли пользоваться интернетом из таких мест, где для обычного сотового звонка надо на сосну залазить?

Динамический контент обычно лучше не сжимать чтобы сэкономить процессор сервера.

Если ты не /dev/null отдаёшь, скорей всего процессорные ресурсы, потраченные на генерацию самого ответа будут на несколько порядков выше, чем процессорные ресурсы, потраченные на сжатие этого ответа.

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

Тут я с вами полностью согласен. Очень много проблем из-за того, что программы не тестируются на слабом железе.

А про сосны… До 21-го года у меня не было даже сотового. А смартфон с Интернетом я купил только в 29. Поэтому по-моему мнению даже Интернет с сосны - это очень большая роскошь.

До 21-го года у меня не было даже сотового. А смартфон с Интернетом я купил только в 29.

Как там в будущем? У нас в 25-м хреново…

Я могу только вас уверить, что за 2000 лет произойдёт очень много событий, но лучше не станет. Но вы скорее всего и сами знаете, раз имеете неведомую нам технологию, которая позволяет вам сёрфить Интернет 2025-го года.

:)

Ну вообще сокращать номер года — вполне общепринятая практика, в то время как 21-го читается исключительно как «двадцать первого» ;)

Я и правда только со второго прочтения догадался, что речь про возраст (который нам ничего не говорит, ведь мы не знаем точно, сколько тебе сейчас, может ты вчера смартфоном обзавёлся, а может 10+ лет назад…).

А так, у меня и в 2025-м смартфона с Интернетом нет. Кнопочный телефон, правда, имеется. Обзавёлся где-то в начале нулевых (не конкретно этим, естественно, но не менее кнопочным).

Замерь время отклика и выбеги что быстрее.

Вы наверняка знаете этот эффект, что когда задумываешься об одном конкретном смысле, который имеешь в виду, о том, что вышла омонимичная фраза совершенно другому смыслу не задумываешься. Так что в этом случае двусмысленность была не нарочной. Я когда писал, думал, что если я после числа добавляю «лет/года», то однозначно ставлю читателя в известность, что речь идёт о возрасте.

Таким же макаром для меня однажды стало открытием, что turkey, которая индейка и Turkey, которая Турция - два совершенно омонимичных слова.

Или например я однажды осознал, что английский Бог God транслителируется в русский Год.

Так-то в этом посте я хотел подчеркнуть, что я приобрёл телефон/смартфон в возрасте уже достаточно сознательном и хорошо помню времена без Интернета. Но если вас интересуют календарные года, то я приобрёл смартфон 10 лет назад.

Вы наверняка знаете этот эффект, что когда задумываешься об одном конкретном смысле

Да, бывает такое.

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

Тут дело скорее именно в этом «-го». Приращения используются только с порядковыми числительными, «21-го» читается как «двадцать первого» и никак иначе. «До 21 года» читалось бы как «до двадцати отдного года», что и имелось в виду. Ну по крайней мере в литературном русском языке так.

Если что, я не пытаюсь включить граммар-наци. К «ошибкам» я давно перестал придираться, если они не меняют смысла (ну или хотя бы не являются очень смешными :). Просто объясняю, почему не сразу очевидно, что имелось в виду, ничего более.

Но если вас интересуют календарные года, то я приобрёл смартфон 10 лет назад.

Понятно.

А так да, года тоже имеют значения. Я просто хорошо помню GPRS — я как раз в те времена из интереса тыкал мобильный интернет, а когда всякие там 4G появились, уже наоборот полностью перестал им пользоваться — телефон только для звонков и СМС, а интернет только на компе. Это я к тому, что вот с теми скоростями это сжатие прям сильно помогло бы. Не зря тогда была специальная мобильная опера, которая работала через специальный прокси, который пережимает всё по пути — для экономии трафика.

По всем пунктам - палец вверх.

В его детстве не было никакого смузи.

Хс, я смотрел заголовки css js не было там br...

Да, на медленном канале половина интернета просто перестаёт работать. Советую попробовать GPRS для любителей БДСМ-интернет-сёрфинга.