Notice the difference between - parsing, showing and storing/retrieving the information!

News for sure might be stored in the database as well as pictures (a script can convert them after they're entered). The only drawback is that you'll have to make general modifications in the code.

I've got another crazy idea about all this, but it needs more testing (not sure what will happen with the reader's eyes ).

Encode/decode letters! Make an alphabet of images, then send them as separate to the browser. You loose kerning and the output code will be tremendous (that's where gzip encoding comes in handy ) but combined with previous ideas (no refferes and using cookies, images send thru php and gif animations) it might become unbreakable.
A PHP script and a html file should be autogenerated along with news, so that they hold news' text (to avoid DB quieries) and a function to retrieve letters. And ofcourse a caching engine (such as eaccelerator) has to be installed/enabled serverside! This also depends on browser caching algorithm - whether it uses their names for identification.

Prelimitary calculations:
example letter tag:

Code::

<img src="/e/n123456.php?l=1234"></img>

1 letter = 30 bytes code
example letter gif:
1 letter (50 frames x 20 bytes each ) = 1k data
example text:
1 page (4000 letters) = 120 k uncompressed code and 4 mb not cached data.

Well, also about 4000 server quieries per page but that could generally be reduced if you group data on words, sentences or even paragraphs.

Also, php script could be avoided if you manage to encrypt letters/words names with a random key each time (or hidden data) and decode them somehow in .htaccess or with javascript.

Another way is to parse all this with a java applet and show it to the user as separate gif images.

If I had more freetime I could make a demo for all of this, but for now - you'll have to satisfy with the ideas only.