<C²: webløg />

Courriel - email address

Avatar Bleizig

vendredi 10 octobre 2003
par Bleizig

C² en compressé

Que c'est enrichissant la communauté Internet ... il y a toujours un internaute prêt à vous suggérer des améliorations pour votre site, et le plus souvent exploitant des fonctionnalités dont vous ne soupconniez même pas l'existence. Dernièrement, Aurélien Maille nous a proposé de mettre en place un système très simple pour compresser les pages avant l'envoi au client, un procédé réduisant considérablement le poids des pages.

Excité à l'idée d'en apprendre plus sur une technique qui m'etait inconnue jusqu'à présent, j'ai commencé à explorer en suivant son conseil: une méthode proposée par leknor. J'ai été surpris de découvrir que les navigateurs Web acceptent depuis belle lurette de recevoir des pages compressées avec gzip et en effet, il est très simple d'utiliser la classe class.gzip_encode.php de leknor, puisque tout y est merveilleusement bien commenté. Je me suis rendu compte que bien que certains gourous de la toile aient découvert cette technique depuis près d'un an, la majorité des sites que j'ai testé n'offraient pas de contenu compressé.

Brievement, voilà comment ca marche en php:

  • Tout d'abord, tout output est sauvé dans un buffer : ob_start();
  • Ensuite, on vérifie que le navigateur supporte bien les pages compressées en examinant $_SERVER["HTTP_ACCEPT_ENCODING"]
  • Enfin, à l'aide de gzcompress(), la page est compressée.

A noter, le code de leknor requiert que les variables globales soient activées (ie "register_globals = On" dans le php.ini). Si votre site, comme CYBERcodeur, préfère avoir cette option désactivée, remplacez les références à $HTTP_ACCEPT_ENCODING par $_SERVER["HTTP_ACCEPT_ENCODING"] (vous pourrez aussi vous débarasser des "global $HTTP_ACCEPT_ENCODING").

En conclusion, un grand merci a Aurélien car les pages de CYBERcodeur sont dorénavant trois fois moins lourdes ce qui j'espère, permettra aux utilisateurs de modem 56k d'accéder au contenu plus vite.

Bleizig | 2003.10.10 @ 15:09

Alors, qu'en pensez-vous ?

Voici ce que vous aviez à en dire... vos impressions, recueillies à vif.

2003.10.10 @ 16:12 par Pierre Gentile

Il existe une fonction encore plus simple pour compresser les pages à la volée : il suffit de placer en tête de fichier la ligne suivante :

<?php ob_start('ob_gzhandler'); ?>

Cette fonction permettra de tester automatiquement l'encodage chez le client et de compresser la page si le client accepte la compression GZip.

Haut retour au début de la page

2003.10.10 @ 16:33 par Freddy

Arf,grillé par Pierre :)
En effet, php permet (depuis la version 4.2 ou un truc du genre je crois) de faire des pages compressées automatiquement (ainsi que l'as indiqué pierre)
Note, cependant, que j'ai vu des personnes ayant des problèmes avec la compression de page : sous windows 98, avec ie version 5 et 5.5, parfois, la boîte de dialogue d'installation des polices arabes apparaît.

(Note à propos du site : j'ai la droite du textarea de commentaire qui est recouverte par la colonne de droite, avec les liens rss. (Mozilla 1.5rc2). Je pense que tu l'as déjà remarqué, mais bon, au cas où :)

Haut retour au début de la page

2003.10.10 @ 16:39 par Anubis

Merci Pierre... Et merci Denis d'avoir déclenché le commentaire de Pierre ;-).

Haut retour au début de la page

2003.10.10 @ 16:55 par Dam

Ya moyen de faire faire tout ça par Apache directement ;

sur ma mandrake :

#urpmi mod_gzip

ou télécharger ici les binaires/sources http://www.schroepl.net/p...

et pof ! un serveur qui se debrouille tout seul pour compresser les page a la vollée avec un fichier de conf en prime et sans changer le code des pages PHP (et il compresse aussi les document non PHP; voir fichier de conf)

Haut retour au début de la page

2003.10.10 @ 17:14 par Bobe

Ahhh..

Merci Dam, j'avais entre aperçu quelque part qu'il y avait un module apache pour ça, mais je n'arrivais pas à remettre la main dessus, et une chose en chassant une autre...

Et merci Denis d'avoir mis ça en place. Même en adsl, on sent une légère différence :)

Prochaine étape, gestion du cache coté client lol ;-)

Haut retour au début de la page

2003.10.10 @ 18:46 par CYBERcodeur

Euh, en fait c'est pas moi qu'il faut remercier pour cette innovation, c'est Bleizig. Moi, je suis nul come mes pieds par un affreux jour de pluie dans le domaine du PHP. :)

