Les performances c'est compliqué. La preuve, tout le monde s'égosille depuis quelques temps sur FireFox3PlusRapideDeLaTerre, alors que chez moi, il rame au défilement comme une vieille brouettes dés qu'il y a plus de 10 contrôles (édition d'un Post Drupal) ou une image de fond statique sur une page.
Pareillement, j'ai longtemps cherché à améliorer la vitesse de FireFox v2 pour retrouver un peu de la vélocité de Konqueror, avec plus où moins de succès. Ce billet n'est donc pas un appeau à Trolls, juste le fruit de mes petites recherches pour botter un peu les fesses du gros panda 
Modifier les paramètres cachés de FireFox
Cela va nous servir par la suite donc autant en parler tout de suite. Les options que nous allons activer sont disponible dans les paramètres internes de firefox, pas dans ses préférences. Pour y accéder il suffit de taper l'URL about:config. S'affiche alors une liste de noms/valeurs. En double cliquant sur une ligne, nous pouvons modifier cette valeur. En clickant droit, il est possible de la supprimer ou d'en créer une nouvelle.
Pour les nouvelle valeur crées, il faut choisir son type : chaîne (string), valeur booléenne (boolean) et valeur entière (integer). Ensuite il faut donne son nom, puis sa valeur.
Voilà, avec cela nous allons pouvoir jouer un peu
Performances réseau
Avouons que la vitesse de transfert est peu la base des performances d'un navigateur, avec celle du moteur de rendu. FireFox n'est pas pire qu'un autre navigateur de ce point de vue. Cependant, comme souvent, ses concepteurs ont des "stratégies" qui ne sont pas forcement heureuses.
Activation du pipelining
C'est une chose étrange que le pipelining (téléchargement en parallèle des éléments) soit désactivé par défaut sur FireFox. Pour l'activer, il suffit simplement de modifier trois valeurs. Les deux premières active le pipeline en mode normal et avec les proxies. La dernière indique le nombre maximum de requête à traiter en parallèle.
network.http.pipelining=true
network.http.proxy.pipelining=true
network.http.pipelining.maxrequests=30
La dernière valeur peut être modulée selon vos goûts mais un nombre trop important ne servirait à rien. A noter que selon mes tests, ce totoche de FireFox v2 refuse de charger les feuilles CSS et JS en parallèle, ce qui est proche de l'aberrant...
Supprimer la résolution IPV6
Une autre modification qui peut améliorer les performances est donc de désactiver la résolution DNS pour l'IPV6 (sauf si vous avez un tel réseau . Le but est d'éviter que FireFox ne s'amuse à résoudre un nom en IPV6 lorsque cela n'a aucune raison d'être :
network.dns.disableIPv6 = true
Pour aller plus loin...
Enfin, comme l'indiquait FreeFlyer, un très bon plugin permet de paramétrer une partie de ces valeurs. Il s'agit de FasterFox. Ce plugin est très dense, il permet de régler le pipelining comme indiqué plus haut, mais permet aussi d'ajouter le téléchargement silencieux des liens d'une page, et pas mal d'autres goodies. A tester donc.
Performances visuelles
XUL
Là il s'agit de la lenteur de l'interface même de FireFox, pas du rendu des pages. C'est la latence que l'on constate par exemple pour afficher la page de préférences.
Techniquement, l'interface graphique de FireFox est décrite par des fichiers XML (barres d'outils, menus, etc...) formant une sorte de langage de description d'interfaces, le XUL. Ces fichiers XML sont "animés" par des... scripts en javascript. En somme, FireFox est une fenêtre vide et tout ce qu'il y a à l'intérieur de cette fenêtre est du XUL. Pour s'en convaincre, collez chrome://browser/content/browser.xul dans la zone d'adresse de FireFox et validez.
L'interface graphique de FireFox est donc totalement interprétée et sa vitesse est par conséquence limitée par l'utilisation de javascript qui est clairement plus lent qu'un équivalent compilé en C. Une bonne manière de s'en convaincre est de lancer epiphany qui pour un temps encore utilise le même moteur de rendu que Firefox : Gecko . Mais dans le cas d'Epiphany, toute l'interface est codée en C, c'est beaucoup plus réactif, beaucoup moins gourmand en mémoire, mais aussi clairement moins puissant.
La aussi, pour ce prouver que ce n'est pas un délire subjectif, il suffit d'utiliser oprofiler pour auditer l'utilisation du processeur lorsque l'on affiche des boites de dialogues, des menus, le résultat est le suivante :
12475 18.4517% libmozjs.so
Le problème est qu'il n'y a pas grand moyen d'améliorer les choses sur cet aspect. Passons donc à la suite.
X11
Alors je sens que je vais faire débouller des armées de trolls colériques en disant cela, mais X11, c'est pas un scoop, c'est lent. Et c'est logique, car au même titre que le couple XUL/JS apporte une richesse payée par une certain lenteur, X11 et la transparence réseau permettent des montages impossibles ailleurs (genre des écrans déportés sur des machines distribuées), mais induisant des temps d'affichages supérieurs à d'autres environnement. Allez disons le, c'est plus lent que Windows.
Et pour s'en convaincre une fois de plus, ce n'est pas sorcier. Installez une VM avec Windows et les pilotes optimisés VMWare, installez y la même version de FireFox que sous Linux, et comparez les deux vitesses d'affichage d'une page. C'est le jour et la nuit et pourtant Windows est dans une VM...
Alors peut-être n'est-ce pas lié qu'à X11, mais aussi à ce que la version Windows de FireFox a été un peu plus bossée, mais le résultat est là. Et là aussi, mis à part éviter de ralentir X11 en préférant les pilotes propriétaires (nVidia notamment), il n'y a pas de recettes miracles pour booster tout cela.
A noter que l'utilisation de xrestop nous montre que FireFox est un mangeur de ressources de tout premier ordre. Ce qui ne doit pas être sans conséquences sur les performances sous X11.
Diminuer le temps d'attente avant rendu visuel d'une page
Finalement, le seul point sur lequel nous pouvons jouer est l'aspect "psychologique" de la vitesse. Si une page met 10 secondes à se charger, le navigateur semblera plus "lent" s'il attends d'avoir toutes les informations pour l'afficher. Nous allons donc indiquer à firefox de lancer le rendu de la page le plus tôt possible. Cela est possible en créant une nouvelle "valeur entière" dans la paramétrage interne de FireFox (voir plus haut) et en fixant à 0ms le temps d'attente avant rendu visuel de la page.
nglayout.initialpaint.delay=0
Conclusion
On ne peut pas dire qu'avec tout cela j'atteigne la vitesse de konqueror mais c'est mieux... On va se consoler avec cela
Euh toute petite remarque, essaie avec la 3.0.1 de FF qui je pense corrige le bug de ressources.. J'avais un site qui me faisait monter le CPU (les CPU) au plafond en 3.0 et qui ne dépasse pas les 20% en 3.0.1..
Attention à ces conseils :
* network.http.pipelining.maxrequests=30 veut dire que FF fera 30 requêtes HTTP simultanées à chaque affichage de page ! C'est bien pour soi mais pas sûr qu'une fois généralisée, cette pratique ne fasse autre chose qu'effondrer des serveurs ; on peut difficilement masquer des problèmes de conception de sites par ce biais là
* network.dns.disableIPv6 = true : désactiver IPv6 alors qu'il faudra le réactiver dans quelques temps, ça n'a pas non plus de sens. "Arrêtez de rouler Hybride tant qu'y de l'essence", c'est ce que ça veut dire
* nglayout.initialpaint.delay=0 : là encore tu joues avec le comportement "standard" des navigateurs
Au-delà de la performance, il faut je pense d'abord comprendre les intérêts de ces réglages. Ça n'a pas été mis là par hasard
@Oncle Tom je ne comprend peut-être pas mais je fais mon maximum pour essayer généralement
* Concernant le pipelining, disons déjà que la RFC 2616 (HTTP), qui date d'environ 13 ans, ça compte, recommande un maximum de deux connexions simultanées. Par défaut, si l'on active cette option sur FireFox, cette valeur est de 4 en standard.
Après, j'avoue ne jamais avoir bien compris le point avec cette histoire. Certes j'occupe plus de bande passante, mais pendant moins longtemps. Pour moi, limiter ce paramètre c'est un peu comme faire une pointe de vitesse avec un réservoir vide pour gagner au plus vite la pompe à essence. Le résultat, quel que soit le nombre de connexion ne dépassera pas ce que notre bande passante peu offrir et ce qui est pris, est rendu en temps. Je laisse plus vite la place en somme.
Maintenant, il y a une option dans FasterFox que je trouve éminemment dangereuse et qui me ferait te rejoindre. C'est le prefetching. Là il y a clairement gaspillage de ressource et réel danger pour les serveurs car le seul fait de visiter une page entraîne le téléchargement de tous les liens locaux qui s'y trouvent et génère autant de requête (et de connections simultanées si le pipelining est activé). Là, je suis d'accord, c'est une véritable ânerie.
* Concernant l'IPV6, ça fait plus de 10 ans que c'est "sur le point d'arriver". Je n'ai jamais dit qu'il était idiot de mettre cela par défaut dans FireFox, mais pour l'instant, ce n'est pas là, et c'est là en revanche, une requête, et donc des ressources dépensées pour rien. Même motif, même punition pour le kernel qui est sur mandriva configuré en IPV6 et qui te pourris les logs de "No IPV6 router found"... En somme, ça va sûrement venir un jour mais pour l'instant c'est pas là. Et un kernel en IPV4 comme Firefox est plus véloce..
* Concernant l'initialPaint, je joue avec l'ergonomie. Afficher un sablier c'est du temps en moins pour le calcul, mais sans sablier, l'utilisateur perçoit tout comme plus lent. Là c'est pareil, voir que ça bouge donne une impression de dynamisme plus agréable que sagement attendre que tout soit chargé. Mais là, je ne m'en cache pas dans le billet, c'est très subjectif.
Pour conclure il n'y a rien, pour un utilisateur, "au delà des performances". Maintenant je suis d'accord, c'est beaucoup de travail pour un résultat assez triste.
J'aimerais bien connaître vos sources d'informations pour configurer firefox! comme ça
je pourrais me faire ma propre idée!
Ben c'est sympa ça, comme si l'auteur de ce blog n'avait pas pour habitude de vérifier de ses sources avant d'écrire un article
!
A part ça, sur le site de Mozilla, tu trouves la signification de ces éléments de configuration (très explicites cela dit).
Je ne remets pas en doute l'authenticité, je cherchais juste la source d'infos pour explorer les autres params de config. je viens de trouver aussi http://kb.mozillazine.org/About:config_entries
,
Petite coquille: l'auteur de ce non-blog!
Petit lien pour yugoboss:
http://kb.mozillazine.org/Firefox_:_FAQs_:_About:config_Entries
Merci J.
Il est niquel ce (non)blog (que je viens de découvrir ce matin)
@Yugoboss il n'y avait pas de problème pour ta question
Mais j'aurais bien en mal de te répondre car cet article est un split d'un plus vieille article d'il y a deux ans que j'ai mis à jour (qui est ici au passage). Donc les sources, depuis le temps, je ne les avait plus.
Sinon, un autre lien pas mal : http://www.formatic-pc.info/optimiser_firefox.php a utiliser en conjonction avec celui de J. car il manque gravement d'explications.
Le pipeline est inutile car supporté par apache, IIS depuis des lustres ...
Le delay également va consommé beaucoup de ressource cpu inutilement, en gros c'est un délai avant lequel firefox ne charge pas la page s'il na rien reçu.
En mettant à 0 firefox va tenter de rendre la page avant même d'avoir reçu le moindre octet du serveur.
Bref que de la tambouille fondés sur des légendes informatiques qui courent depuis un sacré bout de temps.
Là tu m'excuses mais je suis un peu curieux de comprendre.... Le Pipelining si je ne m'abuse, consiste à augmenter le nombre de requêtes concurrentes. Déjà je suis à peu prés sur de moi en affirmant que c'est possible, même sous IIS, depuis que IIS existe. Enfin, je ne vois pas bien en quoi le fait qu'un serveur soit capable de recevoir plusieurs requête en même temps implique qu'il ne soit pas nécessaire que le client émettent plusieurs requêtes concurrent pour que cela prenne du sens... A moins que le protocole HTTP n'ai grandement changé (lorsque j'avais le dos
) tourné et qu'un GET puisse accepter des URL multiples et renvoyer une sorte de "multi-part".
Tout est là : http://kb.mozillazine.org/Network.http.pipelining
Pour ce qui est de nglayout.initialpaint.delay, relis la doc (http://kb.mozillazine.org/Nglayout.initialpaint.delay) car elle indique que par défaut ce délais est déjà de 250ms et qu'il s'agit d'une mise à jour "incrémentale". Elle se base donc sur la différence en rapport à l'étape précédente. S'il n'y a rien à afficher, il n'affiche rien. En revanche s'il a des choses intéressantes à afficher à la 10ième milliseconde, il l'affiche. Alors certes cela a un coup CPU, mais autant qu'une barre de progression...
Maintenant me concernant, la vraie solution sera là quant Epiphany aura fini d'adopter WebKit. Après promis, si ça répond à mes attentes, j'écris plus de billet sur FireFox
Comme toi je ne voyais pas bien le rapport entre le fait qu'un serveur puisse accepter de multiples requêtes simultannées et la configuration du client iou alors je n'ai pas compris le sens du commentaire. Idem pour le delay, moi ça me va très bien que firefox commence à charger sans delay par exemple les images déjà misent en cache. Et pour finir je comprends encore moins la dernière phrase : de quelles légendes s'agit-il ?
Poster un nouveau commentaire