Flickr y la optimización de páginas del sitio web

Muchas son las alabanzas que desde múltiples tribunas se han podido escuchar o leer de Flickr. Y no les falta razón cuando se dice que Flickr es una de las aplicaciones web con más éxito, o una de las más usables (aunque yo pienso que tiene unos defectos de rotulado importantes), o que simplemente es todo un acierto como aplicación, como concepto. Sirva como muestra del grado de aceptación de esta aplicación web, unas simples referencias:

• Flickr tiene su propia entrada en la Wikipedia.
• Flickr: un fenómeno de masas, publicado en Alzado por Isabel Hidalgo de Quintana.
• Flickr nos ayuda a publicar, organizar y compartir fotos en línea, publicado en Maestros del web.

La cuestión es que como parte integrante de eso que se empieza a llamar web2.0 y la popularidad que ha alcanzado, la exposición a la crítica y al análisis es importante, y consecuencia de ello es un post publicado en Aplus Moments, que lleva por título Flickr, please optimize your pages. Vamos, que se está pidiendo que Flickr optimice un poco más sus páginas, ya que éstas presentan defectos de optimización cuando menos importantes.

Y eso, a un sitio web que está sirviendo la cantidad de páginas que sirve, y que soporta una base de usuarios enorme, como es el caso, parece que uno de los objetivos estratégicos que deberían contemplar es el de optimizar sus páginas, para ganar en varios aspectos:

• Experiencia de usuario más positiva
• Menor incidencia de consultas de funcionamiento
• Menor número de peticiones al servidor vía F5 (recargas de página)

Veamos lo que argumenta Aleksandar Vacić respecto de la falta de optimización de las páginas en Flickr. Básicamente se centra en una cosa:

They have 16 (sixteen) Javascript files (look the source on this page for example), all loaded inside of HEAD part of the document.

Que viene a significar que hay 16 ficheros javascript que se inyectan en la página a través del HEAD del documento. Lo que quiere decir que el cliente debe esperar a que se produzcan, se entiende que de forma exitosa, 16 peticiones HTTP antes de cargar cualquier contenido de la página, que es lo que el usuario ve en último término. Cuando menos sí que parece un ejercicio de riesgo. Y además innecesario, ya que como dice Vacić, se pueden unir esas 16 peticiones en una sola.nLos argumentos de Vacić tienen su base en referencias a Speed up your site, de Andy King.

En Torresburriel Estudio te podemos ayudar a implementar procesos de mejora continua en tus productos digitales mediante una consultoría de acompañamiento.
Contacta con nosotros y cuéntanos tu proyecto. Te enviaremos una propuesta adaptada a tus necesidades y presupuesto.