Javascript qui rame sous Chrome

[Ernestine]

Bonjour,

Après plusieurs mois d'utilisation de Google Chrome, je reviens progressivement à Firefox, car Chrome est vraiment décevant :

_ incapable de rendre correctement les polices de caractères non standard (elles sont toutes crénelées dès que le texte est un peu gros)

_ incapable d'afficher le contenu alternatif d'une image (quand l'image n'existe pas il la remplace par une vieille icône)

_ la plupart des extensions, ou fonctionnalités d'extensions, ne fonctionne pas sur les fichiers locaux, pour des raisons soit disant de sécurité.

_ et surtout : le manque de fluidité des effets javascript

Et c'est le sujet de mon message : le javascript. Sur un PC correct, avec une carte graphique correcte, les effets visuels fonctionnent correctement. Mais dès qu'on est sur du matériel un tout petit peu ancien, les effets visuels en javascript sous Chrome sont très mal rendus : ça rame, ça sacade, etc...

Je réalise actuellement un site bourré de JS. Tout marche très bien sous tous les navigateurs : IE (versions 7, 8 et 9), Firefox, Opéra, de même que sur Safari iPhone et iPad. Mais sous Chrome, c'est visuellement franchement pas terrible. Testé sur cinq ordinateurs différents : ceux qui sont dotés d'une carte graphique correcte, ça passe, mais sinon, ça sacade. Les effets de slide, de fade, etc, ne sont pas fluides. Ce n'est pas dramatique, mais quand même assez gênant.

Ma question : y a-t-il des bonnes pratiques à mettre en place pour développer du JS qui fonctionne bien sous Chrome ? Des trucs à éviter ? Des astuces ?

[SStephane]

Je n'utilise pas chrome du tout (ou très rarement), cela dit il me semblait qu'il avait été vendu en prétendant justement d'excellentes perf de ce côté.

Cela dit, je suis entrain de faire une appli bourrée de JS et je n'ai aucun problème particulier avec Chrome et je n'ai jamais remarqué de baisse de perf en JS (pour le reste je me prononce pas). Es-tu certain qu'une partie du code n'est pas à remettre en cause ? Un truc qui plairait pas à chrome spécifiquement, je pense aux trucs un peu aléatoires... timers, tween etc.

[captain_torche]

Tu utilises une librairie, ou du JavaScript "pur" ?

[Ernestine]

Captain >Je fais tout en jquery. Par contre je n'utilise aucun plugin tiers.

En fait, c'est un site "one page" : à chaque clic sur un lien, seule la partie centrale de la page est modifiée. Le contenu de la page suivante est chargé en ajax et vient glisser sur l'écran. En plus de ça, il y a de nombreux redimensionnements et repositionnements en JS. Donc au final, je reconnais que le JS est lourd. Mais étant donné que c'est fluide sur les autres navigateurs, je ne comprends pas pourquoi Chrome a tant de mal.

Es-tu certain qu'une partie du code n'est pas à remettre en cause ? Un truc qui plairait pas à chrome spécifiquement, je pense aux trucs un peu aléatoires... timers, tween etc.

Oui, c'est tout à fait possible, et c'est justement pourquoi j'ai ouvert ce sujet : il y a sûrement un truc que je fais mal. Depuis hier matin je fais des essais et j'ai quelques pistes. Par exemple, si je fais un slideshow dans lequel les images sont préalablement redimensionnées en JS, on dirait que Chrome le digère mal, et que par la suite, le glissement de ces images est légèrement saccadé. Mais je n'ai pas vraiment de réponse claire sur ce sujet.

Sur certains forums, j'ai vu que d'autres personnes avaient eu ce genre de problème, mais jusqu'à maintenant, ça reste très flou. Et c'est vrai que sur le papier, Chrome est réputé pour être performant au niveau javascript. Et il l'est certainement. C'est plutôt dans le rendu visuel que ça pêche.

PS : je vais essayer de vous montrer un exemple de code qui rame dans le courant de la journée, ou demain.

[Ernestine]

Bon, j'ai un peu amélioré les choses en faisant quelques optimisations :

_ utiliser des boucles for plutôt que la fonction each() de jquery (grosse différence de performance)

_ éviter au maximum d'insérer des éléments dans le DOM avec javascript. Il vaut mieux que les éléments soient présents dès le départ dans le code HTML. Donc suppression (dans la mesure du possible) de tout ce qui est wrap(), append(), etc... C'est moins bien d'un point de vue "portabilité" (car c'est quand même préférable quand le javascript s'occupe de générer tout ce dont il a besoin), mais ça permet un vrai gain de performance.

_ faciliter les sélectors en ciblant mieux (mettre des id plutôt que des class dans la mesure du possible)

_ et surtout : quand c'est le JS qui redimensionne les images, c'est surtout là que ça saccade sur Chrome, quand on fait un slideshow avec ces images (surtout qu'en plus je dois faire slider le slideshow lui-même !). Le problème c'est que dans mon cas précis la taille de ces images doit s'adapter en proportion à l'écran et à sa position et d'autres critères. Au final je charge les images en Ajax, en envoyant les dimensions voulues en paramètre (donc envoyées correctement dimensionnées par le serveur). Par contre si l'utilisateur redimensionne sa fenêtre, le redimensionnement en js est obligé (je peux quand même pas les redemander au serveur pour si peu)

_ il y a aussi le fait que j'ai toujours l'outil de développement de Chrome ouvert. Or cet outil consomme beaucoup : dès qu'on le ferme, la fluidité des effets visuels complexes est bien meilleure.

Au final, ça va donc à peu près, désormais c'est encore légèrement saccadé, mais ça reste très correct, quoique nettement moins fluide que sous Firefox, Safari iPad et même IE.

En tous cas merci à vous

[Ernestine]

BINGO !!!

J'ai trouvé. Aussi incroyable que ça puisse paraître, c'est un simple

body {
background-size: 100%;
}

dans la CSS qui faisait buguer Chrome.

Certes, c'est une propriété CSS3, mais même avec

-webkit-background-size: 100%;

ça pose problème, de même qu'avec

-webkit-background-size: cover;

et toutes autres sortes de combinaisons pour la valeur (excepté "auto" bien sûr).

Si vous voulez tester, voir le fichier en pièce jointe : c'est un slideshow minimaliste qui tient en un seul fichier (les images sont sur le net).

Sous chrome, si vous laissez le backround-size sur le body, ça fait saccader considérablement le slideshow. Si vous l'enlevez (ou le mettez en "auto"), ça devient parfaitement fluide. Etonnant non Pour quelle raison un background-size sur le body a-t-il un impact sur la fluidité du slideshow ? Uniquement sur les ordinateurs un peu anciens (je l'ai constaté sur 3 PC sur 5 ici).

index.html