Project

General

Profile

Anomalie #25517

Lenteur de chargment du bureau avec Firefox

Added by Renaud Dussol over 1 year ago. Updated over 1 year ago.

Status:
Fermé
Priority:
Normal
Assigned To:
Target version:
Start date:
10/10/2018
Due date:
% Done:

100%

Distribution:

Description

Cette demande fait suite à la conf téléphonique avec Christophe

Vu que j'étudie le pb de lenteur de chargement du bureau suite aux remarques de certaines utilisateurs, Christophe m'a demandé de comparer avec Chrome

Et il est vrai que les différences sont spectaculaires

Au final on a entre 3 et 12 secondes d'écart entre les deux, la valeur la plus courante étant 5-6 s de plus pour FF

Cela explique aussi pourquoi certains utilisateurs se plaignent et d'autres non...

J'ai remarqué autre chose : les temps de chargement de certaines ressources avec FF semblent très aléatoires, variant sans raison d'un chargement à l'autre, alors que sur Chrome cela semble plus constant

Les affichages en console qui montrent le plus de différence entre les 2 navigateurs sont les suivants :

STARTING (le début) : quelques ms pour Chrome, on est parfois à une demi-seconde pour FF
polymer version master : la différence varie entre 2s et 10 s ! (le plus souvent 2s) (quelques ms pour CH)
RECEIVE REMOTE CACHE : parfois aucune différence, parfois cela monte à +3.5
Waiting for Ressources... +2s
STEP2 FEDE : peut akller jusqu'à +1.5s
Récupération des messages : +1s en général

Il faudrait voir quelles sont les étapes qui se produisent entre ces chargements... et voir s'il n'y a pas un mécanisme (js ?) que FF gère mal...

Ou alors jeter définitivement FF à la poubelle ?
Cela nous embête car c'est le navigateur installé, maintenu et préconisé dans tous els établissements...

Pour d'autres étapes, les temps sont quasiment égaux entre les 2 navigateurs

eDispatcher_FF.mov (7.37 MB) Christophe LEON, 10/15/2018 07:22 AM

out-4.ogv (475 KB) Christophe LEON, 10/15/2018 07:36 AM

History

#1 Updated by Christophe LEON over 1 year ago

  • Status changed from Nouveau to En attente d'informations

Peux tu préciser la version de FF ?

Chez moi sous chrome

 +11ms =>    11ms :  STARTING
21:05:06.827 VM1325:31 +1ms => 12ms : window.WebComponents already charged
21:05:06.827 VM1325:31 +1ms => 13ms : Polymer already charged
21:05:06.985 VM1325:31 +157ms => 170ms : polymer version master

Sous FF 61.0.2 (64 bits) =================

 +5ms =>     5ms :  STARTING import.js:31:3
+2ms => 7ms : window.WebComponents already charged import.js:31:3
+542ms => 549ms : polymer version master

entre la ligne STARTING et la ligne polymer version master c'est le chargement de polymer qui est réalisé
a voir s'il y a une version compatible plus récente de polymer pour FF ou si des plugins particulier ralenti le chargement
peut être voir coté onglet network que tout polymer est bien en cache sur le navigateur

#2 Updated by Renaud Dussol over 1 year ago

Chez moi : FF 62.0.3

Mais le phénomène se produit depuis longtemps

La piste du plugin est intéressante : peut-être un adblocker ou un truc comme ça, je vais vérifier

Auquel cas cela expliquerait pourquoi les personnes se plaignant sont plutôt en général des utilisateurs "avancés"

Sur polymer, effectivement j'ai vu quelques trucs hier soir, notamment des API Phantom qui ne seraient pas otpimisées pour FF, mais j'ai survolé

Je regarde tout ça

#3 Updated by Renaud Dussol over 1 year ago

Rien de mieux en désactivant les extensions

