El Diario de Aleth

Para los que queráis ver los artículos anteriores de ésta serie:

• Optimización web ( I )
• Optimización web ( II ) : CSS Sprites

En este capítulo no apuntaremos muy alto, pero introduciremos una “nueva” herramienta (para los que no la conozcáis, claro está) y seguiremos en la misma línea de intentar reducir el peso de la página. En capítulos posteriores introduciremos otras técnicas complementarias que ya no consistirán en “aligerar” la página.

Texto plano : CSS y JavaScript

A medida que hacemos que nuestra página web sea más y más dinámica y vayamos refinando su estilo los archivos JS y CSS de nuestro sitio crecerán hasta llegar a alcanzar tamaños considerables para tratarse de simples archivos de texto plano. Podéis ver por ejemplo el tamaño de jQuery o Prototype, las dos librerías son bastante pesadas en cuanto a tamaño.

Ciertos programadores de Yahoo decidieron entonces crear una herramienta, el YUI Compressor . Podéis obtenerla desde su página oficial o bien, si estáis usando Debian o Ubuntu (supongo que también estará disponible en Fedora y otras distros) podéis instalarla mediante el instalador apt:

apt-get install yui-compressor

Esta herramienta nos servirá para eliminar todo aquello cuanto sea innecesario en nuestras hojas de estilo y ficheros de script. El problema es que lo hará eliminando espacios, puntos y coma donde pueda, saltos de línea… incluso a veces modificando los nombres de algunas variables internas en funciones para acortarlos. No hará lo mismo con los nombres de las funciones ya que si lo hiciera el fichero de script se tornaría inútil ¡Ni una de las llamadas realizadas desde la página funcionaría!

La forma de hacerlo funcionar (funciona sobre la línea de comandos) es bien sencilla:

yui-compressor fichero_que_quiero_minimizar.css -o nombre_de_nuevo_fichero_minimizado.css

Lo mismo se aplica a los ficheros con extensión .js , aunque yui-compressor dispone de algunas opciones específicas más para esta extensión. Si queréis conocer las opciones de yui-compressor solo tenéis que llamarlo con la opción –help .

Importante: YUI-Compressor no se lleva bien con el CSS no estándar, es decir, si os da por probar características aun experimentales como los gradientes de Firefox, Chrome, Safari u Opera entonces tendréis que ir con más cuidado para evitar que YUI-Compressor os estropee vuestros CSS .

Quiero destacar que, dado que probablemente vayáis a estar desarrollando la web al mismo tiempo que ésta ya esté online y siendo visitada por surferos de la red, el tener código ofuscado por esta herramienta os pueda parecer sumamente molesto aunque os permita reducir el tiempo de envío de los ficheros. Lo que recomiendo en estos casos es no subir directamente lo que tengáis en vuestro directorio de trabajo al servidor sino que tengáis un directorio intermedio donde haya las versiones optimizadas de dichos archivos. Una opción para hacer llevadero este sistema es que os hagáis un script que os sincronice los dos directorios (en una sola dirección, claro) a la vez que os comprime las hojas de estilo y los ficheros de script con yui-compressor de forma automatizada. Al principio puede parecer un rollo hacerse el script, pero a la larga simplifica muchísimo el trabajo y ahorra más tiempo aun.

Imágenes: paletas indexadas

En el capítulo anterior ya hice algunas referencias a las imágenes con paletas indexadas ¿pero qué son exactamente? Intentaré no extenderme con la explicación mucho porque esto es más propio del estudio de gráficos por computador que del diseño de páginas web. Para los que ya sepáis a qué me refiero podéis saltar directamente a la parte práctica, donde comento el caso práctico con GIMP.

Los ordenadores actuales acostumbran a representar internamente los colores mediante tres números (generalmente enteros), uno para cada color luz “básico”. Éstos colores luz básicos son el rojo, el verde y el azul, y por eso llamamos al esquema de representación mencionado RGB (Red Green Blue). Combinando dichos colores podemos obtener “todos” los demás ( en realidad es falso, pero a nivel perceptivo podríamos decir que es cierto ). Normalmente se usan números del 0 al 255, siendo el 0 el número que indica intensidad mínima y el 255 la máxima. Así el color blanco estaría representado por la terna (255, 255, 255). Cada uno de estos números cabe en un byte, por lo que para representar el color de un solo píxel necesitamos 3 bytes.

