[RÉGLÉ] site hyper lent

[Cosmic]

bonjour
je trouve mon site particulièrement lent depuis quelques jours avec ou sans LSCache activé. Il est actuellement hébergé chez O2switch

https://test.smilecollector.photos/fr/photos/dance

cliquez par exemple sur l'article appelé "l'étrange musée"

bon alors on est d'accord que comme c'est un site de photos, ça prend de la place à charger mais ici j'ai l'impression que c'est le serveur lui-même qui prend du temps... ça prend plus de 20 secondes avant que la "page ne change"

il y a un "preloader" pour faire en sorte que les visiteurs attendent mais il faut pour ça que la page commence à charger

vous avez une idée de ce qui pourrait se passer?

PS: et je veux bien savoir comment vous controler...

[pmleconte]

Bonjour,

Si vous testez avec gtmetrix, le message est clair : optimisez vos images : https://gtmetrix.com/reports/test.sm...hotos/Sn2asIvG

Vous pouvez gagner 3mb minimum en le faisant.

Un petit coup de compression des JS (JCH Optimize par exemple) devrait pouvoir accélérer un peu plus.

Pascal

[pmleconte]

En complément, essayez aussi le format webp qui optimise aussi les images. Je viens d'essayer sur vos basketteurs et je suis passé de 510ko à 84ko pour la même qualité d'affichage.

Pascal

[Cosmic]

je vais regarder à ça merci

même si ça veut dire recommencer les 400 galeries déjà créés

[Cosmic]

mais, ça explique pourquoi la page met du temps à charger mais pas les 20 secondes de latences entre le clic et le changement - c'est celui-là que je ne comprends pas

[Cosmic]

ceci dit, il y a peu d'images en général à 510ko elles sont plus autour de 110k...

le spectacle de danse par exemple, les images ont des tailles entre 40ko et 110Mo (avec quelques unes à 130Mo)

la 510Mo est une pure erreur

[RobertG]

Bonjour,

Il ne faut pas oublier la saturation du réseau Internet qui ralentit souvent les transferts et donc l'affichage des pages.

[pmleconte]

Lorsque le nombre d'images et leur taille posent problème, j'utilise lazyload : https://kubik-rubik.de/llfj-lazy-load-for-joomla

Cela permet de ne charger que les images visibles sur l'écran dans un premier temps. Reste à savoir si c'est compatible avec votre CCK...

Pascal

[Cosmic]

Il ne faut pas oublier la saturation du réseau Internet qui ralentit souvent les transferts et donc l'affichage des pages.

possible en effet d'autant que ça explique aussi les lenteurs de mon ftp que j'ai oublié de mentionner plus haut
.
.

Lorsque le nombre d'images et leur taille posent problème, j'utilise lazyload : https://kubik-rubik.de/llfj-lazy-load-for-joomla

Cela permet de ne charger que les images visibles sur l'écran dans un premier temps. Reste à savoir si c'est compatible avec votre CCK...

je vais regarder même si ma galerie utilise déjà un lazyload

.
.

Bonjour,

A première vue, c'est le traitement PHP qui semble prendre du temps, pourtant vous utilisez une version récente de PHP et opcache est bien actif également.

Avez-vous installé une extension dernièrement ? Si c'est le cas, pouvez-vous essayer en désactivant les extensions que vous avez pu installé dernièrement pour voir si cela rend le site plus rapide ?

Généralement lorsque cela bloque sur la partie PHP, c'est lié à une extension ou un thème de site. Si des traitements lourds sont effectués sur chaque page, ça prendre du temps sur PHP et il y aura cette latence au premier accès.

les deux composants principaux de mes pages utilisent le PHP: Balbooa Gallery et FlexiContent. (c'est déjà pour ça que j'ai du finalement partir de chez OVH parce que l'accès aux tables est limité)
.
.


du coup:

1) j'ai modifié la photo de 500Mo (forcément)

2) j'ai réduit les requêtes en limitant les indexations de Flexicontent

3) j'ai dégagé LSCache qui est la dernière extension que j'ai ajoutée (pour voir mais ça aurait dû améliorer)

4) envisager de remplacer Balbooa et donc de refaire 319 galleries pour l'instant mais je ne connais aucune extension faisant la même chose sans passer par une table

pfff

