[SPIP Zone] SPIP & Eco-responsabilité

Archives Zone
#1

Bonjour,

ce serait vraiment bien d'améliorer SPIP & Eco-responsabilité et d'en
faire une ligne de développement claire.

Par exemple, j'ai un site SPIP de 10 pages avec 10 photos de moins de
500ko qui au total (BDD, Plugins, Cache, fichiers) pèse plus de 100Mo,
that's not possible !

- bande passante, charge serveur, espace disque devraient pouvoir être
allégés

Est-ce qu'il serait envisageable de lister les optimisations possibles
pour alléger SPIP, au pif

- choisir les téléchargements de plugins-dist avant MAJ (spip_loader ?)
compagnon désactivables, etc ?

- avoir un moyen d'éviter le chargement d'images dans /IMG/distant/ à
l'affichage de la recherche de plugins, certaines images de Thèmes
pèsent plus de 300ko, est-ce que ce n'est pas possible de les réduire
avant d'envoyer ?

Il y a surement plein d'autres moyens

Merci d'éviter la parano pour essayer d'avancer :slight_smile:

Au plaisir de vous lire.

touti

Écologie de mon site
#2

Hop,

Le 13/11/2019 à 10:34, toutati a écrit :

Bonjour,

ce serait vraiment bien d'améliorer SPIP & Eco-responsabilité et d'en
faire une ligne de développement claire.

Bonne idée que de rédiger un texte à ce sujet, merci d'avance pour les propositions de ce côté.

Je ne pense pas me tromper en disant que l'équipe est sensibilisée sur ce point et que SPIP propose depuis pas mal d'années des outils internes pour respecter les bonnes pratiques de ce côté, exemples :

https://blog.spip.net/CMS-et-sites-a-fort-trafic-parlons-chiffres.html
https://blog.spip.net/SPIP-2-0-vous-fait-economiser-750.html

Par exemple, j'ai un site SPIP de 10 pages avec 10 photos de moins de
500ko qui au total (BDD, Plugins, Cache, fichiers) pèse plus de 100Mo,
that's not possible !

Amha, ce n'est pas l'espace disque qui pose problème, mais plutôt la bande passante des données transférées. Donc, le cache ne devrait pas entrer en considération car il permet justement d'éviter au serveur d'utiliser des ressources pour générer des pages à servir.

- bande passante, charge serveur, espace disque devraient pouvoir être
allégés

oui :slight_smile:

Est-ce qu'il serait envisageable de lister les optimisations possibles
pour alléger SPIP, au pif

- choisir les téléchargements de plugins-dist avant MAJ (spip_loader ?)
compagnon désactivables, etc ?

Ça c'est le vieux serpent de mer des distributions, point qu'on pourrait régler "facilement" avec composer (sauf que je ne suis pas certain que celui-ci soit super écoresponsable).

- avoir un moyen d'éviter le chargement d'images dans /IMG/distant/ à
l'affichage de la recherche de plugins, certaines images de Thèmes
pèsent plus de 300ko, est-ce que ce n'est pas possible de les réduire
avant d'envoyer ?

- le fait de mettre ces images en cache permet justement d'éviter d'utiliser de la bande passant à chaque recherche de plugin.
- si les images en questions sont trop lourdes, c'est à la source qu'il faut corriger le problème, et ça tombe bien ces images sont accessibles à tou⋅te⋅s puisque sur la zone
- faire travailler un serveur pour réduire ces images avant de les servir consommerait de la ressouce

Il y a surement plein d'autres moyens

Je ne doute pas que d'autres personnes ont des idées à proposer sur cette question.

Au plaisir de vous lire.

Idem, au plaisir de lire ta proposition de texte introductif pour formaliser tout ça :slight_smile:

++
b_b

#3

Hello touti,

je suis tout à fait d’accord pour dire que ce doit être une ligne directrice à ne pas perdre de vue dans le développement de SPIP

Toutefois c’est un sujet plus complexe que tu ne le laisses entendre ici.

En effet, il faut distinguer les différentes métriques comme :
- la bande passante consommée par lors de l’installation de SPIP (1 fois)
- le stockage sur le disque du serveur
- la bande passante consommée par les visiteurs du site
- le CPU consommé par le calcul de pages affichées aux visiteurs du site

Tout ça est intrinsèquement lié, et la réduction d’un facteur influe généralement sur les autres.

Par exemple l’augmentation de l’espace de stockage utilisé sur le disque par les caches et BDD permet justement de réduire la consommation provoquée par les visites du site : la bande passante parce qu’on réduit les images servies aux utilisateurs, le CPU parce qu’on évite le calcul des pages.