El sistema mencionado conlleva un problema: las imágenes acaban pesando demasiado. Por eso mismo se inventaron formatos de imágen en los que se aplican ciertas técnicas de compresión, como JPEG, GIF o PNG. JPEG aplica compresión “con pérdida”, lo que significa que se pierden ciertos detalles poco importantes de la imagen a cambio de una reducción drástica en su tamaño, mientras que en otros formatos se usa compresión “sin pérdida”. No “perderé el tiempo” explicándoos como funcionan los sistemas de compresión (en general) porque necesitaría introducir la Teoría de la información y entonces no acabaríamos nunca.

Pero sí os explicaré un sistema de compresión de imágenes muy básico y fácil de entender, el indexado de colores. En el caso de tener una imagen con una cantidad relativamente pequeña de colores nos podemos plantear una forma sencilla para reducir su tamaño: hacer una lista de colores de forma que para cada uno haya un número determinado por su posición en la lista. Si la lista tiene 255 o menos colores podremos representar cada pixel con un solo byte en vez de con 3, pues sólo tendremos que usar un número y no 3 para indicar su color. Si tuviéramos 16535 (256×256-1) o menos colores en nuestra lista, podríamos usar 2 bytes en vez de 3 para representar cada píxel, la reducción no es tanta en este caso, pero sigue siendo considerable. ¿Y solo se puede reducir en un factor de 3 el tamaño de la imagen? No, de hecho podemos reducir aun más el tamaño de la imagen, pero en este caso la lista de colores debería ser más pequeña. Por ejemplo, si tuvieramos 127 o menos colores podríamos reducir en un factor de 6 el tamaño de la imagen (descontando el pequeño añadido en tamaño debido a la lista de colores), si tuvieramos 63 o menos colores podríamos reducir en un factor de 12 el tamaño de la imágen, y así. Supongo que podéis ver fácilmente el patrón.

Práctica

Es interesante saber como reducir el tamaño de nuestras imágenes sin perder demasiada calidad. Una forma sería guardar nuestras imágenes en formato JPEG con una calidad inferior o igual al 85%. En cualquier editor gráfico que se precie podréis seleccionar la calidad de salida del fichero JPEG si hacéis “Guardar como…” o “Exportar”.

El problema de la opción JPEG es que sirve más para imágenes grandes o fotografías que para elementos de la web, en los que probablemente querremos más nitidez. Por suerte, aunque queramos más nitidez también se dará el caso de que usamos menos colores y las imágenes serán más pequeñas, en este caso es aconsejable usar imágenes con paletas indexadas. Indicaré como hacerlo en GIMP, hace tiempo que no toco Photoshop y no sabría deciros qué pasos exactos deberéis seguir los que lo uséis, pero seguramente será también bastante intuitivo.

En primer lugar debéis acceder al menú de Imagen e ir a seleccionar un modo:

Una vez ahí podréis seleccionar cuantos colores queréis que haya en la paleta. A veces se dará el caso de que la imagen tenga más de 255 colores (en este caso las paletas pueden tener solo 255 colores, aunque en la teoría se pudieran tener paletas más grandes), en dicho caso podéis optar por perder algo de calidad eliminando algunos colores (el editor intentará aproximarlos lo mejor posible con los colores de la paleta) o renunciar al indexado de colores.

Después solo tendréis que guardar la imágen (recomiendo el formato PNG por encima de GIF), si usáis las nuevas versiones de Gimp tendréis que usar la opción Exportar y no Guardar, pues ésta se ha dejado solo para el formato nativo de Gimp, XCF .

Consejo final (fuera de contexto)

Lo que escribiré ahora debería haber estado en capítulos anteriores, pero me despisté. Aunque sea recomendable reducir la cantidad de ficheros que deben ser cargados para visualizar la página, hay algunas excepciones que vale la pena mencionar. Tal es el caso de las imágenes redimensionadas, no conviene redimensionar una imagen en tiempo de renderizado dentro de la web, es decir, no es conveniente ajustas las medidas de una imagen a otras que no sean las suyas. El tiempo que tarda el ordenador del visitante en redimensionar hace que su experiencia pueda verse mermada, es preferible tener distintas versiones de la imagen adaptadas a los tamaños pertinentes. Es usual que las redimensiones se den cuando se quieren hacer thumbnails, y también es usual que cuando se está visualizando el thumbnail no se esté visualizando simultáneamente la imagen a tamaño real, por lo que (generalmente) no supondrá un problema en cuanto aumento de peticiones HTTP tener versiones específicas de la imagen para cada tamaño.

Espero que os haya resultado útil, un saludo .

Continuamos la serie sobre optimización web empezada en el artículo “Optimización web ( I )“ .

