Вы можете видеть, что JetNEXUS имеет хороший пост, озаглавленный «Что означает ускорение приложения?» Помимо полного игнорирования ускорения и оптимизации протокола (особенно полезно для повышения производительности этих чатных приложений на основе TCP и HTTP) автор делает вывод, что должен иметь были очевидны, но не являются - сжатие на самом деле хорошо для тяжелых сайтов изображений.

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

Почему сжатие изображения хорошее?

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

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

Понимание качества сжатия изображения

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

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