Extension Fasterfox : une plaie pour les serveurs ?

(reprise du message précédent)

> 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).

@e-t172:

Le coup des requêtes GET qui modifient le contenu c'est exactement ce qui est arrivé comme problème au Google Accelerator. Je crois qu'ils ont évité le problème en refusant le prefetch sur les liens avec une trop grande query-string (de la même manière qu'ils ne les suivent pas avec le robot d'indexation).

Ceci dit, si tu fais du GET pour modifier tes contenus c'est tout de même toi qui fait une bêtise. Le principe du prefetch n'est pas idiot en soit s'il est fait intelligement (respect du robots.txt et choisir avec pertinence ce qu'on charge par avance, genre le premier résultat d'une liste de recherche, ou le lien en "suivant" dans une collection)

J'ai l'impression qu'ici pas mal de monde confond le fait de télécharger tous les éléments d'une page en même temps (ce qui est tout à fait louable et ne consomme pas plus de bande passante en termes de trafic cumulé) et le prefetch, qui consiste à télécharger par avance les pages liées à la page visitée, ce qui provoque un gaspillage pur et simple de la bande passante.
Modifié par e-t172 (07 Dec 2005 - 16:36)

Sans être directement concerné par le problème (pas de serveur "important" ), je crois qu'un point est à relever:
Il est important, je crois, que le problême se règle du coté de l'extension et pas du coté des serveurs ! Le contraire serait le comble!

Un entête x-mox-prefetch ou un ajout dans l'identifiant utilisateur ne sont à mon sens que des "patches" permettant de résoudre le problème de manière temporaire (Pour le site du Zéro, par exemple), mais je crois que la solution définitive se doit d'être du coté de l'extension, pas du coté du serveur !

@+, HoPHP

Je crois aussi que c'est à l'extension de régler ça et pas aux serveurs, ça me paraît logique.
Mais bon, la solution que j'aurais moi, ça serait d'arrêter de développer l'extension (de même que l'équivalent google) et ne plus jamais sortir de produits de ce type. Ce qui est aussi inconcevable dans un sens.

Bref, on est un peu face à un mur je crois...

Moi je me demande ce qu'on peut encore accélérer quand on est déjà abonné au haut débit 8 Mbs... et je ne suis pas persuadé que celui qui surfe en 56k a réellement quelque chose à gagner...

QuentinC a écrit :
Moi je me demande ce qu'on peut encore accélérer quand on est déjà abonné au haut débit 8 Mbs... et je ne suis pas persuadé que celui qui surfe en 56k a réellement quelque chose à gagner...

La théorie du toujours plus ?

Si les pages sont longues à lire (beaucoup de contenu) le "56K" va peut-être avoir le temps de lire pendant que ça se charge et cela ira plus vite pour lui, une fois la première page chargée...

M@teo21 a écrit :
Mais bon, la solution que j'aurais moi, ça serait d'arrêter de développer l'extension (de même que l'équivalent google) et ne plus jamais sortir de produits de ce type.

Et pourquoi pas ? Si la Mozilla Fondation prend position officiellement, n'a-t-elle pas le pouvoir de faire "interdire" l'extension ? Ou alors faire du lobbying vers le concepteur...

@Sylvain> Non, ça ne me semble pas problématique, parce que ce n'est qu'un seul préchargement qui a de fortes chances d'être exploité! Donc, ça permet une lecture plus rapide si le client clique finalement sur le premier lien. L'idée est discutable mais dans tous les cas, pas dangereuse pour les sites concernés...

Je crains d'etre un peu hors sujet mais pour bloquer les aspirateurs qui ne respectent pas robots.txt. Certains sites ajoutent un lien invisible (genre <a href="bloquemoi.php" class="invisible ref="nofollow"></a> ) que seules les aspirateurs et FasterFox du coup suivent (pas les moteurs à cause du nofollow)

Ca pourrait être une solution...

Et pour ma part ce qui m'interesse c'est quel code (php si possible) utilisent ceux qui veulent interdire ce plugin ? Vous en avez une idée ?

En gros, un lien caché aux utilisateurs normaux et aux moteurs de recherche dans chaque page:

<a href="interdis_moi.php" style="display:none;" rel="nofollow">(Texte aléatoire de quelques lettres)</a>

Dans la page PHP interdis_moi.php, on prend l'IP du visiteur et on la met dans un fichier temporaire accompagnée du "timestamp" du moment. Finalement, dans l'entête de la page principale, on vérifie si l'IP est dans le fichier et si son timestamp est assez jeune (pour permettre à un visiteur de revenir, quitte à se faire bloquer). Dans le cas positif, on n'affiche rien (donc surtout pas le lien en question) ou un petit avertissement.

Voilà, je vous pond un script dans la journée si ça vous intéresse...

@+, HoPHP

HoPHP a écrit :
En gros, un lien caché aux utilisateurs normaux et aux moteurs de recherche dans chaque page:

[b]rel="nofollow"[/b]

C'est amusant : les arnaques les plus grossières finissent inévitablement par entrer dans les moeurs, et ne même plus faire réagir.
Modifié par Laurent Denis (09 Dec 2005 - 12:02)

HoPHP a écrit :
Et pourquoi pas ? Si la Mozilla Fondation prend position officiellement, n'a-t-elle pas le pouvoir de faire "interdire" l'extension ?

Certainement pas ! Les extensions sont développées par des indépendants.

HoPHP a écrit :
Ou alors faire du lobbying vers le concepteur...

Ça oui. Au passage, je rappelle que tout le monde peut en faire : http://fasterfox.mozdev.org/contact.html

HoPHP a écrit :
Sans être directement concerné par le problème (pas de serveur "important" ), je crois qu'un point est à relever:
Il est important, je crois, que le problême se règle du coté de l'extension et pas du coté des serveurs ! Le contraire serait le comble!

Un entête x-mox-prefetch ou un ajout dans l'identifiant utilisateur ne sont à mon sens que des "patches" permettant de résoudre le problème de manière temporaire (Pour le site du Zéro, par exemple), mais je crois que la solution définitive se doit d'être du coté de l'extension, pas du coté du serveur !

Dons selon toi le robots.txt n'est pas une solution définitive pour "contrer" les robots ?

La solution pour contrer les robots n'a pas été d'interdire les robots, mais de mettre en place, sur le serveur, le fichier robots.txt. Je ne vois pas pourquoi il en serait autrement avec cette extension (à part le fait qu'on ne sait toujours pas si elle respecte le robots.txt) ? Pourquoi cette extension (qui sera certainement suivie par d'autres, il ne faut pas se leurrer) aurait-elle droit à un traitement différent ? C'est totalement ridicule.

Shagshag a écrit :


Pourquoi où est l'arnaque dans rel="nofollow" ?

Le rel="nofollow" a été créé par les principaux moteurs de recherche pour contourner une limitation de leurs algorythmes sur les blogs.

rel="nofollow"ne dit pas aux robots de ne pas suivre le lien, il dit aux moteurs de recherche de ne pas compter ce lien dans le calcul de la pertinence du site.

Donc son utilisation dans ce contexte est juste totalement hors sujet

Re-bonjour,

<provocateur, mais...>
Cette extension et ses effets pervers sont très sains, finalement : ils invitent à limiter le nombre de liens disponibles par page, ce qui serait dans la plupart des cas une exellente chose : optimisation des interfaces Web, réflexion ergonomique sur le contenu, etc.
</>
Modifié par Laurent Denis (09 Dec 2005 - 14:40)