Cursos de Verano: Protocolo HTTP

Hoy he comenzado una serie de charlas dentro de ITnet en plan formación interna que puede que se extiendan a todo el verano y en el que trato muchos temas distintos.

Esta primera ha sido del protocolo HTTP además de hablar de redirecciones y otras cosas varias.

Si alguien le interesa, está ya disponible para descargar… e intentaré ir publicando las siguientes que vaya haciendo.

Fondos de Escritorio que me gustan

De tanto en tanto me da por buscar algún fondo de pantalla que me guste para ponerlo en mi máquina y, hace un tiempo, encontré estos que, la verdad, por cómo están dibujados, me gustan bastante… hay de todo, más claros y más oscuros, pero creo que vale la pena darles una ojeada…

Servicios ¿en la Nube?

Creo que la gente es inconsciente. Al menos aquellos que deciden el desarrollo de aplicaciones web. Creo que nadie puede dudar de que la informática es un mundo cíclico, y ahora estamos recuperando todo aquello que “los abuelos de Internet” hacían en los ’70. Y es que hace unos años que se ha comenzado a retomar todo lo de los VDI (Virtual Desktop Interface), es decir, que en vez de que cada persona tenga su ordenador, estos estén centralizados… como cuando comenzó la informática en las empresas (antes de los PC -Personal Computers-).

Ahora a todo el mundo le ha dado por comenzar a usar noSQL. Este sistema básicamente es “eliminar” la relación e integridad de las bases de datos almacenando la información pre procesada en un formato similar al JSON (en su mayoría) pero que, si vamos unas décadas atrás… ¡anda! si parecen CSV. ¿Para qué relacionar las bases de datos?

Otra cosa muy moderna es lo de la Web 2.0, que básicamente es aquel sistema en que la empresa sólo pone la plataforma y los usuarios participan… parece que hayamos inventado la rueda en 2005 y en el año 1995 comenzaban servicios como eBay o multitud de sistemas de comentarios y foros en la red.

Para acabar, a lo que iba en un principio: el “Cloud Computing”, llamada también informática distribuida, es decir, todo aquello que había en los ’70 y ’80, un superordenador centralizado y un montón de posibilidades de expansión.

¿Y con esto qué quiero decir? Pues que creo que la gente confunde los conceptos de cloud computing con sitios web distribuidos, CDN -Content Delivery Network- y escalabilidad además de la multigeolocalización. Y es que a lo largo de los años he pasado por multitud de experiencias. Primero comencé haciendo webs y pidiendo cuentas de FTP, luego pidiendo también base de datos, hasta que en el 2000 tuve mi primer servidor dedicado. Poco a poco la escalada ha ido a necesitar varias máquinas, a virtualizar y hasta tener un datacenter. Lo único que me falta ya es tener cable de fibra óptica y dedicarme a abrir calles.

¿Con esto qué quiero decir? Pues que cuando algunos clientes me vienen a explicar que han alojado sus sitios web en Amazon AWS me quedo, en el 95% de los casos, bastante sorprendido. ¿Por qué? Pues básicamente porque los servicios habituales EC2, S3 y RDS no son necesarios tenerlos de esta forma distribuida. En estas últimas semanas he actualizado datos de dos empresas españolas dedicadas a Internet: una tiene picos de tráfico (en percentil-95) de 80 mbps y la otra tiene picos de 250 mbps, y sí, en ambos casos el tráfico está comprimido con gzip o deflate, por lo que se mira que no se vaya de las manos.

Si metemos esto en la coctelera me queda que un proyecto que puede tener picos de 20 mbps no deben estar en Amazon (u otros servicios en la nube) si no es para tener proceso. EC2 es un sistema muy interesante si tienes que procesar datos, hacer cálculos matemáticos que acaben dándote un resultado que puedas almacenar. Si realmente necesitas esto, lo que tradicionalmente se llama “proceso batch” me parece muy correcto externalizar la carga, porque Amazon, Google & co tienen muchísimas máquinas para procesar cosas.

Pero alojar un sitio web “normal y corriente” en un sitio de estas características provoca muchas situaciones que luego son complejas de arreglar, sobre todo si lo miramos desde un punto de vista de conseguir tráfico SEO (entre otros). Pero creo que el ejemplo del SEO será bastante claro.