résultat: pas mieux pas pire - on reste dans l'impasse

[woluweb]

à noter que pour le lazy load, il suffit depuis cette année de mettre un loading="lazy" comme attribut de l'image...

[Cosmic]

à noter que pour le lazy load, il suffit depuis cette année de mettre un loading="lazy" comme attribut de l'image...

ah oui - bon à savoir ça
mais bon les galeries sont gérées par une extension

[daneel]

Bonjour,

1. Quelques erreurs dans la console du navigateur incluant une belle erreur 500 dans la page indiquée en lien. Cela se confirme dans étrange musée avec une erreur sur le chargement de la librairie fcxSlide (slider de flexicontent), le conflit js est une piste à explorer.

2. Concernant lscache, il faut vérifier qu'il fonctionne bien, on doit retrouver "x-litespeed-cache: hit" comme je l'ai déjà expliqué à plusieurs reprises.
Je ne connais pas assez O2switch pour savoir si ce sont bien des serveurs ls pour gèrer l'intégralité du domaine (et sous-domaines), mais la présence de l'indicateur dans l'entête donnera la confirmation. Dans le cas contraire, il faudra voir avec l'hébergeur.

3. Je ne suis pas entièrement d'accord sur le conseil de Pascal qui propose d'utiliser JCH (du moins dans une réponse immédiate). La console du navigateur, c'est un peu le passage obligé et préalable avant toute optimisation. Il faut partir d'une configuration dénuée de compression, de minification, fusion pour ne pas avoir initialement créé des erreurs.

Perso, quand la console (du navigateur) n'affiche pas d'erreurs, j'active le rapport d'erreurs "en développement" dans la configuration de joomla pour contrôler si une extension fonctionne correctement dans la version php que j'utilise. En utilisant les dernières versions de php7, il n'est pas rare que certaines extensions n'ont pas suivis l'évolution, ce qui m'oblige à travailler leur code. Enfin je termine en vérifiant le temps d'execution des requête SQL en activant le débogage système de Joomla, cela donne des mesures concrètes et cela permet de voir si certaines nécessitent d'être en cache comme virtuemart par exemple.

4. C'est seulement par la suite que je travaille l'optimisation car je sais que la moitié du travail est déjà fait !
Tout ce qui a été dit précédemment sur le sujet est bon (y compris sur les images) mais assurez-vous toujours de partir d'un site "propre"

5. Si vous utilisez des extensions d'optimisation (comme jch), contrôlez régulièrement afin de ne pas avoir d'erreurs après leur activation. Pour cela, prenez la page optimisé puis effacez le contenu de la console du navigateur puis rafraichissez la page pour voir toute la liste des erreurs au chargement. Les erreurs doivent être corrigées, les "notices" sont à surveiller.
Certains fichiers js n'apprécient pas forcément d'être fusionnés ou d'être déplacés dans l'ordre de chargement.

Voilà, je sais que l'on peut passe beaucoup de temps, donc bon courage !
N'hésitez pas à créer votre propre checklist et revenir sur le forum pour en discuter.

[pmleconte]

....

3. Je ne suis pas entièrement d'accord sur le conseil de Pascal qui propose d'utiliser JCH (du moins dans une réponse immédiate). La console du navigateur, c'est un peu le passage obligé et préalable avant toute optimisation. Il faut partir d'une configuration dénuée de compression, de minification, fusion pour ne pas avoir initialement créé des erreurs.

...

Merci de me rappeler les réflexes du parfait debugger et j'avais zappé le contrôle des erreurs
Bon dimanche,

Pascal

[Cosmic]

bonjour daneel
merci pour la réponse
.
.

1. Quelques erreurs dans la console du navigateur incluant une belle erreur 500 dans la page indiquée en lien. Cela se confirme dans étrange musée avec une erreur sur le chargement de la librairie fcxSlide (slider de flexicontent), le conflit js est une piste à explorer.

une des deux erreurs 500 est facile à résoudre même si techniquement, il n'y a pas de "readmore" sur cette page... c'est une option qu'on active ou pas dans Flexi mais je vais juste rajouter l'image pour tous...

