PHP: optimiser la génération de pages très dynamiques
28 réponses
Patrick 'Zener' Brunet
Bonjour.
J'aimerais avoir quelques retours d'expérience sur l'optimisation des pages
fortement dynamiques en PHP.
Je cherche toujours pourquoi mon site (www.ipzb.fr) est si lent à charger,
même pour les pages les plus légères.
Pour l'histoire:
- il n'y a pas de requête SQL ni de connexion à des serveurs tiers,
- le sessionning existe pour toutes les pages (gestion d'un contexte
visiteur) mais il est fait avec un système de mini-fichiers très optimisé,
- l'URL rewriting est innocent, j'avais essayé de le désactiver sans
amélioration.
Le site est hébergé par 1and1. Ils ont une réputation de lenteur, mais à ce
point c'est déprimant.
L'extension de Firefox nommée LoadTimeAnalyser montre que, même pour une
page de base et en pleine session, on passe son temps à attendre le serveur,
le transfert des données étant lui presque instantané.
Voyez ce chronogramme (HTML pur):
http://cjoint.com/?lssEIBsuuz
La caractéristique de ce site est que les pages contiennent une forte
proportion d'éléments insérés par du PHP.
Donc il y a des <?php echo GetMachin(); ?> en assez grand nombre au milieu
du HTML.
Par contre les fonctions GetMachin() utilisent au maximum des éléments
précalculés, et à défaut ne font que des opérations très simples
(arithmétique, concaténation de petites chaînes...). Beaucoup ne font même
rien du tout et rendent une chaîne vide avec les options de base du site.
Il y a un bruit qui court selon lequel la primitive echo aurait un bug sur
certains moteurs PHP, dont celui utilisé par 1and1 (j'ai lu ça sur un forum,
invérifiable).
De toute manière, je vois mal comment optimiser davantage: le truc qui
consiste à insérer des fichiers HTML plutôt que de faire du echo ne
s'applique qu'à des tronçons un peu gros, pas à des chaînes de 20
caractères. Et pour les gros tronçons je pratique déjà.
Et PHP en principe c'est fait pour ça,
J'ai même des doutes sur la part du temps de calcul: certains temps
d'attente de plus d'une seconde correspondent à des éléments qui ne sont pas
générés (simple readfile avec 3 headers devant)...
Par exemple les images à la fin du chronogramme, dont le
mArrowR.gif par exemple: 1,2s pour 265 octets :o)
J'aimerais bien trouver un moyen d'avoir un chronogramme complet, montrant
tout le timing de requête+génération de la page avec tous ses éléments au
niveau du serveur... Vous avez une idée sur la méthode ?
Savez-vous aussi comment ça se passe au niveau des fichiers susceptibles
d'être inclus en read-only dans chaque requête HTTP (un mini script PHP de
définitions par exemple) - c'est mis en cache ou il y a risque de bottleneck
?
Merci de vos conseils (dans la mesure ou ce n'est pas "fais du HTML de
base", je sais faire aussi mais c'est hors-sujet ;-).
--
Cordialement.
--
/**************************************************\
* Patrick BRUNET
* E-mail: lien sur http://zener131.free.fr/ContactMe
\**************************************************/
Le Sun, 18 Nov 2007 19:20:41 +0100, "Patrick 'Zener' Brunet" écrivait dans fr.comp.infosystemes.www.auteurs:
Merci de vos conseils (dans la mesure ou ce n'est pas "fais du HTML de base", je sais faire aussi mais c'est hors-sujet ;-).
Mais si tu recodais une page en HTML, tu pourrais voir si c'est vraiment le PHP qui est lent ou autre chose, ce qui te ferait gagner beaucoup de temps si c'est autre chose...
Denis
Le Sun, 18 Nov 2007 19:20:41 +0100, "Patrick 'Zener' Brunet"
<use.link.in.signature@ddress.invalid> écrivait dans
fr.comp.infosystemes.www.auteurs:
Merci de vos conseils (dans la mesure ou ce n'est pas "fais du HTML de
base", je sais faire aussi mais c'est hors-sujet ;-).
Mais si tu recodais une page en HTML, tu pourrais voir si c'est
vraiment le PHP qui est lent ou autre chose, ce qui te ferait
gagner beaucoup de temps si c'est autre chose...
Le Sun, 18 Nov 2007 19:20:41 +0100, "Patrick 'Zener' Brunet" écrivait dans fr.comp.infosystemes.www.auteurs:
Merci de vos conseils (dans la mesure ou ce n'est pas "fais du HTML de base", je sais faire aussi mais c'est hors-sujet ;-).
Mais si tu recodais une page en HTML, tu pourrais voir si c'est vraiment le PHP qui est lent ou autre chose, ce qui te ferait gagner beaucoup de temps si c'est autre chose...
Denis
Antoine
Pour confirmer/infirmer le rôle de l'hébergeur dans cette affaire, tu peux tester ton site chez d'autres hébergeurs php (free.fr par exemple, le newsgroup frih donne fréquemment la liste des hébergeurs gratuits supportant le php).
-- Antoine
Pour confirmer/infirmer le rôle de l'hébergeur dans cette affaire,
tu peux tester ton site chez d'autres hébergeurs php (free.fr par
exemple, le newsgroup frih donne fréquemment la liste des hébergeurs
gratuits supportant le php).
Pour confirmer/infirmer le rôle de l'hébergeur dans cette affaire, tu peux tester ton site chez d'autres hébergeurs php (free.fr par exemple, le newsgroup frih donne fréquemment la liste des hébergeurs gratuits supportant le php).
-- Antoine
Pierre Goiffon
Patrick 'Zener' Brunet wrote:
L'extension de Firefox nommée LoadTimeAnalyser montre que
Ha tiens je ne connaissais pas cette extension (qui ne nomme plutôt Load Time Analyzer avec un Z :) ) Après un rapide test je n'ai pas l'impression que cette extension ajoute bcp par rapport à la fonctionnalité équivalente dans Firebug (onglet Net) ?
Patrick 'Zener' Brunet wrote:
L'extension de Firefox nommée LoadTimeAnalyser montre que
Ha tiens je ne connaissais pas cette extension (qui ne nomme plutôt Load
Time Analyzer avec un Z :) )
Après un rapide test je n'ai pas l'impression que cette extension ajoute
bcp par rapport à la fonctionnalité équivalente dans Firebug (onglet Net) ?
L'extension de Firefox nommée LoadTimeAnalyser montre que
Ha tiens je ne connaissais pas cette extension (qui ne nomme plutôt Load Time Analyzer avec un Z :) ) Après un rapide test je n'ai pas l'impression que cette extension ajoute bcp par rapport à la fonctionnalité équivalente dans Firebug (onglet Net) ?
SAM
Patrick 'Zener' Brunet a écrit :
Bonjour.
J'aimerais avoir quelques retours d'expérience sur l'optimisation des pages fortement dynamiques en PHP.
Il serait peut-être judicieux de passer sur le NG du PHP ?
- les sessions ont-elles besoin de se référer à *des* fichiers ? (n'y a t'il pas de redondances à ce niveau ?) Le serveur ne gère t-il pas tout seul les sessions ? - le cache PHP du serveur est-il bien mis à profit ? - des cookies sont-ils mis en actions ?
Voyez ce chronogramme (HTML pur): http://cjoint.com/?lssEIBsuuz
Il m'apparait surtout qu'il y a vraiment beaucoup de choses à charger, qu'entre chaque groupe de composants il pourrait il y avoir un code serveur dynamique qui réfléchi
N'y aurait-il pas moyen de grouper les réflexions ? D'en mettre éventuellement le résultat dans un temp ou cooky et se servir de ces tampons pour construire la page à afficher ? Bien que si la routine de départ a été optimisée en cache du serveur, de échoyer par ci par là les variables pré-calculées ne devrait pas freiner
La caractéristique de ce site est que les pages contiennent une forte proportion d'éléments insérés par du PHP. Donc il y a des <?php echo GetMachin(); ?> en assez grand nombre au milieu du HTML.
à mon idée ça ne joue pas si c'est juste écrire des variables (et qu'il n'y a pas à les recalculer)
Par contre les fonctions GetMachin() utilisent au maximum des éléments précalculés,
tout dépend de où il faut que le php court pour aller trouver ou retrouver ces près-calculs, non ?
Il y a un bruit qui court selon lequel la primitive echo aurait un bug sur certains moteurs PHP, dont celui utilisé par 1and1 (j'ai lu ça sur un forum, invérifiable).
<?=$ma_variable ?> fonctionne-ce ? (peut-être + rapide ?) faut voir aussi ce que contient cette variable ?
De toute manière, je vois mal comment optimiser davantage: le truc qui consiste à insérer des fichiers HTML plutôt que de faire du echo ne s'applique qu'à des tronçons un peu gros, pas à des chaînes de 20 caractères. Et pour les gros tronçons je pratique déjà. Et PHP en principe c'est fait pour ça,
tu peux aussi printer l'ensemble de la page (bonjour le boulot !)
Merci de vos conseils (dans la mesure ou ce n'est pas "fais du HTML de base", je sais faire aussi mais c'est hors-sujet ;-).
Je viens de re-essayer - je ne sais ce qu'il y a dans la page d'arrivée qui calcule la config et qui tarde à envoyer la suite - la page d'accueil se charge assez rapidement (j'ai déjà tout dans le cache de mon navigateur) encore que, vu que la page semble ne pas être très garnie ... (quoi que 83ko tt de même) - passé à une autre page, bon oui ça a l'air d'aller sauf que ... curieusement ... après l'affichage global, des trucs continuent à s'immiscer dans les lignes déjà là ...
Il me semble curieux que les appels aux JS et CSS externes soient des php. Ne force-ce pas à : - recalculs systématiques de ces sorties de JS ou CSS - non mise en cache du navigateur de ces sorties ? Ne serait-il pas plus simple d'échoyer directement l'url du fichier à charger ? (puisqu'elle figure en variable de l'url, elle doit sortir de qque part ET a déjà été calculée par ailleurs, ça me semble une redondance et une possibilité de freinage) (est-ce que tout ça n'est-il pas disponible une fois pour toute dans sa session ?)
-- sm
Patrick 'Zener' Brunet a écrit :
Bonjour.
J'aimerais avoir quelques retours d'expérience sur l'optimisation des pages
fortement dynamiques en PHP.
Il serait peut-être judicieux de passer sur le NG du PHP ?
- les sessions ont-elles besoin de se référer à *des* fichiers ?
(n'y a t'il pas de redondances à ce niveau ?)
Le serveur ne gère t-il pas tout seul les sessions ?
- le cache PHP du serveur est-il bien mis à profit ?
- des cookies sont-ils mis en actions ?
Voyez ce chronogramme (HTML pur):
http://cjoint.com/?lssEIBsuuz
Il m'apparait surtout qu'il y a vraiment beaucoup de choses à charger,
qu'entre chaque groupe de composants il pourrait il y avoir un code
serveur dynamique qui réfléchi
N'y aurait-il pas moyen de grouper les réflexions ?
D'en mettre éventuellement le résultat dans un temp ou cooky
et se servir de ces tampons pour construire la page à afficher ?
Bien que si la routine de départ a été optimisée en cache du serveur, de
échoyer par ci par là les variables pré-calculées ne devrait pas freiner
La caractéristique de ce site est que les pages contiennent une forte
proportion d'éléments insérés par du PHP.
Donc il y a des <?php echo GetMachin(); ?> en assez grand nombre au milieu
du HTML.
à mon idée ça ne joue pas si c'est juste écrire des variables (et qu'il
n'y a pas à les recalculer)
Par contre les fonctions GetMachin() utilisent au maximum des éléments
précalculés,
tout dépend de où il faut que le php court pour aller trouver ou
retrouver ces près-calculs, non ?
Il y a un bruit qui court selon lequel la primitive echo aurait un bug sur
certains moteurs PHP, dont celui utilisé par 1and1 (j'ai lu ça sur un forum,
invérifiable).
<?=$ma_variable ?>
fonctionne-ce ? (peut-être + rapide ?)
faut voir aussi ce que contient cette variable ?
De toute manière, je vois mal comment optimiser davantage: le truc qui
consiste à insérer des fichiers HTML plutôt que de faire du echo ne
s'applique qu'à des tronçons un peu gros, pas à des chaînes de 20
caractères. Et pour les gros tronçons je pratique déjà.
Et PHP en principe c'est fait pour ça,
tu peux aussi printer l'ensemble de la page
(bonjour le boulot !)
Merci de vos conseils (dans la mesure ou ce n'est pas "fais du HTML de
base", je sais faire aussi mais c'est hors-sujet ;-).
Je viens de re-essayer
- je ne sais ce qu'il y a dans la page d'arrivée qui calcule la config
et qui tarde à envoyer la suite
- la page d'accueil se charge assez rapidement (j'ai déjà tout dans le
cache de mon navigateur) encore que, vu que la page semble ne pas
être très garnie ... (quoi que 83ko tt de même)
- passé à une autre page, bon oui ça a l'air d'aller
sauf que ... curieusement ... après l'affichage global, des trucs
continuent à s'immiscer dans les lignes déjà là ...
Il me semble curieux que les appels aux JS et CSS externes soient des php.
Ne force-ce pas à :
- recalculs systématiques de ces sorties de JS ou CSS
- non mise en cache du navigateur de ces sorties ?
Ne serait-il pas plus simple d'échoyer directement l'url du fichier à
charger ? (puisqu'elle figure en variable de l'url, elle doit sortir de
qque part ET a déjà été calculée par ailleurs, ça me semble une
redondance et une possibilité de freinage) (est-ce que tout ça n'est-il
pas disponible une fois pour toute dans sa session ?)
J'aimerais avoir quelques retours d'expérience sur l'optimisation des pages fortement dynamiques en PHP.
Il serait peut-être judicieux de passer sur le NG du PHP ?
- les sessions ont-elles besoin de se référer à *des* fichiers ? (n'y a t'il pas de redondances à ce niveau ?) Le serveur ne gère t-il pas tout seul les sessions ? - le cache PHP du serveur est-il bien mis à profit ? - des cookies sont-ils mis en actions ?
Voyez ce chronogramme (HTML pur): http://cjoint.com/?lssEIBsuuz
Il m'apparait surtout qu'il y a vraiment beaucoup de choses à charger, qu'entre chaque groupe de composants il pourrait il y avoir un code serveur dynamique qui réfléchi
N'y aurait-il pas moyen de grouper les réflexions ? D'en mettre éventuellement le résultat dans un temp ou cooky et se servir de ces tampons pour construire la page à afficher ? Bien que si la routine de départ a été optimisée en cache du serveur, de échoyer par ci par là les variables pré-calculées ne devrait pas freiner
La caractéristique de ce site est que les pages contiennent une forte proportion d'éléments insérés par du PHP. Donc il y a des <?php echo GetMachin(); ?> en assez grand nombre au milieu du HTML.
à mon idée ça ne joue pas si c'est juste écrire des variables (et qu'il n'y a pas à les recalculer)
Par contre les fonctions GetMachin() utilisent au maximum des éléments précalculés,
tout dépend de où il faut que le php court pour aller trouver ou retrouver ces près-calculs, non ?
Il y a un bruit qui court selon lequel la primitive echo aurait un bug sur certains moteurs PHP, dont celui utilisé par 1and1 (j'ai lu ça sur un forum, invérifiable).
<?=$ma_variable ?> fonctionne-ce ? (peut-être + rapide ?) faut voir aussi ce que contient cette variable ?
De toute manière, je vois mal comment optimiser davantage: le truc qui consiste à insérer des fichiers HTML plutôt que de faire du echo ne s'applique qu'à des tronçons un peu gros, pas à des chaînes de 20 caractères. Et pour les gros tronçons je pratique déjà. Et PHP en principe c'est fait pour ça,
tu peux aussi printer l'ensemble de la page (bonjour le boulot !)
Merci de vos conseils (dans la mesure ou ce n'est pas "fais du HTML de base", je sais faire aussi mais c'est hors-sujet ;-).
Je viens de re-essayer - je ne sais ce qu'il y a dans la page d'arrivée qui calcule la config et qui tarde à envoyer la suite - la page d'accueil se charge assez rapidement (j'ai déjà tout dans le cache de mon navigateur) encore que, vu que la page semble ne pas être très garnie ... (quoi que 83ko tt de même) - passé à une autre page, bon oui ça a l'air d'aller sauf que ... curieusement ... après l'affichage global, des trucs continuent à s'immiscer dans les lignes déjà là ...
Il me semble curieux que les appels aux JS et CSS externes soient des php. Ne force-ce pas à : - recalculs systématiques de ces sorties de JS ou CSS - non mise en cache du navigateur de ces sorties ? Ne serait-il pas plus simple d'échoyer directement l'url du fichier à charger ? (puisqu'elle figure en variable de l'url, elle doit sortir de qque part ET a déjà été calculée par ailleurs, ça me semble une redondance et une possibilité de freinage) (est-ce que tout ça n'est-il pas disponible une fois pour toute dans sa session ?)
-- sm
kurtz le pirate
In article <fhpvq0$fuf$, "Patrick 'Zener' Brunet" wrote:
J'aimerais avoir quelques retours d'expérience sur l'optimisation des pages fortement dynamiques en PHP.
ça veut dire quoi *fortement* dynamique ?
Je cherche toujours pourquoi mon site (www.ipzb.fr) est si lent à charger, même pour les pages les plus légères.
ben, un regard rapidement montre que presque tout les appels à des images, style, script,... passent par une requête php.
de plus du javascript qui lance toutes les 15mn le PingSession.
et un autre truc qui me chagrine : je ne sais pas comment les navigateurs peuvent interpréter les feuilles de style alors que celles ci ne sont pas entièrement chargées puisque requête php... et qui contiennent aussi des requêtes à l'intérieur : background-image: URL('/getdata.php?type=cssimage&nameÞfault/Images/RedPin.gif');
bref, me semble bien compliqué pour le résultat obtenu.
-- klp
In article <fhpvq0$fuf$1@shakotay.alphanet.ch>,
"Patrick 'Zener' Brunet" <use.link.in.signature@ddress.invalid> wrote:
J'aimerais avoir quelques retours d'expérience sur l'optimisation des pages
fortement dynamiques en PHP.
ça veut dire quoi *fortement* dynamique ?
Je cherche toujours pourquoi mon site (www.ipzb.fr) est si lent à charger,
même pour les pages les plus légères.
ben, un regard rapidement montre que presque tout les appels à des
images, style, script,... passent par une requête php.
de plus du javascript qui lance toutes les 15mn le PingSession.
et un autre truc qui me chagrine : je ne sais pas comment les
navigateurs peuvent interpréter les feuilles de style alors que celles
ci ne sont pas entièrement chargées puisque requête php... et qui
contiennent aussi des requêtes à l'intérieur :
background-image:
URL('/getdata.php?type=cssimage&nameÞfault/Images/RedPin.gif');
bref, me semble bien compliqué pour le résultat obtenu.
In article <fhpvq0$fuf$, "Patrick 'Zener' Brunet" wrote:
J'aimerais avoir quelques retours d'expérience sur l'optimisation des pages fortement dynamiques en PHP.
ça veut dire quoi *fortement* dynamique ?
Je cherche toujours pourquoi mon site (www.ipzb.fr) est si lent à charger, même pour les pages les plus légères.
ben, un regard rapidement montre que presque tout les appels à des images, style, script,... passent par une requête php.
de plus du javascript qui lance toutes les 15mn le PingSession.
et un autre truc qui me chagrine : je ne sais pas comment les navigateurs peuvent interpréter les feuilles de style alors que celles ci ne sont pas entièrement chargées puisque requête php... et qui contiennent aussi des requêtes à l'intérieur : background-image: URL('/getdata.php?type=cssimage&nameÞfault/Images/RedPin.gif');
bref, me semble bien compliqué pour le résultat obtenu.
-- klp
Olivier Miakinen
Le 19/11/2007 16:40, kurtz le pirate a écrit :
et un autre truc qui me chagrine : je ne sais pas comment les navigateurs peuvent interpréter les feuilles de style alors que celles ci ne sont pas entièrement chargées puisque requête php... et qui contiennent aussi des requêtes à l'intérieur : background-image: URL('/getdata.php?type=cssimage&nameÞfault/Images/RedPin.gif');
La réponse à ta question, c'est que le navigateur attendra la fin du chargement de la feuille de style avant de l'utiliser, bien sûr. Mais si tout ceci n'est pas mis en cache, alors cela veut dire qu'à chaque fois il y aura jusqu'à trois exécutions *simultanées* de PHP, une pour le code HTML, une pour la feuille de style, et une pour l'image de fond.
Patrick, j'espère que tu gères convenablement les paramètres de cache dans chacun de tes scripts PHP. Ou plus exactement j'espère pour toi que c'est ça que tu as oublié de faire, et que rajouter le code kivabien corrigera du même coup tes problèmes de lenteur.
bref, me semble bien compliqué pour le résultat obtenu.
[OUI]
L'image de fond, par exemple, aurait intérêt à être statique : ainsi tu laisses Apache s'occuper des paramètres de cache, chose qu'il fait très bien tout seul.
Le 19/11/2007 16:40, kurtz le pirate a écrit :
et un autre truc qui me chagrine : je ne sais pas comment les
navigateurs peuvent interpréter les feuilles de style alors que celles
ci ne sont pas entièrement chargées puisque requête php... et qui
contiennent aussi des requêtes à l'intérieur :
background-image:
URL('/getdata.php?type=cssimage&nameÞfault/Images/RedPin.gif');
La réponse à ta question, c'est que le navigateur attendra la fin du
chargement de la feuille de style avant de l'utiliser, bien sûr. Mais
si tout ceci n'est pas mis en cache, alors cela veut dire qu'à chaque
fois il y aura jusqu'à trois exécutions *simultanées* de PHP, une pour
le code HTML, une pour la feuille de style, et une pour l'image de fond.
Patrick, j'espère que tu gères convenablement les paramètres de cache
dans chacun de tes scripts PHP. Ou plus exactement j'espère pour toi que
c'est ça que tu as oublié de faire, et que rajouter le code kivabien
corrigera du même coup tes problèmes de lenteur.
bref, me semble bien compliqué pour le résultat obtenu.
[OUI]
L'image de fond, par exemple, aurait intérêt à être statique : ainsi tu
laisses Apache s'occuper des paramètres de cache, chose qu'il fait très
bien tout seul.
et un autre truc qui me chagrine : je ne sais pas comment les navigateurs peuvent interpréter les feuilles de style alors que celles ci ne sont pas entièrement chargées puisque requête php... et qui contiennent aussi des requêtes à l'intérieur : background-image: URL('/getdata.php?type=cssimage&nameÞfault/Images/RedPin.gif');
La réponse à ta question, c'est que le navigateur attendra la fin du chargement de la feuille de style avant de l'utiliser, bien sûr. Mais si tout ceci n'est pas mis en cache, alors cela veut dire qu'à chaque fois il y aura jusqu'à trois exécutions *simultanées* de PHP, une pour le code HTML, une pour la feuille de style, et une pour l'image de fond.
Patrick, j'espère que tu gères convenablement les paramètres de cache dans chacun de tes scripts PHP. Ou plus exactement j'espère pour toi que c'est ça que tu as oublié de faire, et que rajouter le code kivabien corrigera du même coup tes problèmes de lenteur.
bref, me semble bien compliqué pour le résultat obtenu.
[OUI]
L'image de fond, par exemple, aurait intérêt à être statique : ainsi tu laisses Apache s'occuper des paramètres de cache, chose qu'il fait très bien tout seul.
Patrick 'Zener' Brunet
Bonsoir.
J'ai pu faire des mesures...
"Patrick 'Zener' Brunet" a écrit dans le message de news: fhpvq0$fuf$
J'aimerais avoir quelques retours d'expérience sur l'optimisation des pages fortement dynamiques en PHP.
Je cherche toujours pourquoi mon site (www.ipzb.fr) est si lent à charger, même pour les pages les plus légères. [...]
L'extension de Firefox nommée LoadTimeAnalyser montre que, même pour une page de base et en pleine session, on passe son temps à attendre le serveur, le transfert des données étant lui presque instantané. Voyez ce chronogramme (HTML pur): http://cjoint.com/?lssEIBsuuz
La caractéristique de ce site est que les pages contiennent une forte proportion d'éléments insérés par du PHP. Donc il y a des <?php echo GetMachin(); ?> en assez grand nombre au milieu du HTML.
Donc hier soir j'ai outillé le code PHP de tous les générateurs (à partir d'une fonction microtime) afin de (temporairement) insérer le timing complet de la génération dans un commentaire à la fin de tous les composants textuels (pages, CSS, Javascripts). Avec IE on peut facilement tout retrouver dans le cache.
Ben voilà ce que ça donne pour la page de garde Home (une fois la première détection faite, donc en rechargeant la page après avoir vidé le cache en conservant le cookie):
Ca c'est le texte de la page:
</html> <!-- Build timing: time = 0.912621 / Start get time = 0.912799 / Require PHP scripts time = 0.917121 / Get URL data time = 0.917173 / Start EnsureSession time = 0.918549 / ES / Start CSession time = 0.929135 / ES / Build Session time = 0.930268 / ES / Get cookie time = 0.93038 / ES / Open Session 1 time = 0.936492 / ES / Start NotLite time = 0.936547 / ES / End of NotLite time = 0.936596 / Url / Language time = 0.936636 / Url / Target time = 0.936698 / Url / All computed time = 0.939901 / End of Require PHP scripts time = 0.939947 / Get / Test languages time = 0.940356 / Get / Update Cookie time = 0.940384 / Get / Save Session time = 0.941046 / Get / Check access time = 0.941204 / Get / Include page time = 0.987784 / Get completed -->
Ca c'est le premier élément appelé, MainLinker.js:
/* <!-- Build timing: time = 1.409722 / Start getdata time = 1.410103 / Get URL data time = 1.410255 / Include JS script time = 1.410774 / getdata completed --> */
Ca c'est le dernier Javascript:
/* <!-- Build timing: time = 1.707 / Start getdata time = 1.707358 / Get URL data time = 1.707501 / Include JS script time = 1.708071 / getdata completed --> */
Et ça c'est la CSS principale:
/* <!-- Build timing: time = 2.00429 / Start getlite time = 2.004621 / Get URL data time = 2.004706 / Check CSS script time = 2.004783 / Include CSS script time = 2.005835 / AStSh / Get URL data time = 2.005876 / AStSh / Require scripts time = 2.008578 / ES / Start CSession time = 2.018955 / ES / Build Session time = 2.020477 / ES / Get cookie time = 2.020587 / ES / Open Session 1 time = 2.02215 / AStSh / Start building time = 2.037601 / getlite completed --> */
Donc environ 1,15s pour générer tout ce qui est textuel, et qui est normalement envoyé en temps réel au navigateur.
Plus précisément, la page prend 0,08s à être générée, et la requête pour le premier composant est reçue 0,5s plus tard.
Ensuite viennent les images qui sont simplement injectées après des headers par readfile...
Le temps total de téléchargement aujourd'hui était de 6,2s pour cette page.
Si on regarde le chronogramme (http://cjoint.com/?lssEIBsuuz, c'est le même), ça confirme que la génération en PHP a un coût totalement marginal, et on voit aussi que le délai de connexion est assez faible.
Je ne vois que deux anomalies: - cette mise en attente systématique après connexion, - le fait que les images ont l'air de se bousculer, dès que les CSS ont été envoyées, tout se met alors à démarrer en parallèle mais les transferts effectifs restent séquentiels... Pourquoi ?
La seule différence, c'est que les images utilisent le script getdata.php qui n'accède pas à la session, contrairement au get.php et au getlite.php, mais cet accès ne coûte que 1ms...
Bref c'est très gonflant, et la dernière fois que je leur ai soumis le problème, les gens du support de 1&1 ont répondu "qu'après s'être concertés, ça ne venait pas de chez eux" :-(
Vous connaissez un bon apachéologue ?
Merci de votre soutien :-)
-- Cordialement. -- /************************************************** * Patrick BRUNET * E-mail: lien sur http://zener131.free.fr/ContactMe **************************************************/
Bonsoir.
J'ai pu faire des mesures...
"Patrick 'Zener' Brunet" <use.link.in.signature@ddress.invalid> a écrit dans
le message de news: fhpvq0$fuf$1@shakotay.alphanet.ch...
J'aimerais avoir quelques retours d'expérience sur l'optimisation des
pages fortement dynamiques en PHP.
Je cherche toujours pourquoi mon site (www.ipzb.fr) est si lent à charger,
même pour les pages les plus légères.
[...]
L'extension de Firefox nommée LoadTimeAnalyser montre que, même pour
une page de base et en pleine session, on passe son temps à attendre le
serveur, le transfert des données étant lui presque instantané.
Voyez ce chronogramme (HTML pur):
http://cjoint.com/?lssEIBsuuz
La caractéristique de ce site est que les pages contiennent une forte
proportion d'éléments insérés par du PHP.
Donc il y a des <?php echo GetMachin(); ?> en assez grand nombre au
milieu du HTML.
Donc hier soir j'ai outillé le code PHP de tous les générateurs (à partir
d'une fonction microtime) afin de (temporairement) insérer le timing complet
de la génération dans un commentaire à la fin de tous les composants
textuels (pages, CSS, Javascripts).
Avec IE on peut facilement tout retrouver dans le cache.
Ben voilà ce que ça donne pour la page de garde Home (une fois la première
détection faite, donc en rechargeant la page après avoir vidé le cache en
conservant le cookie):
Ca c'est le texte de la page:
</html>
<!-- Build timing:
time = 0.912621 / Start get
time = 0.912799 / Require PHP scripts
time = 0.917121 / Get URL data
time = 0.917173 / Start EnsureSession
time = 0.918549 / ES / Start CSession
time = 0.929135 / ES / Build Session
time = 0.930268 / ES / Get cookie
time = 0.93038 / ES / Open Session 1
time = 0.936492 / ES / Start NotLite
time = 0.936547 / ES / End of NotLite
time = 0.936596 / Url / Language
time = 0.936636 / Url / Target
time = 0.936698 / Url / All computed
time = 0.939901 / End of Require PHP scripts
time = 0.939947 / Get / Test languages
time = 0.940356 / Get / Update Cookie
time = 0.940384 / Get / Save Session
time = 0.941046 / Get / Check access
time = 0.941204 / Get / Include page
time = 0.987784 / Get completed
-->
Ca c'est le premier élément appelé, MainLinker.js:
/* <!-- Build timing:
time = 1.409722 / Start getdata
time = 1.410103 / Get URL data
time = 1.410255 / Include JS script
time = 1.410774 / getdata completed
-->
*/
Ca c'est le dernier Javascript:
/* <!-- Build timing:
time = 1.707 / Start getdata
time = 1.707358 / Get URL data
time = 1.707501 / Include JS script
time = 1.708071 / getdata completed
-->
*/
Et ça c'est la CSS principale:
/* <!-- Build timing:
time = 2.00429 / Start getlite
time = 2.004621 / Get URL data
time = 2.004706 / Check CSS script
time = 2.004783 / Include CSS script
time = 2.005835 / AStSh / Get URL data
time = 2.005876 / AStSh / Require scripts
time = 2.008578 / ES / Start CSession
time = 2.018955 / ES / Build Session
time = 2.020477 / ES / Get cookie
time = 2.020587 / ES / Open Session 1
time = 2.02215 / AStSh / Start building
time = 2.037601 / getlite completed
-->
*/
Donc environ 1,15s pour générer tout ce qui est textuel, et qui est
normalement envoyé en temps réel au navigateur.
Plus précisément, la page prend 0,08s à être générée, et la requête pour le
premier composant est reçue 0,5s plus tard.
Ensuite viennent les images qui sont simplement injectées après des headers
par readfile...
Le temps total de téléchargement aujourd'hui était de 6,2s pour cette page.
Si on regarde le chronogramme (http://cjoint.com/?lssEIBsuuz, c'est le
même), ça confirme que la génération en PHP a un coût totalement marginal,
et on voit aussi que le délai de connexion est assez faible.
Je ne vois que deux anomalies:
- cette mise en attente systématique après connexion,
- le fait que les images ont l'air de se bousculer, dès que les CSS ont été
envoyées, tout se met alors à démarrer en parallèle mais les transferts
effectifs restent séquentiels... Pourquoi ?
La seule différence, c'est que les images utilisent le script getdata.php
qui n'accède pas à la session, contrairement au get.php et au getlite.php,
mais cet accès ne coûte que 1ms...
Bref c'est très gonflant, et la dernière fois que je leur ai soumis le
problème, les gens du support de 1&1 ont répondu "qu'après s'être concertés,
ça ne venait pas de chez eux" :-(
Vous connaissez un bon apachéologue ?
Merci de votre soutien :-)
--
Cordialement.
--
/**************************************************
* Patrick BRUNET
* E-mail: lien sur http://zener131.free.fr/ContactMe
**************************************************/
"Patrick 'Zener' Brunet" a écrit dans le message de news: fhpvq0$fuf$
J'aimerais avoir quelques retours d'expérience sur l'optimisation des pages fortement dynamiques en PHP.
Je cherche toujours pourquoi mon site (www.ipzb.fr) est si lent à charger, même pour les pages les plus légères. [...]
L'extension de Firefox nommée LoadTimeAnalyser montre que, même pour une page de base et en pleine session, on passe son temps à attendre le serveur, le transfert des données étant lui presque instantané. Voyez ce chronogramme (HTML pur): http://cjoint.com/?lssEIBsuuz
La caractéristique de ce site est que les pages contiennent une forte proportion d'éléments insérés par du PHP. Donc il y a des <?php echo GetMachin(); ?> en assez grand nombre au milieu du HTML.
Donc hier soir j'ai outillé le code PHP de tous les générateurs (à partir d'une fonction microtime) afin de (temporairement) insérer le timing complet de la génération dans un commentaire à la fin de tous les composants textuels (pages, CSS, Javascripts). Avec IE on peut facilement tout retrouver dans le cache.
Ben voilà ce que ça donne pour la page de garde Home (une fois la première détection faite, donc en rechargeant la page après avoir vidé le cache en conservant le cookie):
Ca c'est le texte de la page:
</html> <!-- Build timing: time = 0.912621 / Start get time = 0.912799 / Require PHP scripts time = 0.917121 / Get URL data time = 0.917173 / Start EnsureSession time = 0.918549 / ES / Start CSession time = 0.929135 / ES / Build Session time = 0.930268 / ES / Get cookie time = 0.93038 / ES / Open Session 1 time = 0.936492 / ES / Start NotLite time = 0.936547 / ES / End of NotLite time = 0.936596 / Url / Language time = 0.936636 / Url / Target time = 0.936698 / Url / All computed time = 0.939901 / End of Require PHP scripts time = 0.939947 / Get / Test languages time = 0.940356 / Get / Update Cookie time = 0.940384 / Get / Save Session time = 0.941046 / Get / Check access time = 0.941204 / Get / Include page time = 0.987784 / Get completed -->
Ca c'est le premier élément appelé, MainLinker.js:
/* <!-- Build timing: time = 1.409722 / Start getdata time = 1.410103 / Get URL data time = 1.410255 / Include JS script time = 1.410774 / getdata completed --> */
Ca c'est le dernier Javascript:
/* <!-- Build timing: time = 1.707 / Start getdata time = 1.707358 / Get URL data time = 1.707501 / Include JS script time = 1.708071 / getdata completed --> */
Et ça c'est la CSS principale:
/* <!-- Build timing: time = 2.00429 / Start getlite time = 2.004621 / Get URL data time = 2.004706 / Check CSS script time = 2.004783 / Include CSS script time = 2.005835 / AStSh / Get URL data time = 2.005876 / AStSh / Require scripts time = 2.008578 / ES / Start CSession time = 2.018955 / ES / Build Session time = 2.020477 / ES / Get cookie time = 2.020587 / ES / Open Session 1 time = 2.02215 / AStSh / Start building time = 2.037601 / getlite completed --> */
Donc environ 1,15s pour générer tout ce qui est textuel, et qui est normalement envoyé en temps réel au navigateur.
Plus précisément, la page prend 0,08s à être générée, et la requête pour le premier composant est reçue 0,5s plus tard.
Ensuite viennent les images qui sont simplement injectées après des headers par readfile...
Le temps total de téléchargement aujourd'hui était de 6,2s pour cette page.
Si on regarde le chronogramme (http://cjoint.com/?lssEIBsuuz, c'est le même), ça confirme que la génération en PHP a un coût totalement marginal, et on voit aussi que le délai de connexion est assez faible.
Je ne vois que deux anomalies: - cette mise en attente systématique après connexion, - le fait que les images ont l'air de se bousculer, dès que les CSS ont été envoyées, tout se met alors à démarrer en parallèle mais les transferts effectifs restent séquentiels... Pourquoi ?
La seule différence, c'est que les images utilisent le script getdata.php qui n'accède pas à la session, contrairement au get.php et au getlite.php, mais cet accès ne coûte que 1ms...
Bref c'est très gonflant, et la dernière fois que je leur ai soumis le problème, les gens du support de 1&1 ont répondu "qu'après s'être concertés, ça ne venait pas de chez eux" :-(
Vous connaissez un bon apachéologue ?
Merci de votre soutien :-)
-- Cordialement. -- /************************************************** * Patrick BRUNET * E-mail: lien sur http://zener131.free.fr/ContactMe **************************************************/
Patrick 'Zener' Brunet
Bonsoir.
"Denis Beauregard" a écrit dans le message de news:
Le Sun, 18 Nov 2007 19:20:41 +0100, "Patrick 'Zener' Brunet" écrivait dans fr.comp.infosystemes.www.auteurs:
>Merci de vos conseils (dans la mesure ou ce n'est pas "fais du HTML >de base", je sais faire aussi mais c'est hors-sujet ;-).
Mais si tu recodais une page en HTML, tu pourrais voir si c'est vraiment le PHP qui est lent ou autre chose, ce qui te ferait gagner beaucoup de temps si c'est autre chose...
En fait la structure du site fait qu'il n'est pas simple du tout d'y insérer une page hors-layout, en pur HTML.
Bon, entre temps j'ai pu mesurer les performances de la génération PHP elle-même.
-- Cordialement. -- /************************************************** * Patrick BRUNET * E-mail: lien sur http://zener131.free.fr/ContactMe **************************************************/
Bonsoir.
"Denis Beauregard" <denis.b-at-francogene.com.invalid@nospam.com.invalid> a
écrit dans le message de news: qm21k3t29a9foo0vlridfa3go2cls0geiv@4ax.com...
Le Sun, 18 Nov 2007 19:20:41 +0100, "Patrick 'Zener' Brunet"
<use.link.in.signature@ddress.invalid> écrivait dans
fr.comp.infosystemes.www.auteurs:
>Merci de vos conseils (dans la mesure ou ce n'est pas "fais du HTML
>de base", je sais faire aussi mais c'est hors-sujet ;-).
Mais si tu recodais une page en HTML, tu pourrais voir si c'est
vraiment le PHP qui est lent ou autre chose, ce qui te ferait
gagner beaucoup de temps si c'est autre chose...
En fait la structure du site fait qu'il n'est pas simple du tout d'y insérer
une page hors-layout, en pur HTML.
Bon, entre temps j'ai pu mesurer les performances de la génération PHP
elle-même.
--
Cordialement.
--
/**************************************************
* Patrick BRUNET
* E-mail: lien sur http://zener131.free.fr/ContactMe
**************************************************/
"Denis Beauregard" a écrit dans le message de news:
Le Sun, 18 Nov 2007 19:20:41 +0100, "Patrick 'Zener' Brunet" écrivait dans fr.comp.infosystemes.www.auteurs:
>Merci de vos conseils (dans la mesure ou ce n'est pas "fais du HTML >de base", je sais faire aussi mais c'est hors-sujet ;-).
Mais si tu recodais une page en HTML, tu pourrais voir si c'est vraiment le PHP qui est lent ou autre chose, ce qui te ferait gagner beaucoup de temps si c'est autre chose...
En fait la structure du site fait qu'il n'est pas simple du tout d'y insérer une page hors-layout, en pur HTML.
Bon, entre temps j'ai pu mesurer les performances de la génération PHP elle-même.
-- Cordialement. -- /************************************************** * Patrick BRUNET * E-mail: lien sur http://zener131.free.fr/ContactMe **************************************************/
Patrick 'Zener' Brunet
Bonsoir.
"Pierre Goiffon" a écrit dans le message de news: 47415688$0$9203$
Patrick 'Zener' Brunet wrote: > L'extension de Firefox nommée LoadTimeAnalyser montre que
Ha tiens je ne connaissais pas cette extension (qui ne nomme plutôt Load Time Analyzer avec un Z :) )
Dézolé, il était tard :o)
Après un rapide test je n'ai pas l'impression que cette extension ajoute bcp par rapport à la fonctionnalité équivalente dans Firebug (onglet Net) ?
Ben disons que c'est très léger à installer pour un truc qui donne tout de même un diagramme complet. Ce serait mieux si la fenêtre tenait dans l'écran et le diagramme sur un A4, mais ça aide bien en l'état. -- Cordialement. -- /************************************************** * Patrick BRUNET * E-mail: lien sur http://zener131.free.fr/ContactMe **************************************************/
Bonsoir.
"Pierre Goiffon" <pgoiffon@free.fr.invalid> a écrit dans le message de news:
47415688$0$9203$426a34cc@news.free.fr...
Patrick 'Zener' Brunet wrote:
> L'extension de Firefox nommée LoadTimeAnalyser montre que
Ha tiens je ne connaissais pas cette extension (qui ne nomme plutôt
Load Time Analyzer avec un Z :) )
Dézolé, il était tard :o)
Après un rapide test je n'ai pas l'impression que cette extension ajoute
bcp par rapport à la fonctionnalité équivalente dans Firebug (onglet
Net) ?
Ben disons que c'est très léger à installer pour un truc qui donne tout de
même un diagramme complet.
Ce serait mieux si la fenêtre tenait dans l'écran et le diagramme sur un A4,
mais ça aide bien en l'état.
--
Cordialement.
--
/**************************************************
* Patrick BRUNET
* E-mail: lien sur http://zener131.free.fr/ContactMe
**************************************************/
"Pierre Goiffon" a écrit dans le message de news: 47415688$0$9203$
Patrick 'Zener' Brunet wrote: > L'extension de Firefox nommée LoadTimeAnalyser montre que
Ha tiens je ne connaissais pas cette extension (qui ne nomme plutôt Load Time Analyzer avec un Z :) )
Dézolé, il était tard :o)
Après un rapide test je n'ai pas l'impression que cette extension ajoute bcp par rapport à la fonctionnalité équivalente dans Firebug (onglet Net) ?
Ben disons que c'est très léger à installer pour un truc qui donne tout de même un diagramme complet. Ce serait mieux si la fenêtre tenait dans l'écran et le diagramme sur un A4, mais ça aide bien en l'état. -- Cordialement. -- /************************************************** * Patrick BRUNET * E-mail: lien sur http://zener131.free.fr/ContactMe **************************************************/
Patrick 'Zener' Brunet
Bonsoir.
"kurtz le pirate" a écrit dans le message de news:
In article <fhpvq0$fuf$, "Patrick 'Zener' Brunet" wrote:
> J'aimerais avoir quelques retours d'expérience sur l'optimisation des > pages fortement dynamiques en PHP.
ça veut dire quoi *fortement* dynamique ?
Ca veut dire beaucoup de contenu généré en fonction du contexte de l'utilisateur (options d'accessibilité, de confort, de look bientôt, etc.). Par opposition au simple enfilage de 2 ou 3 tronçons statiques.
ben, un regard rapidement montre que presque tout les appels à des images, style, script,... passent par une requête php.
Oui, il y a du dynamique partout, même les images peuvent être adaptables selon la résolution d'écran et des options de coloration. Mais pour tout ce qui est fixe, c'est un simple enfilage de fichier par readfile après sélection.
Des fois que ça influe sur le comportement du navigateur, j'ai activé l'URL rewriting pour ces ressouces, donc maintenant il les voit comme statiques chaque fois que c'est possible.
de plus du javascript qui lance toutes les 15mn le PingSession.
Oui, si JS est dispo, on ne timeoute pas. Mais bon, un reload par quart d'heure, c'est pas dramatique...
et un autre truc qui me chagrine : je ne sais pas comment les navigateurs peuvent interpréter les feuilles de style alors que celles ci ne sont pas entièrement chargées puisque requête php... et qui contiennent aussi des requêtes à l'intérieur : background-image: URL('/getdata.php?type=cssimage&nameÞfault/Images/RedPin.gif');
Donc désormais, elles ont l'air statique aussi...
Mais normalement le boulot du navigateur est de demander les ressources telles qu'elles sont désignées, et dès que le besoin est créé, donc le HTML appelle tout le reste au cours de son interprétation, et la CSS appelle les css-images de la même manière un peu plus tard...
bref, me semble bien compliqué pour le résultat obtenu.
C'est un projet expérimentatal visant à fournir un contenu *unique* qui s'adapte à tous les cas: - avec ou sans cookie, - avec ou sans JS, - de Lynx à Firefox en passant par IE et tous les vieux coucous, - compatible souris, clavier et IHM spéciales, - et relookable à la CSS Zen Garden en prime. Donc c'est forcément 98% server-side.
Oui, c'est compliqué, mais où serait le plaisir ? :-)
-- Cordialement. -- /************************************************** * Patrick BRUNET * E-mail: lien sur http://zener131.free.fr/ContactMe **************************************************/
Bonsoir.
"kurtz le pirate" <kurtzlepirate@yahoo.fr> a écrit dans le message de news:
kurtzlepirate-DD3AD3.16403419112007@news-1.proxad.net...
In article <fhpvq0$fuf$1@shakotay.alphanet.ch>,
"Patrick 'Zener' Brunet" <use.link.in.signature@ddress.invalid> wrote:
> J'aimerais avoir quelques retours d'expérience sur l'optimisation des
> pages fortement dynamiques en PHP.
ça veut dire quoi *fortement* dynamique ?
Ca veut dire beaucoup de contenu généré en fonction du contexte de
l'utilisateur (options d'accessibilité, de confort, de look bientôt, etc.).
Par opposition au simple enfilage de 2 ou 3 tronçons statiques.
ben, un regard rapidement montre que presque tout les appels à des
images, style, script,... passent par une requête php.
Oui, il y a du dynamique partout, même les images peuvent être adaptables
selon la résolution d'écran et des options de coloration.
Mais pour tout ce qui est fixe, c'est un simple enfilage de fichier par
readfile après sélection.
Des fois que ça influe sur le comportement du navigateur, j'ai activé l'URL
rewriting pour ces ressouces, donc maintenant il les voit comme statiques
chaque fois que c'est possible.
de plus du javascript qui lance toutes les 15mn le PingSession.
Oui, si JS est dispo, on ne timeoute pas.
Mais bon, un reload par quart d'heure, c'est pas dramatique...
et un autre truc qui me chagrine : je ne sais pas comment les
navigateurs peuvent interpréter les feuilles de style alors que celles
ci ne sont pas entièrement chargées puisque requête php... et qui
contiennent aussi des requêtes à l'intérieur :
background-image:
URL('/getdata.php?type=cssimage&nameÞfault/Images/RedPin.gif');
Donc désormais, elles ont l'air statique aussi...
Mais normalement le boulot du navigateur est de demander les ressources
telles qu'elles sont désignées, et dès que le besoin est créé, donc le HTML
appelle tout le reste au cours de son interprétation, et la CSS appelle les
css-images de la même manière un peu plus tard...
bref, me semble bien compliqué pour le résultat obtenu.
C'est un projet expérimentatal visant à fournir un contenu *unique* qui
s'adapte à tous les cas:
- avec ou sans cookie,
- avec ou sans JS,
- de Lynx à Firefox en passant par IE et tous les vieux coucous,
- compatible souris, clavier et IHM spéciales,
- et relookable à la CSS Zen Garden en prime.
Donc c'est forcément 98% server-side.
Oui, c'est compliqué, mais où serait le plaisir ? :-)
--
Cordialement.
--
/**************************************************
* Patrick BRUNET
* E-mail: lien sur http://zener131.free.fr/ContactMe
**************************************************/
"kurtz le pirate" a écrit dans le message de news:
In article <fhpvq0$fuf$, "Patrick 'Zener' Brunet" wrote:
> J'aimerais avoir quelques retours d'expérience sur l'optimisation des > pages fortement dynamiques en PHP.
ça veut dire quoi *fortement* dynamique ?
Ca veut dire beaucoup de contenu généré en fonction du contexte de l'utilisateur (options d'accessibilité, de confort, de look bientôt, etc.). Par opposition au simple enfilage de 2 ou 3 tronçons statiques.
ben, un regard rapidement montre que presque tout les appels à des images, style, script,... passent par une requête php.
Oui, il y a du dynamique partout, même les images peuvent être adaptables selon la résolution d'écran et des options de coloration. Mais pour tout ce qui est fixe, c'est un simple enfilage de fichier par readfile après sélection.
Des fois que ça influe sur le comportement du navigateur, j'ai activé l'URL rewriting pour ces ressouces, donc maintenant il les voit comme statiques chaque fois que c'est possible.
de plus du javascript qui lance toutes les 15mn le PingSession.
Oui, si JS est dispo, on ne timeoute pas. Mais bon, un reload par quart d'heure, c'est pas dramatique...
et un autre truc qui me chagrine : je ne sais pas comment les navigateurs peuvent interpréter les feuilles de style alors que celles ci ne sont pas entièrement chargées puisque requête php... et qui contiennent aussi des requêtes à l'intérieur : background-image: URL('/getdata.php?type=cssimage&nameÞfault/Images/RedPin.gif');
Donc désormais, elles ont l'air statique aussi...
Mais normalement le boulot du navigateur est de demander les ressources telles qu'elles sont désignées, et dès que le besoin est créé, donc le HTML appelle tout le reste au cours de son interprétation, et la CSS appelle les css-images de la même manière un peu plus tard...
bref, me semble bien compliqué pour le résultat obtenu.
C'est un projet expérimentatal visant à fournir un contenu *unique* qui s'adapte à tous les cas: - avec ou sans cookie, - avec ou sans JS, - de Lynx à Firefox en passant par IE et tous les vieux coucous, - compatible souris, clavier et IHM spéciales, - et relookable à la CSS Zen Garden en prime. Donc c'est forcément 98% server-side.
Oui, c'est compliqué, mais où serait le plaisir ? :-)
-- Cordialement. -- /************************************************** * Patrick BRUNET * E-mail: lien sur http://zener131.free.fr/ContactMe **************************************************/
