Je lis le log de commit et je réagis, mais je n’ai pas ausculté le code en détail car je n’utilise pas :
Achtung, achtung, achtung !
affichage_final est appelé à chaque hit, sans mise en cache, ce qui signifie donc ici que tu reconstruit le sprite à chaque hit (ou a minima que tu reliste toutes les images et vérifie que le sprite est bon).
C’est potentiellement très mauvais en terme de performance et charge serveur, et je doute que le jeu en vaille la chandelle (amha le temps perdu à chaque hit sur la génération/vérification du sprite ne justifie pas le gain potentiel obtenu derrière).
A contrario précédemment sur recuperer_fond, au moins tout ce qui concerne les modèles et les #INCLURE était en cache SPIP (parce que mis dans le cache de l’appelant).
--
Cédric
Le 19 oct. 2019 à 00:03 +0200, spip-zone-commit@rezo.net, a écrit :
Author: jluc@no-log.org
Date: 2019-10-18 22:02:57 +0000 (Fri, 18 Oct 2019)
New Revision: 118215
Modified:
_plugins_/creer_sprites_css/trunk/creer_sprites_fonctions.php
_plugins_/creer_sprites_css/trunk/paquet.xml
Log:
Les sprites sont desormais calcules une seule fois par page, via affichage_final. Les timestamps, qui avaient ete retires par erreur surement par r92857, sont restaures. On peut au besoin forcer le calcul des sprites au niveau de chaque fichier en utilisant #FILTRE{creer_sprite}. Fixes Connexion · GitLab
Je lis le log de commit et je réagis, mais je n’ai pas ausculté le code en détail car je n’utilise pas :
Achtung, achtung, achtung !
affichage_final est appelé à chaque hit, sans mise en cache, ce qui signifie donc ici que tu reconstruit le sprite à chaque hit (ou a minima que tu reliste toutes les images et vérifie que le sprite est bon).
C’est potentiellement très mauvais en terme de performance et charge serveur, et je doute que le jeu en vaille la chandelle (amha le temps perdu à chaque hit sur la génération/vérification du sprite ne justifie pas le gain potentiel obtenu derrière).
A contrario précédemment sur recuperer_fond, au moins tout ce qui concerne les modèles et les #INCLURE était en cache SPIP (parce que mis dans le cache de l’appelant).
Merci de veiller !
recuperer_fond appelait 100 fois par page la génération des sprites : pour chaque inclusion ... et chaque modèle !
Du coup
1) les sprites étaient spécifiques à chaque squelette, pas moyen d'ajouter une image dans un sprite commencé dans un autre squelette
2) impossible d'utiliser #LESAUTEURS ou #LOGO_XXX dans un squelette qui générait des sprites puisque ça réinitialisait le fichier généré.
Dans la version 1.3, j'ai corrigé un peu ce point en excluant explicitement l'appel lorsque c'est le modèle pour #LESAUTEURS ou #LOGO_etc (qui appelle un modèle au moins en 3.3) mais on ne peut toujours pas inclure une noisette ou un autre modèle car ça casse le calcul de sprite du squelette appelant.
Ça peut pas rester comme ça.
et de toute façon, avec Z & co, c'est bien plus intéressant, pour les sprites générés, de générer les fichiers au niveau de la page plutôt que du squelette.
Concernant les problèmes de perf de la version 2, as tu vu que le pipeline creer_sprite_affichage_final ne fait quelque chose QUE s'il y a des sprites dans la globale, ce qui ne se passe QUE le filtre |sprite a été exécuté et que de nouveaux sprites ont été générés.
Donc ça ne se passe QUE si il y a eu "calcul", et cet affichage_final n'a aucun coût s'il n'y a pas besoin de calculer.
N'est il pas ?
JL
--
Cédric
Le 19 oct. 2019 à 00:03 +0200, spip-zone-commit@rezo.net, a écrit :
Author: jluc@no-log.org
Date: 2019-10-18 22:02:57 +0000 (Fri, 18 Oct 2019)
New Revision: 118215
Modified:
_plugins_/creer_sprites_css/trunk/creer_sprites_fonctions.php
_plugins_/creer_sprites_css/trunk/paquet.xml
Log:
Les sprites sont desormais calcules une seule fois par page, via affichage_final. Les timestamps, qui avaient ete retires par erreur surement par r92857, sont restaures. On peut au besoin forcer le calcul des sprites au niveau de chaque fichier en utilisant #FILTRE{creer_sprite}. Fixes Connexion · GitLab
Oui dans ce cas en effet ! (comme dit dans mon mail, je n’ai pas analysé le code, juste réagis sur le principe).
Du coup ça arrive à gérer si juste un des squelettes a été calculé et à retrouver la sprite globale et mettre à jour si besoin ?
ou dans ce cas ça recréé une sprite pour ce seul squelette ?
J’ai quand même l’impression qu’il y a un soucis de principe : je ne vois pas très bien comment maintenir et actualiser proprement un sprite unique, transversalement à plusieurs squelettes différents et calculés pas forcément au même moment…
Et pour le coup avoir un sprite par squelette perd probablement beaucoup de son intérêt, sauf quand on fait beaucoup d’images dans un seul squelette, et je crois comprendre que c’est bien le point de départ et l’utilité de ce plugin.
(Bref ici j’arrive pas à voir si l’automatisation apporte réellement un gain)
--
Cédric
Le 21 oct. 2019 à 11:21 +0200, JLuc <jluc@no-log.org>, a écrit :
Concernant les problèmes de perf de la version 2, as tu vu que le pipeline creer_sprite_affichage_final ne fait quelque
chose QUE s'il y a des sprites dans la globale, ce qui ne se passe QUE le filtre |sprite a été exécuté et que de
nouveaux sprites ont été générés.
Donc ça ne se passe QUE si il y a eu "calcul", et cet affichage_final n'a aucun coût s'il n'y a pas besoin de calculer.
N'est il pas ?
Du coup ça arrive à gérer si juste un des squelettes a été calculé et à retrouver la sprite globale et mettre à jour si besoin ? Non il n'y a actuellement aucun cache statique des données permettant la génération du sprite final.
ou dans ce cas ça recréé une sprite pour ce seul squelette ?
Oui et euh... du coup il est inadapté à l'autre squelette
J’ai quand même l’impression qu’il y a un soucis de principe : je ne vois pas très bien comment maintenir et actualiser proprement un sprite unique, transversalement à plusieurs squelettes différents et calculés pas forcément au même moment…
Effectivement. C'était mon prochain chantier d'utiliser (ou tester...) ce nouveau feature
pour collecter dans un seul sprite les petits morceaux de déco éparpillés dans différentes noisettes,
mais maintenant je crains que ça ne marche pas.
Et pour le coup avoir un sprite par squelette perd probablement beaucoup de son intérêt, sauf quand on fait beaucoup d’images dans un seul squelette, et je crois comprendre que c’est bien le point de départ et l’utilité de ce plugin.
C'est entre autres ce qui a motivé l'évolution.
L'autre motif basique c'est qu'avec la version 1.3 il est impossible de faire une inclusion dans un squelette qui génère des sprites... ce qui est frustrant.
Une piste de fix serait d'intégrer, dans la globale, le nom du squelette qui a besoin d'une image,
et que la génération finale du sprite se fasse comme avant lors du pipeline recuperer_fond
mais QUE pour les sprites générés pour ce squelette.
(Bref ici j’arrive pas à voir si l’automatisation apporte réellement un gain)
Par rapport à quoi ?
JLuc
Le 21 oct. 2019 à 11:21 +0200, JLuc <jluc@no-log.org>, a écrit :
Concernant les problèmes de perf de la version 2, as tu vu que le pipeline creer_sprite_affichage_final ne fait quelque
chose QUE s'il y a des sprites dans la globale, ce qui ne se passe QUE le filtre |sprite a été exécuté et que de
nouveaux sprites ont été générés.
Donc ça ne se passe QUE si il y a eu "calcul", et cet affichage_final n'a aucun coût s'il n'y a pas besoin de calculer.
N'est il pas ?
Le 21 oct. 2019 à 12:18 +0200, JLuc <jluc@no-log.org>, a écrit :
Le 21/10/2019 à 11:40, Cerdic a écrit :
> (Bref ici j’arrive pas à voir si l’automatisation apporte réellement un gain)
Par rapport à quoi ?
JLuc
Par rapport à ne rien faire.
L’intérêt d’un sprite c’est d’avoir une seule image à charger au lien de N petites, donc d’optimiser le nombre de requêtes http et leur durée.
MAIS pour ça il faut que le sprite soit bien fait : qu’il puisse être unique sur tout le site et chargé une seule fois.
Si l’URL de ton sprite change sans arrêt parce que une des images change, ça devient pire, car on passe son temps à recharger une plus grosse image.
Si ton sprite est différent d’une page à l’autre, c’est totalement contre-productif, puisque ça veut dire que tu charges plusieurs fois les mêmes images, alors que sans sprite le navigateur aurait mis en cache les petites images de la première page, et à la seconde page il chargerait que celles qui lui manquent.
Et sans compter que les sprites ça avait un sens avant http2, mais maintenant que le navigateur sait tout tuneler (il charge tout à la suite dans une seule connexion http) ça perd beaucoup (voire totalement) de son intérêt potentiel
L’intérêt d’un sprite c’est d’avoir une seule image à charger au lien de N petites, donc d’optimiser le nombre de requêtes http et leur durée.
MAIS pour ça il faut que le sprite soit bien fait : qu’il puisse être unique sur tout le site et chargé une seule fois.
Oui et non.
Non car j'ai l'impression que (comme d'autres spipeurs) tu envisages l'usage des sprites seulement pour des éléments de déco sans sémantique.
Mais on peut s'en servir aussi pour les LOGOS et le portfolio des articles.
Ce n'est pas de la déco et ce n'est pas unique sur tout le site
car ça n'aurait pas de sens de charger sur toutes les pages les images du portfolio de tous les articles.
Mais Oui il ne faut des sprites différents que lorsque c'est nécessaire.
Par exemple sur passerelleco.info, tous les articles de la rubrique Agenda
partagent le même sprite pour leur colonne de gauche :
Et sans compter que les sprites ça avait un sens avant http2, mais maintenant que le navigateur sait tout tuneler (il charge tout à la suite dans une seule connexion http) ça perd beaucoup (voire totalement) de son intérêt potentiel
Ya un outil spécifique pour apprécier l'effet de http2 ?
Les logos pourquoi pas, car en effet ils n’ont pas de sémantique.
Mais remplacer les images d’un portfolio par un sprite par contre, c’est amha un contre-sens sémantique : tu remplaces une balise img avec un sens et un texte alternatif par une image en background spritée (perdant au passage toute possibilité d’afficher la seule image, la downloader, l’agrandir).
Sans compter que par les temps qui courent, une image de portfolio se doit d’avoir une taille importante pour avoir une qualité acceptable sur un image retina, et qu’en la spritant on perd tout possibilité d’adapter cette qualité ou de délivrer une image de taille suffisante (ou alors le sprite va avoir une taille phénoménale qui rallonge le temps à attendre avant de voir quoi que ce soit)
Là pour moi c’est vraiment un mauvais usage (mais tu fais bien ce que tu veux)
--
Cédric
Le 21 oct. 2019 à 13:01 +0200, JLuc <jluc@no-log.org>, a écrit :
Le 21/10/2019 à 12:40, Cerdic a écrit :
> L’intérêt d’un sprite c’est d’avoir une seule image à charger au lien de N petites, donc d’optimiser le nombre de
> requêtes http et leur durée.
> MAIS pour ça il faut que le sprite soit bien fait : qu’il puisse être unique sur tout le site et chargé une seule fois.
Oui et non.
Non car j'ai l'impression que (comme d'autres spipeurs) tu envisages l'usage des sprites seulement pour des éléments de
déco sans sémantique.
Mais on peut s'en servir aussi pour les LOGOS et le portfolio des articles.
Ce n'est pas de la déco et ce n'est pas unique sur tout le site
car ça n'aurait pas de sens de charger sur toutes les pages les images du portfolio de tous les articles.
Mais Oui il ne faut des sprites différents que lorsque c'est nécessaire.
> Et sans compter que les sprites ça avait un sens avant http2, mais maintenant que le navigateur sait tout tuneler (il
> charge tout à la suite dans une seule connexion http) ça perd beaucoup (voire totalement) de son intérêt potentiel
Ya un outil spécifique pour apprécier l'effet de http2 ?
Les logos pourquoi pas, car en effet ils n’ont pas de sémantique.
Mais remplacer les images d’un portfolio par un sprite par contre, c’est amha un contre-sens sémantique : tu remplaces une balise img avec un sens et un texte alternatif par une image en background spritée (perdant au passage toute possibilité d’afficher la seule image, la downloader, l’agrandir).
Plus précisément c'est les vignettes qui sont spritées, mais pas les images du portfolio elles mêmes
qu'on peut afficher seules, downloader...
donc pas de gêne.
Et sans compter que les sprites ça avait un sens avant http2, mais maintenant que le navigateur sait tout tuneler (il
charge tout à la suite dans une seule connexion http) ça perd beaucoup (voire totalement) de son intérêt potentiel
Avec gtmetrix j'ai mesuré 4 ou 5 fois avec et sans sprite la page d'accueil :
Avec sprites :
- Total Page Size : 359KB
- Requests : 31
- Fully Loaded Time : entre 2.8s et 3s
- Contentful paint : 1,1s
Sans sprites :
- Total Page Size : 409KB
- Requests : 55
- Fully Loaded Time : 3.3s
- Contentful paint : 1,3s
Il revient régulièrement sur ton accueil. Et là il suffit qu'il y ait
UNE news qui a changé avec une vignette en plus, et hop il doit
recharger un énorme sprite de toutes les vignettes de la page (qui va
donc être différent). Alors que sans, il aurait déjà eu 99,9% des
vignettes dans son cache, et il n'aurait rechargé que LA vignette de la
news en plus.
C'est pas juste le fully load qu'il faut regarder donc, mais les
différences entre qu'est-ce qui va être mis en cache ou pas. Si les
sprites changent trop souvent, ça vaut moyennement le coup. Les sprites
c'est essentiellement utile quand la liste du contenu ne change pas ou
quasiment jamais.
J'ai du mal à voir le gain entre le temps passé à maintenir un code plus
compliqué dans ses squelettes et le mini gain (qui n'est même pas sûr
pour ce cas d'utilisation) que ça apporterait. Ce temps serait peut-être
mieux à configurer le serveur pour permettre le HTTP2 une fois pour
toute (et donc en one shot, sans avoir à maintenir un code compliqué
ensuite)
Et donc imagine un lecteur régulier :
Il revient régulièrement sur ton accueil. Et là il suffit qu'il y ait
UNE news qui a changé avec une vignette en plus, et hop il doit
recharger un énorme sprite de toutes les vignettes de la page (qui va
donc être différent). Alors que sans, il aurait déjà eu 99,9% des
vignettes dans son cache, et il n'aurait rechargé que LA vignette de la
news en plus.
Tu en viens à examiner des scénarii particuliers d'utilisation.
Le fait que ce plugin ne soit pas une solution universelle
n'est pas une critique rédhibitoire à son usage.
Il n'y a pas non plus de squelette ou de boucle universelles.
C'est vrai que le calcul d'un sprite est un peu lourd quand il se fait.
La situation que tu évoques met en avant l'intérêt d'avoir des sprites différents
pour des groupes d'images différents, pour optimiser la fabrication des sprites
selon la fréquence de raffraîchissement des images.
C'est possible avec ce plugin car
- il exige de nommer le sprite créé. On en crée un ou plusieurs par noisette
- dans chacun on met que ce qu'on veut.
Sur ce site (comme sur beaucoup) les articles bougent moins souvent que les forums.
Sur la page d'accueil il y a un sprite pour les articles et un pour les images
donc ça devrait bien se passer.
Il y a même 2 sprites pour les logos des articles de 2 types différents (rédactionnel ou actu)
étant donné qu'un sprite ne peut être défini et utilisé que dans une même noisette.
J'ai du mal à voir le gain entre le temps passé à maintenir un code plus
compliqué dans ses squelettes et le mini gain (qui n'est même pas sûr
pour ce cas d'utilisation) que ça apporterait.
C'est une vraie question,
qui peut amener aussi à ne pas utiliser "trop" de plugins différents.
Ce temps serait peut-être mieux à configurer le serveur pour permettre le HTTP2 une fois pour
toute (et donc en one shot, sans avoir à maintenir un code compliqué ensuite)
Sur ce site, http2 est actif ainsi que l'annonce la doc de l'hébergeur
et ainsi que j'ai vérifié avec HTTP/2 Test - Verify HTTP/2 Support | KeyCDN Tools
L'utilisation de creer_sprite_css améliore donc les temps de chargement
même avec http2 actif.
Je ne sais pas si l'allégement du poids total est la seule explication...
