Re: stripping white space?

Hi Maxim, > 1. HTTP compression, which is not 100% compatible, but catches most > of the browsers anyway. Yes. The standard PHP implementation actually inspects the HTTP headers to determine if the browser supports gzip encoding. If not, it will send the files uncompressed. Looking at our website stats, 97%+ of the people use a version 4 browser so they're fine. > 2. Our own caching system: in two words: ob_*() to save the output > as a text file, mod_rewrite to check for file and throw the plain .txt files > if exist, PostgreSQL triggers to update (delete cached) .txt files. Hah! We think alike :) I implemented a similar system on our own website a few weeks ago. It does not cache complete pages (that's hardly possible due to the dynamic nature of our site), but instead caches HTML 'blocks'. (one page can consist of multiple blocks). Instead of serving those files directly from the filesystem I let PHP inspect them first: each file contains a timestamp that allows for expiry times. The results are wonderful: our website (http://www.blender.nl) has approximately 80.000 pageviews a day and the system load is almost never higher than 0.4. (Dual PIII/450/512MB/FreeBSD) If people are interested I'll publish the code for the caching module. > 3. Browser/Platform detection: there's no need to make > cross-platform heavy but compatible pages, just specific style sheets and > html tags for specific browser families. Clever! That's something I will put on my to-do list as well. > 4. clever HTML design, so there are less tags, tables etc, to have > files smaller. And *that* also includes less comments and double quotes on > integers. We do nothing with XML, so that is why I am so shocked why people > here discourage me that much. In my experience once you use HTTP compression, adding a few comments or whitelines do hardly add to the filesize anymore. I don't think it's worth the trouble to write super-compact HTML. I don't know a single thing about XML, so I'll skip that discussion :) Bart