En este capítulo trataremos una técnica que viene siendo usada desde mucho antes de la aparición de la web dentro del mundo de la programación, en concreto dentro del mundo de los videojuegos, y en algunas ocasiones en la creación de interfaces gráficas. Los que ya sepáis algo sobre eso y hayáis leído el título, como buenos lectores que sois, ya debéis saber a qué me refiero, para los que el título no les diga mucho os daré una breve explicación.

La técnica de trabajar con sprites está relacionada con la presentación de imágenes por pantalla, por lo general pequeñas. Usualmente, tanto en webs como en videojuegos, acabamos teniendo conjuntos enormes de imágenes. Cada una de estas imágenes acostumbra a tener un fichero asociado (siempre y cuando no estemos usando ya la técnica de los sprites) y eso tiene bastantes implicaciones (negativas) en el rendimiento de nuestra página o videojuego.

En el caso de los videojuegos las desventajas son varias:

• Por cada imagen se tiene que hacer una lectura de disco, además, el hecho de que estén en ficheros separados puede implicar fácilmente que las imágenes estén alejadas unas de otras (físicamente) sobre el disco. No es que se trate de fragmentación, pero a efectos prácticos conlleva casi los mismos problemas de lentitud.
• Normalmente, siempre y cuando el programador o grafista no tenga problemas neuronales o de visión, las paletas de colores de cada imagen serán muy parecidas entre ellas (habrá paleta si y solo si usamos un esquema de colores indexados, lo que se hace para reducir el tamaño final de la imágen, aunque implica que podamos usar menos colores que usando directamente el esquema RGB). El hecho de que no se compartan esas paletas implica que se carga información redundante en memoria por cada imágen que leemos desde el disco (lo que implica un mayor consumo de memoria).

En el caso de las páginas web, los problemas pueden llegar a ser incluso peores:

• A parte de que el servidor tiene que hacer bastantes lecturas de disco por cada página web cargada (sí, ya sé que muchos los cargará en alguna caché en memoria y todo eso, pero si el sitio web es mínimamente grande los contenidos de la cache irán rotando, y si el sitio está alojado en un hosting compartido la cosa será más complicada aun) también tendrá que hacer más envíos al navegador del visitante para que éste pueda visualizar la página web por completo. Y ahí es donde está el gran problema, los tiempos de lectura de disco son casi despreciables si los comparamos con los tiempos de envío a través de la red, pues no se envía solo la imágen, sino que además también se envían sus respectivas cabeceras HTTP, lo que incrementa la cantidad de información a enviar.
• Como antes, el navegador consumirá más memoria para mantener esas imágenes, esto ahora mismo no supone un gran problema porque los ordenadores personales cada vez tienen más memoria principal, pero también es importante decir que los usuarios se están acostumbrando a abrir cada vez más pestañas en sus navegadores… y aquí el consumo de memoria se dispara y su importancia (aunque sigue siendo poca) crece algo más.
• Si se tienen elementos mínimamente dinámicos, como botones pulsables que cambian su imagen de fondo cuando se pasa el ratón por encima o cuando se hace click sobre ellos puede aparecer un problema estético muy importante, resulta que dado que la página no debía cargar la imagen en el primer momento de renderizado… casi en todos los navegadores se da el hecho de que ésta no se descarga hasta el momento de ser necesitada. Esto implica que en el momento de pasar el ratón por encima del susodicho botoncito nos encontraremos con que la imágen no cambia inmediatamente (la primera vez que lo hagamos), habrá un retraso perceptible bastante antiestético y que puede llegar incluso a confundir al visitante, pues puede tener la sensación de que el elemento está bloqueado o algo por el estilo.

El primer punto junto con el tercero son los que más motivan la técnica de los CSS Sprites, que paso a comentar seguidamente.

La técnica de los CSS Sprites consiste en combinar un conjunto de imágenes en una sola, formando una especie de mosaico, para luego mostrar solo las partes que nos interesen de ella en ciertos elementos de la web. Cargar una sola imagen nos ayudará a reducir la cantidad de peticiones HTTP, eliminará el problema del retraso comentado anteriormente, y en muchas ocasiones también nos servirá para reducir el tamaño total de las imágenes (porque, en el caso de tener una paleta de colores indexada es probable que compartan una gran parte de ésta). Tengo que decir que, aunque en la mayoría de casos podamos conseguir el beneficio extra de reducir el tamaño total de las imagenes, esto no siempre es así y a veces puede pasar incluso lo contrario, aun así los beneficios de reducir la cantidad de peticiones HTTP compensarían esta penalización.