Pour ce qui est de la boîte de commentaire, j'en ai pris bonne note. Je règlerai rapidement (parce qu'en matière de CSS, je suis un peu moins minable quand même ;) !!!

Haut retour au début de la page

2003.10.10 @ 19:11 par Faden

Du tout bon ...

Et les teux de compression ça donne quoi ?

Haut retour au début de la page

2003.10.10 @ 21:17 par Bleizig

Ca divise par 3 la taille des pages en moyenne ce qui n'est pas negligeable.

Haut retour au début de la page

2003.10.10 @ 21:49 par Jerotito

Un immense merci à Pierre Gentile.

J'adore cette magie du <?php ob_start('ob_gzhandler'); ?>

J'ai testé sur une page qui pesait 74 Ko à l'origine.
À l'arrivée, moins de 11 Ko. *Très* appréciable. :-)

http://jerotito.org/resso...

Je suppose que les clients qui ne supportent pas la compression GZip recevront la page au poids normal de 74 Ko. Mais au fait, quels sont « ces clients » ? Les vieux navigateurs ?

Haut retour au début de la page

2003.10.11 @ 01:44 par Fabrice Lezoray

Pour info, On peut également jouer sur le taux de compression :

<?php ob_start( array ( 'ob_gzhandler' , 4) ); ?>

4 est le taux par défaut , des valeurs de 1 à 9 sont supportées, avec 9 , le niveau de compression maximum.

Sinon, comme indiqué dans la doc PHP, il est préférable d' utiliser ce simple bout de code au début du script à compresser :

<?php ini_set ( 'zlib.output_compression' , 'On' ); ?>

... au lieu des fonctions ob_* , ca évite toutes les petites tracasseries liées a la bufferisation , et notemment l' obligation d' envoyer l' integralité du buffer vers le client après le 'flush' , alors qu' en réglant ce parametre du php.ini , le buffer de sortie est envoyé vers le client dés que necéssaire et par paquet de 4 ko max

Pour répondre à Jerotito , il y a un début de réponse dans les notes des Utilisateurs de la fonction ob_gzhandler() (avant avant dernier commentaire)

http://fr.php.net/manual/...


Haut retour au début de la page

2003.10.11 @ 03:43 par Fabrice Bonny

Sauf erreur, mettre 'zlib.output_compression = On' dans la config PHP doit faire exactement pareil. Dans tous les cas ça détecte que le navigateur renvoye 'gzip' dans le 'accept-encoding'.

Côté HTML, il existe 'mod_deflate' en natif sur Apache 2: 'SetOutputFilter DEFLATE'.

Haut retour au début de la page

2003.10.11 @ 15:26 par Dam

petite correction:

Sur apache2 le module de compression c'est mod_deflate

Dam

Haut retour au début de la page

2003.10.11 @ 16:22 par Philippe Charles

Le module mod_deflate d'apache2 compresse à la volée tout ce qu'il envoit au browser ... ça peut être utile pour les css par exemple.

Haut retour au début de la page

2003.10.13 @ 09:51 par un usenaute

Bonjour,

D'abors, les compressions de données transportées par http sont évoquées depuis longtemps (enfin plusieurs mois), voir lien http://blog.dreams4net.co... .

Ensuite, puisque l'architecture des serveurs est généralement :
client http
|
serveur http = souvent Apache http
|
interpréteur php
|
logiciel php

Il me semble préférable de laisser toutes les compressions aux bons soins du serveur http,
qui vérifiera la compatibilité du client et compressera aussi bien les pages html que les images.

(Si c'est aplaudi je ferai une copie dans fciw*)



Haut retour au début de la page

2003.10.13 @ 13:46 par Eric Daspet

Usenaute je suis tout à fait d'accord (étrange vu le lien fournit, n'est-ce pas ?)

Dans l'idéal PHP s'occupe du contenu et des méta données associées (type du document, jeu de caractère, infos de cache ...). Toujours dans l'idéal si on a un serveur web c'est pour lui laisser gérer les connexions, il faut ca très bien.

L'utilisation du mod_gzip est AMHA à préférer, elle a l'avantage de marcher aussi pour les CSS, les images, et faire les détections qui s'imposent automatiquement.


En fait Denis quand j'ai vu cet article j'ai été très embêté, parce que ça veut dire que bien qu'on soit dans un cerlce très restreint ce sont toujours les même sujets qui sortent en boucle : en peu de jours voilà le sujet des tailles de police et de la compression qui ressortent alors qu'ils ont déjà fait la une (je ne parle pas du fait que j'en ai personnellement parlé, je nsuis loin d'être le seul) quelques mois auparavant.

J'ai peur que dans quelques temps on redécouvre les entetes de cache HTTP et la négociation de contenu, et ainsi de suite. J'ai un petit peut le gout de l'oeuvre inutile...

