Lo que Google trama en Mountain View

Dice Google que para construir un buen motor de búsqueda hacen falta tres cosas:

1. Descargar una buena parte de la web
2. Indexar las páginas y evaluar cómo de relevantes son
3. Clasificarlas y devolverlas a los clientes que las buscan con la mayor velocidad posible

En los últimos meses nos estamos desayunando (o al menos los que nos damos el atracón de RSS con el café y las tostadas) con un montón de noticias referentes a nuevos servicios ofrecidos por Google o incluso cambios en los algoritmos que ya ofrecen. Sin ir más lejos el propio motor de búsqueda está ahora mismo en plena fase de evolución.

Ayer Google presentaba su infraestructura propia de DNS, pero no es lo único que están haciendo con la motivación de acelerar la web.  Aquí podemos encontrar un listado de sugerencias que nos hacen para mejorar la velocidad de carga, incluyéndose entre otros, proyectos bastante interesantes como Speedy, un intento de optimizar el protocolo HTTP.

Pero seamos realistas, Google es una empresa cotizada que se debe a sus accionistas, no un generador de software libre por el bien de la comunidad. Por ello, creo que es justo interpretar todas sus acciones en vistas de la obtención de beneficios. Esto no quiere decir que sea algo “maligno”, pero es una empresa y como tal debemos juzgar sus acciones.

Speedy (o SPDY)

Hay que ser objetivos, el protocolo HTTP no es todo lo eficiente que debería ser y Google no ha sido el primero en hacer una propuesta para mejorarlo, sin embargo, por el tamaño de Google y su penetración en el mercado, es probablemente uno de los actores mejor posicionados para impulsar un cambio de estándares. Ahora bien, ¿qué buscan conseguir con Speedy?

1. Reducir en la mitad el tiempo necesario para cargar una web
2. Que el despliegue del nuevo protocolo sea sencillo y rápido
3. Que no sea necesario realizar ni un cambio en el código de las webs
4. Que el protocolo se desarrolle en consenso con especialistas y resto de la industria

Partiendo de estos objetivos que ellos mismos se ponen, es difícil que encuentren mucha gente en contra. Cualquiera querría cargar sus páginas web en la mitad de tiempo de una forma transparente total y utilizando un protocolo que no nos ha impuesto una sola compañía, sino que es fruto del consenso.

Google DNS

La noticia más fresca sobre Google es de ayer mismo, cuando anunciaban que lanzaban su servicio de DNS. Un servidor de DNS no es más que un servicio que traduce nombres de dominio (pepe.com) a la dirección numérica utilizada en Internet. ¿Qué ventajas tiene utilizar sus servidores DNS sobre los de nuestro ISP según Google?

1. Mayor seguridad, mayor rendimiento y resultados más correctos (sic)
2. Ayudaría a los ISP reduciendo su carga de peticiones DNS
3. Ayudará a los usuarios de Internet favoreciendo una web más rápida y segura

Soy usuario de Internet desde el 94 más o menos (épicas facturas de teléfono por aquel entonces, bendita tarifa plana) y hay que reconocer que cuando el servidor DNS de tu proveedor se va al garete o tiene mucha carga y tarda en responder, es un dolor tratar de navegar, por lo que la propuesta de utilizar sus múltiples servidores distribuídos por medio mundo a priori parece interesante desde el punto de vista del usuario.

Sin embargo, si profundizamos un poco más, nos encontramos con la política de privacidad del servicio, donde nos dicen lo que van a guardar por cada petición DNS que un usuario haga, a saber:

• Ciertos detalles técnicos (ip, tipo de consulta, protocolo de transporte, etc)
• Información estadística (tiempo de respuesta, qué máquina de Google ha atendido la petición, etc)
• Información de geolocalización (localización, región, ciudad y el metro code)

Y aquí es donde empiezo yo a construir mi teoría sobre por dónde van los tiros. El metro code es el código que asigna Google a cada Ciudad en su API de AdWords. Es decir, si un anunciante quiere lanzar una campaña a la gente que viva en Jaén, deberá utilizar el código “AN ES” y la publicidad se mostrará sólo a los que vivan allí.

Explicado esto, imaginemos esto en un escenario en el que la mayoría de los usuarios (que ya lo serán además de Google) utilizan su sistema de DNS. Supongamos a alguien que está buscando en el propio Google cursos de corte y confección. A google le interesa saber tu ciudad, para colocarte los anuncios de gente que haya pagado por estar ahí cuando alguien busque un curso de corte y confección. Si ahora pueden cruzar tu posición con lo que estás buscando, tienen todo para servirte justo la publicidad que “estás buscando”. De paso, ellos tienen estadísticas de en qué regiones del mundo la cosa es más o menos efectiva al almacenar en qué máquinas se realiza cada consulta.

Desde el punto de vista del que vive de la publicidad, desde luego es una idea genial, una forma perfecta de hacer negocio de la tecnología. Chapó. El tema es hasta que punto alguien está dispuesto a perder parte de su anonimidad. Aunque sólo sea información geográfica, a mi me parece suficiente como para al menos plantear ciertos problemas al asunto.

¿Y qué tiene que ver Speedy y el resto de cosas para acelerar la web en todo esto?

Google no es idiota. Sabe que vive de la publicidad, pero también sabe que depende de tener una masa de usuarios descomunal, de los que un pequeño porcentaje, termina pinchando en la publicidad. Si la gente de este porcentaje, ya de por sí pequeño, al hacer click en un anunció tarda una eternidad en cargarlo, cierra la página. En un modelo de cobro de publicidad por impactos reales o por ventas reales, desde luego esto es bastante malo para Google.

En mi opinión, debido a esto vino el cambio en el algoritmo de ranking de AdWords, en el que ahora el tiempo de carga del sitio de destino pesa muchísimo a la hora de posicionar el anuncio. Cuanto antes cargue, antes Google le da al botón de facturar y más dinero entra en la empresa.

Por tanto, en mi opinión, para conseguir un buen motor de búsqueda hacen falta esas tres cosas… y conseguir que el motor te de dinero.