Member Avatar for raigs

My website is programmed in PHP and currently uses HTTP compression (gzip) using PHP's built-in compression functions. (I cannot use mod_deflate.c because my shared hosting provider will not install it because it would use a lot of CPU.) The shared server where my website is hosted currently hosts 100 other websites. I have programmed the html and css quite efficiently and there is not much room to rewrite the same thing with less markup. My images are already compressed.

My question is whether using PHP's compression actually is faster for the user than sending it uncompressed.
1. The CPU compresses the output, sends the output to the browser and the browser has to decompress it. (Compression functions use considerable CPU on both computers.)
2. Send the output uncompressed. (Saves CPU but sends more data.)

Is it worth it to compress my webpages if each consist of 20kb of html/css and 30kb of images?

  • 3 Contributors
  • 2 Replies
  • 114 Views
  • 1 Day Discussion Span
  • Latest Post Latest Post by almostbob

Dani AI

Generated

Short answer for : for text resources (HTML/CSS/JS) compression is usually worth it — it often cuts transfer size by a large percent and so reduces load time — but doing on-the-fly compression in PHP on a CPU-limited shared host can become a bottleneck under load. As said, it is a bandwidth vs CPU trade; 's testing suggestion is right in spirit — measure, do an A/B and compare real transfer sizes and timings.

Practical, low-risk options that avoid repeated PHP CPU cost:

  • Precompress static text assets once at deploy time and serve the pre-gzipped file when the client accepts it (many servers have a static-gzip option). This gives the benefits of compression without compressing per request.
  • Offload compression to a CDN or reverse proxy which does it in native code and scales better.
  • If you must compress on the fly, choose a lower compression level to reduce CPU at the cost of slightly larger bytes.

How to decide: measure both wire bytes and server CPU. Use the browser Network panel plus tools like WebPageTest or Google PageSpeed to compare compressed vs uncompressed responses and check perceived load times. Also monitor server CPU during spikes; if CPU climbs and pages are being generated frequently, prefer precompression or CDN.

Implementation notes and reading:

Recommended Answers

All 2 Replies

Member Avatar for adamramadhan

well its a choice either bandwidth or ram usage .

Member Avatar for almostbob

make yourself a page
a really enormous wad of text
images are insignificant as jpg and png are already optimized and nobody should be bmp-ing
make 2
one with gzip enabled, one without
compare load times
run both through http://www.websiteoptimization.com/services/analyze/ to see the difference
I find a huge speed differential in favoour of

<?php ob_start("ob_gzhandler"); 
ob_flush(); ?>

css and javascripts respond well to gzip,
example: in the include file creates your <head>
change references to 'style.css' to 'style.css.php'

<?php header ('content-type:text/css'); 
ob_start("ob_gzhandler"); ?>/*<style>*/
.rss-box { margin:1em 3%; padding:4px 8px; background-color:#ededed; border:2px dashed #7485CA; }
.rss-title, rss-title a { font-family:"American Typewriter", "Trebuchet MS", Trebuchet, Lucida, sans-serif; font-size:100%; font-weight:bold; margin:5px 0; padding:0; letter-spacing:1px; }
/* bla bla bla */
<?php ob_flush(); ?>

likewise can be script.js.php with content-type:text/javascript and gzip enabled

Edited by almostbob because: n/a
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.