par contre, pour la plus grosse (celle ci-dessous), je n'ai aucune idée de par où commencer à regarder. mais comme c'est le php qui semble déconné (d'après o2switch), ça pourrait être une partie de mon souci.

bootstrap.min.js?96971e75880dbcf3f48f2d6c6bcdf6a8:6 Uncaught Error: COLLAPSE: Option "parent" provided type "boolean" but expected type "(string|element)".
    at Object.typeCheckConfig (bootstrap.min.js?96971e75880dbcf3f48f2d6c6bcdf6a8:6)
    at a.t._getConfig (bootstrap.min.js?96971e75880dbcf3f48f2d6c6bcdf6a8:6)
    at new a (bootstrap.min.js?96971e75880dbcf3f48f2d6c6bcdf6a8:6)
    at HTMLDivElement.<anonymous> (bootstrap.min.js?96971e75880dbcf3f48f2d6c6bcdf6a8:6)
    at Function.each (jquery.min.js?96971e75880dbcf3f48f2d6c6bcdf6a8:2)
    at a.fn.init.each (jquery.min.js?96971e75880dbcf3f48f2d6c6bcdf6a8:2)
    at a.fn.init.a._jQueryInterface [as collapse] (bootstrap.min.js?96971e75880dbcf3f48f2d6c6bcdf6a8:6)
    at HTMLDocument.<anonymous> (dance:350)
    at u (jquery.min.js?96971e75880dbcf3f48f2d6c6bcdf6a8:2)
    at Object.fireWith [as resolveWith] (jquery.min.js?96971e75880dbcf3f48f2d6c6bcdf6a8:2)

je comprends que ça se joue au niveau du template mais est-ce le template en lui-même qui bug ou une extension (Flexi par exemple puisque c'est, je pense, la seule extension qui modifie le template... tout du moins de la partie "component") qui interagirait mal... et franchement, comment comprendre tout ce qui est écrit pour le néophyte que je suis dans les pages de lien?

pour les warnings concernant les cookies, je vois qu'il y a des pages d'aide, je m'en vais aller lire ça... mais ça semble concerner une version future de Chrome donc j'ai un peu de temps
.
.

2. Concernant lscache, il faut vérifier qu'il fonctionne bien, on doit retrouver "x-litespeed-cache: hit" comme je l'ai déjà expliqué à plusieurs reprises.
Je ne connais pas assez O2switch pour savoir si ce sont bien des serveurs ls pour gèrer l'intégralité du domaine (et sous-domaines), mais la présence de l'indicateur dans l'entête donnera la confirmation. Dans le cas contraire, il faudra voir avec l'hébergeur.

Pour l'instant je l'ai désactivé, je vais regarder plus tard sur ce point mais je garde précieusement ce conseil...
.
.

3. Je ne suis pas entièrement d'accord sur le conseil de Pascal qui propose d'utiliser JCH (du moins dans une réponse immédiate). La console du navigateur, c'est un peu le passage obligé et préalable avant toute optimisation. Il faut partir d'une configuration dénuée de compression, de minification, fusion pour ne pas avoir initialement créé des erreurs.

4. C'est seulement par la suite que je travaille l'optimisation car je sais que la moitié du travail est déjà fait !
Tout ce qui a été dit précédemment sur le sujet est bon (y compris sur les images) mais assurez-vous toujours de partir d'un site "propre"

question idiote: comment partir d'une configuration dénuée de compression, de minification, fusion pour ne pas avoir initialement créé des erreurs? je ne me souviens pas avoir activé des options de ce genre mais quid des extensions? ça veut dire désactivé les extensions? ou tu parles d'autre chose?
.
.

5. Si vous utilisez des extensions d'optimisation (comme jch), contrôlez régulièrement afin de ne pas avoir d'erreurs après leur activation. Pour cela, prenez la page optimisé puis effacez le contenu de la console du navigateur puis rafraichissez la page pour voir toute la liste des erreurs au chargement. Les erreurs doivent être corrigées, les "notices" sont à surveiller.
Certains fichiers js n'apprécient pas forcément d'être fusionnés ou d'être déplacés dans l'ordre de chargement.

je ne pense pas avoir ce genre d'extension
.
.

Voilà, je sais que l'on peut passe beaucoup de temps, donc bon courage !
N'hésitez pas à créer votre propre checklist et revenir sur le forum pour en discuter.

merci pour le courage - je n'ai de toute façon plus de cheveux à m'arracher
pour créer une checklist, il faudrait savoir où on met les pieds