Par contre fais plusieurs essais avec FF car les temps sont très aléatoires : je viens d'avoir un chargement de polymer à 450 ms, un autre à 1533ms, un autre à 520ms et un autre à 2148ms... (par contre j'avais "disable cache" coché

Je fais quelques essais sur la prod (hier c'était sur le serveur de test) en décochant bien "disable cache" cette fois :
Chrome à gauche du slash, FF à droite, les essais sont séparés par des |

polymer version master : 188ms / 3831ms | 402ms / 3275ms | 194ms / 2856ms
RECIEVE REMOTE CACHE : 383ms / 1757ms | 847ms / 1732ms | 462ms / 2063ms
Waiting for Ressources... : 1900ms / 2731ms | 1631ms / 3867ms | 1991ms / 3806ms
[STEP2 FEDE] : écart non significatif sur les 2 premiers essais... 3eme essai : 147ms / 3258ms
[TOKEN] 0060087M : 574ms / 3271ms au premier essai, écart quasi nul sur les suivants
Récupération des messages : 251ms / 1150ms | 151ms / 3011ms | 212ms / 1476ms
A noter que j'ai actuellement 2 chargements des ressources PP et donc 2 appels à la récupération des messages : il s'agit ici du 2eme, le premier ne montre pas d'écart signiificatif, au contraire souvent FF est plus rapide que Chrome dans ce cas...

A chaque fois, globalement on a un bureau chargé :

- Sous chrome : en 7-8s après le 1er chargement PP, 11-12 s après le 2eme, et 15-16s lors de l'event "CACHE USED" qui semble marquer la fin de tout
- Sous FF : en 12-13 s après le 1er chargement PP, 18-19 s apres le 2eme, et 21-22 s à CACHE USED

#4 Updated by Renaud Dussol over 1 year ago

Tester avec le X3 pour voir si notre template n'aggrave pas l'écart entre les 2 navigateurs
Car à la Réunion l'écart n'est pas aussi important que chez nous

#5 Updated by Renaud Dussol over 1 year ago

Aucune amélioration en utilisant le samples/x3, donc ce n'est pas lié au template

PAR CONTRE : maintenant que je commence à être habitué, je remarque quelques différences dans les outputs de chrome et firefox

1) une ligne que je vois systématiquement dans chrome et pas dans firefox :

+0ms =>    36ms : Polymer already charged

et qui arrive juste avant "polymer version master"

2) Une erreur qui est bien présente dans les 2, mais qui arrive beaucoup plus tôt dans Chrome (presque au début) :

  +1ms =>   534ms : starts elements loading

  DevTools failed to parse SourceMap: https://esterel.ac-nice.fr/edispatcher/ng/public/assets/js/md5.min.js.map

  +855ms =>  1389ms : RECIEVE REMOTE CACHE

Alors que dans firefox elle arrive complètement à la fin :

 +1ms => 12525ms : => AJAX

 Source map error: SyntaxError: JSON.parse: unexpected character at line 1 column 1 of the JSON data
 Resource URL: https://esterel.ac-nice.fr/edispatcher/ng/public/assets/js/v1.0+2-47
 Source Map URL: md5.min.js.map[Learn More]

 +4664ms => 17189ms : CACHE USED : 0.19 hour(s)