Maintenant toute la difficulté c’est qu’en fonction du trafic absorbé par un site, les compromis optimaux ne sont pas les même : on peut concevoir qu’un petit site qui aurait quelques dizaines de visites par jour ne gagne pas vraiment à avoir tant de caches.
Mais dans cette analyse il faut aussi prendre en compte non seulement le trafic des vrais visiteurs, mais aussi le trafic des robots d’indexation. Et l’expérience montre que même sur un petit site peu visité, du moment qu’il est référencé on va avoir un trafic de robots non négligeable.

Il faudrait donc déjà avoir des repères sur le cout et l’impact énergétique du stockage vs utilisation du CPU vs utilisation de la bande passante, et j’avoue que là je n’ai pas de données en tête et je n’ai pas cherché sur ce sujet :frowning:

Mais il est certain qu’on peut déjà prêter attention aux sources qu’on envoie, et notamment à optimiser systématiquement les images sources des plugins et thèmes : c’est un réflexe qui ne coûte rien et n’a que des bénéfices, donc c’est un premier pas.

Ensuite la possibilité de choisir certains plugins ou non dans les plugins-dist est déjà une réalité.
Même si spip-loader ne permet pas nativement ça de choisir quel plugins on veut, il est assez facile de supprimer tous les plugins que tu n’utilises pas (et de mémoire on est quasi propre sur les dépendances)

Peut-être on pourrait commencer par écrire une doc et un article sur le sujet pour poser les enjeux, ce sur quoi on a déjà travaillé et qui est bien, ce sur quoi les utilisateurs de SPIP peuvent agir à leur niveau, les voies d’améliorations.
Et peut-être aussi une liste de bonnes pratiques en ce sens pour les développeurs de plugin serait utile ?

--
Cédric
Le 13 nov. 2019 à 10:34 +0100, toutati <toutati@free.fr>, a écrit :

Bonjour,

ce serait vraiment bien d'améliorer SPIP & Eco-responsabilité et d'en
faire une ligne de développement claire.

Par exemple, j'ai un site SPIP de 10 pages avec 10 photos de moins de
500ko qui au total (BDD, Plugins, Cache, fichiers) pèse plus de 100Mo,
that's not possible !

- bande passante, charge serveur, espace disque devraient pouvoir être
allégés

Est-ce qu'il serait envisageable de lister les optimisations possibles
pour alléger SPIP, au pif

- choisir les téléchargements de plugins-dist avant MAJ (spip_loader ?)
compagnon désactivables, etc ?

- avoir un moyen d'éviter le chargement d'images dans /IMG/distant/ à
l'affichage de la recherche de plugins, certaines images de Thèmes
pèsent plus de 300ko, est-ce que ce n'est pas possible de les réduire
avant d'envoyer ?

Il y a surement plein d'autres moyens

Merci d'éviter la parano pour essayer d'avancer :slight_smile:

Au plaisir de vous lire.

touti

----
spip-zone@rezo.net - https://listes.rezo.net/mailman/listinfo/spip-zone

#4

Le 13/11/2019 à 11:10, Bruno Bergot a écrit :

Je ne doute pas que d'autres personnes ont des idées à proposer sur cette question.

Au plaisir de vous lire.

Un truc qui m'étonne dans les dev de plugins, c'est le fait de mettre le js en dur dans le html (bigfoot, crayons, ancredouce) et pas en appel externe : du coup on ne profite pas du cache navigateur ni de la compression.

mais peut etre y a-t-il une raison que j'ignore?

#5

Ce sont des cas particuliers, en effet, avec des raisons particulières.
Comme je le disais dans mon mail précédent, quand on commence à réflechir et à vouloir optimiser la performance et/ou l’empreinte écologique, le diable est dans les détails.

Pour l’exemple de crayons (puisque j’ai le nez dedans) :

son js n’est pas injecté en dur dans le html, mais il est chargé par un bout de loader js, en async, en effet
La raison est que ce js est utilisé uniquement pour les admins, on ne veut donc pas qu’il soit compacté/minifié avec les autres JS car soit il faudrait envoyer le js des crayons à tous les utilisateurs (ridicule) soit on aurait 2 feuilles js compactées/minifiées : une contenant crayon et une ne le contenant pas.
Et du coup les admins passeraient de l’une à l’autre et devraient in fine charger 2 fois plus de JS

j’ai pas regardé les autres, je peux pas répondre sur ces cas particuliers.