Hoy en día montar un sitio web, si lo quieres escalable, es bastante sencillo. Necesitas un servidor para “cosas varias” (correo, DNS…), otro, normalmente con cierta potencia, para la base de datos, unos cuantos frontales web con programación (PHP, ASP…) y otro(s) frontal para contenidos estáticos, lo ideal en un dominio sin cookies y que además tire de un NAS con discos de alto rendimiento. Si por encima de esto ponemos un sistema de web-caché ya estamos listos y controlamos el 100% de la cadena de errores y del sitio. Además, este sistema te permite llegar a hacer una múltiple geolocalización en varias partes del mundo si dispones de un proveedor con posibilidades de distribución BGP en varios AS. Y encima, este sistema te saldrá muy barato si lo montas bien.

¿Por qué no me gusta Amazon? Pues primero porque el sitio web no está en los países en los que quieres trabajar, lo que implica ya el uso de conexiones internacionales que, por norma general, son más lentas que las locales (por ejemplo, usar Amazon para un sitio web en España es un suicidio, porque no tienen infraestructura en el país). Además, su sistema de estáticos, por defecto, no es el mejor del mundo y puede llegar a generar una serie de URL extrañas que acaban duplicando contenidos y, a la larga, perjudicando a los buscadores (aunque supongo que poco a poco se han ido poniendo las pilas en este tema).

Que conste que no estoy en contra de los servicios en la nube, simplemente creo que para “un sitio web” no es la mejor opción. Me parece perfecto usar servicios como Google Mail, Dropbox y similares, que al final son SaaS, pero el HaaS ha de estar muy bien trabajado para que no se produzca ningún problema a medio-largo plazo.

En fin, al final y como resumen lo que quiero destacar es que debemos medir muy bien lo que queremos para nuestros proyectos y sobre todo hablar con propiedad: no es lo mismo la computación en la nube que tener un sitio escalado en la red.

Google Panda, Adsense y más patentes

Una vez más la solución a los problemas que Google nos genera se encuentra en alguna de sus patentes… y es que sin duda la llamada Compensation Distribution Using Quality Score nos puede dar una idea muy clara de lo que Google podría estar pensando hacer tras el Google Panda.

Among other disclosed subject matter, a computer-implemented method for compensation distribution includes analyzing first content from a publisher with regard to a quality criterion. The method includes associating the first content with a quality score based on the analysis. The method includes providing second content to the publisher to be published with the first content. The method includes distributing a compensation to the publisher relating to the second content, the compensation based at least in part on the quality score.

La idea de esta patente va muy relacionada con la calidad de los contenidos y Google Adsense. Aún así, aunque todo va relacionado con la publicidad el sistema menciona por activa y por pasiva el concepto de Quality Score de los contenidos en relación a lo que ese contenido luego pueda generar de publicidad.

Entre las cosas que comenta podemos encontrar esto:

[…] informing the publisher, before the first content is again analyzed, about a quality of the first content […]

Esto podría suponer que Google está queriendo aumentar la calidad de los sitios web y que, como los webmasters no lo hacen, ha decidido que un algoritmo puede conseguir eliminar aquellas páginas de sus resultados de búsqueda, eliminar los contenidos de baja calidad, y al enviar tráfico de su buscador conseguir que la publicidad mostrada con respecto a los contenidos sea de mayor calidad y por tanto, al final, ganar más dinero.

La patente habla de muchas cosas de una forma bastante abstracta, pero de la que se pueden intuir varios temas. Por un lado habla del concepto real time y por otro habla de primeros contenidos, segundos contenidos… esto, al final se resume en quién es el proveedor primario de la información y cada cuanto se produce y otros la replican. Quizá, no vaya tan relacionado con Adsense sino con Google News, pero nunca se sabe.

Lo que sí que deja muy claro es que el creador, el generador de la información primaria es el que ha de llevarse más pasta por ser el origen de la información, y que el resto se llevará de forma que se degrade dicha información.

Pero… ¿qué se considera calidad?

[…] In some implementations, the classifier module 122 may determine quality scores based on one or more of the following aspects of the pages 110a-110b: authoritativeness, verifiability, entertainment value, grammatical accuracy, educational value, timeliness, aesthetic quality, originality, cohesiveness, reputation, informational value, search ranking, popularity, server responsiveness, or other quality criteria and/or combinations thereof, to name a few examples. […]

