J’ai passé beaucoup de temps à optimiser mon CSS, à supprimer des plugins, à éliminer les redirections, tout ce que je pouvais faire pour améliorer les temps de chargement, mais apparemment les principaux coupables sont :
mobile_4-randomcharacters-.css, qui contient normalize.css et Pikaday et se charge en 1,5 seconde sur mobile
et /assets/ember_jquery-randomcharacter-.js qui se charge en 3,6 secondes sur mobile
Je ne sais pas quoi faire avec ces fichiers, qui ont les temps de chargement les plus élevés.
Le chargement sur ordinateur de bureau est plus rapide, mais pas excellent.
Le serveur dispose d’un CPU, 2 Go de RAM, 50 Go de SSD et 2 To de bande passante sur un serveur professionnel basé aux États-Unis.
2 workers Unicorn, ni le CPU ni la RAM ne sont sous forte charge, et je n’ai pas beaucoup d’utilisateurs ni de plugins.
Des idées ? Merci.
thank you, PageSpeed Insights says the CPU time (not delivery time) specifically for the second asset was almost 4 seconds, will a CDN like fastly still help with that? I currently use cloudflare with caching, is there a tweak on cloudflare I should use or just add something like fastly on top?!
That is indeed a big asset that will take time to parse and evaluate. As Discourse is a “Single Page Application” that cost is all paid upfront when the user first arrive, and this is a trade-off of our the approach, which is focused on making all the subsequent interaction, typical of forum usage, lightweight.
There are plan for EmberJS to drop mandatory JQuery, which will reduce this payload a fair bit, but we are years away of making this transition in Discourse.
Well, the pagespeed defaults force a Nexus 5X and a 3G connection, which even for Brazil (a third world country) is on the low end for today standards, so real world performance will depend on that.
Les statistiques de performance du serveur n’affichent pratiquement aucune charge, pourtant l’URL met une éternité à se charger. J’ai chronométré 1,2 minute pour un visiteur non connecté dans une fenêtre de navigation privée, même lorsque plusieurs composants étaient déjà en cache. Les éléments les plus lents étaient les fichiers de police OpenSans en .ttf, avec plus d’une minute ; ensuite, plusieurs composants .js ont pris entre 30 et 45 secondes.
Je vais examiner les options de mise en cache, mais en regardant ces composants, je ne pense pas que tous puissent être mis en cache. Au total, seul 730 Ko de données ont été transférés. Si les 3 vCPU étaient sollicités à pleine capacité, je songerais à passer à un serveur plus rapide, mais même avec une charge minimale ou nulle, je suis simplement perplexe.
Y a-t-il quelque chose qui attend une autre ressource avant de pouvoir avancer ? Existe-t-il un moyen d’exécuter des tests sur le serveur pour vérifier l’état de santé des composants, comme la base de données ?