Mais de manière générale, un js ou un css ne doit être inclu dans la minification/concaténation des autres que si il est sur toutes les pages et pour tous les visiteurs.
Sinon on introduit des combinatoires et on va générer autant de feuilles css/js concaténées différentes que il y aura de combinaisons, ce qui peut vite devenir une horreur contreproductive, provoquant en fait le téléchargement de beaucoup plus de données et aboutissant à un ralentissement du site…

--
Cédric
Le 13 nov. 2019 à 11:41 +0100, Maïeul <maieul@maieul.net>, a écrit :

Le 13/11/2019 à 11:10, Bruno Bergot a écrit :

>
> Je ne doute pas que d'autres personnes ont des idées à proposer sur
> cette question.
>
> >
> > Au plaisir de vous lire.
> >
Un truc qui m'étonne dans les dev de plugins, c'est le fait de mettre le
js en dur dans le html (bigfoot, crayons, ancredouce) et pas en appel
externe : du coup on ne profite pas du cache navigateur ni de la
compression.

mais peut etre y a-t-il une raison que j'ignore?

----
spip-zone@rezo.net - https://listes.rezo.net/mailman/listinfo/spip-zone

#6

Le 13/11/2019 à 12:27, Cerdic a écrit :

Ce sont des cas particuliers, en effet, avec des raisons particulières.
Comme je le disais dans mon mail précédent, quand on commence à réflechir et à vouloir optimiser la performance et/ou l’empreinte écologique, le diable est dans les détails.

Pour l’exemple de crayons (puisque j’ai le nez dedans) :

oui, ce que tu dis pour les crayons se tient. Pour les ancres douces et pour bigfoot, en l'occurence il n'y a strictement aucun test dans le code actuellement pour savoir si on doit ou pas insérer le js (ni selon page, ni selon visiteur). En fait, la seule raison de ce js inline, c'est de pouvoir avoir des variables php dans sa génération. Du coup peut être que cela pourrait être remplacé par du js dynamique? Qui profiterai du coup du cache de spip ?

#7

Voui,

Le 13/11/2019 à 11:10, Bruno Bergot a écrit :

Hop,

Le 13/11/2019 à 10:34, toutati a écrit :

Bonjour,

ce serait vraiment bien d'améliorer SPIP & Eco-responsabilité et d'en
faire une ligne de développement claire.

Bonne idée que de rédiger un texte à ce sujet, merci d'avance pour les
propositions de ce côté.

Je compilerai avec plaisir ce que l'on raconte ici, pas de souci :slight_smile:

Je ne pense pas me tromper en disant que l'équipe est sensibilisée sur
ce point et que SPIP propose depuis pas mal d'années des outils
internes pour respecter les bonnes pratiques de ce côté, exemples :

https://blog.spip.net/CMS-et-sites-a-fort-trafic-parlons-chiffres.html
https://blog.spip.net/SPIP-2-0-vous-fait-economiser-750.html

Par exemple, j'ai un site SPIP de 10 pages avec 10 photos de moins de
500ko qui au total (BDD, Plugins, Cache, fichiers) pèse plus de 100Mo,
that's not possible !

Amha, ce n'est pas l'espace disque qui pose problème,

En l'occurrence si, c'est un site dont l'espace serveur est limité à
100Mo, c'est parce que j'ai cherché à réduire l'emprise sur cet espace
que j'ai un peu galéré que je me suis dit que ce sujet était intéressant
à discuter un peu plus. En 2004, j'avais codé Plook avec cette ligne
écologique, petit CMS sans BDD dépassé aujourd'hui mais dont le core
pesait 60ko :slight_smile:

J'entends les catégories que listent Cerdic, et là, ne serait-ce que
pour réduire l'espace disque, je pense à un moyen (plugin) de
redimensionner les images dès leur téléchargement avec des options
accessibles. Je ne sais pas si il existe non plus des outils pour
comparer et prendre en compte tous les paramètres. par exemple le
service des pages grace au cache SPIP fait que cela alourdit d'un côté
l'espace d'emprise disque mais allège de l'autre le CPU

mais plutôt la bande passante des données transférées. Donc, le cache
ne devrait pas entrer en considération car il permet justement
d'éviter au serveur d'utiliser des ressources pour générer des pages à
servir.

- bande passante, charge serveur, espace disque devraient pouvoir être
allégés

oui :slight_smile:

Est-ce qu'il serait envisageable de lister les optimisations possibles
pour alléger SPIP, au pif

- choisir les téléchargements de plugins-dist avant MAJ (spip_loader ?)
compagnon désactivables, etc ?

