J'ai des requêtes AJAX qui retournent quelques kilo de données.
Je me demandais si quelqu'un avait déja développé une compression de
donnée JSON (en PHP par exemple) et la décompréssion Javascript associée.
Et surtout si cela avait un impact...
Firefox m'indique que le temps de réception de mes données est de
l'ordre de 250 à 300 ms, ce qui n'est pas énorme mais bon s'il y avait
moyen de diviser par deux, pourquoi ne pas le faire.
Le Mon, 11 Oct 2010 13:52:49 +0200, Etienne a écrit:
Le 09/10/2010 10:55, SAM a écrit :
Je suis très intéressé car ... je n'imaginais pas qu'un navigateur pouvait décompresser à la volée un "responseText"
Ok.
bon alors c'est extrêmement simple a mettre en place.
Il suffit de mettre dans les .htaccess la ligne AddOutputFilterByType DEFLATE text/html text/xml
Cela permet par exemple de ne compresser qu'un seul dossier (celui des requêtes ajax) encore que j'imagine que tout doit être bon à compresser.
J'en arrive tout de suite au résultat. C'est extrêmement intéressant.
Difficile de quantifier exactement.
La partie script prends un peut plus de temps. Je dirai que dans mon c'est passé de 100 a 200 ms. (il ne faut pas en conclure que ca double mais plutot que la compression prend environ 100 ms)
Par contre le temps de transfert est quand à lui passé de 350ms à 50ms. Soit un temps non négligeable. les données originales faisaient environ 60ko.
Dans tous les cas de figures, ca va plus vite, et sur des requêtes ajax rapide qui renvoient pas mal de données et c'est directement perceptible.
Donc. ben a utiliser sans modération à partir du moment ou votre serveur n'est pas sur les genoux.
Etienne
dans un autre domaine, professionnel, la compression http/xml a fait chuter l'occupation de la bande passante de 30% à 4%
-- Utilisant le client e-mail révolutionnaire d'Opera : http://www.opera.com/mail/
Le Mon, 11 Oct 2010 13:52:49 +0200, Etienne <etienne@tlk.fr> a écrit:
Le 09/10/2010 10:55, SAM a écrit :
Je suis très intéressé car ...
je n'imaginais pas qu'un navigateur pouvait décompresser à la volée
un "responseText"
Ok.
bon alors c'est extrêmement simple a mettre en place.
Il suffit de mettre dans les .htaccess la ligne
AddOutputFilterByType DEFLATE text/html text/xml
Cela permet par exemple de ne compresser qu'un seul dossier (celui des
requêtes ajax) encore que j'imagine que tout doit être bon à compresser.
J'en arrive tout de suite au résultat.
C'est extrêmement intéressant.
Difficile de quantifier exactement.
La partie script prends un peut plus de temps.
Je dirai que dans mon c'est passé de 100 a 200 ms. (il ne faut pas en
conclure que ca double mais plutot que la compression prend environ 100
ms)
Par contre le temps de transfert est quand à lui passé de 350ms à 50ms.
Soit un temps non négligeable. les données originales faisaient environ
60ko.
Dans tous les cas de figures, ca va plus vite, et sur des requêtes ajax
rapide qui renvoient pas mal de données et c'est directement perceptible.
Donc.
ben a utiliser sans modération à partir du moment ou votre serveur n'est
pas sur les genoux.
Etienne
dans un autre domaine, professionnel, la compression http/xml a fait
chuter l'occupation
de la bande passante de 30% à 4%
--
Utilisant le client e-mail révolutionnaire d'Opera :
http://www.opera.com/mail/
Le Mon, 11 Oct 2010 13:52:49 +0200, Etienne a écrit:
Le 09/10/2010 10:55, SAM a écrit :
Je suis très intéressé car ... je n'imaginais pas qu'un navigateur pouvait décompresser à la volée un "responseText"
Ok.
bon alors c'est extrêmement simple a mettre en place.
Il suffit de mettre dans les .htaccess la ligne AddOutputFilterByType DEFLATE text/html text/xml
Cela permet par exemple de ne compresser qu'un seul dossier (celui des requêtes ajax) encore que j'imagine que tout doit être bon à compresser.
J'en arrive tout de suite au résultat. C'est extrêmement intéressant.
Difficile de quantifier exactement.
La partie script prends un peut plus de temps. Je dirai que dans mon c'est passé de 100 a 200 ms. (il ne faut pas en conclure que ca double mais plutot que la compression prend environ 100 ms)
Par contre le temps de transfert est quand à lui passé de 350ms à 50ms. Soit un temps non négligeable. les données originales faisaient environ 60ko.
Dans tous les cas de figures, ca va plus vite, et sur des requêtes ajax rapide qui renvoient pas mal de données et c'est directement perceptible.
Donc. ben a utiliser sans modération à partir du moment ou votre serveur n'est pas sur les genoux.
Etienne
dans un autre domaine, professionnel, la compression http/xml a fait chuter l'occupation de la bande passante de 30% à 4%
-- Utilisant le client e-mail révolutionnaire d'Opera : http://www.opera.com/mail/
Pierre Goiffon
On 09/10/2010 01:58, SAM wrote:
Je ne sais si les navigateurs dégzippent les codes JavaScript ...
La compression gzip côté serveur est appliquée sur le HTML, mais également sur le CSS, le JS, tout ce qui est texte en fait ! Ca marche plutôt bien, et d'ailleurs la large majorité des librairies JS aujourd'hui fournissent une version directement minifiée ET gzippée !
Pour l'usage particulier que l'on peut en faire sur un appel XHR, pas de raison que ça ne fonctionne pas. Par contre je n'en ai pas l'expérience directe, et j'imagine qu'il pourrait potentiellement y avoir des bugs de navigateurs ? Mais Paul Gaborit semble avoir eu une expérience satisfaisante ?
On 09/10/2010 01:58, SAM wrote:
Je ne sais si les navigateurs dégzippent les codes JavaScript ...
La compression gzip côté serveur est appliquée sur le HTML, mais
également sur le CSS, le JS, tout ce qui est texte en fait !
Ca marche plutôt bien, et d'ailleurs la large majorité des librairies JS
aujourd'hui fournissent une version directement minifiée ET gzippée !
Pour l'usage particulier que l'on peut en faire sur un appel XHR, pas de
raison que ça ne fonctionne pas. Par contre je n'en ai pas l'expérience
directe, et j'imagine qu'il pourrait potentiellement y avoir des bugs de
navigateurs ? Mais Paul Gaborit semble avoir eu une expérience
satisfaisante ?
Je ne sais si les navigateurs dégzippent les codes JavaScript ...
La compression gzip côté serveur est appliquée sur le HTML, mais également sur le CSS, le JS, tout ce qui est texte en fait ! Ca marche plutôt bien, et d'ailleurs la large majorité des librairies JS aujourd'hui fournissent une version directement minifiée ET gzippée !
Pour l'usage particulier que l'on peut en faire sur un appel XHR, pas de raison que ça ne fonctionne pas. Par contre je n'en ai pas l'expérience directe, et j'imagine qu'il pourrait potentiellement y avoir des bugs de navigateurs ? Mais Paul Gaborit semble avoir eu une expérience satisfaisante ?
Etienne
Le 12/10/2010 17:13, Pierre Goiffon a écrit :
La compression gzip côté serveur est appliquée sur le HTML, mais également sur le CSS, le JS, tout ce qui est texte en fait ! Ca marche plutôt bien, et d'ailleurs la large majorité des librairies JS aujourd'hui fournissent une version directement minifiée ET gzippée !
Etrange.
Comment le client fait il pour savoir que le fichier reçu est déjà gzippé si ce n'est pas une information au niveau de la connexion qui le lui dit.
M'est d'avis qu'en fait apache indique au client qu'il vient de compresser le fichier qu'il est en train de lui envoyer.
et que donc une pré-compression n'est guère possible sauf à indiquer manuellement je ne sais pas ou (dans les entètes peut etre) que le fichier est déjà compréssé.
non ?
La compression des librairie JS n'a a mon avis rien a voir. Elle se contente juste de virer les espaces inutile, de renomer au plus court les variables locales, et si elles compressent, elles embarquent avec le code pour décompresser.
Tout cela n'est que pure spéculation de ma part (je le précise).
Etienne
Le 12/10/2010 17:13, Pierre Goiffon a écrit :
La compression gzip côté serveur est appliquée sur le HTML, mais
également sur le CSS, le JS, tout ce qui est texte en fait !
Ca marche plutôt bien, et d'ailleurs la large majorité des librairies JS
aujourd'hui fournissent une version directement minifiée ET gzippée !
Etrange.
Comment le client fait il pour savoir que le fichier reçu est déjà
gzippé si ce n'est pas une information au niveau de la connexion qui le
lui dit.
M'est d'avis qu'en fait apache indique au client qu'il vient de
compresser le fichier qu'il est en train de lui envoyer.
et que donc une pré-compression n'est guère possible sauf à indiquer
manuellement je ne sais pas ou (dans les entètes peut etre) que le
fichier est déjà compréssé.
non ?
La compression des librairie JS n'a a mon avis rien a voir. Elle se
contente juste de virer les espaces inutile, de renomer au plus court
les variables locales, et si elles compressent, elles embarquent avec le
code pour décompresser.
Tout cela n'est que pure spéculation de ma part (je le précise).
La compression gzip côté serveur est appliquée sur le HTML, mais également sur le CSS, le JS, tout ce qui est texte en fait ! Ca marche plutôt bien, et d'ailleurs la large majorité des librairies JS aujourd'hui fournissent une version directement minifiée ET gzippée !
Etrange.
Comment le client fait il pour savoir que le fichier reçu est déjà gzippé si ce n'est pas une information au niveau de la connexion qui le lui dit.
M'est d'avis qu'en fait apache indique au client qu'il vient de compresser le fichier qu'il est en train de lui envoyer.
et que donc une pré-compression n'est guère possible sauf à indiquer manuellement je ne sais pas ou (dans les entètes peut etre) que le fichier est déjà compréssé.
non ?
La compression des librairie JS n'a a mon avis rien a voir. Elle se contente juste de virer les espaces inutile, de renomer au plus court les variables locales, et si elles compressent, elles embarquent avec le code pour décompresser.
Tout cela n'est que pure spéculation de ma part (je le précise).
Etienne
Paul Gaborit
À (at) Wed, 13 Oct 2010 10:10:07 +0200, Etienne écrivait (wrote):
Le 12/10/2010 17:13, Pierre Goiffon a écrit :
La compression gzip côté serveur est appliquée sur le HTML, mais également sur le CSS, le JS, tout ce qui est texte en fait ! Ca marche plutôt bien, et d'ailleurs la large majorité des librairies JS aujourd'hui fournissent une version directement minifiée ET gzippée !
Etrange.
Comment le client fait il pour savoir que le fichier reçu est déjà gzippé si ce n'est pas une information au niveau de la connexion qui le lui dit.
Cela fait partie tout simplement des entêtes standard du protocole HTTP: le navigateur indique dans sa requête le type de compression qu'il accepte (via Accept-Encoding) et le serveur peut lui renvoyer sa réponse avec l'entête (via Content-Encoding) correspondant à la compression qu'il a choisie.
Pour ce qui est acceptable comme compression, je pense quand même qu'il faut procéder à des tests puisque le fichier de configuration du module deflate d'Apache sur Ubuntu indique la chose suivante :
<IfModule mod_deflate.c> # these are known to be safe with MSIE 6 AddOutputFilterByType DEFLATE text/html text/plain text/xml
# everything else may cause problems with MSIE 6 AddOutputFilterByType DEFLATE text/css AddOutputFilterByType DEFLATE application/x-javascript application/javascript application/ecmascript AddOutputFilterByType DEFLATE application/rss+xml </IfModule>
Il y a donc des limitations au moins avec MSIE 6...
-- Paul Gaborit - <http://perso.mines-albi.fr/~gaborit/>
À (at) Wed, 13 Oct 2010 10:10:07 +0200,
Etienne <etienne@tlk.fr> écrivait (wrote):
Le 12/10/2010 17:13, Pierre Goiffon a écrit :
La compression gzip côté serveur est appliquée sur le HTML, mais
également sur le CSS, le JS, tout ce qui est texte en fait !
Ca marche plutôt bien, et d'ailleurs la large majorité des librairies JS
aujourd'hui fournissent une version directement minifiée ET gzippée !
Etrange.
Comment le client fait il pour savoir que le fichier reçu est déjà
gzippé si ce n'est pas une information au niveau de la connexion qui
le lui dit.
Cela fait partie tout simplement des entêtes standard du protocole HTTP:
le navigateur indique dans sa requête le type de compression qu'il
accepte (via Accept-Encoding) et le serveur peut lui renvoyer sa réponse
avec l'entête (via Content-Encoding) correspondant à la compression
qu'il a choisie.
Pour ce qui est acceptable comme compression, je pense quand même qu'il
faut procéder à des tests puisque le fichier de configuration du module
deflate d'Apache sur Ubuntu indique la chose suivante :
<IfModule mod_deflate.c>
# these are known to be safe with MSIE 6
AddOutputFilterByType DEFLATE text/html text/plain text/xml
# everything else may cause problems with MSIE 6
AddOutputFilterByType DEFLATE text/css
AddOutputFilterByType DEFLATE application/x-javascript
application/javascript application/ecmascript
AddOutputFilterByType DEFLATE application/rss+xml
</IfModule>
Il y a donc des limitations au moins avec MSIE 6...
--
Paul Gaborit - <http://perso.mines-albi.fr/~gaborit/>
À (at) Wed, 13 Oct 2010 10:10:07 +0200, Etienne écrivait (wrote):
Le 12/10/2010 17:13, Pierre Goiffon a écrit :
La compression gzip côté serveur est appliquée sur le HTML, mais également sur le CSS, le JS, tout ce qui est texte en fait ! Ca marche plutôt bien, et d'ailleurs la large majorité des librairies JS aujourd'hui fournissent une version directement minifiée ET gzippée !
Etrange.
Comment le client fait il pour savoir que le fichier reçu est déjà gzippé si ce n'est pas une information au niveau de la connexion qui le lui dit.
Cela fait partie tout simplement des entêtes standard du protocole HTTP: le navigateur indique dans sa requête le type de compression qu'il accepte (via Accept-Encoding) et le serveur peut lui renvoyer sa réponse avec l'entête (via Content-Encoding) correspondant à la compression qu'il a choisie.
Pour ce qui est acceptable comme compression, je pense quand même qu'il faut procéder à des tests puisque le fichier de configuration du module deflate d'Apache sur Ubuntu indique la chose suivante :
<IfModule mod_deflate.c> # these are known to be safe with MSIE 6 AddOutputFilterByType DEFLATE text/html text/plain text/xml
# everything else may cause problems with MSIE 6 AddOutputFilterByType DEFLATE text/css AddOutputFilterByType DEFLATE application/x-javascript application/javascript application/ecmascript AddOutputFilterByType DEFLATE application/rss+xml </IfModule>
Il y a donc des limitations au moins avec MSIE 6...
-- Paul Gaborit - <http://perso.mines-albi.fr/~gaborit/>
Jean-Marc Desperrier
Etienne wrote:
Il suffit de mettre dans les .htaccess la ligne AddOutputFilterByType DEFLATE text/html text/xml
Il y a moyen de mettre sur le serveur le fichier déjà compressé avec une extension xxx.ext.gz, et que ce soit ce fichier qui soit lu et envoyé directement quand le client demande xxx.ext, avec l'en-tête qui indique que les données sont compressé. Il faut vérifier exactement les intructions magiques nécessaires pour cela, ça doit être autour du negociate.
Ca évite de charger le serveur.
Etienne wrote:
Il suffit de mettre dans les .htaccess la ligne
AddOutputFilterByType DEFLATE text/html text/xml
Il y a moyen de mettre sur le serveur le fichier déjà compressé avec une
extension xxx.ext.gz, et que ce soit ce fichier qui soit lu et envoyé
directement quand le client demande xxx.ext, avec l'en-tête qui indique
que les données sont compressé.
Il faut vérifier exactement les intructions magiques nécessaires pour
cela, ça doit être autour du negociate.
Il suffit de mettre dans les .htaccess la ligne AddOutputFilterByType DEFLATE text/html text/xml
Il y a moyen de mettre sur le serveur le fichier déjà compressé avec une extension xxx.ext.gz, et que ce soit ce fichier qui soit lu et envoyé directement quand le client demande xxx.ext, avec l'en-tête qui indique que les données sont compressé. Il faut vérifier exactement les intructions magiques nécessaires pour cela, ça doit être autour du negociate.
Ca évite de charger le serveur.
WebShaker
Le 13/10/2010 20:05, Jean-Marc Desperrier a écrit :
Il y a moyen de mettre sur le serveur le fichier déjà compressé avec une extension xxx.ext.gz, et que ce soit ce fichier qui soit lu et envoyé directement quand le client demande xxx.ext, avec l'en-tête qui indique que les données sont compressé. Il faut vérifier exactement les intructions magiques nécessaires pour cela, ça doit être autour du negociate.
Pour les données statiques peut-être, mais pour les réponses ajax... Etienne
Le 13/10/2010 20:05, Jean-Marc Desperrier a écrit :
Il y a moyen de mettre sur le serveur le fichier déjà compressé avec une
extension xxx.ext.gz, et que ce soit ce fichier qui soit lu et envoyé
directement quand le client demande xxx.ext, avec l'en-tête qui indique
que les données sont compressé.
Il faut vérifier exactement les intructions magiques nécessaires pour
cela, ça doit être autour du negociate.
Pour les données statiques peut-être, mais pour les réponses ajax...
Etienne
Le 13/10/2010 20:05, Jean-Marc Desperrier a écrit :
Il y a moyen de mettre sur le serveur le fichier déjà compressé avec une extension xxx.ext.gz, et que ce soit ce fichier qui soit lu et envoyé directement quand le client demande xxx.ext, avec l'en-tête qui indique que les données sont compressé. Il faut vérifier exactement les intructions magiques nécessaires pour cela, ça doit être autour du negociate.
Pour les données statiques peut-être, mais pour les réponses ajax... Etienne
Paul Gaborit
À (at) Thu, 14 Oct 2010 01:28:27 +0200, WebShaker écrivait (wrote):
Le 13/10/2010 20:05, Jean-Marc Desperrier a écrit :
Il y a moyen de mettre sur le serveur le fichier déjà compressé avec une extension xxx.ext.gz, et que ce soit ce fichier qui soit lu et envoyé directement quand le client demande xxx.ext, avec l'en-tête qui indique que les données sont compressé. Il faut vérifier exactement les intructions magiques nécessaires pour cela, ça doit être autour du negociate.
Pour les données statiques peut-être, mais pour les réponses ajax...
Pour les réponses AJAX, un mécanisme automagique de mise en cache des réponses (par exemple un proxy cache) peut être très performant. Évidemment cela implique de savoir choisir à bon escient entre requête GET et requête POST .
-- Paul Gaborit - <http://perso.mines-albi.fr/~gaborit/>
À (at) Thu, 14 Oct 2010 01:28:27 +0200,
WebShaker <etienne@tlk.fr> écrivait (wrote):
Le 13/10/2010 20:05, Jean-Marc Desperrier a écrit :
Il y a moyen de mettre sur le serveur le fichier déjà compressé avec une
extension xxx.ext.gz, et que ce soit ce fichier qui soit lu et envoyé
directement quand le client demande xxx.ext, avec l'en-tête qui indique
que les données sont compressé.
Il faut vérifier exactement les intructions magiques nécessaires pour
cela, ça doit être autour du negociate.
Pour les données statiques peut-être, mais pour les réponses ajax...
Pour les réponses AJAX, un mécanisme automagique de mise en cache des
réponses (par exemple un proxy cache) peut être très performant.
Évidemment cela implique de savoir choisir à bon escient entre requête
GET et requête POST .
--
Paul Gaborit - <http://perso.mines-albi.fr/~gaborit/>
À (at) Thu, 14 Oct 2010 01:28:27 +0200, WebShaker écrivait (wrote):
Le 13/10/2010 20:05, Jean-Marc Desperrier a écrit :
Il y a moyen de mettre sur le serveur le fichier déjà compressé avec une extension xxx.ext.gz, et que ce soit ce fichier qui soit lu et envoyé directement quand le client demande xxx.ext, avec l'en-tête qui indique que les données sont compressé. Il faut vérifier exactement les intructions magiques nécessaires pour cela, ça doit être autour du negociate.
Pour les données statiques peut-être, mais pour les réponses ajax...
Pour les réponses AJAX, un mécanisme automagique de mise en cache des réponses (par exemple un proxy cache) peut être très performant. Évidemment cela implique de savoir choisir à bon escient entre requête GET et requête POST .
-- Paul Gaborit - <http://perso.mines-albi.fr/~gaborit/>
Paul Gaborit
À (at) Fri, 15 Oct 2010 10:02:02 +0200, Etienne écrivait (wrote):
Le 15/10/2010 03:51, Paul Gaborit a écrit :
Pour les réponses AJAX, un mécanisme automagique de mise en cache des réponses (par exemple un proxy cache) peut être très performant. Évidemment cela implique de savoir choisir à bon escient entre requête GET et requête POST .
Je parlais de réponse AJAX dynamique ne renvoyant jamais le même résultat...
C'est quand même assez rare que *toutes* les requêtes AJAX ne renvoient jamais le même résultat. Une bonne méthode pour profiter des mécanismes de caches consiste au minimum à donner une durée de vie (même courte) aux réponses dynamiques.
Enfin bon la compression serveur via mod_deflate est tout de même très simple et très performante... Donc y a pas trop de raison de se compliquer la vie :)
C'est un point de vue. Certains en négligeant l'utilité d'un cache en frontal d'un serveur Web applicatif ont perdu beaucoup d'argent et de temps (il y a eu un exemple récent et relativement retentissant avec un certain site que voulait lancer l'état français il y a quelques semaines).
-- Paul Gaborit - <http://perso.mines-albi.fr/~gaborit/>
À (at) Fri, 15 Oct 2010 10:02:02 +0200,
Etienne <etienne@tlk.fr> écrivait (wrote):
Le 15/10/2010 03:51, Paul Gaborit a écrit :
Pour les réponses AJAX, un mécanisme automagique de mise en cache des
réponses (par exemple un proxy cache) peut être très performant.
Évidemment cela implique de savoir choisir à bon escient entre requête
GET et requête POST .
Je parlais de réponse AJAX dynamique ne renvoyant jamais le même résultat...
C'est quand même assez rare que *toutes* les requêtes AJAX ne renvoient
jamais le même résultat. Une bonne méthode pour profiter des mécanismes
de caches consiste au minimum à donner une durée de vie (même courte)
aux réponses dynamiques.
Enfin bon la compression serveur via mod_deflate est tout de même très
simple et très performante...
Donc y a pas trop de raison de se compliquer la vie :)
C'est un point de vue. Certains en négligeant l'utilité d'un cache en
frontal d'un serveur Web applicatif ont perdu beaucoup d'argent et de
temps (il y a eu un exemple récent et relativement retentissant avec un
certain site que voulait lancer l'état français il y a quelques
semaines).
--
Paul Gaborit - <http://perso.mines-albi.fr/~gaborit/>
À (at) Fri, 15 Oct 2010 10:02:02 +0200, Etienne écrivait (wrote):
Le 15/10/2010 03:51, Paul Gaborit a écrit :
Pour les réponses AJAX, un mécanisme automagique de mise en cache des réponses (par exemple un proxy cache) peut être très performant. Évidemment cela implique de savoir choisir à bon escient entre requête GET et requête POST .
Je parlais de réponse AJAX dynamique ne renvoyant jamais le même résultat...
C'est quand même assez rare que *toutes* les requêtes AJAX ne renvoient jamais le même résultat. Une bonne méthode pour profiter des mécanismes de caches consiste au minimum à donner une durée de vie (même courte) aux réponses dynamiques.
Enfin bon la compression serveur via mod_deflate est tout de même très simple et très performante... Donc y a pas trop de raison de se compliquer la vie :)
C'est un point de vue. Certains en négligeant l'utilité d'un cache en frontal d'un serveur Web applicatif ont perdu beaucoup d'argent et de temps (il y a eu un exemple récent et relativement retentissant avec un certain site que voulait lancer l'état français il y a quelques semaines).
-- Paul Gaborit - <http://perso.mines-albi.fr/~gaborit/>