Si nos fijamos, la mayoría de páginas web ultrarápidas que nos puedan pasar por la cabeza usan ésta técnica, el ejemplo paradigmático de página web ligera es la del buscador de Google. Os muestro una de las imágenes que usan para aplicar la técnica:

Y ahora viene la parte interesante, he hablado mucho pero todavía no he explicado como hacer esto. ¿Como se hace pues? Pues no hay una fórmula exacta, pero intentaré sentar las bases para que cada uno pueda aplicar las variaciones que considere pertinentes.

Para facilitar las cosas empezaremos con elementos de tamaño fijo, supongamos que tenemos un elemento div con tamaño 32×32, y tenemos en una imágen un set de iconos de 32×32 .. no sé, unas ocho filas por ocho columnas de iconos, unos 64. Supongamos también que queremos que el fondo de dicho elemento div sea el icono situado en la fila 6 y columna 5. Lo que escribiremos en la hoja de estilos CSS es:

background:url(/ruta/a/la/imagen.png) no-repeat -160px -192px }

Analizemos este trozo de código. la primera parte background nos indica que vamos a definir los atributos del fondo del elemento. url(/ruta/a/la/imagen.png) nos indica la imagen donde buscaremos nuestro fondo. -160px es la cantidad de pixels que nos tendremos que desplazar horizontalmente sobre la imagen que contiene los sprites para encontrar el fondo que queremos (5×32, 5 columnas), -192px ídem, pero para las filas. El elemento no-repeat nos indica que no queremos que la imagen se repita a modo de mosaico.

Aquí es importante destacar que debemos definir el tamaño del elemento al que queremos poner fondo para que no aparezcan a continuación de la imagen que queríamos mostrar todas sus “compañeras de viaje”. Otro punto interesante es que el elemento no-repeat podría ser cambiado por repeat-x o por repeat-y en algunos casos, como cuando queremos dibujar fondos periódicos o dibujar los contornos de alguna caja con tamaño variable (dependiendo del contenido). En este caso la distribución de las imágenes dentro de la imagen contenedora es muy importante, pues si hacemos un repeat-x y tenemos otras imágenes a la izquierda o la derecha de la que queremos repetir, el efecto que queríamos conseguir será estropeado. Ídem con el caso de repeat-y.

Esta técnica puede ser usada para crear menus, para personalizar las “bolitas” de las listas, para dibujar los bordes y el fondo de cajas con tamaño variable, para mejorar el efecto de elementos pulsables, etc.

Un saludo, y hasta la próxima entrega.

Hace muchísimo que no escribo ningún artículo técnico por aquí, y más aun que no escribo ninguna reflexión. Pero se acabó lo que se daba, a partir de ahora intentaré actualizar más frecuentemente el blog y hoy voy a empezar una pequeña serie de (también pequeños) artículos sobre optimización de páginas web.

Introducción

Cuando desarrollamos páginas web nos encontramos con decenas sino cientos de problemas a medida que avanzamos. Los que acostumbran a ser más usuales son los relacionados con la maquetación y el tan temido Microsoft Internet Explorer, otras veces tenemos problemas con el lenguaje de scripting en el lado del servidor, y otras con la base de datos… pero de lo que casi nunca nos salvamos (y pocas veces nos damos cuenta, al menos cuando somos aprendices) es de los problemas relacionados con el tiempo de carga y renderizado de la página.

Los tiempos de carga excesivos no son tan vistos como un problema debido a que no afectan al buen funcionamiento de las páginas y en parte también a nuestra experiencia con líneas de baja velocidad antes de la irrupción de ADSL y otras tecnologías de banda ancha, vamos, que estamos acostumbrados a sufrir y no lo notamos tanto. Aun así, y aunque los visitantes toleren bastante la lentitud, deberíamos encontrar la causa del ralentizamiento para atajarla.

Motivación

• Los visitantes se sienten más satisfechos cuando nuestro sitio carga rápida y fluidamente, lo que, en gran cantidad de contextos, nos puede reportar una mayor cantidad de beneficios económicos.
• Por lo general, hacer páginas rápidas y fluidas sirve también para consumir una menor cantidad de recusos del servidor por visita, lo que nos puede ahorrar costes económicos o bien permitirnos atender a más visitantes.
• Parece ser que la velocidad de carga de los sitios será un factor más a tener en cuenta por parte de algunos buscadores para el posicionamiento de las webs.
• Y el que nos debería importar más a los geeks: Hacer páginas web fluidas es síntoma de saber hacer bien las cosas, de un buen nivel técnico, y cuando todavía no se sabe como conseguirlo, supone un reto interesante.

