Envole » Envole-Mutualisé » eole-dispatcher

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

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

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

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

Correspond à :

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

Dans import.js

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à

Comportement identique sur METICE, je viens de faire un test

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

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

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

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

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

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

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