[su_wiloke_sc_company_website]Cuando se quiere ver un video de alta calidad, con una ADSL normal, uno espera un rato a que se cargue el principio (buffering) de forma que tras unos 5/10 segundos se puede ver el video casi sin cortes. El ancho de banda, la cantidad de información que circula por la red desde el servidor a tu ordenador, está justificada, sobre todo porque los de Youtube (o el portal que esté sirviendo el video) han estudiado mucho que codec usar de compresión de video para tener la máxima calidad en el menor espacio posible.
De la misma forma, las páginas web deberían hacer lo mismo, pero desgraciadamente la tendencia es al pasotismo de dicha optimización, puesto que las ADSL soportan ya descargas de 1 mega en apenas unos segundos … ¿para qué voy a querer hacerlo más rápido?
Por muchas razones, pero dos sobre todo, una del lado del visitante y otra del lado de tu bolsillo. Quieras que no, no es lo mismo navegar por una web en la que se tarda unos 6/8 segundos en cargar cada página, que en la que puede mostrarse en 2/3 segundos. La navegación es mucho más fluida y está demostrado que en las páginas más rápidas la media de páginas vistas por sesión del usuario es mucho mayor. Así lo he podido comprobar en aquellas página que he optimizado, casi duplicándose la experiencia del usuario.
Por otro lado, cuando uno tiene que pagar la factura del servidor dedicado, y su contrato va por transferencia en lugar de «ancho de banda» (aunque en términos generales es «casi» lo mismo a la hora de contar), es mejor pagar o consumir menos «canuto», pues dejas «más espacio» a otros posibles visitantes concurrentes al sitio web.
Por tanto, es importante tener en cuenta la optimización de un sitio web. Se me ha ocurrido coger el del 20minutos, por ser una página que me saca de quicio cuando tengo que cargarla en el iPhone, ya que casi es 1 mega de información con todos los archivos que carga, y es famosa por su carga de contenidos.
La página home tiene 219 archivos, que van uno a uno a nuestro ordenador la primera vez que la cargamos. Afortunadamente, gracias a la caché, «sólo» son 49 los que hay que cargar por segunda vez. Entre ellos están 25 Javascripts, 33 hojas de estilo y más de 100 imagenes. Con apenas un primer nivel de optimización básica, se podría reducir el número de archivos cargados totales a menos de 160, comprimiendo JS y CSS. Las imagenes CSS podrían reducirse a un par, y las imagenes, haciéndo un breve estudio (tampoco le voy a hacer la consultoría entera gratuita al 20minutos ;)) se podrían reducir más de un 30% de su peso (no en número).
Así pues, se podría pasar de una página de 220 archivos con 960K de descarga, a otra de unos 120 archivos con 380K de descarga. Multipliquemos por unos 50.000 usuarios al día (supongo que tendrá más). El ahorro de descarga de transferencia por sus servidores al día sería de 29 terabytes, 20 veces más de lo que muchos disfrutan con un servidor dedicado, y seguro que unos cuantos de cientos de euros en la factura del periódico, además de, recordemos, una navegación mucho más agradable y rápida para el usuario, pudiéndo aumentar el número de páginas vistas por sesión.
Esto es simplemente un primer nivel de optimización, ya que existen muchísimos otros factores en el lado del servidor donde está alojada la página, o incluso en el código fuente, que hacen que la página sea más rápida y óptima tanto para navegadores como para buscadores.
En tiempos de crisis, no deberíamos derrochar tanto byte :P