Primeros pasos

Empezaremos con consejos aplicables a prácticamente cualquier tipo de página, servidor, framework de desarrollo, lenguaje de scripting en el lado del servidor… vamos, que iniciaremos la lista de consejos con algunos bastante universales y, siento decirlo, algo aburridillos (tranquilos, no faltarán consejos interesantes de verdad más adelante).

1. Intentad hacer vuestras páginas lo más pequeñas que os sea posible. Con esto no me refiero a que hagáis que las letras sean pequeñas, como supongo que habréis entendido, sino a que el tamaño del documento que envía el servidor web debería ser pequeño para que éste tarde el mínimo tiempo posible en enviarlo.
2. Para conseguir el punto anterior es muy importante que vuestro código sea limpio y conforme a los estándares, en particular: evitad usar tablas para tabular los elementos de vuestras páginas, para eso están los elementos div y span, y como no, las hojas de estilo en cascada (CSS).
3. Es interesante unificar todos los estilos de la página en un único archivo css, que podrá ser compartido entre diferentes secciones de ésta, de forma que solo se tendrá que descargar una vez la información de estilos y se podrá reutilizar para varias páginas de vuestro sitio.
4. Reducid la cantidad de ficheros a descargar para visualizar vuestra página, es decir, usad cuantos menos ficheros de imagen mejor, cuantas menos hojas de estilo, mejor, y cuantos menos ficheros de script, mejor también. Esto es muy importante debido a que cada petición HTTP implica una sobrecarga importante en el envío de información. La sobrecarga es debida a que, además de los ficheros en sí, se tienen que enviar también cabeceras con cierta metainformación, por lo que se pierde mucho tiempo enviando información “inútil”. Otro problema asociado es que las descargas son, en cierta medida, bloqueantes. El protocolo HTTP impone un límite de descargas simultáneas por página, por lo que éstas no se pueden paralelizar y se tienen que hacer una detrás de otra, provocando el retraso en la carga.
5. Ahora uno de los más extraños (por ser el menos evidente): Intentad situar el código JavaScript cuanto más cerca del final del documento, mejor. Esto es importante debido a que los navegadores pierden tiempo interpretando y ejecutando el código cuando lo encuentran, siendo esta tarea también bloqueante. Así pues, si situáis el código JavaScript al final de vuestras páginas conseguiréis que sean renderizadas antes, mejorando la experiencia del usuario.

Herramientas

Aunque todavía tengo que explicar muchas cosas en esta serie de artículos, creo que puede ser conveniente para los que queráis ir más rápidos una lista de herramientas muy útiles que os ayudarán a encontrar más puntos a mejorar en vuestros sitios web.

• Speed Tracer: es una extensión para el navegador Chrome / Chromium creada por Google , nos permite ver el tiempo de carga del sitio web desglosado elemento por elemento para identificar algunos cuellos de botella de nuestro sitio. También da algunos pequeños consejos para mejorar la web cuando detecta fallos.
• YSlow: es una extensión para el navegador Firefox creada por Yahoo que, a mi parecer, junto con Speed Tracer forma un tandem perfecto. Se necesite instalar la extensión Firebug antes que ésta. Asigna una nota a la página que evaluamos mediante una media ponderada de puntuaciones sobre ciertos aspectos de ésta. No solo da puntuaciones, también es una herramienta a la que parece encantarle dar consejos, y muy buenos por cierto, aprendí bastante de ella xD, fue algo así como mi profesora. Los gráficos que genera ni son tan bonitos ni útiles como los de Speed Tracer, pero a cambio la información realmente útil se muestra mucho más digerida y apta para ser utilizada directamente.
• Page Speed: otra extensión creada por Google, pero esta vez para Firefox, que parece ser una mezcla entre YSlow y Speed Tracer, ésta muestra directamente una lista de consejos que deberíamos seguir, y los marca en rojo, amarillo o verde segun considere si ya lo estamos haciendo o no.

Hay muchas más herramientas  que podrían resultar útiles, pero estas son las más remarcables dentro del panorama actual… y ciñéndonos a las herramientas que nos dan información o consejos. Hay otras herramientas que comentaré en los siguientes artículos y que no listo aquí porque prefiero presentarlas dentro de un contexto más adecuado.

Espero que os haya resultado útil y/o interesante, un saludo .