Ça c'est le vieux serpent de mer des distributions, point qu'on
pourrait régler "facilement" avec composer (sauf que je ne suis pas
certain que celui-ci soit super écoresponsable).

La distribution d'un SPIP-light n'est pas pensable ? :slight_smile:

- avoir un moyen d'éviter le chargement d'images dans /IMG/distant/ à
l'affichage de la recherche de plugins, certaines images de Thèmes
pèsent plus de 300ko, est-ce que ce n'est pas possible de les réduire
avant d'envoyer ?

- le fait de mettre ces images en cache permet justement d'éviter
d'utiliser de la bande passant à chaque recherche de plugin.
- si les images en questions sont trop lourdes, c'est à la source
qu'il faut corriger le problème, et ça tombe bien ces images sont
accessibles à tou⋅te⋅s puisque sur la zone
- faire travailler un serveur pour réduire ces images avant de les
servir consommerait de la ressouce

Oui mais, un seul serveur serait nécessaire plutôt que d'alourdir tout
les "receveurs". Et un json ne serait-il pas suffisant pour lister les
plugins dispos plutot que de charger la BDD ?

Il y a surement plein d'autres moyens

Je ne doute pas que d'autres personnes ont des idées à proposer sur
cette question.

Au plaisir de vous lire.

Idem, au plaisir de lire ta proposition de texte introductif pour
formaliser tout ça :slight_smile:

++
b_b

#8

toutati a écrit le 13/11/2019 à 13:08 :

J'entends les catégories que listent Cerdic, et là, ne serait-ce que
pour réduire l'espace disque, je pense à un moyen (plugin) de
redimensionner les images dès leur téléchargement avec des options
accessibles.

Y'a une piste ici :
https://github.com/marcimat/bigup/issues/1

Et côté extensions de navigateurs :
https://darktrojan.github.io/shrunked/
https://github.com/darktrojan/shrunked/releases

Mais ça n'est pas officiellement dans les extensions de FF, alors méfiance...

--
RealET

#9

Hop,

Le 13/11/2019 à 12:43, Maïeul a écrit :

oui, ce que tu dis pour les crayons se tient. Pour les ancres douces et pour bigfoot, en l'occurence il n'y a strictement aucun test dans le code actuellement pour savoir si on doit ou pas insérer le js (ni selon page, ni selon visiteur). En fait, la seule raison de ce js inline, c'est de pouvoir avoir des variables php dans sa génération. Du coup peut être que cela pourrait être remplacé par du js dynamique? Qui profiterai du coup du cache de spip ?

On digresse là, mais pour en revenir à bigfoot, si tu parles des quelques pauvres lignes insérées dans le head pour initialiser le script cf https://zone.spip.net/trac/spip-zone/browser/spip-zone/plugins/bigfoot/trunk/bigfoot_pipelines.php#L23 je pense que ce n'est pas "grand chose" par rapport au poids total de la lib https://zone.spip.net/trac/spip-zone/browser/spip-zone/plugins/bigfoot/trunk/javascript/littlefoot.min.js

De plus, on a déjà abordé maintes fois la question du "doit on insérer un script tout le temps ou uniquement après détection de son besoin dans la page" pour en conclure que c'est contre productif.

++
b_b

#10

Le mercredi 13 novembre 2019 à 14:11 +0100, Bruno Bergot a écrit :

Hop,

On digresse là, mais pour en revenir à bigfoot, si tu parles des
quelques pauvres lignes insérées dans le head pour initialiser le
script
cf

https://zone.spip.net/trac/spip-zone/browser/spip-zone/plugins/bigfoot/trunk/bigfoot_pipelines.php#L23

je pense que ce n'est pas "grand chose" par rapport au poids total de
la
lib

https://zone.spip.net/trac/spip-zone/browser/spip-zone/plugins/bigfoot/trunk/javascript/littlefoot.min.js

certes, mais pour autant je ne comprend pas ca raison d'être en html pas
en ligne

De plus, on a déjà abordé maintes fois la question du "doit on
insérer
un script tout le temps ou uniquement après détection de son besoin
dans
la page" pour en conclure que c'est contre productif.

qu'est-ce qui est finalement contreproductif ?

++
b_b

#11

Re,

Le 13/11/2019 à 13:08, toutati a écrit :

Amha, ce n'est pas l'espace disque qui pose problème,

En l'occurrence si, c'est un site dont l'espace serveur est limité à
100Mo, c'est parce que j'ai cherché à réduire l'emprise sur cet espace
que j'ai un peu galéré que je me suis dit que ce sujet était intéressant
à discuter un peu plus.

