Mais comment faire ça avec SPIP ? Est-ce que quelqu'un l'a déjà fait ?
Si j'insère des "ob_end_flush()" dans mon squelette entre le <head> et le <body> par exemple, comment va se comporter le pipeline affichage_final, par exemple ?
Si c'est faisable, est-il envisageable d'automatiser cela dans Zpip, éventuellement ?
Il est maintenant relativement connu quand on s'intéresse aux performances des sites web qu'envoyer le HTML fragment par fragment permet d'améliorer la performance perçue par l'utilisateur : Flushing the Document Early | High Performance Web Sites
Je note que Steve Souders commence bien par expliquer que la génération du document HTML ne prend en général que 10% à 20% du temps total de chargement de la page, et que dans le cas contraire, il peut être intéressant de flusher ...
Dans le cas de SPIP, on s'applique à bien rester sous ce seuil de 10 à 20%, et le flush n'apporte pas grand chose dans ce cas.
Sinon, si tu as des pages lourdes, et que tu veux vraiment envoyer par morceaux,
c'est plutot APL que je propose d'utiliser en effet.
Mais comment faire ça avec SPIP ? Est-ce que quelqu'un l'a déjà fait ?
Si j'insère des "ob_end_flush()" dans mon squelette entre le <head> et le <body> par exemple, comment va se comporter le pipeline affichage_final, par exemple ?
Ça va carrément mettre le bazar (voire planter, ou dans le meilleur des cas ne rien faire)
Il est maintenant relativement connu quand on s'intéresse aux performances des sites web qu'envoyer le HTML fragment par fragment permet d'améliorer la performance perçue par l'utilisateur : Flushing the Document Early | High Performance Web Sites
Je note que Steve Souders commence bien par expliquer que la génération du document HTML ne prend en général que 10% à 20% du temps total de chargement de la page, et que dans le cas contraire, il peut être intéressant de flusher ...
Effectivement.
J'ai retrouvé le vrai article que je voulais citer initialement :
Dans le cas de SPIP, on s'applique à bien rester sous ce seuil de 10 à 20%, et le flush n'apporte pas grand chose dans ce cas.
Il apporte un rendu progressif, qui évite le syndrome de l'attente frustrante devant une page blanche. Il faut mieux attendre en tout 5 seconde, mais en voyant la page se construire progressivement dès la première seconde, qu'attendre 3 secondes devant du blanc avant de tout avoir soudainement.
Sinon, si tu as des pages lourdes, et que tu veux vraiment envoyer par morceaux, c'est plutot APL que je propose d'utiliser en effet.
La page (presque) blanche fournie aux utilisateurs sans JS me gêne un peu, sinon j'aurais effectivement adopté APL...
Mais comment faire ça avec SPIP ? Est-ce que quelqu'un l'a déjà fait ?
Si j'insère des "ob_end_flush()" dans mon squelette entre le <head> et le <body> par exemple, comment va se comporter le pipeline affichage_final, par exemple ?
Ça va carrément mettre le bazar (voire planter, ou dans le meilleur des cas ne rien faire)
Donc ce serait top que SPIP s'occupe lui-même de cette diffusion progressive du HTML...
Il est maintenant relativement connu quand on s'intéresse aux performances des sites web qu'envoyer le HTML fragment par fragment permet d'améliorer la performance perçue par l'utilisateur : Flushing the Document Early | High Performance Web Sites
Je note que Steve Souders commence bien par expliquer que la génération du document HTML ne prend en général que 10% à 20% du temps total de chargement de la page, et que dans le cas contraire, il peut être intéressant de flusher ...
Dans le cas de SPIP, on s'applique à bien rester sous ce seuil de 10 à 20%, et le flush n'apporte pas grand chose dans ce cas.
Il apporte un rendu progressif, qui évite le syndrome de l'attente frustrante devant une page blanche. Il faut mieux attendre en tout 5 seconde, mais en voyant la page se construire progressivement dès la première seconde, qu'attendre 3 secondes devant du blanc avant de tout avoir soudainement.
Sinon, si tu as des pages lourdes, et que tu veux vraiment envoyer par morceaux, c'est plutot APL que je propose d'utiliser en effet.
La page (presque) blanche fournie aux utilisateurs sans JS me gêne un peu, sinon j'aurais effectivement adopté APL...
heu non tu as pas du tester une version récente. Les utilisateurs sans js ont une page complète en un hit, à l'ancienne.
Mais comment faire ça avec SPIP ? Est-ce que quelqu'un l'a déjà fait ?
Si j'insère des "ob_end_flush()" dans mon squelette entre le <head> et le <body> par exemple, comment va se comporter le pipeline affichage_final, par exemple ?
Ça va carrément mettre le bazar (voire planter, ou dans le meilleur des cas ne rien faire)
Donc ce serait top que SPIP s'occupe lui-même de cette diffusion progressive du HTML...
Je vois pas de solution viable et compatible avec un certain nombre de fonctionnalités.
Sinon, si tu as des pages lourdes, et que tu veux vraiment envoyer par morceaux, c'est plutot APL que je propose d'utiliser en effet.
La page (presque) blanche fournie aux utilisateurs sans JS me gêne un peu, sinon j'aurais effectivement adopté APL...
heu non tu as pas du tester une version récente. Les utilisateurs sans js ont une page complète en un hit, à l'ancienne.
Non, j'ai bien testé — en tout cas je suppose que SPIP Contrib est à jour — et la première page est d'abord presque vide, puis on redirige en posant un cookie pour les fois suivantes. C'est bien la première fois qui me gène, parce que c'est le nouvel arrivant qu'il faut réussir à garder là...
Mais comment faire ça avec SPIP ? Est-ce que quelqu'un l'a déjà fait ?
Si j'insère des "ob_end_flush()" dans mon squelette entre le <head> et le <body> par exemple, comment va se comporter le pipeline affichage_final, par exemple ?
Ça va carrément mettre le bazar (voire planter, ou dans le meilleur des cas ne rien faire)
Donc ce serait top que SPIP s'occupe lui-même de cette diffusion progressive du HTML...
Je vois pas de solution viable et compatible avec un certain nombre de fonctionnalités.
SPIP fait bien un envoi de la page en HTML, au final, donc il doit bien y avoir moyen d'y glisser quelques "ob_flush(); flush();", non ?
Sinon, si tu as des pages lourdes, et que tu veux vraiment envoyer par morceaux, c'est plutot APL que je propose d'utiliser en effet.
La page (presque) blanche fournie aux utilisateurs sans JS me gêne un peu, sinon j'aurais effectivement adopté APL...
heu non tu as pas du tester une version récente. Les utilisateurs sans js ont une page complète en un hit, à l'ancienne.
Non, j'ai bien testé — en tout cas je suppose que SPIP Contrib est à jour — et la première page est d'abord presque vide, puis on redirige en posant un cookie pour les fois suivantes. C'est bien la première fois qui me gène, parce que c'est le nouvel arrivant qu'il faut réussir à garder là...
Quel navigateur donc ? Car si tu n'as pas javascript, il y a une meta refresh dans un <noscript> qui déclenche le rechargement.
Mais oui il est clair que dans ce scenario on défavorise le nouvel arrivant sans js par rapport aux autres.
Mais comment faire ça avec SPIP ? Est-ce que quelqu'un l'a déjà fait ?
Si j'insère des "ob_end_flush()" dans mon squelette entre le <head> et le <body> par exemple, comment va se comporter le pipeline affichage_final, par exemple ?
Ça va carrément mettre le bazar (voire planter, ou dans le meilleur des cas ne rien faire)
Donc ce serait top que SPIP s'occupe lui-même de cette diffusion progressive du HTML...
Je vois pas de solution viable et compatible avec un certain nombre de fonctionnalités.
SPIP fait bien un envoi de la page en HTML, au final, donc il doit bien y avoir moyen d'y glisser quelques "ob_flush(); flush();", non ?
non, car du coup plus moyen de gérer les traitement finaux (pipeline affichage_final, gestion des headers envoyés a retardement, ...)
Non, j'ai bien testé — en tout cas je suppose que SPIP Contrib est à jour — et la première page est d'abord presque vide, puis on redirige en posant un cookie pour les fois suivantes. C'est bien la première fois qui me gène, parce que c'est le nouvel arrivant qu'il faut réussir à garder là...
Quel navigateur donc ?
Firefox 3.6 sur Mac.
Car si tu n'as pas javascript, il y a une meta refresh dans un <noscript> qui déclenche le rechargement.
Oui, mais ce n'est pas immédiat.
Mais oui il est clair que dans ce scenario on défavorise le nouvel arrivant sans js par rapport aux autres.
Bon, après, je ne sais pas du tout combien j'ai personnellement de visiteurs sans JS, je pourrais sans doute tirer profit sans problème de APL, mais dans le cadre d'une réflexion plus générale, je trouve cela dommage.
Mais comment faire ça avec SPIP ? Est-ce que quelqu'un l'a déjà fait ?
Si j'insère des "ob_end_flush()" dans mon squelette entre le <head> et le <body> par exemple, comment va se comporter le pipeline affichage_final, par exemple ?
Ça va carrément mettre le bazar (voire planter, ou dans le meilleur des cas ne rien faire)
Donc ce serait top que SPIP s'occupe lui-même de cette diffusion progressive du HTML...
Je vois pas de solution viable et compatible avec un certain nombre de fonctionnalités.
SPIP fait bien un envoi de la page en HTML, au final, donc il doit bien y avoir moyen d'y glisser quelques "ob_flush(); flush();", non ?
non, car du coup plus moyen de gérer les traitement finaux (pipeline affichage_final, gestion des headers envoyés a retardement, ...)
Donc c'est au niveau d'affichage_final qu'il faut intervenir peut-être... Rajouter pour commencer un flush() entre </head> et <body>
Je confirme le pages blanches de Contrib, vraiment pas agréables, qui durent parfois suffisamment trop longtemps pour que je j'aille cliquer ailleurs, sans comprendre que ça va finir par arriver.
Avec Firefox 3.6 sur Mac également.
- si javascript *désactivé* dans le navigateur (oui : ça existe) le *premier* appel à spip-contrib affiche un *contenu* vide avec un lien "cliquez ici si la page reste incomplète bla bla bla" comme on peut voir ici : http://www.circaete.net/contrib/latence.jpg
cet affichage (page blanche) peut durer oui.
il ne se produit qu'au *premier* accès à spip-contrib
- avec javascript activé dans le navigateur (si si : il y a encore des fous qui vivent dangereusement) la parallèle loading peut effectivement prendre un certain temps durant lequel le *contenu* reste vide comme on peut le voir ici : http://www.circaete.net/contrib/latence_2.jpg
et là aussi ça peut durer...
« Zpip permet cela au moyen de la déclaration d’une variable globale. Dans votre fichier mes_fonctions, il suffit de lister les blocs que vous voulez utiliser sur votre projet. »
Juste en passant cette page : http://gasteroprod.com/spip.php?page=tags
ne se charge pas sur FF3.6.10 sur Gnu/nux. Peut être la même chose que
la page 404 sur spip-contrib
