| Auteur | Pages : [>] [>>] |
|---|---|
| Raphael | # 06 Dec 2005 - 15:08:11 |
Mangez des kiwiz ! Administrateur 10672 Posts |
Bonjour à tous, J'aimerais en savoir plus et entamer un débat (s'il y'a lieu d'en avoir un) sur l'extension Fasterfox, dont l'utilité est d'accélérer les chargements de pages web. Le principe de mettre en cache les autres pages du site en tâche de fond, pour les charger plus rapidement ensuite. Je viens d'avoir une discussion avec Mateo du Site du Zéro et il semblerait que cette extension, qui fait partie des extensions les plus téléchargées pose de véritables problèmes aux serveurs et aux bandes passantes. Le plugin analyse le code html de la page à la recherche de liens. Il prend tous les liens qu'il voit et se met à charger en fond les pages correspondantes, qu'il met en cache. Ce qui fait que le serveur pour une personne reçoit facilement 40 requêtes de pages supplémentaires simultanément, sans parler du fait évident qu'il y a gaspillage (le type n'ira jamais voir toutes ces pages qui ont été préchargées). Mateo explique le cas en prenant l'exemple du Site du Zéro : Mateo a écrit : Ce plugin a plusieurs modes. Par défaut il se met en turbo et ne respecte pas les recommandations RFC, or en mode turbo firefox se met à télécharger en fond tous les liens des pages que l'on visite en augmentant considérablement la charge des serveurs. Il paraîtrait que certains sites commencent à bloquer firefox pour ces raisons (quand ils détectent le prefetch), dnsstuff.com par exemple. J'aimerais avoir vos avis plus éclairés que moi à ce sujet. Si cela s'avère vérifié, il faudrait peut-être diffuser massivement ce genre d'informations à Mozilla et aux webmasters en général. Qu'en pensez-vous ? EDIT : autres sources de discussions sur le sujet : - Electronic Arts forum - Whirlpool forums Modifié par Raphael (06 Dec 2005 - 15:14) La FAQ répond à 90% des questions de ce forum. En général, 5 min de recherches suffisent... |
| Lanza | # 06 Dec 2005 - 16:10:36 |
Mouton Noir 856 Posts |
Amusant : infos du net propose le téléchargement de FasterFox tout en promettant de bannir l'utilisateur qui l'utiliserait sur leur serveur <!-- sans commentaires... --> |
| chu | # 06 Dec 2005 - 16:22:15 |
| 116 Posts |
On n'a pas fini d'en voir qui utilisent ce genre de joujou je crois... J'en connais qui trouvent que le 8megabit c'est pas assez rapide et qui utilisent cette m.... C'est bien les soft ouverts, mais ça laisse plein d'utilisations possibles. Trop sans doute. Quant à bloquer les nav qui préfètchent, je voudrais bien savoir comment on peut faire ça... Faudrait analyser le nombre de requète par seconde de chaque utilisateur ? Ca boufferait pas davantage de ressources serveur ? |
| Roger | # 06 Dec 2005 - 17:08:29 |
tuf 145 Posts |
c'est serait vraiment trop c** que FF soit blacklisté pour ca quand même... |
| QuentinC | # 06 Dec 2005 - 18:00:38 |
Étudiant qui bosse ... ou pas 4241 Posts |
Bonsoir, Argl c'est n'importe nawak ce truc ! Quel gâchis... le jour où un visiteur cliquera systématiquement sur les 400 liens de chaque page... on pourrait presque assimiler ça à un aspirateur java.lang.BrainNotFoundException : Neuron connection failure |
| Pandore | # 06 Dec 2005 - 19:39:18 |
Ange Gardien 441 Posts |
C'est pour moi une extension totalement inutile ! Je n'en vois même pas l'intérêt : qui va regarder toutes les pages d'un site web ??? Surtout que certains sites sont très bien fournis en nombres de pages. C'est vraiment un gros gaspillage de ressources ... " Plus les choses changent, plus elles restent les mêmes ... " |
| Calimo | # 06 Dec 2005 - 19:54:19 |
| 50 Posts |
Étant le traducteur de cette extension, je me sens concerné. Je pourrais faire quelques suggestions à l'auteur : - Est-ce qu'il respecte les règles robots.txt ? Si non, alors il est indispensable que ce soit le cas pour la version 1.0 en préparation - Avec Firefox 1.5, il est possible d'ajouter (par exemple) "Fasterfox/0.8.1" à la chaine UserAgent. Est-ce que cela pourrait être utile ? Est-ce une proposition à lui faire ? - Par défaut, respecter les RFC… Mais avant ça, il me faut votre avis. Est-ce que ce genre de mesures pourrait être efficace ? |
| agilis | # 06 Dec 2005 - 20:21:35 |
<apprenti geek /> 300 Posts |
Ah mon avis, le fait d'ajouter Fasterfox dans le UserAgent peut faciliter le blocage des internautes surfant avec cette extension. Ou du moins leur imposer un temps entre chaque requête... Le respect des fichiers robots.txt peut s'avérer très intéressant afin de ne pas pénaliser l'internaute mais toutefois désactiver SaferFox. Mais je ne connais pas bien les fichiers robots.txt donc je ne sais pas si c'est fesable facilement... Voili voilou... a+ |
| Felipe | # 06 Dec 2005 - 20:30:14 |
| Administrateur 4766 Posts |
Je clique sur les liens en les ouvrant dans un onglet en arrière-plan (càd que je reste sur la page d'origine), le temps de finir de lire la page en cours, les onglets ouverts sont chargés depuis longtemps. Les onglets sont les amis des internautes et des serveurs :o Concours de novembre: racontez-nous une histoire |
| Lanza | # 06 Dec 2005 - 20:31:12 |
Mouton Noir 856 Posts |
Calimo a écrit : J'aime assez ces mesures. Il faudrait aussi permettre au webmaster, plutôt que de bannir systèmatiquement l'internaute qui n'est pas forcément au courant des "ravages" que peut provoquer cette extension, la possibilité de désactiver la fonctionnalité "aspirateur" Fasterfox pendant la visite d'un site, par exemple via une balise meta ou un entête HTTP (je ne sais pas si on peut envoyer des entêtes spécifiques). Et prévenir l'utilisateur que ça a été désactivé (au hasard, via une icône dans la barre d'état). <!-- sans commentaires... --> |
| Calimo | # 06 Dec 2005 - 20:58:27 |
| 50 Posts |
Est-ce que quelqu'un a fait des tests sur le robots.txt ? |
| Calimo | # 06 Dec 2005 - 22:00:24 |
| 50 Posts |
Je lis dans un rapport de bug enflammé de la part d'un webmaster dont le serveur a crashé (mais Fasterfox n'est pas la seule en cause, il y a visiblement un "effet slashdot" à petite échelle), qu'il est possible d'utiliser l'entête X-moz: prefetch pour savoir s'il s'agit d'une requête de préchargement. À noter que le préchargement est aussi fait de manière "smart" dans certains cas, par exemple sur le premier résultat de Google. |
| M@teo21 | # 06 Dec 2005 - 22:20:35 |
| 8 Posts |
Calimo > selon moi, cette extension ne devrait pas proposer du tout le mode turbo. Quitte à faire du prefetching, autant respecter au moins les recommandations RFC. C'est la base de la base quand même. Alors le mode turbo par défaut, je vous laisse imaginer les dégâts ! Nous n'avons pas testé les règles robots.txt mais vu qu'il ne respecte pas les RFC je ne vois pas pourquoi il se mettrait à respecter les robots.txt. Ce n'est pas une mauvaise idée ceci dit. Ajouter une info fasterfox à la chaîne UserAgent me paraît important mais pas indispensable. Ce qui est fondamental c'est qu'il indique le header X-moz : prefetch. Je crois que c'est déjà le cas, on est arrivés à le bloquer sur le Site du Zér0 et devinez quoi... depuis c'est super rapide ! Quoiqu'il en soit, il me semble clair qu'une plus grande sensibilisation de l'utilisateur serait utile. Un message "Attention, vous augmentez la charge des serveurs" devrait s'afficher la première fois qu'on utilise l'extension au moins. Malheureusement une telle extension qui devient si populaire c'est carrément problématique pour les serveurs calimo > tu dis que le préchargement est fait de manière douce sur google, il n'en est rien sur le site du zéro. Le plugin voit des pages html de partout et se dit "chouette, des pages statiques, je peux précharger comme un barbare !"... Alors qu'en réalité nous faisons de l'url rewriting et que par conséquent nos pages sont tout sauf statiques.En fait, notre découverte de Fasterfox vient d'un rapport de bug qu'on nous a fait : on nous a plusieurs fois signalé que certaines personnes se faisaient déconnecter au bout de quelques minutes. Cela n'avait pas de sens pour nous à l'époque car, mis à part le timeout, rien ne déconnectait aussi aléatoirement les membres du site. Maintenant, nous avons compris pourquoi : fasterfox préchargeait la page "deconnexion.html"... Modifié par M@teo21 (06 Dec 2005 - 22:24) |
| Igor | # 06 Dec 2005 - 22:33:42 |
| Modérateur 5567 Posts |
Calimo a écrit : Voir dans cette entrée de la faq Mozilla: Link Prefetching FAQ [en ]. Ainsi que la page de la faq google: Questions concernant la pré-extraction (prefetching) des résultats. Dont la dernière entrée précise: 3. Je souhaite bloquer ou ne pas tenir compte des requêtes de pré-extraction. Que dois-je faire ? Ce qui n'est pas neutre. Une extension que pour ma part je ne souhaiterais pas voir se développer plus avant, les effets positifs sont minimes (pour l'utilisateur) et clairement pénibles, dangereux et anormalement consommateur de ressources pour les serveurs (les hébergeurs mutualisés par exemple), couteux pour ceux qui font héberger leurs sites. Une économie et une écologie des ressources numériques reste probablement à inventer. A mon avis, Calimo la solution serait qu'il n'y ait pas de traduction en français. |
| Ganf | # 06 Dec 2005 - 23:09:12 |
| 65 Posts |
Cette histoire de RFC c'est un peu du vent. Tout d'abord, pour comprendre un peu mieux de quoi on parle, il s'agit de la RFC 2616. Il y a dit que les clients ne devraient pas utiliser plus de 2 connexions persistantes simultanées par serveur ("SHOULD NOT", le should ayant un poids assez fort dans les RFC). Maintenant : - Cette RFC décrit l'état de l'art en 1999. Depuis les débits et surtout le nombre de ressources liées a explosé. Quand on charge une page il n'est maintenant plus rare d'avoir une dizaine de fichiers graphiques, une ou deux CSS, un ou deux fichiers javascript, une déclaration p3p et j'en passe. Les capacités des serveurs ont aussi bien augmenté. Si on remet ça au gout actuel, il n'est pas totalement idiot de penser qu'on puisse monter à 4. - Il est fréquent d'outrepasser les RFC. Elles sont souvent rédigées à fortiori pour dire "actuellement voilà comment ça se passe", et pas à priori pour dire "voilà comme ça va se passer". S'il ne fallait pas outrepasser les RFC ce site n'existerait pas (la RFC s'est arrêtée à HTML 4.0). Bref, aller plus loin qu'une RFC c'est super fréquent, surtout une RFC de 6 ans sur un détail de performance (qui a bien changé depuis). Je me demande même si par défaut le nombre de connexions simultanées par domaine n'est pas de 4 sur un IE/win classique. Pourtant personne n'a crié au scandale jusqu'à présent. Si par contre le robots.txt n'est pas respecté c'est beaucoup plus contestable, parce que là il y a une volonté expresse de l'auteur ou du responsable du site Web. Qu'on soit clair, ce qui gêne tout le monde c'est que l'extension fasse des dizaines de requêtes par avance, donc la majorité sont inutiles. Qu'il les fasse en simultané ou pas influe en fait relativement peu. Google Accelerator a engendré la même polémique, pour les mêmes causes. Malheureusement ce phénomène n'est pas prêt de s'arrêter et ne pourra être endigué qu'avec un truc bien connu : les proxy. Est-ce qu'il ne serait pas temps que les FAI remettent en route les proxy qu'ils avaient avant ? Ca règle le problème des RSS, des prefetch et de la charge réseau des serveurs de publication (ceux qui n'ont pas un contenu totalement dynamique qui change à chaque microseconde). Certes, ces extensions ne sont pas très respectueuses à faire des requêtes à tort et à travers, mais AMHA le problème principal c'est surtout les FAI qui ont commencé à dire "boaf, avec la bande passante qui devient moins chère, on va arrêter de fournir des proxy". Ils n'ont vu que leur problématique interne, et pas les conséquences chez les hébergeurs. |
| Calimo | # 07 Dec 2005 - 11:16:37 |
| 50 Posts |
M@teo21 a écrit : En fait là je parlais d'un comportement par défaut de Firefox (donc sans l'extension). Nativement, le premier résultat d'une recherche Google est préfetché. Parce que Google inclut un attribut rel="prefetch" sur le premier lien trouvé. Mais c'est sur qu'avec cette extension, tout est préfetché. N'hésitez pas à faire part de vos craintes/menaces (de blacklistage et cie) à l'auteur. http://fasterfox.mozdev.org/contact.html Il est très ouvert et tout à fait prêt à se remettre en question s'il y a des arguments valables. Il n'a pas hésité à modifier pas mal de choses pour "coller" aux localisations, et je pense qu'il sera prêt aussi à rendre l'extension plus "smart" pour en assurer la pérennité PS : l'extension inclut aussi toute une série d'amélioration côté client qui n'interfère pas le moins du monde avec les serveurs (retour rapide, délai de rendu initial, etc.) |
| M@teo21 | # 07 Dec 2005 - 11:36:43 |
| 8 Posts |
Salut, Calimo > les améliorations côté client c'est très bien. Mais quand ça touche au serveur, c'est un autre problème ! Ganf > je n'ai fait que des suppositions pour le robots.txt, je n'ai jamais dit qu'il n'était pas respecté (mais je le pense ^^) On est quand même TRES loin des RFC en mode turbo d'après ce qu'on a vu. Nos visiteurs prefetch 40 pages simultanément dans la même seconde. Dans de telles conditions, il me paraît normal que notre serveur ait autant tiré la gueule (on ne dispose pas de moyens infinis comme on l'a dit). La bande passante n'est pas mon problème, mon problème c'est la capacité du serveur lui-même à répondre à autant de requêtes. Oublie donc le souci de bande passante pour le moment (je ne suis en tout cas pas près d'avoir à y faire face). Entre 4 et 40 connexions simultanées, je pense qu'il y a une marge non négligeable. Et 40, vous en conviendrez, c'est un tantinet exagéré ! |
| e-t172 | # 07 Dec 2005 - 12:41:31 |
| 101 Posts |
Il y a également un problème dont j'aimerais discuter : Comme vous l'avez dit, les RFC sont assez peu souvent totalement respectées. Ainsi, la RFC HTTP indique que seule une requête de type POST doit modifier du contenu, et non une requête GET. Mais moi, dans un souci d'ergonomie, je ne respecte pas entièrement cette règle, de même que beaucoup de webmasters. Par exemple : sur Agrégaweb, sur la page "Vos flux", vous pouvez modifier l'ordre d'affichage des flux en cliquant sur les liens "Monter" ou "Descendre". Sauf que ces liens sont des requêtes GET, url-rewritées qui plus est; exemples : http://www.agregaweb.net/flux/monter/41/ http://www.agregaweb.net/flux/descendre/52/ Imaginez un instant ce qui se passerait si Fasterfox préfetchait ces liens sans demander quoi que ce soit à l'utilisateur... Modifié par e-t172 (07 Dec 2005 - 12:43) |
| dew | # 07 Dec 2005 - 12:48:30 |
| Administrateur 719 Posts |
C'est justement ce qui se produisait avec Google web accelerator, qui est sur le point de refaire surface. Et là, ça va faire mille fois plus mal que Fasterfox. |
| Ganf | # 07 Dec 2005 - 15:46:27 |
| 65 Posts |
> Nos visiteurs prefetch 40 pages simultanément dans la même seconde. Attention, si tu parles de la RFC ils parlent de connexions réellement simultanées. Ce n'est pas l'information que te retournent les outils de statistiques ou les applications (qui elles regardent le nombre de connexions dans un laps de temps relativement court). Si tes pages mettent 100ms à venir (ce qui ne me parait irréaliste si ton serveur a de la bande passante et qu'on parle de plein de petits fichiers HTML/js/css zippés), on peut faire 20 requêtes/pages dans la même seconde en respectant la RFC. (ceci dit je suis d'accord, faire 40 requêtes de prefetch c'est abusé, si elles sont faites trop rapidement et pas étalées dans le temps c'est encore pire). |
Les références web : openweb.eu.org - opquast.com - webmaster-hub.com - webrankinfo.com - salemioche.net - web-pour-tous.org - webonorme.org
Nos partenaires : Editions Eyrolles
Nikozen : Hébergement - Réalisation : Alsacreations.fr







calimo > tu dis que le préchargement est fait de manière douce sur google, il n'en est rien sur le site du zéro. Le plugin voit des pages html de partout et se dit "chouette, des pages statiques, je peux précharger comme un barbare !"... Alors qu'en réalité nous faisons de l'url rewriting et que par conséquent nos pages sont tout sauf statiques.