Si tu es limitée en espace disque et que c'est le cache de SPIP qui pose problème, tu as plusieurs options à dispo :

- installer memoization et profiter d'un cache en RAM avec memcached et autres, ça aura en plus l'avantage d'améliorer les perfs de ton cache (amha c'est la meilleure solution)
- bidouiller pour "mapper" le répertoire de ton cache vers de la ram à l'aide de tmpfs par exemple (sur un dédié uniquement)
- désactiver le cache de SPIP (ce qui est contre productif du point de vue du sujet abordé ici) à l'aide de define('_NO_CACHE', -1); cf https://programmer.spip.net/Configurer-le-cache

J'ai comme l'impression qu'on s'écarte du sujet initial de la discussion, pour régler le problème d'un site particulier qui manque d'espace disque.

Ça c'est le vieux serpent de mer des distributions, point qu'on
pourrait régler "facilement" avec composer (sauf que je ne suis pas
certain que celui-ci soit super écoresponsable).

La distribution d'un SPIP-light n'est pas pensable ? :slight_smile:

Tout est "pensable", on est souvent très fort⋅e⋅s pour penser, parfois moins pour agir :stuck_out_tongue:

Sérieusement, tant que la communauté (dont nous faisons partie tous les deux) ne propose pas de distrib clé en main, n'importe qui peut faire une distrib SPIP light avec quelques scripts dans un coin. Le problème est plus de trouver comment le faire de manière propre, automatisée, grand public et pérenne.

- le fait de mettre ces images en cache permet justement d'éviter
d'utiliser de la bande passant à chaque recherche de plugin.
- si les images en questions sont trop lourdes, c'est à la source
qu'il faut corriger le problème, et ça tombe bien ces images sont
accessibles à tou⋅te⋅s puisque sur la zone
- faire travailler un serveur pour réduire ces images avant de les
servir consommerait de la ressouce

Oui mais, un seul serveur serait nécessaire plutôt que d'alourdir tout
les "receveurs". Et un json ne serait-il pas suffisant pour lister les
plugins dispos plutot que de charger la BDD ?

Je le répète, amha c'est à la source qu'il faut corriger, et donc optimiser les images avant de les envoyer sur des outils qui les distribuent. Perso, je passe toutes les images que je commit en png8 au lieu de png32, puis je les optimise avec trimage https://trimage.org/

Si tu parles d'envoyer un fichier json à tous les sites qui souhaitent avoir la liste des plugins, c'est déjà ce qu'on fait avec un fichier XML (et je crois bien que Eric a une piste pour utiliser du JSON de ce côté). Mais, si tu proposes de ne pas stocker en base et de transférer un JSON à chaque action sur les plugins, l'effet sera bien pire niveau bande passant (une fois de plus, désolé ^^).

++
b_b

#12

Yop,

Le mer. 13 nov. 2019 à 14:28, Bruno Bergot <bruno@eliaz.fr> a écrit :

Je le répète, amha c’est à la source qu’il faut corriger, et donc
optimiser les images avant de les envoyer sur des outils qui les
distribuent. Perso, je passe toutes les images que je commit en png8 au
lieu de png32, puis je les optimise avec trimage https://trimage.org/

Là je pense que c’est assez simple et surement utile vu l’objectif recherché.
Et je suis sur qu’on est pas tous vertueux comme b_b.
Ce qui serait pas mal c’est d’édicter quelques recommandations sur le sujet car j’avoue que je n’ai pas du tout le réflexe sur les images et que je pourrais pas mal améliorer ça dans les plugins que je maintiens.
En général je mets des png surement 32 et je ne passe pas d’optimisation.
Après y a la taille aussi, comme pour le logo d’un plugin qui est souvent variable alors que je crois qu’on ne l’affiche jamais à plus de 32px dans le privé et peut-être 64 dans Plugins SPIP. On pourrait se donner une taille max et revoir les autres. D’ailleurs y a un index qui est créé par Smart-Paquets qui permet de visualiser les logos extraits lors du traitement et qui sont transférés par SVP : on y voit toutes les tailles…

Si tu parles d’envoyer un fichier json à tous les sites qui souhaitent
avoir la liste des plugins, c’est déjà ce qu’on fait avec un fichier XML
(et je crois bien que Eric a une piste pour utiliser du JSON de ce
côté).

