Возможно, браузер ближе к ограничению по сравнению с сетевым ограничением, верно? У нас очень тяжелое приложение ajax, поэтому, с точки зрения броузера (а не сервера), возможно, лучше не использовать сжатие.Стоит ли с точки зрения производительности браузера сжимать ответы HTTP?
Что вы думаете
Все зависит от браузера и устройства. На обычном ноутбуке или настольном компьютере на дома Я ожидаю, что сеть будет ограничивающим фактором. В хорошо связанном офисе может быть быть ЦП, если есть какое-то настоящее узкое место.
Тогда вы получили нетбуки, потенциально через 3G, а затем мобильные телефоны ...
Лично я бы пойти на сжатие - Я думаю, что более вероятно, будет победа, чем горлышко.
Ну, в общих циклов центрального процессора довольно дешево, по сравнению с скорость сети. И декомпрессия не займет слишком много циклов процессора, если вы не пытаетесь распаковать MB-данные.
Но я думаю, в конце концов, это зависит от людей, которые будут использовать веб-сайт. Если вы уверены, что у них действительно быстрые интернет-соединения, возможно, вам не придется использовать сжатие. С другой стороны, вы всегда можете быть уверены, что у них довольно приличные процессоры.
Мои клиенты, как правило, являются небольшими офисами, использующими подключение к Интернету, и пропускная способность является важным фактором. Наше приложение обслуживает довольно большие страницы, поэтому сжатие имеет огромное значение.
В зависимости от ширины полосы, количества пользователей, размера страниц.
Сжатие и декомпрессия довольно оптимизированы, и вы можете контролировать уровень сжатия.
Самая распространенная причина для не с использованием сжатия - это загрузка ЦП на сервер (для динамических страниц). Обычно это гораздо большая проблема, поэтому я полагаю, что загрузка процессора на среднем настольном ПК незначительна (если вы не хотите использовать bz2).
Если сжатие накладывает большую нагрузку на сервер и/или степень сжатия является плохим (например, страница 20K сжимается до 19K), я бы подумал о ее отключении. Если у ваших пользователей очень быстрое соединение с низкой задержкой с сервером, браузер почти наверняка будет связан с сетью.
Я бы также рассмотрел методы кеширования HTTP - они довольно эффективны, тем более, с AJAX. Это экономит вашу пропускную способность, а циклы процессоров как на стороне сервера, так и на стороне клиента - нет необходимости повторно запрашивать, повторно генерировать, повторно передавать, повторно анализировать и повторно сохранять то, что у вас уже есть.
См. Yahoo's best practices for making web pages fast. Особенно Gzip Components вывод:
Gzipping как многие типы файлов, как это возможно простой способ уменьшить вес страницы и ускорить работу пользователей.
Декомпрессия является очень быстрым процессом по сравнению с сжатием. Даже слабый процессор (например, один в мобильном устройстве) может эффективно декомпрессировать GZIP (ZIP, Deflate и т. Д.) Практически в любое время. Сжатие данных намного сложнее.Используя сжатие, вы увеличиваете нагрузку на сервер ... и уровень увеличения не всегда ничтожно мал. Обычно это компромисс между использованием пропускной способности и использованием ЦП на стороне сервера. Для клиента он обычно не играет большой роли, если доступ к Интернету очень медленный (например, подключение к мобильному телефону). Однако только текст/html/css/js может быть эффективно сжат, большинство других данных, которые вы найдете на веб-страницах (например, тонны изображений, например), вообще не могут быть сжаты; поэтому, если мы говорим о страницах, где есть данные веб-страницы 8 кб, а сама страница загружает данные изображения более 200 кб, забудьте о сжатии, она практически не купит вас.
Любой скрипт или контент, загруженные браузером, будут нуждаться только в распаковке, поскольку он идет по проводу, и с этого момента он уже находится в распакованном виде (единственное исключение - если вы делаете что-то странное с заголовками HTTP, например, Cache -контроль: нет-магазин).
Он будет распаковываться быстрее, чем он может загрузить - узким местом вряд ли будет декомпрессия.
Даже слегка устаревший вялый компьютер может, вероятно, распаковать GZIP со скоростью более 50 МБ в секунду, для чего потребуется насыщение сети по меньшей мере 410 Мбит/с (это 410 000 кбит/с) для насыщения.
Меня больше беспокоят багги-браузеры, такие как IE6 (pre-SP2), которые запрашивают сжатый контент, но не могут справиться с ним в некоторых ситуациях, например, при сжатии CSS.
Это может быть не очень актуально для вопроса, но поскольку вы упомянули «очень тяжелое приложение ajax», обратите внимание, что IE плохо работает, когда дело доходит до JavaScript. Загрузка домашней страницы для StackOverflow.com на IE 7 зависает моего браузера в течение нескольких секунд. –