Haut retour au début de la page

2003.10.13 @ 14:55 par Anubis

La répétition est malheureusement la base de l'enseignement... S'il existait aujourd'hui un support permettant un accès parfait à l'information, cela se saurait :-).

Haut retour au début de la page

2003.10.13 @ 15:41 par Bleizig

Eric,

Avant d'ecrire cet article, j'ai pris au hasard une dizaine de blogs de la communaute que je lis regulierement et 8 sur les 10 ne compressaient pas les pages ... j'en ai donc deduis que ce sujet n'etait pas largement repandu.

Au final, les nombreux commentaires postes en reaction m'ont permis de beaucoup apprendre sur le sujet et je pense que je ne suis pas le seul, ce n'etait donc pas, imho, completement inutile.

Haut retour au début de la page

2003.10.14 @ 04:45 par Eric Daspet

(grr, et moi j'aurai du regarder le champ auteur au lieu de parler de Denis par défaut)

Oulà, loi de moi l'idée de penser que c'était inutile. Je regrette juste que ça ne le soit pas justement ;)
Peut être qu'à faire trop de choses on se disperse. Il faudrait quelque part une ressource type OpenWeb mais plus généraliste, où on puisse poser des articles de cet ordre.
Parce que là chacun le fait sur son blog. C'est bien, mais force est d'avouer que ça ne marche pas. Et quand je dis que ça ne marche pas je parle du cercle très restreint de passionnés, je n'ose meme pas imaginer ce qu'il doit en rester pour les autres.

Ce n'était absolument pas orienté comme une critique, mais plus comme un regret : un constat que finalement ce qu'on fait n'est pas aussi utile que ce que j'espérai

Haut retour au début de la page

2003.10.14 @ 11:44 par CYBERcodeur

Je suis bien content de te voir apporter cette nuance Eric parce que je t'avoue franchement que je comprennais mal le sens de ton précédent commentaire... La compression des fichiers est un aspect de la conception Web qui est indubitablement méconnu, peu importe à quel point toi et une poignée d'autres s'y connaissent. Je suis prêt à parier ce que tu veux que si on lançait un sondage, la très grande majorité des lecteurs de cYBERcodeur n'en aurait jamais entendu parler avant aujourd'hui. En fait, je suis convaincu que la très grande majorité n'aurait même pas conscience que tu avais abordé le sujet il y a longtemps. La mémoire collective est un phénomène particulièrement abstrait sur le Web... c'est pas parce qu'un truc est archivé qu'il est forcément consulté.

C'est vraiment pas parce que les commentaires vont dans le sens qu'ils vont que tous les lecteurs s'y connaissent. Loin de là.

J'en tiens à preuve l'éternel retour vers des débats qui se renouvellent sans cesse et qui cycliquement, refont les manchettes parce que l'air du temps s'y prête bien. Personnellement, je tiens la barre de CYBERcodeur pour permettre (autant que possible) aux non-initiés de s'intégrer progressivement aux pratiques associées avec la conformité aux normes et l'accessibilité. Si la proportion d'experts en la matière est la plus visible sur le site, je doute fort qu'elle soit la plus importante en terme d'individus. Alors oui, nous reprennons certains sujets et oui, nous continuerons à le faire. Parce que l'expérience nous prouve que c'est par la répétition que les gens finissent par comprendre... pas par un seul texte lancé à un moment précis dans le temps, mais bien par un ensemble de texte, répartis progressivement dans un continuum. Le construit de la connaissance doit se faire progressivement. C'est la psychologie cognitive qui le dit, pas moi. :)

Pense seulement aux principes d'accessibilité. J'en ai entendu parler pour la première fois en 1998. Cela ferait donc presque 6 ans. Et déjà, à cette époque, c'était pas du tout neuf. 6 ans et plus donc, que les gens répètent les mêmes trucs évidents comme mettre une valeur aux ALT des images. Pour l'avoir répété, on l'a répété. Est-ce inscrit dans les habitudes des développeurs d'aujourd'hui ? Pas du tout. Tu le fais, je le fais, certains d'entre nous le font. Mais la majorité des gens ? Pas du tout. Conclusion ? Faut répéter, et répéter encore. Alors on répète.

Mon but avec CYBERcodeur n'est pas tant de repousser les limites des technologies et de réfléchir sur les directions vers lesquelles nous évoluons que de rassembler les développeurs vers une méthodologie qui continue de faire ses preuves au jour le jour. Ainsi donc, je vais continuer à parler de sujets très simples à l'occasion, que j'essaie du mieux que je peu d'entre-mêler de sujets plus complexes, afin de satisfaire tout le monde. Je ne suis pas intéressé à tenir un weblog exclusivement pour la poignée d'experts et d'initiés dont tu fais partie. Je suis beaucoup plus intéressé à offrir un tremplin à ceux qui souhaitent le devenir, à ceux qui souhaitent rejoindre nos rangs et comprendre les subtilités du box model.

