Forum : 3 - Le site : philosophie, organisation, problèmes...

Bonjour Samuel!
En effet, chez moi aussi le site est très lent.

Peut-être existe-t'il un système de "cache" sur Tiki pour accélérer un peu l'affichage

Merci pour les recherches @Samuel.

L'option "deflate" n'est pas activée chez notre hébergeur car (de la bouche d'un admin de TF) : "ils ont eu des soucis avec du segfault d'Apache en folie. Cette option peut également casser la crypto TLS."

Au sujet de l'option d'activation gzip, je viens de l'activer à l'instant. Tu nous diras si tu sens une amélioration ces jours-ci, et il faudra également veiller à ce qu'on ne soit pas victime de "page blanche" comme indiqué dans la documentation "Compression" de Tiki .

C'est chouette si ça améliore la rapidité d'affichage des pages du site.

Hello,

Personnellement, je n'y crois pas trop (il serait bon de tester avant/après l'activation de la compression).

Le serveur mets du temps à répondre. Une fois qu'il s'est décidé, le contenu est servi rapidement.

Je pense plutôt à des goulots d'étranglements au niveau base de données (serveur à genou, base de données non optimisée énorme...) ou serveur web. Difficile à dire sur une plateforme mutualisée.

A+
Erwan

C'est vrai que ce site n'est pas des plus rapides, mais perso, vu ma connexion, ce n'est pas pire que de nombreux autres. Et vu la qualité du contenu, je suis prêt à attendre 10 secondes!
De ma petite expérience, les 2 actions les plus simples pour gagner facilement un peu de temps:
- compactage des scripts javascript (c'est différent de la compression)
- mise en cache des pages

Après comme déjà évoqué, si la BDD est sur un autre serveur, il peut y avoir des problèmes de débit entre les serveurs. Mais ça tu ne peux pas le savoir, c'est le gestionnaire de l'infra qui peux regarder.
Coté BDD, il faut d’abord faire quelques mesures pour savoir ce qui prend du temps. 3 Go pour la base, ça reste gérable avec tu mariaDB normalement.

Je retire ce que j'ai dit ! Enfin partiellement

De mon point de vue, le site semble plus véloce (au moins actuellement).

A voir avec le temps.

@Samuel : tu pourrais refaire tes prises d'info google speed insight / lighthouse stp et voir s'il y a une différence notable ?

Le site me semble plus rapide ce soir sous chromium. C'est moins flagrant avec Firefox (même machine).
Mais bon, ça dépend aussi de la qualité de ma connexion à un instant donné
Qu'est ce qui a changé dans la config?

Chez moi ausi, la différence est flagrante ! Le site se charge quasiment aussi vite que n'importe quel autre (Firefox)
Édit : pour publier un message, c'est toujours lent !

https://lighthouse-dot-webdotdevsite.appspot.com//lh/html?url=http%3A%2F%2Flinuxmao.org

Je suis dubitatif. J'ai aussi l'impression que le site est plus réactif, mais d'un autre côté, les mesures n'ont pas changé.

J'ai fait des captures d'écran pour voir où ça coince. Je charge ça dès que je suis sur un ordi fixe.

Je n'aime pas trop les outils google, ils ont un peu trop orienté vers une utilisation de chrome.
Je préfère utiliser plusieurs autres ressources, par exemple pour la page d'accueil du site:
https://smallseotools.com/fr/page-speed-test/
https://developers.google.com/speed/pagespeed/insights/?hl=fr&url=https%3A%2F%2Flinuxmao.org%2F
https://www.dareboost.com/fr/report/a_35fd371a9e6f78d3a4d29f10f?reportIds=a_35fd371a9e6f78d3a4d29f10f

Le temps de chargement constaté se situe entre 3 et 5 secondes. La moitié du temps, c'est l'attente de la réponse du serveur, puis vient les chargements, en particulier des images et les scripts js
Ce qui ressort globalement:
- la page est lourde (2,3 Mo), il y a beaucoup à charger (d'où la recommandation de compresser, mais ce n’est qu’un pansement), et complexe (1208 éléments)
- l'image du logo pourrait être allégée (32 ko)
- il y a une autre grosse image (https://download.tuxfamily.org/linuxmao/tiki/img/linuxmao/accueil/distributions.png)
- il y a aussi beaucoup de petites images, ce qui augmente le temps coté serveur, tu pourrais aussi réduire leur taille (Lmms, ardour,distributions, calf, tikilogo)
- coté css, c'est pas trop mal, est ce que tu as mis le plugin pour compacter le texte à charger ? (pas compresser, compacter). il y a beaucoup de petits fichiers, pas bon pour le serveur
- coté js, c'est le point noir. il faut absolument compacter, il semblerait que ce n'est pas fait. De plus, il y aurait des scripts inutilisés qui sont chargés pour rien. Et beaucoup de petits scipts, pas bon pour le serveur.
- il ressort aussi qu'il n'y a pas de mise en cache correcte. Je ne connais pas l'en tete Vary: Accept-Encoding, mais il semblerait que ça améliorerait la compression

si j'ai le temps je ferais la même chose pour l’accueil du forum

Pour l’accueil du forum, on retrouve globalement la même chose
La page fait 2MB
L'image du logo, et les images en général
du javascript non utilisé
javascript et css à optimiser (minify)
Trop d'objets dans la page

Attention toutefois. Ce ne sont que des analyses du temps de chargement. Elles ne tiennent pas compte du temps de réponse du serveur. Ca se mesure normalement coté serveur, mais j'ai trouvé un site qui le mesure, sans trop préciser comment
https://www.bitcatcha.com/report/1b062b2d5d0e47b08839daff0067b91a/
Et c'est plus que correct pour cette page

Quelques tests sur ma machine avec les firefox developer tools
Temps de chargement total: 17 secondes. Les temps les plus longs:
temps de réponse du serveur: 3,2 secondes
Les css: 2s
le js: 6,2 s. Sauf pour tikijsplugin language=fr qui met 12 secondes
les images: 11 secondes . La plus grosse étant, et de très loin, le logo linuxmao.png; son chargement prend 3s.

Attention, les temps ne se cumulent pas. après la réponse du serveur, les chargements démarrent en parallèle
Vous pouvez regarder ce que ça donne chez vous si vous avez firefox
Ouvrez la page à analyser
ouvrez les developer tools avec Ctrl + Shift + E, onglet réseau
rechargez la page
Plus d'infos sur
https://developer.mozilla.org/en-US/docs/Tools/Network_Monitor

Je ne vois pas de fichier nommé "linuxmao.png".
Est-ce que tu voulais dire "logo.png" peut être ?
Si oui, il s'agit de la tétière : https://download.tuxfamily.org/linuxmao/tiki/img/linuxmao/logo.png. Si tu sais comment la réduire en taille sans la réduire en qualité, dis moi.

oui le logo. Sans réduire la qualité, ça va être compliqué. Tu es déjà en couleur 8 bits RVB. 469 x 64 = 30 k pixels
Tu peux jouer un peu sur la résolution. Je l'ai enregistré en jpeg avec une qualité de 70%; la taille est divisée par 2, et le visuel reste identique. Je ne sais pas si tu peux utiliser des images jpeg.

mais le plus gros gain se fera un "minifiant" le css et le js

Je trouve super de s'occuper de ça. Mertci piratebab pour tes connaissances et olinuxx pour les implémentations.

Je viens d'activer la minification du CSS et sa mise dans un fichier unique.
J'ai purgé les caches de Tiki.

On va bien voir si ça accélère.
Pour l'instant, je n'en ai pas l'impression.

merci olinuxx

De mon coté je ne perçois pas de différence (mais ça reste subjectif car non mesuré). Par contre là où je trouve le temps long, c'est plus lors des requêtes. Il y a une latence assez importante entre la requête et la réponse du serveur. Mais là c'est probablement plus chez tuxfamily. Au prix de l'hébergement de linuxmao, on ne va pas se plaindre.

Même sur Raspberry Py 2b, le site se charge rapidement passé le délai de réponse du serveur.

C'est quand même un gros site web avec une grosse BDD. Peut être qu'une suppression des vieux messages inutiles (et jamais consultés) pourrait améliorer les choses. Voire une purge des utilisateurs qui ne se sont pas connecter depuis x années. Mais là c'est un travail de titan.

Pour ce qui est des images et du CSS, ils sont conservés dans le cache des navigateurs. À moins de venir ici trop rarement. Le CSS minifié pèse 111k chez moi. Pas la mère à boire et peu de gain possible.

Salut tout le monde,
Je ne sais pas trop comment participer à tout ça, donc je reste spectateur.
Si vous arrivez à accélérer les temps de chargement ce sera encore plus sympa !
Merci à tous en tout cas.