Aller au contenu | Aller au menu | Aller à la recherche

jeudi, janvier 7 2010

Pub google chrome

Depuis hier, des pubs en 4x3 fleurissent dans le métro et dans les stations RER, vantant les mérites de Google Chrome[1]. C'est la première fois que je vois une pub pour un navigateur.

Je ne trouve pas cette pub en elle-même super percutante, mais bon, on va dire que c'est un avis très subjectif, à cause de mon statut de contributeur à Mozilla :-).

Mais pas seulement. En fait je la trouve totalement nulle.

En effet, il y a quelque chose qui m'a fait bondir dans cette pub, c'est la mention "0 bug". Ce qui est tout à fait mensonger. Ce n'est pas comme si le nombre de bugs ouverts sur le bugzilla de webkit était à 0, hein. Nous avons même à Zoomorama, découvert des crashers (mais je n'ai plus les numéros de bug sous la main).

Un logiciel a toujours, et aura toujours des bugs. Même dans une pub, on ne devrait pas raconter ce genre de connerie "0 bug", mais plutôt se focaliser sur d'autres aspects du logiciel (rapidité, fonctionnalités ou je ne sais quoi d'autre...[2]). Dire "0 bug", c'est prendre les gens pour des cons.

Et hop, Google descend encore d'un cran dans mon estime.

Notes

[1] désolé, je n'ai pas de photos, mais j'en ai trouvé une ici

[2] ce que google fait aussi dans la pub

mardi, septembre 2 2008

Google Chrome

On attendait un ouragan du coté de la Nouvelle Orléans. Finalement il a plutôt dérivé sur le web. Et il fait très mal : Google annonce la sortie prochaine de son propre navigateur web, qui aura pour nom Google Chrome. Les rumeurs depuis plusieurs mois sur un "GBrowser" étaient donc fondées.

Coté technique :

  • Le rendu sera effectué par le moteur Webkit (utilisé par Safari et Adobe Air)
  • Le moteur javascript a été réécrit from scratch, portant le doux nom "V8", et embarquant une machine virtuelle et un optimisateur de code (ça me rappelle TraceMonkey et Tamarin tiens... ;-))
  • La grosse nouveauté par rapport à la concurrence[1], sera que chaque onglet aura son propre processus, donc une page web ne pourra pas "geler" le reste du navigateur, même si elle fait n'importe quoi. Chaque onglet sera une "sandbox".
  • On peut détacher un onglet pour en faire une fenêtre dédiée à une appli web (même finalité que Mozilla Prism donc..)
  • Intégration de Google Gears (api pour développeurs web)

Une BD orienté technique explique toutes les caractéristiques de ce nouveau navigateur.

Cependant, à y regarder de plus prêt, il n'y a pas multitudes d'innovations dans ce navigateur. La machine virtuelle pour le javascript, les applis indépendantes, le support des standards, et les autres fonctionnalités pour l'utilisateur, sont des choses vers lesquelles presque tout les éditeurs de navigateurs intégrent déjà ou sur le point de le faire.

Bref, mis à part Microsoft, je ne pense pas que les autres éditeurs aient du soucis à se faire au niveau technique. Par contre, cette annonce est tout de même un ouragan, parce que... c'est Google. Imaginez un lien "téléchargez Google Chrome" sur chaque page du moteur de recherche Google, moteur qui je le rappelle est utilisé par une grosse majorité des internautes... Même si la communication de la concurrence à l'égard de cette annonce semble calme, je pense que dans certaines équipes, ça doit être le branle bas de combat[2].

Et puis, pour les fournisseurs d'applications en ligne, ça va être un gros concurrent, car je doute que Google Chrome sera fourni sans des liens vers Google Docs, Google Maps, Google Mail et cie...

Cette annonce marque le commencement d'une nouvelle phase dans la guerre des navigateurs déclenchée par Mozilla avec Firefox 1.0. Niveau DEFCON 2 je dirais. Voir 1 à Redmond, le principal concurrent :-)

Notes

[1] quoique, IE8 parait-il le fait aussi

[2] Pas chez Mozilla, car ils sont très très certainement au courant depuis des lustres, d'autant plus que leur deal avec Google vient d'être re-signé pour 3 ans. D'ailleurs, ce ne serait pas étonnant qu'il y ait anguille sous roche, comme le pense Daniel

jeudi, avril 6 2006

Big Daddy vous indexe

