Komprese výstupního kódu

Existuje nějaká jiná funkce, než ob_start("ob_gzhandler"); na kompresi výstupního kódu nebo urychlení načítání stránek ?

Zkoušel jsem něco jako :

$str=addslashes(ob_get_contents());
$fp=popen("echo \"" . $str . "\" | /usr/bin/tidy -i -u -q -latin1 --indent-spaces 1 -wrap 0", "r");
@$newstr=fread($fp, 99999);
ob_end_clean();
Header( "Content-length: " . strlen( $newstr ) );
echo $newstr;

, ale nezdá se, že by to mělo nějaký efekt :(
jestli jsi to zkousel tady, tak ten krok s popen nemuze fungovat

jinak myslim, ze gzip je natolik ucinna komprese, ze "zkraslovani" html kodu pred kompresi nema moc smysl - vstup do komprese bude mensi, ale ucinnost taky, takze bych tipnul, ze v praxi se to moc nevyplati

kazdopadne html se ma psat jednou a poradne, takze veci jako ten "tidy" ... pokud teda spravne tusim, jakou to ma mit funkci ... jsou pak zbytecne

mam v planu otestovat, jak se mod_gzip-ovani vsech stranek projevi na zatizeni, pokud by to bylo prijatelne, nastavil bych to globalne pro vsechny text/html soubory
mam v planu otestovat, jak se mod_gzip-ovani vsech stranek projevi na zatizeni, pokud by to bylo prijatelne, nastavil bych to globalne pro vsechny text/html soubory
a jak se to pr tojevi na prohlizecich
tak, ze objem prenasenych dat klesne radove 5x u normalnich stranek, mam vyzkouseno, ze u stranek generovanych ve frontpage to je klidne 20x

ps: neni spatne oznacit, co pises sam a co pise nekdo pred tebou
podle toho, co jsme zkouseli s kolegou, tak mit zapnute qzipovani se asi vyplaci (ale tezko to mohu posoudit - nemam k dispozici vlastni server s takovym naporem jako webzdarma).
...
mod_gzip_minimum_file_size 100
mod_gzip_item_include file \.html$
...


v pripade generovani dynamickych stranek muze urcite byt vyhodne qzipovat pouzitim ob_start("ob_gzhandler"); (myslim, ze od verze4.0.x? a je potreba mit patricne prekompilovane php) vyhodou je, ze se php samo postara o to, zda data poslat komprimovane nebo ciste v zavislosti na prohlizeci.

>a jak se to pr tojevi na prohlizecich
kazdej rozumnej dnes 'bezne' pouzivanej prohlizec podporuje qzip, jinak standartem je v hlavicce ACCEPT_ENCODING predavat parametr qzip v pripade, ze to zvlada.

m.s.
to admin: sorry zapomnel jsem

ja bych moznost gzipovani nechal na uzivatalich
(myslim ze to tu uz je podporovane) pripadne pokud se admin rozhodne zapnout toto globalne pro vsechny text/html soubory tak mit moznost toto pro svoje soubory vzpnout }nastavit jinak
>mit moznost toto pro svoje soubory vzpnout...

...proc? vzdyt tobe to muze byt uplne jedno (spis muzes byt rad) :-)

m.s.
kdyz uz treba komprimuju to se to bude komprimovat 2x? (nechci to zase cele prekopavat)
2x? nemyslim si. pokud je komprese zapla defaultne tak se to bude komprimovat at chces nebo ne... ale proc dvakrat? nebo snad pouzivas nejakou svoji tridu neb jinou nestandartni metodu na kompresi?

m.s.
Pokud to podporujou vpohodě všechny prohlížeče, tak jsem rozhodně pro, ale v opačném případě bych dal možnost to vypnout.
vzdyt je to napsane vyse. pokud prohlizes tuto moznost podporuje, pak v hlavicce ACCEPT_ENCODING posila krome jineho i qzip... co je stale nejasne? :-)

jedina moznost je, ze prohlizec odesle hlaseni, ze podporuje komprese i kdyz ji neumi (ale jestli se takto nejaky chova, tak si snad ani nezaslouzi byt pouzivam - to uz je uplne jiny problem)

m.s.
> (ale jestli se takto nejaky chova, tak si snad ani nezaslouzi byt pouzivam
> - to uz je uplne jiny problem)

za posledni pul rok jsem mel nekolik hlaseni, ze jim nefunguje wz v eksploreru (ze to vypisuje nejaky rosypany caj misto pismenek), tak jsem usoudil ze jde o neco takoveho, pokud jsi dobre vzpominam, vzdy jsme to uzavreli s tim, ze pouziva nejakou spatnou proxy, ktera accept-encoding serveru preda, ale klientovi content-encoding uz nevrati ... nebo neco podobneho, kazdopadne nepekneho

pokud by takovych emailu chodilo denne nekolik desitek, asi bychom s timto radeji ustoupili i kdyz to neni muj styl
nn explorer o pane boze kde jsou nejake normy ....
4martin s.: Mě to je jasný, že se to posílá v hlavičce, ale chtěl jsem vědět, jestli to funguje 100%, což jak zmínil admin možná taky ne.
100% neni nic :-) imho takove pripady jsou (jak uz padlo) spatne nastavenou proxy pripadne prohlizecem (zapnuta podpora http1.1 v IE atd.)

ale to uz pak zalezi na konkretnim pripadu...

m.s.
Ja sem takova lamka a proto se otvrene zeptam:
V tomhle foru sem se dozvedel o moznosti komprese stranek, tak sem chvilku hledal a nasel sem na http://www.cdr.cz/a/clanky/clanek/195/2 clanek jak to udelat. PHP zatim prakticky nerozumim, tak se chci zeptat, jestli ma cenu komprimovat takhle svoje stranky.
Jestli to co ziskam na dobe stahovani nestratim na dobe komprimovani na serveru. A jestli je ten zapis na www.cdr.cz idealni.
no, pokud na serveru neco komprimujes, tak je to plus minus autobus rychlosti svetla (nebo si myslis, ze komprimovani tve JEDNE stranky bude tomuto serveru trvat tak dlouho? :o) )... jde spise o pozdejsi stahovani stranky ze serveru na tvuj kompl.
i kdyz jsem se tedy uz setkal (a dennodenne setkavam) s tim, ze pokud prijdu na webzdarma ve vecernich hodinach (od sedmi do desiti), tak se po kliku na link treba pet sekund nic nedeje, a pak se mi za dve sekundy stahne cela stranka (naraz, nenacita se od kliku.). Takze i server ma holt nekdy horky chvilky s vypoctama...