Le fait que toi et d'autres y trouviez un peu votre compte me fait extrèmement plaisir, ne te méprends pas. Seulement, mon rôle est de faire voir la lumière aux développeurs qui sont encore dans le noir. Avec toi, le travail est déjà accompli ! On a beau se frotter le dos avec un discours d'élite, tout ce qu'on parvient à faire, c'estcréer une cloche autour de nos connaissances et les rendre hermétiques à qui boudrait bien se les approprier. C'est pas du tout mon intention et je suis convaincu que ce n'est pas la tienne non plus. :)

Que certains d'entre nous travaillent fort à aborder de nouveaux sujets et de nouvelles problématiques est crucial. C'est comme ça que nous repoussons les limites de nos connaissances, collectivement. Peut-être est-ce un peu plus le genre de responsabilité que tu te donnes. Mais ce n'est pas celle de CYBERcodeur (enfin, pas uniquement). Mon but le plus important, c'est que le néophyte puisse embarquer dans le train lui aussi. Pour ce faire, il faut constamment reconstruire les bases, et parler des différences entre HTML et XHTML par exemple, pas juste les entêtes de cache HTTP (qui pour moi, soit dit en passant, relèvent du mystère le plus opaque ;).

À la lumière de ton second commentaire, je comprends exactement ton point de vue et ça me rassure. C'est regrettable que nous ayons toujours à revenir en arrière et répéter les mêmes choses, j'en conviens. Mais les gens qui arrivent à peine parmi nous ne peuvent deviner l'historique qui nous permet de se situer ou l'on se situe maintenant. Moi je veux leur donner la chance d'embarquer dans la course. Je te préviens d'avance, on discutera des mêmes sujets dans plusieurs années encore. T'as tout intérêt à t'y faire ! Il y aura toujours de nouvelles vagues de développeurs à convertir, qui auront besoin de repasser par les mêmes bases. Faut pas compter sur eux pour faire l'effort de reconstituer les archives des sites. C'est beaucoup trop de travail; c'est déjà assez compliqué de s'approprier les connaissances !

Ce que l'on fait est très utile, ne te méprends pas. La forme et le ton dans lequel la plupart d'entre nous le faisons n'est peut-être pas adapté par contre. En soit, cela recoupe les commentaires que j'ai déjà fait sur la liste des pompeurs à l'effet que le discours ne devait pas devenir trop élitiste. Personnellement, voilà déjà quelques mois que je travaille avec Bleizig à transcender le modèle du weblog pour parvenir à autre chose, une forme renouvellée de 'plateforme collaborative et communautaire à vocation sociale'.

CYBERcodeur n'est plus l'affaire d'un seul homme, c'est maintenant l'affaire d'une équipe qui est encore à bâtir. Exactement pour les raisons que tu évoques, parce que le modèle ne marche pas assez bien dans sa forme actuelle. Ce n'est pas une question de faire mourir les Weblogs, c'est une question de leur permettre d'évoluer vers le prochain stade... et de découvrir quel est ce stade par la même occasion, de le définir nous-mêmes, plutôt que d'attendre que d'autres le fasse à notre place.

À ce moment, notre travail commencera réellement à prendre tout son sens. :)

Haut retour au début de la page

2004.10.15 @ 13:38 par Imankalis

salut à tous,
j'suis dégoutté...moi ça marche pas votre truc!
<?php ob_start('ob_gzhandler'); ?>
je suis hébergé par freesurf (php v4.2.3) (et j'ai IE6 sous Xp.)
Il a un Pb avec 'ob_gzhandler' ...
j'ai essayé leknor (fichier imposant) et marche pas non plus .Cf:
<?php
ob_start();
include('class.gzip_encode.php');
?>

je n'ai pas d'erreur avec:
<?php ob_start( array ( 'ob_gzhandler' , 4) ); ?>
OU
<?php ini_set( 'zlib.output_compression' , 'On' ); ?>
mais ça fait absolument rien du tout...
d'ailleur je vais sur:
http://leknor.com/code/gz...
pour vérifier si ma page a bien été compressée mais aucune de vos méthodes ne semble marcher..snifff!
Quelqu'un peut il m'envoyé un mail ou mieux un fichier type à imankalis@aol.com pour me décrire précisement comment il fait...

Grand MERCI!

Haut retour au début de la page

Les commentaires et trackbacks sont désormais fermés. Pour toute remarque, vous pouvez toujours nous contacter.

Pisteur (Trackback)