J’essaie d’améliorer le First Contentful Paint (FCP) et le Largest Contentful Paint (LCP) avec ces deux PR :
Je suis très intéressé par l’impact réel de ces changements – alors s’il vous plaît, essayez-les et donnez votre avis.
Et bien sûr, toute aide pour les tests, le refactoring et la couverture des tests est plus que bienvenue.
Le premier ressemble à une optimisation facile qui me semble logique. @david et @eviltrout ont passé du temps à optimiser ce domaine, je serai donc très curieux de voir ce qu’ils en pensent.
Le second semble un peu plus fragile à long terme, je comprends tout à fait le désir d’optimiser, mais cela m’inquiète un peu car ce sera un domaine que nous devrons entretenir.
Salut @rrit - merci pour les PRs. La première semble être une bonne amélioration. Avez-vous pu mesurer l’impact sur les performances ? Combien de temps cela permet-il d’économiser ?
Comme l’a dit @sam, la maintenabilité de la seconde est un peu préoccupante. On dirait une copie/coller du code source d’Ember ? Avez-vous modifié quelque chose afin d’améliorer les performances ?
Implémenté maintenant via Map au lieu de Array.
Temps passé au démarrage de l’application dans lookupView - pour une instance de développement :
sans patch : 124 ms
Firefox Profiler (callstack filtré sur lookupView)
avec patch : 9 ms
Firefox Profiler (callstack filtré sur lookupView)
Temps économisé : ~115 ms
Cela réduit le temps passé dans appendOutletView de 1,083 ms à 946 ms - pour une instance de développement.
Oui, c’est en fait un copier-coller avec un changement : utiliser une vérification peu coûteuse pour isPath.
// remplace @ember/-internals/utils isPath
// @see: https://github.com/emberjs/ember.js/blob/3537670c14883346e11e841fcb71333384fcbc87/packages/%40ember/-internals/metal/lib/path_cache.ts#L5-L7
// @see: https://github.com/emberjs/ember.js/blob/255a0dd3c7de1187f4a2f61a97cf78bfff8f66a8/packages/%40ember/-internals/glimmer/lib/utils/bindings.ts#L70
let isPath = context.indexOf('.') > -1;
Par exemple, renderTopicListItem déclenche finalement de nombreux appels à _getPath (encore 50-100 ms à économiser) :
Firefox Profiler (callstack filtré sur _getPath à l’intérieur de renderTopicListItem)
Peut-être que les appels coûteux à _getPath sont quelque chose à optimiser dans Ember.js et non dans Discourse.
Et consultez Firefox Profiler pour avoir un aperçu de l’exécution JavaScript :
Merci pour les correctifs. Le second semble un peu fragile.
Vos benchmarks s’exécutent-ils en mode développement ou en mode production ? Ember a un profil assez différent dans les deux cas.
@david a trouvé une excellente façon de résoudre ce problème - voir son commentaire sur github.
Le temps d’appel à renderTopicListItem sur la page Web ‘latest’ passe de 348 ms à 201 ms dans une build Ember ‘production’.
Les benchmarks précédents s’exécutaient toujours en mode développement.
# Démarrer ember en mode production
d/ember-cli server --environment="production"
Malheureusement, je n’ai pas réussi à reproduire cette augmentation de vitesse significative. Sur Firefox et Chrome (macOS), je ne constate aucune amélioration mesurable. Chrome passe environ 23 ms dans renderTopicListItem. Firefox 30 ms. Sur un ancien appareil Android (Pixel 3), je constate environ 108 ms. Les chiffres ne semblent pas changer avant/après le changement.
Soit dit en passant, j’ai mesuré ces chiffres en utilisant l’ API de performance. J’ai ajouté performance.mark("rtli-start") au début de renderTopicListItem, puis performance.measure("rtli", "rtli-start") à la fin.
Ensuite, j’ai rechargé le navigateur avec les outils de développement fermés et les plugins du navigateur désactivés (les outils de développement et les plugins du navigateur peuvent affecter considérablement les performances de rendu). Ensuite, une fois le chargement terminé, j’ai ouvert les outils de développement et exécuté ceci pour additionner les mesures :
performance.getEntriesByName("rtli").reduce((v, m) => v + m.duration, 0);
Nous allons certainement fusionner ce changement - c’est clairement une meilleure implémentation. Mais je ne suis pas sûr que cela nous donne une différence visible en termes de performances de rendu 
Je peux toujours reproduire les avantages en termes de performances en utilisant l’API de performance en mode privé de Firefox (Linux).
Test de http://localhost:4200/latest
Le temps passé dans renderTopicListItem est passé d’environ 290 ms à environ 190 ms.
Mon instance de test Discourse contient de nombreux sujets avec de nombreuses réponses et de nombreux auteurs différents - données extraites d’une instance productive. Cela entraîne de nombreux éléments à rendre.
C’est peut-être la différence dans nos benchmarks ?
Discourse pré-rendu 30 sujets sur la page ‘latest’. Ensuite, le contenu est affiché pour la première fois (FCP). Sous le pli, seulement ~12 sujets sont visibles.
Même pour une page de sujet : 20 posts pré-rendus, mais un maximum de 6 posts sur une ligne sont visibles sous le pli.
Cela pourrait être un autre point d’optimisation pour le FCP.
Pourriez-vous partager les versions de Firefox et de l’OS ? Le nombre de 290 ms est presque 3 fois plus lent qu’un appareil Android de 2018, ce qui est un peu surprenant.
Cela pourrait expliquer une partie de la différence, oui. Dans mon cas, je les ai exécutés en utilisant des données en direct de Meta :
bin/ember-cli --environment production --proxy https://meta.discourse.org
Oui, c’est une amélioration possible. Cependant, nous devrons être très prudents pour que la mise en page et/ou le défilement ne sautent pas (par exemple, si l’utilisateur actualise la page alors qu’il est déjà à mi-chemin). La définition de « sous la ligne de flottaison » varie également en fonction de l’appareil/du navigateur/du thème.
Malheureusement, l’exécution d’ember avec un proxy échoue pour moi :
d/ember-cli --environment production --proxy https://meta.discourse.org
Erreur de compilation Discourse
Erreur [ERR_TLS_CERT_ALTNAME_INVALID]: Le nom d'hôte/IP ne correspond pas aux noms alternatifs du certificat :
Hôte : localhost. n'est pas dans les noms alternatifs du certificat : DNS:*.cdck-prod-meta.discourse.cloud
Erreur de compilation Discourse
Erreur [ERR_TLS_CERT_ALTNAME_INVALID]: Le nom d'hôte/IP ne correspond pas aux noms alternatifs du certificat :
Hôte : meta.discourse.org. n'est pas dans les noms alternatifs du certificat : DNS:*.cdck-prod-meta.discourse.cloud
Extrait de Firefox about:support
| Nom | Firefox |
|---|---|
| Version | 95.0.2 |
| ID de compilation | 20211219102529 |
| ID de distribution | canonical-002 |
| User-Agent | Mozilla/5.0 (X11; Linux x86_64; rv:95.0) Gecko/20100101 Firefox/95.0 |
| Système d’exploitation | Linux 5.10.0-0.bpo.9-amd64 #1 SMP Debian 5.10.70-1~bpo10+1 (2021-10-10) |
| Thème du système d’exploitation | Adwaita-dark / Adwaita |
| Fichier du programme d’application | /snap/firefox/777/usr/lib/firefox/firefox |
| Nom | Firefox Developer Edition |
|---|---|
| Version | 96.0b10 |
| ID de compilation | 20211228195952 |
| Répertoire de mise à jour | /opt/firefox-dev-autoinstall |
| Canal de mise à jour | aurora |
| User-Agent | Mozilla/5.0 (X11; Linux x86_64; rv:96.0) Gecko/20100101 Firefox/96.0 |
| Système d’exploitation | Linux 5.10.0-0.bpo.9-amd64 #1 SMP Debian 5.10.70-1~bpo10+1 (2021-10-10) |
| Thème du système d’exploitation | Adwaita-dark / Adwaita |
| Fichier du programme d’application | /opt/firefox-dev-autoinstall/firefox-bin |
Extrait de Chromium chrome://system/
| VERSION CHROME | 90.0.4430.212 compilé sur Debian 10.9, exécuté sur Debian 10.11 |
|---|---|
| VERSION OS | Linux : 5.10.0-0.bpo.9-amd64 |
Version de l’OS :
# cat /etc/os-release
PRETTY_NAME="Debian GNU/Linux 10 (buster)"
NAME="Debian GNU/Linux"
VERSION_ID="10"
VERSION="10 (buster)"
VERSION_CODENAME=buster
ID=debian
La PR pour le refactoring est maintenant fusionnée :
Merci d’avoir soulevé ce point @rrit - c’est une belle amélioration !
Ce sujet a été automatiquement fermé après 9 heures. Les nouvelles réponses ne sont plus autorisées.