Oui si on établit que Contrib devient le référentiel des plugins, il existe maintenant une API REST qui permet de récupérer cette collection en JSON qu’on pourrait utiliser à la place des xml ce qui éviterait d’en récupérer n et aussi limiterait le nombre et donc la taille transférée puisqu’on ne rapatrierait que les plugins compatibles avec la version de SPIP du site demandeur (le XML contient toujours tous les plugins).
Donc on gagnerait globalement en bande passante je pense.

Mais, si tu proposes de ne pas stocker en base et de transférer
un JSON à chaque action sur les plugins, l’effet sera bien pire niveau
bande passant (une fois de plus, désolé ^^).

Par contre, je pense qu’il est mieux de stocker tout ça en BD, ça fait l’effet d’un cache et c’est donc plus performant au vu de l’objectif recherché.

++

Eric

#13

Hi,

C’est intéressant et je le note mais vrai, ce n’est pas mon propos de trouver des solutions au cas par cas ou pour un site particulier. Ce qui m’intéresse c’est de voir à quels endroits on peut (ou pas) faire baisser la charge énergétique.

#14

Oué Maieul tu disgresse, tu aurais du faire un autre fil, et là sur bigfoot l’exemple est assez clair :
on insère 10 lignes de js dans le head pour initialiser la config de la lib.
C’est pas le script qu’on insère inline, c’est juste une variable de config.

Tu peux tourner 10 fois autour du pot, c’est la façon la plus efficace et écologique de faire ça !
Ces 10 lignes de config pèsent quelques centaines d’octets.
Si tu veux les éviter tu vas devoir faire un fichier js externe juste pour cette config et le maintenir ce qui implique plein de code
Ou alors tu vas faire un js en squelette et l’inclure dans les scripts et là c’est une horreur, compare le cout de calculer une page SPIP en plus par rapport au cout des 10 lignes de PHP qui insèrent ce JS.
Et sans compter que si tu mets cette config dans un fichier externe, si la config change ton fichier change, et donc tous le JS concaténé change, donc il faut tout reloader chez tous les visiteurs. C’est aussi très mauvais.

Bref là ce qui est fait sur bigfoot est la meilleure pratique.

Comme dit en début de fil, la gestion de la performance (qui va bien souvent avec l’optimisation globale de l’effort à produire pour servir des pages) est un vrai gros problème complexe que tu ne peux traiter qu’en ayant une reflexion globale, car si tu regardes juste une partie du problème ça te mène à des modifications qui te donnent l’impression d’optimiser la partie que tu regardes, mais en fait du dégrade le global.
Et corrolairement, il y a rarement de solution idéale et universelle, ce sont des compromis.

--
Cédric
Le 13 nov. 2019 à 14:23 +0100, Maïeul Rouquette <maieul@maieul.net>, a écrit :

Le mercredi 13 novembre 2019 à 14:11 +0100, Bruno Bergot a écrit :
> Hop,

>
> On digresse là, mais pour en revenir à bigfoot, si tu parles des
> quelques pauvres lignes insérées dans le head pour initialiser le
> script
> cf
>
https://zone.spip.net/trac/spip-zone/browser/spip-zone/plugins/bigfoot/trunk/bigfoot_pipelines.php#L23
>
> je pense que ce n'est pas "grand chose" par rapport au poids total de
> la
> lib
>
https://zone.spip.net/trac/spip-zone/browser/spip-zone/plugins/bigfoot/trunk/javascript/littlefoot.min.js

certes, mais pour autant je ne comprend pas ca raison d'être en html pas
en ligne
>
> De plus, on a déjà abordé maintes fois la question du "doit on
> insérer
> un script tout le temps ou uniquement après détection de son besoin
> dans
> la page" pour en conclure que c'est contre productif.
>

qu'est-ce qui est finalement contreproductif ?
> ++
> b_b

#15

mais précisement, c'est ce genre d'explication que je voulais.
Comprendre pourquoi ce choix. Et savoir ce qui est plus intéressant
entre un chargement à chaque hit ou un fichier js a calculer de manière
plus globale. Et maintenant je l'ai.

Et je ne vois pas en quoi est-ce une digression dans un fil précisement
sur la question de l'optimisation.
Le mercredi 13 novembre 2019 à 15:42 +0100, Cerdic a écrit :

Oué Maieul tu disgresse, tu aurais du faire un autre fil, et là sur
bigfoot l’exemple est assez clair :
on insère 10 lignes de js dans le head pour initialiser la config de
la lib.
C’est pas le script qu’on insère inline, c’est juste une variable de
config.