Autoridad, verificabilidad, entretenimiento, precisión gramatical, valor educativo, fechas y horas, calidad estética, originalidad, cohesión, reputación, valor informativo, ránking de búsqueda, popularidad, capacidad de respuesta del servidor…

Otro detalle del que se habla es del diseño. Por primera vez (que yo recuerde) se habla de que un diseño “bueno” (o “malo”) influirá en la calidad de un sitio, lo que significa que aquellos sitios que usen diseños complejos y difíciles de comprender y analizar tendrán más problemas para aumentar su calidad. Esto no sé si puede llegar a tener relación directa con HTML5, pero podría serlo. También recomendaría el uso de “plantillas”; esto, personalmente, es algo que llevo comentando desde hace tiempo… hay que hacer sitios web en los que la navegación y la estructura sea simple, navegable, indexable y usable, ya que hacer una página con muchos elementos perdiendo el foco del contenido principal acabará penalizando.

In another example, quality scores can range from a value of 0 to a value of 100, and a relatively high quality page can be given a score of 95. In some implementations, the quality scores can be a cumulative score. For example, the classifier module can add a point to a page’s quality score for every detected “good” aspect of the page (e.g., a working link, a verifiable fact) and/or subtract a point for every detected “bad” aspect of the page (e.g., broken link, misspelled word). Other types of scoring can be used.

Una vez más, la calidad de los enlaces y de los textos frente a la cantidad… escribir bien y enlazar a sitios de calidad y con criterio seguirán siendo aspectos básicos (y nada nuevos, la verdad).

La conclusión de algo que nadie ha comentado (en público) es: ¿qué ocurre con los ingresos de Adsense tras la llegada del osito Panda?

Cachear de forma sencilla una página dinámica en PHP

¿Te ha pasado alguna vez que tienes una web desde hace un montón de años, que la hiciste tú y a veces te da problemas de saturación por exceso de visitas? Pues a mi sí y, aunque llevaba tiempo pensando en alguna forma de cachear, que acababa siendo hipercompleja, hoy me ha dado por pensar alguna forma sencilla basándome en unas pruebas que había hecho hacía poco.

La cuestión es que sabía cómo hacerlo, iba por el camino, pero entre unas cosas y otras “nunca encontraba el momento”, hasta ahora. El sistema es bastante simple y en principio se podría aplicar a cualquier sitio. El código sería algo tal que este:

<?php
$md5 = md5($_SERVER["REQUEST_URI"]); // convertimos la URL a único identificador
$file = "cache/".$md5.".html"; // donde se guardará el fichero
$hora = filemtime($file); // comprobamos la hora del fichero si ya existiera
if(time() <= $hora+86400) { // asignamos un tiempo de cache de 86400 segundos
    include($file); // incluimos el contenido del fichero cacheado
    echo "<!-- ".date('YmdHis', $hora)." -->"; // (opcional) añadimos al pie de página la fecha-hora de la caché
    exit; // salimos
}
ob_start(); // abrimos la memoria
?>
AQUI VA LA WEB NORMAL
<?php
$fp = fopen($file, 'w+'); // abrimos el fichero de caché
fwrite($fp, ob_get_contents()); // guardamos el contenido de la página generada en el fichero
fclose($fp); // cerramos el fichero
ob_end_flush(); // devolvemos la página que se ha generado y cerramos la memoria
?>

Con este sistema podremos incrementar una página dinámica tranquilamente entre un 50% y un 1.000% la velocidad, dependiendo de la carga de base de datos o cálculo que tuviera anteriormente.

El ansia de indexarlo todo

De un tiempo a esta parte que me estoy encontrando con algunas cosas que no me gustan de Google. Sí, ya sé que es muy fácil meterse con el gigante de Mountain View, pero creo que a alguien de la parte de búsquedas se le ha ido un poco la cabeza.

Todo ha comenzado con el cambio de diseño de mi blog, o sea, de esta página, y de paso con la instalación del nuevo WordPress 3.2. Revisando mis “plugins de SEO” me he dado cuenta de que se estaba indexando más de lo debido. hace meses que decidí que si quería tener unos buenos resultados en Google y Bing sólo tenía que indexar las entradas del blog y las pocas páginas que tengo (como la Guía SEO). Con esto eliminaba un montón de combinatoría y lo hacía gracias a el All in One SEO Pack que le pone un “noindex” a aquellas páginas que le digo. Como decía, todo aquello del estilo “categoría” o “etiqueta”, fechas y paginaciones.