Google a annoncé (le 1er Avril semble-t-il, mais ce n'est pas un poisson) le lancement de son nouvel indexeur, de nom de code Big Daddy.

Vous avez sûrement dû remarquer dans les statistiques de votre site la venu d'un certain navigateur appelé GoogleBot. C'est le robot indexeur de Google. Son principe est simple : il s'agit d'un programme qui fait de simples requêtes http GET vers des liens qu'il connaît. Il récupère le contenu brut de la page web, indexe son contenu, récupère les liens qui s'y trouvent et les suit.

Cette technique simple a toutefois une limite : tout ce qui est généré dynamiquement dans la page est totalement ignoré, car l'indexeur n'exécute pas le javascript. En effet, pour faire un robot indexeur qui exécute le javascript, il faut construire un arbre DOM représentant le document, et appeler un moteur Javascript. Et si on veut pouvoir suivre les liens qui sont appelé en javascript (du style, les liens <a href="javascript:window.open..."), il faut que le robot "clique" sur le lien, donc gère aussi les événements DOM.

En clair : réaliser ce genre de robot d'indexation revient à développer un "vrai" navigateur. C'est pour cela que cela n'a probablement pas été fait jusqu'à... il y a quelques jours chez Google.

Big Daddy c'est donc ça : un robot indexeur qui est aussi un vrai navigateur. Et pour cause : il est basé sur Gecko, le moteur de Firefox.

On comprend mieux maintenant certains rapprochements entre Google et Mozilla. Il ne s'agissait pas d'un GBrowser, mais d'un robot d'indexation d'un nouveau genre. J'imagine qu'ils ont du faire des traitements qui font (en trés gros) des document.getElementsByTagName("a"), et qui envoient des évènements DOM "click" sur les éléments trouvés, une fois que la page a été chargé (et donc le code JS executé).

Les conséquences ? Pour les points positifs : une indexation des contenus qui échappaient jusqu'à présent à googlebot. Pour les points négatifs : ça va être plus dur de persuader les développeurs web à rendre leur site accessible : ils vont pouvoir mettre de l'Ajax partout, faire du code crade. On ne pourra plus brandir l'argument "pense à google le plus connu des aveugles du web, si tu ne rend pas ton site un minimum accessible, tu seras moins bien référencé". Et pour cause, il est beaucoup moins aveugle maintenant :-/

Il doit aussi y avoir d'autres conséquences au niveau référencement. Mais je ne connais pas assez les techniques de référencement pour l'affirmer.

Mise à jour : quelques liens

vendredi, mai 16 2003

Ces maudits aspirateurs

Eric nous liste ses arguments contre l'utilisation des systèmes anti-aspirateur de site. Son point de vue est tout à fait valable, au point même que je me sens culpabilisé :-). En effet, j'utilise moi-même un système anti-aspirateur sur mon site tahiti-fenua.com.

Cependant, j'ai ma propre opinion envers ces outils "vampires". Voici donc mes arguments pour l'utilisation de systèmes anti-aspirateur, en particulier dans mon cas précis.

Statistiques faussées

Un aspirateur aspire le maximum de page qu'on lui indique. La visite d'un aspirateur n'est donc pas représentatif, et le nombre de page "lues" ne devrait donc pas pris en compte dans les outils de stats. Il y en a qui font la distinction entre visiteur normal et robot/aspirateur. Mais je ne sais pas si, par exemple dans Awstats, les résultats de visites et de page lues au total prennent oui ou non en compte les stats liés à ces visiteurs pas commun. Et puis comme l'a fait remarqué Eric, étant donné que l'on peut modifier le user-agent dans la plupart des aspirateurs, on se retrouve donc avec des statistiques faussées (et si en plus l'outil de stats ne fait pas la distinction visiteur normal vs aspirateur...).

Ca n'a pas l'air grave, mais en fait, pour moi, un peu quand même. Sur un petit site comme le mien, qui ne compte que 400 à 500 visiteurs par jour, avec une moyenne de 5200 pages lues par jour, le passage d'un aspirateur bouleverse profondément mon petit moteur de stats. Le dernier internaute qui a aspiré le site, cela a représente au bas mot prés de 5000 pages ! (Et oui, ca en fait des pages, les forums, et tout et tout... et je ne compte pas les images, css..). On voit bien que finalement, les stats sont toutes faussées, ce qui rend le suivi de l'évolution du site un tantinet difficile. Déjà que les outils de stats, ne sont pas par nature fiable à 100%... Si j'avais des millions de hits par mois, je m'en foutrais un peu. Mais là...

Ma liberté à moi c'est de pouvoir regarder avec amusement ces petites courbes de stats monter chaque mois, sans que leur progression ne soit perturbée par des vampires (oui, je sais, ça fait un peu egoiste..).

