I've been doing a lot of reading about compressing your servers output stream.

Before gzip compression, the homepage was about 321k! This means that it would take about 89 seconds for a normal 56k user to download the page.

After gzip compression, the page is 79k! Now it takes the same 56k user 22 seconds to download the page.

If your server can support a little extra load (to compress the output stream), then I highly reccomend using a output stream compression engine!

Here is a list of .NET/ISAPI (for IIS) modules that I'm aware of:

.NET Modules
ASPAccelerator.NET
http://www.intesoft.net/aspaccelerator/
Blowery HttpCompression Module

ISAPI Filters
XCompress
http://www.xcompress.com/
IIS Accelerator

SqueezePlay
http://www.innermedia.com/
jetNEXUS for IIS

PipeBoost

TurboIIS Pro

Maybe someone can post some good ones for Apache..

Dani AI

Generated

Compression is one of the cheapest wins for page speed — as noted, gzipping server output can dramatically shrink HTML and speed up slow connections. Keep these basics in mind: compress only text-based responses (HTML, CSS, JS, JSON, XML); do not gzip already-compressed binaries (JPEG/PNG/MP3/PDF/ZIP). Prefer static pre-compression for very large static files when CPU is tight, and enable dynamic compression for server-generated pages that are worth the CPU cost.

Building on ’s Apache point: modern Apache setups should use mod_deflate (Apache 2.x+) rather than older approaches. A minimal, safe Apache config that compresses common text types and avoids double-compressing binaries looks like this:

<IfModule mod_deflate.c>
  AddOutputFilterByType DEFLATE text/html text/plain text/xml text/css application/javascript application/json application/xml
  # avoid compressing already-compressed files
  SetEnvIfNoCase Request_URI \.(gif|jpe?g|png|zip|gz|rar|mp3|mp4|avi)$ no-gzip
</IfModule>

<IfModule mod_headers.c>
  Header append Vary Accept-Encoding
</IfModule>

For IIS: modern IIS versions include static and dynamic compression modules out of the box — enable them in IIS Manager or web.config, pick the MIME types to compress, and set CPU/cache thresholds. If running older IIS or shared hosting where CPU is scarce, pre-compress static assets and serve them when the client advertises support. Consider Brotli (br) for better compression on modern browsers, but keep gzip as a fallback.

Quick tests and troubleshooting: verify responses include a Content-Encoding header and Vary: Accept-Encoding (browser devtools or curl). For example:

curl -I -H "Accept-Encoding: gzip, deflate, br" https://your.site/

If compression doesn’t appear, check that proxies/CDNs forward Accept-Encoding and that server-side filters aren’t excluded by MIME or size rules. Finally, heed ’s recommendation to keep pages lean — compression helps a lot, but smaller payloads are still the best win.

Recommended Answers

All 2 Replies

For Apache, in httpd.conf, look for this line:

AddEncoding x-gzip gz tgz

It's usually on by default, but if it isn't, you can add/uncomment it within <IfModule mod_mime.c> so it reads like this:

<IfModule mod_mime.c>
AddEncoding x-compress Z
AddEncoding x-gzip gz tgz

If you don't have that module loaded (mod_mime.c) then it won't do you any good, so check the Modules section to ensire it's being loaded.

commented: Nice Apache Gzip Tip! +36

I think a web page that you download to your system shouldnt' be more then 64k max.
It is kind of unspoken rule between web developers. And I agree.

100+ is maybe because its a big article.
250+ is maybe because it has a big image file
but
300+ is just too big.

gzipped pages should load instantly, for they wont result in more then 12k per page.

Be a part of the DaniWeb community

We're a friendly, industry-focused community of developers, IT pros, digital marketers, and technology enthusiasts meeting, networking, learning, and sharing knowledge.