Ahora me he puesto a darle una ojeada a otros elementos que había filtrado semanas atrás. Entre estos elementos están las páginas de feed que se generan por cada entrada del WordPress y que incluyen los comentarios. Esto al final lo tuve que eliminar de forma radical desde el robots.txt mediante un Disallow: /blog/*/feed y Disallow: /blog/*/trackback. Gracias a esto mi Webmaster Tools se ha llenado de “errores” diciendo que no puede indexar un montón de estas URL.

Si alguno le dedica unos minutos a revisar de dónde salen esas URL detectará que en los enlaces normales de las entradas no aparecen, aunque sí que se pueden conseguir a través de enlaces como <link> o comentarios HTML. Y ahora viene la gran pregunta: ¿por qué Google sigue estos enlaces?

Este tipo de URL, sumadas a otras tantas, están generando una serie de errores y de contenidos duplicados en mi sitio que no son normales, algo por lo que luego Google se quejará y dirá que “tenemos contenidos de baja calidad”.

Dedicándole un rato a los paneles del resto de buscadores, como el de Bing me he dado cuenta que estos errores no aparecen, es decir, que Bing me indexa, por ejemplo, el feed principal, pero no el resto. No sé si es que Bing no revisará los enlaces que se generan en la cabecera de la página o es que detecta que son ficheros XML y por tanto “no comprensibles” por el usuario y los pasa por alto. Y es que… ¿tiene sentido mostrar en los resultados de búsqueda contenidos en un MIME-type que no es comprensible? está claro que un text/html o un text/plain son básicos, incluso los tipos correspondiente a los multimedia y que los buscadores informan, ¿pero un XML?

Esto me lleva a revisar los ratios de conversión de ambos buscadores. Y es que si reviso los datos de Bing, el CTR es del 10%. Es cierto que Bing me trae pocas visitas (un 15% quizá) pero lo que queda claro es que ese poco tráfico que me trae es de mucha más calidad que el que me envía Google. De la misma forma, aunque aquí ya sí que hay poco o nada de tráfico, el ratio de CTR de Yahoo! es del 12%, siendo de casi el 50% cuando el resultado está en primera posición y de un 25% cuando está en segunda.

En muchas ocasiones he comentado que WordPress me parece un gran gestor de contenidos, pero que la base no está bien construida de cara al crecimiento, y cada vez me doy más cuenta de que la gente que construye plugins de SEO para WordPress no acaba de tener muy claro la extensibilidad del mismo. Mientras tanto, habrá que seguir “parcheando” las cosas de la mejor manera posible…

PostData: Si alguien quiere hacer un plugin de SEO bueno para WordPress que me lo diga que le doy ciertas indicaciones de las cosas que debería tener y muy agradecido ejerceré de conejillo de indias.

Presentación sobre SEO / WPO

Hace un par de días tuve, una vez más, la oportunidad de impartir una clase de un par de horas sobre SEO en ESDi. En este caso se planteaba como una clase más práctica para gente que no tiene muchos conocimientos tecnológicos y que probablemente tendrán que decidir a qué empresa de SEO contratar, por lo que me focalicé bastante en ese punto, el de cómo elegir a una empresa, qué ha de aportar esa empresa y cómo se ha de pensar el proyecto antes de lanzarse.

Hoy en día el que quiere lanzar un proyecto en la red y lo quiere lanzar bien ha de pensar en bastantes cosas… para empezar qué quiere conseguir con el proyecto, dónde se va a alojar (si está enfocado a un país o a nivel internacional), cómo evitar que haya posibles saturaciones en el sitio y absorber picos de tráfico… Además comenté algunas diferencias entre hacer la optimización de un proyecto nuevo de uno ya lanzado o de las diferencias entre el “SEO claro” y el “SEO oscuro”.

Además, y a raíz de algunas preguntas que me han hecho en varias ocasiones sobre qué herramientas utilizo para todo el tema de la optimización, hice un resumen de ellas, que básicamente son las propias de los buscadores: Bing, Google, Yahoo! y Yandex.

Puedes descargarte la presentación y comentar qué te ha parecido.