J’ai lu il y a quelques jours une note sur le blog de Korben à propos de l’URL pre-fetching . JE savais que ce n’était pas nouveau, et j’ai pu le constater via un lien fournit par Jérémy : DNS Prefetching (or Pre-Resolving) (le post date de septembre 2008, donc ça n’est pas nouveau), qui est en fait la pré-résolution des DNS (pour les liens affichés sur une page web). Cette technique permet donc de diminuer ce temps pour tout accès à une page web à partir de la page, car la résolution DNS est déjà opérée.
Ci-dessus, ce que donne le about:histograms/DNS.PrefetchFoundName pour mon Chrome 4.
Notons que ces deux techniques permettent d’accélérer l’affichage d’une page au sein du navigateur. Cela signifie que Google met autant la pression sur les webmasters de sites web (pour qu’ils optimisent de leur côté l’affichage de leurs sites) que sur les développeurs de Chrome (ou alors ils se mettent la pression tout seuls).
Pourquoi vouloir repousser les limites toujours plus loin ?
La raison est finalement assez simple. Google veut tout particulièrement que le maximum d’utilisateurs utilise ses services. Pour cela, l’entreprise fournit des services extrêmement rapides, car elle a compris que les utilisateurs ne quitteront le offline (les clients lourds) que lorsque les clients légers auront une rapidité similaires. Je ne sais plus où je lisais ça, mais le papier expliquait que les utilisateurs s’attendaient à un temps de réponse sur une appli desktop (si mes souvenirs sont bons, c’était quelquechose comme 10ms), et qu’ils n’avaient pas la même attente pour une appli web. En tout cas, il y a fort à parier que Google cherche à atteindre un temps comparable au desktop pour la navigation web, quitte à « inventer » des petits tours de passe-passe permettant de gratter ça et là quelques milli-secondes. L’URL prefetching et le DNS pre-fetching en font partie.
Ce n’est pas exactement la meme chose en fait…
le DNS prefetch, c’est pour résoudre un NDD avec son ip avant meme que tu l’ai demandé (et ça oui c’est vieux)
l’ URL prefetch, c’est simplement pour ouvrir une connexion http avec un serveur avant que tu l’ai demandé.
D’ailleurs ca a été intégré dans chromium ce moi de mai
http://src.chromium.org/viewvc/chrome?view=rev&revision=47479
@Korben: Oui oui, j’avais bien compris ça. J’ai mis ma réflexion sur le fait que c’était toutes deux des méthodes pour accélérer le chargement au niveau du navigateur, et donc en soit, la recherche dans ce domaine n’était pas nouvelle. D’ailleurs, quelque soit le site web, tu peux ouvrir une connexion avant, tout comme tu peux résoudre des NDD.
Pour le reste, je ne remet pas ton billet en doute, le truc a effectivement été intégré à Chromium au moi de mai 🙂
On écrit mois 😉
Sinon, je pense que Google ne se compare pas avec les clients lourds.
Internet est complexe, comprendre un ensemble d’éléments simples qui interagissent.
Pragmatique, Google sait qu’il faut maîtriser les couches bases des éléments simples afin d’optimiser la performance globale et de comprendre les comportements émergents.
Ainsi, il apporte le service DNS, puis le client et bientôt, il poussera de nouvelles technologies encore plus innovantes pour améliorer les fonctionnalités comme IPv6 ou le Wimax.
Ce qui est impressionnant, c’est qu’une brique aussi structurante que Chrome pour Google soit open source et donne accès à ces informations. Preuve que la transparence n’est pas une faille stratégique tant qu’on est capable d’exécuter le plan stratégique.