Zend FR

Alors, non, ZF n'utilise pas ceci, car cela necessite l'extension gzip, ce qui ne va pas dans le sens de ZF.
Tu peux en effet compresser ton flux via cette commande, le mieux est de la redéfinir dans la vue, dont voici une partie de la structure :

 public function render($name)
    {
        // find the script file name using the parent private method
        $this->_file = $this->_script($name);
        unset($name); // remove $name from local scope

        ob_start();
        $this->_run($this->_file);

        return $this->_filter(ob_get_clean()); // filter output
    }

Transforme l'ob_start() ici.

Attention, si la directive zlib.output_compression  est activée, ca ne fonctionnera pas car le flux est déja compréssé ( certains hebergeurs économisent de la bande passante en activant par défaut la compression de flux dans PHP ).
Il est aussi possible d'activer cette extension au niveau du serveur directement.

cela necessite l'extension gzip, ce qui ne va pas dans le sens de ZF.

Pourquoi ça? Que veux tu dire par là?

Et alors, ça marche? Si c'est aussi simple que ça moi aussi je vais utiliser Zlib ^^

D'après ce que j'ai compris :

- il ne faut utiliser la compression Gzip que si le serveur http n'en fait pas.
   Y a t-il un moyen de le savoir par code ? Comment être sur qu'il ne le fera jamais ?
- bufferiser la sortie (ob_) optimise le flux réponse de manière propre

C'est toujours un soucis quand plusieurs intervenants on la possibilité de faire la même chose (le serveur,php ou le code)
If faut pouvoir tester dans son code, comme pour les magic_quotes_gpc si ce n'est pas fait à un niveau supérieur.

En règle générale,
- Je pense que ce n'est pas à l'application de gérer les perfs réseau. C'est bien le boulot du serveur ça.
  On devrait même pouvoir agir sur la bufferisation au niveau de php et non par code (ob_).
- Ne pas faire confiance aux autres couches pour la sécurité (magic_quotes_gpc)

Qu'en pensez vous ?

Il est en effet préférable de laisser le serveur gérer la négociation avec le client.
Si le client envoie des en-têtes comme quoi il est capable de recevoir du gzip (deflate), alors le serveur (je parlerai d'Apache) , si il est configuré pour, peut servir un contenu compréssé.
La RFC 2616 vous en apprendra plus ( bon courage )
De nos jours, c'est très souvent le cas, car cela permet une économie très importante de bande passante (qui est très chère), pour une charge processeur très raisonnable (2 à 5% supplémentaires en moyenne).

Il n'est pas interdit d'interroger son serveur manuellement (avec un client textuel, putty, curl ....) afin de voir les en-têtes de réponse et de faire par la même occaz des tests de sécurité ^^
Des extensions FF existent aussi (LiveHTTPHeaders)

La compression a du bon pour la bande passante mais elle a aussi des inconvénients.
Je peux en donner au moins un, IE ne sais pas gérer les etags lorsque la page est compressée.
Si, dans les entêtes, vous ne géré que les etags et pas de expires, vous n'aurez plus aucun 304 avec IE.
Du coup, le gain obtenu peut être nettement amoindri voir négatif faute de 304.

Certain browser (IE5) ont aussi des pb de rendu lors de la compression des css.