Tu peux tourner 10 fois autour du pot, c’est la façon la plus efficace
et écologique de faire ça !
Ces 10 lignes de config pèsent quelques centaines d’octets.
Si tu veux les éviter tu vas devoir faire un fichier js externe juste
pour cette config et le maintenir ce qui implique plein de code
Ou alors tu vas faire un js en squelette et l’inclure dans les scripts
et là c’est une horreur, compare le cout de calculer une page SPIP en
plus par rapport au cout des 10 lignes de PHP qui insèrent ce JS.
Et sans compter que si tu mets cette config dans un fichier externe,
si la config change ton fichier change, et donc tous le JS concaténé
change, donc il faut tout reloader chez tous les visiteurs. C’est
aussi très mauvais.

Bref là ce qui est fait sur bigfoot est la meilleure pratique.

Comme dit en début de fil, la gestion de la performance (qui va bien
souvent avec l’optimisation globale de l’effort à produire pour servir
des pages) est un vrai gros problème complexe que tu ne peux traiter
qu’en ayant une reflexion globale, car si tu regardes juste une partie
du problème ça te mène à des modifications qui te donnent l’impression
d’optimiser la partie que tu regardes, mais en fait du dégrade le
global.
Et corrolairement, il y a rarement de solution idéale et universelle,
ce sont des compromis.

#16

Super ! hophophop Excuse moi, il est où cet index ? Waaa, mais y’a plein de solutions là ! pas de soucis, je pose juste des questions parfois naïvement, je n’ai pas les outils de calcul pour une requête Json sur un fichier interne au site

#17

Le 13 nov. 2019 à 15:29 +0100, toutati <toutati@free.fr>, a écrit :

Hi,
C'est intéressant et je le note mais vrai, ce n'est pas mon propos de trouver des solutions au cas par cas ou pour un site particulier. Ce qui m'intéresse c'est de voir à quels endroits on peut (ou pas) faire baisser la charge énergétique.

Oui mais justement, on a pas de solution miracle pour « faire baisser la charge énérgétique » pour tout le monde dans tous les cas. On peut optimiser certains cas d’usages, et essayer d’élargir la couverture avec des configurations.
Mais là encore c’est à double tranchant : les configurations ça donne l’impression qu’on traite tous les cas alors que in fine ça repose sur la capacité de l’utilisateur à comprendre comment configurer pour son cas d’utilisation, et donc on a autant de risque qu’il dégrade le résultat plutôt que de l’améliorer, sauf à faire des supers tutos, docs, assitants de configuration…

Perso je vois bien juste une page avec des cases à cocher pour télécharger le core SPIP +tels ou tels plugins-dist zippé à la demande, mais c'est peut-être impossible à réaliser. Ou bien il faut pouvoir demander la désactivation depuis le BO de certains plugins-dist. Medias est le plus lourd (17Mo) et il faut voir si il est remplaçable par du plus light, c-a-d juste du oembed par exemple qui piocherait dans le dossier IMG/ftp ou autre

Mais justement, par exemple medias c’est un des plugins les plus indispensables dans SPIP actuellement

Quel serait ton/votre idée précisément là-dessus ?
Et l'idée qui est derrière tout ça, et peut-être illusoire (mais on a le droit de rêver) c'est de pouvoir switcher (en se passant au mieux de BDD) pour choisir de n'utiliser que des textes et des images et les agencer grace à SPIP. Et cette idée est ancienne et n'est pas de moi… Voila, voila …

J’ai l’impression que ce que tu décris ressemble plus à ce que font aujourd'hui les générateurs de site statique. Ou au projet de fil d’outil qui construisait un site en se basant simplement sur une arborescence fichier de documents textes et images, sans base de donnée

C’est une autre direction, un autre projet, et ça n’est pas moins intéressant, mais ça ne réponds pas au même besoin.

Clairement si la question est « comment faire un site de 10 pages avec SPIP qui occupera pas plus de 10Mo sur l’espace disque » la réponse est « c’est pas avec SPIP que tu feras ça »
On peut le regretter, mais c’est aussi le prix d’une grande souplesse et de beaucoup de possibilité.

Même si ça n’empêche pas de se poser des questions et de faire du mieux que l’on peut, il y a des objectifs qui sont totalement antagonistes.
Et ça ne veut pas dire pour autant que SPIP n’est pas écologique.
Je pense au contraire qu’aujourd’hui c’est un des outils de publications les plus efficaces et les moins dispendieux, dans la catégorie des CMS ou apparentés, notamment si tu le compares avec les outils mainstream comme wordpress.
Mais ça reste incomparablement plus lourd et complexe que tout ce que tu pourras faire avec un générateur de site statique.