Et si il n'y avait que ça encore...

Réèlle consommation de bande passante

Quand un aspirateur passe sur mon site et pompe 5000 pages en quelques dizaines de minutes, je suis en droit de me dire que, oui, les aspirateurs, ça suxor !

Quels intérêts aura l'internaute de télécharger le site entier ? ou même seulement une rubrique entière. Aucun dans le premier cas, mais compréhensible dans le second. Je doute fort qu'il lise les 5000 pages et qu'elles l'intéressent toutes. Au final, c'est un gâchis en temps de téléchargement et de bande passante, autant pour lui que moi.

Que dire aussi lorsque le contrat d'hébergement impose une limite de bande passante, de X Mo par mois ? Que quelques internautes passent l'aspirateur sur votre site, et vous voilà à payer les Mo de bande passante supplémentaire à la fin du mois, quand ce n'est pas à pleurer devant le blocage pur et simple de l'accès au site par l'hébergeur.

Actuellement, je ne suis pas dans ce cas, mon hébergeur ne m'impose pas de limite, mais ça pourrais le devenir si mon site bouffait trop de BP.

un serveur qui s'essoufle

La machine hébergeant mon site commence à ne plus se faire toute jeune. Malgré la ligne 100Mbits/s sur laquelle elle est connectée, avec son pentium 200 et ses 128 Mo de ram, la vieille s'essouffle vite au passage d'un aspirateur. J'ai fait l'expérience et je peux vous assurer que le processeur pédale comme un fou (à cause en grande partie de la forte sollicitation de la base de donnée dans ces moments là).

Du coup le site devient difficilement accessible pendant quelques minutes. Et pas seulement le mien, mais tout les autres petits sites qui sont sur la même machine, parce que je ne suis pas sur un serveur dedié.

Laisser pomper le site par un seul internaute, et par la même occasion, empêcher tout les autres de visiter le site (et les autres sites) agréablement : je ne vois pas ce que cela apporte globalement. La liberté des uns, s'arrête là où commence celle des autres. Je préfère privilégier donc la majorité des internautes. Je ne vois pas pourquoi Monsieur le pompeur aurait plus le droit qu'un autre de visiter le site.

Autant, sinon, faire une seule page, proposant en téléchargement avec un zip contenant tout le site. Et encore, là aussi, ça ne résout pas le problème de bande passante. Ça l'aggraverais même. Et puis ce n'est plus ce que j'appelle du web.

Seul les pompeurs sont lésés

Un anti-aspirateur, bien fait, ne devrait pas géner la visite des robots d'indexation des principaux moteurs de recherche.

A voir le code source de la solution de phpfreaks,celle-ci n'est pas terrible, voir idiote.
Ma solution ne bannit pas tout à tire-larigot. Lorsque le nombre de pages lue sur une période donnée pour un internaute donné, dépasse un certain seuil, une page spécial, légère est affiché avec un petit texte explicatif. Il suffit donc d'attendre quelques minutes/secondes pour reprendre la visite (ou le pompage).

Certes, cette méthode m'oblige à faire des enregistrements en base de donnée, mais étant donné que ceux-ci me servent également pour mon petit outil de stats perso, je n'y échappe pas...

Il faut noter que cela ne concerne pas les images, css etc. Donc l'enregistrement d'une ou quelques page en local n'est nullement affecté (à ma connaissance).

Et finalement ma méthode n'empêche nullement les robots d'indexations. En observant les accès de ceux-ci sur le site, on remarquera qu'en fait, ils étalent leurs requêtes sur la journée. On constatera ainsi que google ne fait en moyenne que quelques requêtes (1 à 10 ) par heure, un taux qui est loin d'égaler celui des aspirateurs et qui n'activera donc pas le blocage de l'anti-aspirateur.

conclusion

Quand Tahiti-fenua aura des milliers de visiteurs par jour, sera hébergé sur une bécane performante, que j'aurais optimisé le code de manière à mettre en cache les pages pour moins solliciter la base de donnée, quand j'aurais un outil de stats plus performant, que je pourrais à loisir consommer toute la bande passante car le site sera sur un serveur dédié, je pourrais alors enlever ce système anti-aspirateur.

Mais je n'en suis pas encore là, donc je garde pour l'instant mon anti-aspirateur :-).

Par contre, si vous n'êtes pas dans mon cas, vous n'avez, comme l'a dit Eric, peu de raison d'avoir un anti-aspirateur.