Bon déjà ce n'est peut-être pas normal que j'ai cette erreur (j'ai vérifié, elle est présente aussi sur METICE, donc ça ne doit pas être bien grave, mais peut-être faut-il corriger ?), mais le fait qu'elle soit traitée à des moments très différents m'interpelle...

Et d'autre part ce "Polymer already charged" indique clairement qu'un événement est détecté par chrome (présence de polymer en cache ?) et pas par FF

#6 Updated by Renaud Dussol over 1 year ago

Correspond à :


       if (typeof Polymer == 'undefined') {
            edispatcher_import(_EDISPATCHER+"/ng/public/polymer"+_POLYMERVERSION+"/polymer.html");
        } else {
            console.log("Polymer already charged")
        }

Dans import.js

#7 Updated by Renaud Dussol over 1 year ago

En fait, en ajoutant plusieurs logs sur le typeof Polymer, je m'aperçois que dans Firefox, durant tout le import.js, typeof Polymer est à undefined

Ce qui a pour conséquence que la plupart des chargements ne se font pas...

Polymer.Base.importHref( [_EDISPATCHER_ELEMENTS_PATH]) ne se fait pas
timerPolymer=setInterval(function() {
if (typeof Polymer 'undefined') return; > s'arrête ici

De toutes façons Polymer n'étant pas reconnu à ce moment là, cela retournerait une erreur

A la fin du import.js, Polymer est toujous undefined

DONC en fait, dans firefox, import.js NE FAIT RIEN (enfin si il charge les css, bootstrap et les fonts)
Alors que dans Chrome , j'ai l'impression qu'une grosse partie du boulot a déjà été fait...

Alors qu'au début de elements.html, si j'ajoute un typeof Polymer dans la console : j'ai bien "function"

Qu'est-ce qui se passe entre import.js et elements.html ?

Qu'est-ce qui a fait que Polymer a été enfin reconnu ?

.......

J'ai l'impression que dans la timeline de FF, import.js est systématiquement chargé en premier (juste après le template)

et polymer.html arrive bien aprés

Alors que dans chrome, import.js arrive après les chargements de jquery, bootstrap, webcomponents et... polymer.html

Donc dans FF, quand import.js s'exécute, il n'a pas encore reçu polymer...

Je ne sais pas à quoi c'est dû... j'ai essayé de déplacer l'appel à import.js au début du body dans layout.twig.html, j'ai essayé d'enlever le random tag, pour voir si ça ne venait pas de là, mais rien à faire, import.js est systématiquement appelé en premier, en tout cas TOUJOURS avant polymer.html

Je pense que bcp de problèmes viennent de là

#8 Updated by Renaud Dussol over 1 year ago

Comportement identique sur METICE, je viens de faire un test

#9 Updated by Renaud Dussol over 1 year ago

Apparemment Chrome est le seul navigateur a bien gérer les HTML imports

Références (pour Firefox) :
https://developer.mozilla.org/en-US/docs/Web/Web_Components/HTML_Imports

Une solution qui semble donner satisfaction est d'ajouter un enventListener sur le chargement complet des ressources nécessaires au premier script utilisant un import, comme décrit ici :

https://stackoverflow.com/questions/25819898/using-polymer-to-include-jquery-via-html-imports-not-working-in-safari-and-firef

Si je modifie le import.js.twig en ajoutant un eventListener au chargement de Polymer, cela accélère nettement le chargement de Polymer et c'est globalement plus rapide

Sinon, autre piste (qui pourrait expliquer pourquoi chez toi cela met moins de temps ) :

Apparemment une option permet d'activer la gestion des imports HTML dans Firefox

dom.webcomponents.customelements.enabled
dom.webcomponents.shadowdom.enabled

Par défaut elles sont à FALSE, peux-tu vérifier si c'est le cas sur tes Firefox ?

Sources :

https://stackoverflow.com/questions/33686393/link-rel-import-not-working-in-mozila-firefox
https://caniuse.com/#feat=imports

Je vais tester sur ma prod (sans la modif de import.js) et sur le serveur de test avec cette valeur modifiée

#10 Updated by Renaud Dussol over 1 year ago

Effectivement en activant ces options cela semble plus rapide

Toujours moins que Chrome mais globalement on gagne 2-3 s par rapport à avant

C'est encourageant, sachant que le FF est (je crois bien) déployé en établissement par des scripts donc on peut ajouter l'activation de cette option sur les déploiements (ou au moins au Rectorat)

La première astuce est finalement décevante : le eventListener fonctionne, mais il attend le chargement de polymer, qui prend autant de temps qu'avant... Donc on a bien "polymer already charged" mais il prend autant de temps à se charger...

Il faudrait voir s'il n'y a pas une alternative au HTML import

#11 Updated by Renaud Dussol over 1 year ago

En fait je viens de comprendre :

Dans chrome tout est chargé par les imports HTML
On peut carrément supprimer le JS webcomponents, cela fonctionne

Dans Firefox, tout est géré par webcomponents.js, le HTML import ne fonctionne pas (enfin, il se met à fonctionner une fois que webcomponents a lancé ses listeners)

C'est un fonctionnement "dégradé", non optimisé, et c'est moins rapide

Je ne pense pas qu'il y ait de solution...

En fait la solution serait (si j'ai bien tout compris ) de passer sur Polymer 3 qui utilise ES6

#12 Updated by Renaud Dussol over 1 year ago

Les options de about:config améliorent quand même le chargement

Malheureusement cela ne dispense pas de l'utilisation des webcomponents pour charger Polymer

#13 Updated by Christophe LEON over 1 year ago

J'ai passé quelques optimisations, notamment

- :acf82738 , qui permet de générer une url d'import js de la forme /edispatcher/ng/importjs/<id du user>/<version_ed>/<flags> au lieu de /edispatcher/ng/import.js?<flags>
la suppression du passage des flags en paramètre de query permet au navigateur de cacher cette url. La version et le id du suer sont mis dans l'url pour garantir un cache de l'url par user et en fonction de la version de eDispatcher

- :c4e922df , la détection des zones arena n'était pas en cache un && false traînait sur le test de la présence du cache

- :077f0244 , Cache-control directive pour /edispatcher/ng/public, permettant d'indiquer au navigateur de cacher tous les templates

En PJ une vidéo du chargement avec FF , chargement complet sur 3 sources ( Arena, Rectorat, eDispatcher acad ) en ~ 4s
correspond à la 8s sur la vidéo

Un constat intéressant , si je charge le bureau console de dev fermée et que je l'ouvre ensuite le temps de chargement de polymer est de l'ordre de 400ms
Sous FF console de dev fermé le bureau se charge en moins de 5s (cf pj out-4.ogv )

#14 Updated by Renaud Dussol over 1 year ago

Je n'ai qu'un mot : génial !
Merci, je vais tester ces modifs sur notre serveur de test
J'ai fait quelques essais chez moi ce WE

Sur safari : HYPER rapide (presque mieux que Chrome), c'est d'autant plus étonnant que caniuse indique que Safari semble ne pas supporter les imports HTML non plus
Sur Firefox Windows : même comportement que mon FF linux du boulot, même en activant les options du about:config
Sur Edge : mêmes lenteurs que sous FF. On dirait qu'on est face au même problème

Il y a un truc qu'il faut que je creuse : ce sont tous les navigateurs alternatifs qui sont basés sur moteurs chromium, comme Brave par exemple, qui est très bien et que j'utilise personnellement de + en +
L'idée étant d'offrir une alternative aux utilisateurs qui seraient grincheux d'avoir à utiliser uniquement chrome

#15 Updated by Renaud Dussol over 1 year ago

  • Status changed from En attente d'informations to Accepté
  • % Done changed from 0 to 90

Pour moi les fix semblent donner satisfaction concernant ce problème

Le plantage potentiel posé par le "async" sur le importjs semble avoir été réglé par le passage au "defer"

Je passe à 90%, on attend quelques temps et on pourra passer à résolu si pas de nouveau pb détecté...

#16 Updated by Christophe LEON over 1 year ago

Pour infos firefox 63, qui vient de sortir, supporte les webcomponents.

https://developer.mozilla.org/en-US/docs/Web/Web_Components

#17 Updated by Christophe LEON over 1 year ago

  • Status changed from Accepté to Résolu
  • Target version set to Envole 5.12
  • % Done changed from 90 to 100

#18 Updated by Arnaud FORNEROT over 1 year ago

  • Status changed from Résolu to Fermé

Also available in: Atom PDF