Mais une autre approche par exemple c’est la mutualisation.
Si au lieu de déployer un SPIP complet pour chaque site, tu mets en commun une instance de SPIP pour N sites, tu divises le poids des sources par N.

Juste pour illustrer que la réponse elle se trouve à tous les niveaux, pas uniquement à celui des développeurs, mais aussi comment les utilisateurs choisissent leur outil et pour quoi, et comment ils les utilisent.

Cédric

#18

Le 13 nov. 2019 à 15:52 +0100, toutati <toutati@free.fr>, a écrit :

Le 13/11/2019 à 15:04, Eric Lupinacci a écrit :
>
> > > Si tu parles d'envoyer un fichier json à tous les sites qui souhaitent
> > > avoir la liste des plugins, c'est déjà ce qu'on fait avec un fichier XML
> > > (et je crois bien que Eric a une piste pour utiliser du JSON de ce
> > > côté).
> >
> > Oui si on établit que Contrib devient le référentiel des plugins, il existe maintenant une API REST qui permet de récupérer cette collection en JSON qu'on pourrait utiliser à la place des xml ce qui éviterait d'en récupérer n et aussi limiterait le nombre et donc la taille transférée puisqu'on ne rapatrierait que les plugins compatibles avec la version de SPIP du site demandeur (le XML contient toujours tous les plugins).
> > Donc on gagnerait globalement en bande passante je pense.
Waaa, mais y'a plein de solutions là !

Un parfait exemple de « l’enfer est pavé de bonnes intentions » :slight_smile:

Remplacer un fichier statique (le xml actuel) par une API REST et donc du PHP, et ici même du SPIP pour servir un index de plugins, c’est de l’ordre de 50 fois plus couteux en terme d’effort machine sur le serveur source.

Il va falloir en gagner de la bande passante pour compenser ça !

Cédric

#19

Yop,

Le mer. 13 nov. 2019 à 16:03, Cerdic <cedric@yterium.com> a écrit :

Donc on gagnerait globalement en bande passante je pense.

Waaa, mais y'a plein de solutions là !

Un parfait exemple de « l’enfer est pavé de bonnes intentions » :slight_smile:

Remplacer un fichier statique (le xml actuel) par une API REST et donc du
PHP, et ici même du SPIP pour servir un index de plugins, c’est de l’ordre
de 50 fois plus couteux en terme d’effort machine sur le serveur source.

Alors là c'est pas tout à fait vrai.
La requête sera toujours la même dans ce cas et sera donc en cache.
Donc il sera assez rare que l'on recalcule sauf à échéance du cache.
Je ne saurais pas évaluer d'ailleurs le cout de chaque solution mais tu
vois que c'est encore plus compliqué que tu ne le disais :p.

++
Eric

#20

Non justement, je compare un hit en cache SPIP, qui nécessite PHP, et donc de lancer le moteur SPIP, avec un hit sur un fichier statique qui est donc servi par apache, voire Varnish.
Si jamais tu dois EN PLUS faire du calcul de ton cache SPIP, c’est bien pire (tu peux multiplier l’effort par 10 environ encore).

A contrario, le fichier statique servi par apache/Varnish, il a une date de génération connue, et donc potentiellement le client peut le demander avec un Not-Modified-Since ce qui evite même de le renvoyer !

On n’en est pas toujours conscient, mais entre envoyer un fichier statique et envoyer du contenu généré par SPIP (même en cache) on est pas du tout sur le même ordre de grandeur en terme d’effort serveur

--
Cédric
Le 13 nov. 2019 à 16:12 +0100, Eric Lupinacci <eric@smellup.net>, a écrit :

Yop,

> Le mer. 13 nov. 2019 à 16:03, Cerdic <cedric@yterium.com> a écrit :
> > > > > Donc on gagnerait globalement en bande passante je pense.
> > > Waaa, mais y'a plein de solutions là !
> >
> > Un parfait exemple de « l’enfer est pavé de bonnes intentions » :slight_smile:
> >
> > Remplacer un fichier statique (le xml actuel) par une API REST et donc du PHP, et ici même du SPIP pour servir un index de plugins, c’est de l’ordre de 50 fois plus couteux en terme d’effort machine sur le serveur source.
>
> Alors là c'est pas tout à fait vrai.
> La requête sera toujours la même dans ce cas et sera donc en cache.
> Donc il sera assez rare que l'on recalcule sauf à échéance du cache.
> Je ne saurais pas évaluer d'ailleurs le cout de chaque solution mais tu vois que c'est encore plus compliqué que tu ne le disais :p.
>
> ++
> Eric