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.
À (at) Fri, 08 Oct 2010 23:49:08 +0200, WebShaker écrivait (wrote):
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.
Il suffit de demander au serveur de compresser les données. Pour Apache, c'est mod_deflate qui permet de le faire. Un navigateur bien élevé doit savoir décompresser cela tout seul de manière transparente (pas besoin de décomrpesser en Javascript).
-- Paul Gaborit - <http://perso.mines-albi.fr/~gaborit/>
À (at) Fri, 08 Oct 2010 23:49:08 +0200,
WebShaker <etienne@tlk.fr> écrivait (wrote):
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.
Il suffit de demander au serveur de compresser les données. Pour Apache,
c'est mod_deflate qui permet de le faire. Un navigateur bien élevé doit
savoir décompresser cela tout seul de manière transparente (pas besoin
de décomrpesser en Javascript).
--
Paul Gaborit - <http://perso.mines-albi.fr/~gaborit/>
À (at) Fri, 08 Oct 2010 23:49:08 +0200, WebShaker écrivait (wrote):
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.
Il suffit de demander au serveur de compresser les données. Pour Apache, c'est mod_deflate qui permet de le faire. Un navigateur bien élevé doit savoir décompresser cela tout seul de manière transparente (pas besoin de décomrpesser en Javascript).
-- Paul Gaborit - <http://perso.mines-albi.fr/~gaborit/>
SAM
Le 08/10/10 23:49, WebShaker a écrit :
Salut.
J'ai des requêtes AJAX qui retournent quelques kilo de données.
Ha! Oui ! quand même ! ;-)
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.
(j'ai copié-collé et sauvé en texte ce post-ci, il fait 1088 oct, zippé, il fait 1133 oct ... en gz ... pas essayé)
Et surtout si cela avait un impact...
Le seul impact est de bien penser ses requêtes et l'optimisation des données à la Json. (à mon idée, et vu de ma chaise)
Firefox m'indique que le temps de réception de mes données est de l'ordre de 250 à 300 ms,
Je me demande bien sur quoi il se base ? Que sait-il de la qualité de "ma" connexion ?
ce qui n'est pas énorme mais bon s'il y avait moyen de diviser par deux, pourquoi ne pas le faire.
Si je comprends bien c'est une appli qui n'est qu'à ton profit, puisque tu te bases sur les vitesses de "ton" équipement.
Etienne
J'ai comme idée que les trucs Json peuvent être parfois assez lourdingues, peut-être faut-il voir s'il est possible de les alléger? Par exemple : <http://www.aspfr.com/codes/OPTIMISATION-SERIALISATION-JSON-LIST_46766.aspx>
-- Stéphane Moriaux avec/with iMac-intel
Le 08/10/10 23:49, WebShaker a écrit :
Salut.
J'ai des requêtes AJAX qui retournent quelques kilo de données.
Ha! Oui ! quand même ! ;-)
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.
(j'ai copié-collé et sauvé en texte ce post-ci, il fait 1088 oct,
zippé, il fait 1133 oct ... en gz ... pas essayé)
Et surtout si cela avait un impact...
Le seul impact est de bien penser ses requêtes et l'optimisation des
données à la Json.
(à mon idée, et vu de ma chaise)
Firefox m'indique que le temps de réception de mes données est de
l'ordre de 250 à 300 ms,
Je me demande bien sur quoi il se base ?
Que sait-il de la qualité de "ma" connexion ?
ce qui n'est pas énorme mais bon s'il y avait
moyen de diviser par deux, pourquoi ne pas le faire.
Si je comprends bien c'est une appli qui n'est qu'à ton profit,
puisque tu te bases sur les vitesses de "ton" équipement.
Etienne
J'ai comme idée que les trucs Json peuvent être parfois assez
lourdingues, peut-être faut-il voir s'il est possible de les alléger?
Par exemple :
<http://www.aspfr.com/codes/OPTIMISATION-SERIALISATION-JSON-LIST_46766.aspx>
J'ai des requêtes AJAX qui retournent quelques kilo de données.
Ha! Oui ! quand même ! ;-)
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.
(j'ai copié-collé et sauvé en texte ce post-ci, il fait 1088 oct, zippé, il fait 1133 oct ... en gz ... pas essayé)
Et surtout si cela avait un impact...
Le seul impact est de bien penser ses requêtes et l'optimisation des données à la Json. (à mon idée, et vu de ma chaise)
Firefox m'indique que le temps de réception de mes données est de l'ordre de 250 à 300 ms,
Je me demande bien sur quoi il se base ? Que sait-il de la qualité de "ma" connexion ?
ce qui n'est pas énorme mais bon s'il y avait moyen de diviser par deux, pourquoi ne pas le faire.
Si je comprends bien c'est une appli qui n'est qu'à ton profit, puisque tu te bases sur les vitesses de "ton" équipement.
Etienne
J'ai comme idée que les trucs Json peuvent être parfois assez lourdingues, peut-être faut-il voir s'il est possible de les alléger? Par exemple : <http://www.aspfr.com/codes/OPTIMISATION-SERIALISATION-JSON-LIST_46766.aspx>
-- Stéphane Moriaux avec/with iMac-intel
SAM
Le 09/10/10 00:36, Paul Gaborit a écrit :
À (at) Fri, 08 Oct 2010 23:49:08 +0200, WebShaker écrivait (wrote):
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.
Il suffit de demander au serveur de compresser les données. Pour Apache, c'est mod_deflate qui permet de le faire. Un navigateur bien élevé doit savoir décompresser cela tout seul de manière transparente (pas besoin de décomrpesser en Javascript).
Je ne sais si les navigateurs dégzippent les codes JavaScript ...
Et ... on a parlé d'Ajax ... théoriquement c'est le JavaScript qui est en fonctionnement, et il attend du texte (de code JS ?) en clair, j'imagine.
De toutes façons, pour "quelques" ko ... on ne va rien gagner. Ça ne peut fonctionner bien que pour des listes ou tables *à rallonge* (la compression agissant surtout sur les redondances)
en dessous de 50ko gzip, le temps de calcul du décompactage sera supérieur au gain de temps du transfert de, disons 65 ko brut (sauf, peut-être, en RTC ?)
-- Stéphane Moriaux avec/with iMac-intel
Le 09/10/10 00:36, Paul Gaborit a écrit :
À (at) Fri, 08 Oct 2010 23:49:08 +0200,
WebShaker<etienne@tlk.fr> écrivait (wrote):
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.
Il suffit de demander au serveur de compresser les données. Pour Apache,
c'est mod_deflate qui permet de le faire. Un navigateur bien élevé doit
savoir décompresser cela tout seul de manière transparente (pas besoin
de décomrpesser en Javascript).
Je ne sais si les navigateurs dégzippent les codes JavaScript ...
Et ... on a parlé d'Ajax ... théoriquement c'est le JavaScript qui est
en fonctionnement, et il attend du texte (de code JS ?) en clair, j'imagine.
De toutes façons, pour "quelques" ko ... on ne va rien gagner.
Ça ne peut fonctionner bien que pour des listes ou tables *à rallonge*
(la compression agissant surtout sur les redondances)
en dessous de 50ko gzip, le temps de calcul du décompactage sera
supérieur au gain de temps du transfert de, disons 65 ko brut
(sauf, peut-être, en RTC ?)
À (at) Fri, 08 Oct 2010 23:49:08 +0200, WebShaker écrivait (wrote):
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.
Il suffit de demander au serveur de compresser les données. Pour Apache, c'est mod_deflate qui permet de le faire. Un navigateur bien élevé doit savoir décompresser cela tout seul de manière transparente (pas besoin de décomrpesser en Javascript).
Je ne sais si les navigateurs dégzippent les codes JavaScript ...
Et ... on a parlé d'Ajax ... théoriquement c'est le JavaScript qui est en fonctionnement, et il attend du texte (de code JS ?) en clair, j'imagine.
De toutes façons, pour "quelques" ko ... on ne va rien gagner. Ça ne peut fonctionner bien que pour des listes ou tables *à rallonge* (la compression agissant surtout sur les redondances)
en dessous de 50ko gzip, le temps de calcul du décompactage sera supérieur au gain de temps du transfert de, disons 65 ko brut (sauf, peut-être, en RTC ?)
-- Stéphane Moriaux avec/with iMac-intel
Paul Gaborit
À (at) Sat, 09 Oct 2010 00:56:23 +0200, SAM écrivait (wrote):
Le 08/10/10 23:49, WebShaker a écrit :
Firefox m'indique que le temps de réception de mes données est de l'ordre de 250 à 300 ms,
Je me demande bien sur quoi il se base ? Que sait-il de la qualité de "ma" connexion ?
Il n'en sait rien ! ;-)
Firefox (via Firebug, j'imagine) ne fait que mesurer le temps entre le début de l'envoi de la requête et la fin de la réception de la réponse. La vrai question est : où ce temps est-il consommé ? Il y a le transfert de la requête, le traitement et le transfert de la réponse. Un temps de 250 à 300 ms n'est certainement pas pris par le transfert de quelques kilo-octets de données (surtout si c'est un test local). À mon avis, c'est plutôt le temps de traitement qui est en cause. Si c'est un CGI qui répond, l'utilisation de FastCGI est un moyen facile d'améliorer les choses.
J'ai comme idée que les trucs Json peuvent être parfois assez lourdingues, peut-être faut-il voir s'il est possible de les alléger? Par exemple : <http://www.aspfr.com/codes/OPTIMISATION-SERIALISATION-JSON-LIST_46766.aspx>
L'article cité ci-dessus est un exemple typique de mauvaise réponse à un vrai problème. Une simple compression des données (traitée directement par le serveur et par la navigateur) réalise une bien meilleure optimisation de la taille des données transférées sans avoir à écrire la moindre ligne de code (puisque ces fonctions de compression sont déjà écrites, débuguées et optimisées depuis longtemps) et avec l'avantage de savoir traiter n'importe quelle structure de données...
-- Paul Gaborit - <http://perso.mines-albi.fr/~gaborit/>
À (at) Sat, 09 Oct 2010 00:56:23 +0200,
SAM <stephanemoriaux.NoAdmin@wanadoo.fr.invalid> écrivait (wrote):
Le 08/10/10 23:49, WebShaker a écrit :
Firefox m'indique que le temps de réception de mes données est de
l'ordre de 250 à 300 ms,
Je me demande bien sur quoi il se base ?
Que sait-il de la qualité de "ma" connexion ?
Il n'en sait rien ! ;-)
Firefox (via Firebug, j'imagine) ne fait que mesurer le temps entre le
début de l'envoi de la requête et la fin de la réception de la
réponse. La vrai question est : où ce temps est-il consommé ? Il y a le
transfert de la requête, le traitement et le transfert de la réponse. Un
temps de 250 à 300 ms n'est certainement pas pris par le transfert de
quelques kilo-octets de données (surtout si c'est un test local). À mon
avis, c'est plutôt le temps de traitement qui est en cause. Si c'est un
CGI qui répond, l'utilisation de FastCGI est un moyen facile d'améliorer
les choses.
J'ai comme idée que les trucs Json peuvent être parfois assez
lourdingues, peut-être faut-il voir s'il est possible de les alléger?
Par exemple :
<http://www.aspfr.com/codes/OPTIMISATION-SERIALISATION-JSON-LIST_46766.aspx>
L'article cité ci-dessus est un exemple typique de mauvaise réponse à un
vrai problème. Une simple compression des données (traitée directement
par le serveur et par la navigateur) réalise une bien meilleure
optimisation de la taille des données transférées sans avoir à écrire la
moindre ligne de code (puisque ces fonctions de compression sont déjà
écrites, débuguées et optimisées depuis longtemps) et avec l'avantage de
savoir traiter n'importe quelle structure de données...
--
Paul Gaborit - <http://perso.mines-albi.fr/~gaborit/>
À (at) Sat, 09 Oct 2010 00:56:23 +0200, SAM écrivait (wrote):
Le 08/10/10 23:49, WebShaker a écrit :
Firefox m'indique que le temps de réception de mes données est de l'ordre de 250 à 300 ms,
Je me demande bien sur quoi il se base ? Que sait-il de la qualité de "ma" connexion ?
Il n'en sait rien ! ;-)
Firefox (via Firebug, j'imagine) ne fait que mesurer le temps entre le début de l'envoi de la requête et la fin de la réception de la réponse. La vrai question est : où ce temps est-il consommé ? Il y a le transfert de la requête, le traitement et le transfert de la réponse. Un temps de 250 à 300 ms n'est certainement pas pris par le transfert de quelques kilo-octets de données (surtout si c'est un test local). À mon avis, c'est plutôt le temps de traitement qui est en cause. Si c'est un CGI qui répond, l'utilisation de FastCGI est un moyen facile d'améliorer les choses.
J'ai comme idée que les trucs Json peuvent être parfois assez lourdingues, peut-être faut-il voir s'il est possible de les alléger? Par exemple : <http://www.aspfr.com/codes/OPTIMISATION-SERIALISATION-JSON-LIST_46766.aspx>
L'article cité ci-dessus est un exemple typique de mauvaise réponse à un vrai problème. Une simple compression des données (traitée directement par le serveur et par la navigateur) réalise une bien meilleure optimisation de la taille des données transférées sans avoir à écrire la moindre ligne de code (puisque ces fonctions de compression sont déjà écrites, débuguées et optimisées depuis longtemps) et avec l'avantage de savoir traiter n'importe quelle structure de données...
-- Paul Gaborit - <http://perso.mines-albi.fr/~gaborit/>
Paul Gaborit
À (at) Sat, 09 Oct 2010 01:58:19 +0200, SAM écrivait (wrote):
Je ne sais si les navigateurs dégzippent les codes JavaScript ...
Et ... on a parlé d'Ajax ... théoriquement c'est le JavaScript qui est en fonctionnement, et il attend du texte (de code JS ?) en clair, j'imagine.
Mais du text/json c'est exactement la même chose que du text/html, du text/css ou du text/xml. A priori, on attend du texte clair. Mais rien n'empêche de le compresser puisqu'il sera décompresser avant d'être fourni au code javascript. Le seul cas qui pourrait poser problème serait MSIE 6 qui est, semble-t-il, assez chatouilleux sur ce qu'on a le droit de compresser ou non... À tester !
-- Paul Gaborit - <http://perso.mines-albi.fr/~gaborit/>
À (at) Sat, 09 Oct 2010 01:58:19 +0200,
SAM <stephanemoriaux.NoAdmin@wanadoo.fr.invalid> écrivait (wrote):
Je ne sais si les navigateurs dégzippent les codes JavaScript ...
Et ... on a parlé d'Ajax ... théoriquement c'est le JavaScript qui est
en fonctionnement, et il attend du texte (de code JS ?) en clair,
j'imagine.
Mais du text/json c'est exactement la même chose que du text/html, du
text/css ou du text/xml. A priori, on attend du texte clair. Mais rien
n'empêche de le compresser puisqu'il sera décompresser avant d'être
fourni au code javascript. Le seul cas qui pourrait poser problème
serait MSIE 6 qui est, semble-t-il, assez chatouilleux sur ce qu'on a le
droit de compresser ou non... À tester !
--
Paul Gaborit - <http://perso.mines-albi.fr/~gaborit/>
À (at) Sat, 09 Oct 2010 01:58:19 +0200, SAM écrivait (wrote):
Je ne sais si les navigateurs dégzippent les codes JavaScript ...
Et ... on a parlé d'Ajax ... théoriquement c'est le JavaScript qui est en fonctionnement, et il attend du texte (de code JS ?) en clair, j'imagine.
Mais du text/json c'est exactement la même chose que du text/html, du text/css ou du text/xml. A priori, on attend du texte clair. Mais rien n'empêche de le compresser puisqu'il sera décompresser avant d'être fourni au code javascript. Le seul cas qui pourrait poser problème serait MSIE 6 qui est, semble-t-il, assez chatouilleux sur ce qu'on a le droit de compresser ou non... À tester !
-- Paul Gaborit - <http://perso.mines-albi.fr/~gaborit/>
Guy Ratajczak
Le 09/10/2010 00:56, SAM a écrit :
Le 08/10/10 23:49, WebShaker a écrit :
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.
(j'ai copié-collé et sauvé en texte ce post-ci, il fait 1088 oct, zippé, il fait 1133 oct ... en gz ... pas essayé)
Le post d'origine avec en-tête fait 1299 octets. Voici le résultat de son transfert en HTTP gzipped :
De 1299 à 833 ça fait un bon ratio. Et comme le disait Paul, c'est le serveur qui fait le boulot. Pas besoin d'implémenter soit même une compression avec tous les problèmes que cela peut poser.
Et surtout si cela avait un impact...
Le seul impact est de bien penser ses requêtes et l'optimisation des données à la Json. (à mon idée, et vu de ma chaise)
L'idée est là : - d'abord bien penser ses requêtes et les données à renvoyer ; - ensuite optimiser, notamment avec la compression.
J'ai comme idée que les trucs Json peuvent être parfois assez lourdingues, peut-être faut-il voir s'il est possible de les alléger?
C'est la première partie de l'optimisation : être sûr de n'envoyer que des données nécessaires.
Bonne journée, -- Guy
Le 09/10/2010 00:56, SAM a écrit :
Le 08/10/10 23:49, WebShaker a écrit :
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.
(j'ai copié-collé et sauvé en texte ce post-ci, il fait 1088 oct,
zippé, il fait 1133 oct ... en gz ... pas essayé)
Le post d'origine avec en-tête fait 1299 octets. Voici le résultat de
son transfert en HTTP gzipped :
De 1299 à 833 ça fait un bon ratio.
Et comme le disait Paul, c'est le serveur qui fait le boulot. Pas besoin
d'implémenter soit même une compression avec tous les problèmes que cela
peut poser.
Et surtout si cela avait un impact...
Le seul impact est de bien penser ses requêtes et l'optimisation des
données à la Json.
(à mon idée, et vu de ma chaise)
L'idée est là :
- d'abord bien penser ses requêtes et les données à renvoyer ;
- ensuite optimiser, notamment avec la compression.
J'ai comme idée que les trucs Json peuvent être parfois assez
lourdingues, peut-être faut-il voir s'il est possible de les alléger?
C'est la première partie de l'optimisation : être sûr de n'envoyer que
des données nécessaires.
De 1299 à 833 ça fait un bon ratio. Et comme le disait Paul, c'est le serveur qui fait le boulot. Pas besoin d'implémenter soit même une compression avec tous les problèmes que cela peut poser.
Et surtout si cela avait un impact...
Le seul impact est de bien penser ses requêtes et l'optimisation des données à la Json. (à mon idée, et vu de ma chaise)
L'idée est là : - d'abord bien penser ses requêtes et les données à renvoyer ; - ensuite optimiser, notamment avec la compression.
J'ai comme idée que les trucs Json peuvent être parfois assez lourdingues, peut-être faut-il voir s'il est possible de les alléger?
C'est la première partie de l'optimisation : être sûr de n'envoyer que des données nécessaires.
Bonne journée, -- Guy
WebShaker
Le 09/10/2010 00:36, Paul Gaborit a écrit :
Il suffit de demander au serveur de compresser les données. Pour Apache, c'est mod_deflate qui permet de le faire. Un navigateur bien élevé doit savoir décompresser cela tout seul de manière transparente (pas besoin de décomrpesser en Javascript).
En effet, je n'y avait pas pensé. je vais tester. Etienne
Le 09/10/2010 00:36, Paul Gaborit a écrit :
Il suffit de demander au serveur de compresser les données. Pour Apache,
c'est mod_deflate qui permet de le faire. Un navigateur bien élevé doit
savoir décompresser cela tout seul de manière transparente (pas besoin
de décomrpesser en Javascript).
En effet, je n'y avait pas pensé. je vais tester.
Etienne
Il suffit de demander au serveur de compresser les données. Pour Apache, c'est mod_deflate qui permet de le faire. Un navigateur bien élevé doit savoir décompresser cela tout seul de manière transparente (pas besoin de décomrpesser en Javascript).
En effet, je n'y avait pas pensé. je vais tester. Etienne
SAM
Le 09/10/10 10:10, WebShaker a écrit :
Le 09/10/2010 00:36, Paul Gaborit a écrit :
Il suffit de demander au serveur de compresser les données. Pour Apache, c'est mod_deflate qui permet de le faire. Un navigateur bien élevé doit savoir décompresser cela tout seul de manière transparente (pas besoin de décomrpesser en Javascript).
En effet, je n'y avait pas pensé. je vais tester. Etienne
Je suis très intéressé car ... je n'imaginais pas qu'un navigateur pouvait décompresser à la volée un "responseText"
-- Stéphane Moriaux avec/with iMac-intel
Le 09/10/10 10:10, WebShaker a écrit :
Le 09/10/2010 00:36, Paul Gaborit a écrit :
Il suffit de demander au serveur de compresser les données. Pour Apache,
c'est mod_deflate qui permet de le faire. Un navigateur bien élevé doit
savoir décompresser cela tout seul de manière transparente (pas besoin
de décomrpesser en Javascript).
En effet, je n'y avait pas pensé. je vais tester.
Etienne
Je suis très intéressé car ...
je n'imaginais pas qu'un navigateur pouvait décompresser à la volée
un "responseText"
Il suffit de demander au serveur de compresser les données. Pour Apache, c'est mod_deflate qui permet de le faire. Un navigateur bien élevé doit savoir décompresser cela tout seul de manière transparente (pas besoin de décomrpesser en Javascript).
En effet, je n'y avait pas pensé. je vais tester. Etienne
Je suis très intéressé car ... je n'imaginais pas qu'un navigateur pouvait décompresser à la volée un "responseText"
-- Stéphane Moriaux avec/with iMac-intel
Etienne
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
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.
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
Etienne
Le 11/10/2010 13:52, Etienne a écrit :
Difficile de quantifier exactement.
Bon j'étais un peu frustré du ne pas pouvoir bencher plus précisement le gain obtenu. J'ai donc écrit un petit script qui me permet de mieux quantifier tout ca et qui consiste a éxécuter 50 fois la requête ajax et réaliser une moyenne.
Donc les données retournées par ma requête font 59ko (je transferts 250 "entêtes" de mails dans un client mail) J'utilise un Xeon 3Ghz (ce qui je suppose doit avoir un impact important sur le temps de compression).
Sans compression Moyenne de temps Connexion : 31 ms Moyenne de temps d'excution : 109 ms Moyenne du temps de transfert : 230 ms ----- Moyenne du temps complet : 370 ms
Avec compression Moyenne de temps Connexion : 31 ms Moyenne de temps d'excution : 125 ms Moyenne du temps de transfert : 30 ms ----- Moyenne du temps complet : 186 ms
Donc c'est tout pile deux fois plus rapide. ce qui est quand même très bien.
Etienne
Le 11/10/2010 13:52, Etienne a écrit :
Difficile de quantifier exactement.
Bon j'étais un peu frustré du ne pas pouvoir bencher plus précisement le
gain obtenu.
J'ai donc écrit un petit script qui me permet de mieux quantifier tout
ca et qui consiste a éxécuter 50 fois la requête ajax et réaliser une
moyenne.
Donc les données retournées par ma requête font 59ko (je transferts 250
"entêtes" de mails dans un client mail)
J'utilise un Xeon 3Ghz (ce qui je suppose doit avoir un impact important
sur le temps de compression).
Sans compression
Moyenne de temps Connexion : 31 ms
Moyenne de temps d'excution : 109 ms
Moyenne du temps de transfert : 230 ms
-----
Moyenne du temps complet : 370 ms
Avec compression
Moyenne de temps Connexion : 31 ms
Moyenne de temps d'excution : 125 ms
Moyenne du temps de transfert : 30 ms
-----
Moyenne du temps complet : 186 ms
Donc c'est tout pile deux fois plus rapide.
ce qui est quand même très bien.
Bon j'étais un peu frustré du ne pas pouvoir bencher plus précisement le gain obtenu. J'ai donc écrit un petit script qui me permet de mieux quantifier tout ca et qui consiste a éxécuter 50 fois la requête ajax et réaliser une moyenne.
Donc les données retournées par ma requête font 59ko (je transferts 250 "entêtes" de mails dans un client mail) J'utilise un Xeon 3Ghz (ce qui je suppose doit avoir un impact important sur le temps de compression).
Sans compression Moyenne de temps Connexion : 31 ms Moyenne de temps d'excution : 109 ms Moyenne du temps de transfert : 230 ms ----- Moyenne du temps complet : 370 ms
Avec compression Moyenne de temps Connexion : 31 ms Moyenne de temps d'excution : 125 ms Moyenne du temps de transfert : 30 ms ----- Moyenne du temps complet : 186 ms
Donc c'est tout pile deux fois plus rapide. ce qui est quand même très bien.
