Con este artículo empezaremos una serie de posts que tratarán de diversas técnicas y consejos que podemos seguir para mejorar el rendimiento y los tiempos de carga de nuestra página web. Y es que el rendimiento de una aplicación web no sólo depende de la programación del lado del servidor, si no también del marcado, el uso que hagamos de hojas de estilo, de imágenes, de nuestra programación javascript... Todos ellos campos que afectan directamente al desarrollador web en su faceta de maquetador/diseñador.

Hoy empezaremos desarrollando una técnica CSS muy sencilla y efectiva: Los CSS Sprites.

La problemática.

Una de nuestras máximas prioridades a la hora de optimizar nuestra aplicación web debe ser reducir las peticiones que ésta hará al servidor una vez el HTML se haya cargado en el navegador del cliente. Cada archivo de hoja de estilos, cada archivo Javascript, cada imagen... cada elemento externo en definitiva, se solicita de forma separada y aumenta por tanto la transferencia y el tiempo de carga, esto resulta obvio. Lo que no resulta tan evidente es que ese aumento no es proporcional a la suma del tamaño de los archivos externos, es decir, la carga de 10 elementos de 5 KB no es igual de rápida que la de un elemento de 50 KB.

Además de sumar los tiempos de transferencia para cada archivo, deberemos sumar por un lado el tiempo que tarda en realizarse la propia conexión+petición+respuesta y el tamaño correspondiente a las cabeceras del archivo. Recordemos, en relación a las cabecera, que éstas se adjuntan a cada petición al servidor y que si, además, nuestra aplicación usa cookies, éstas también se adjuntarán a cabeceras para cada archivo. Podría darse el caso, por ejemplo en un archivo de imagen pequeño, en qué el tamaño de las cabeceras + cookies ¡superara al tamaño del propio archivo!

La solución.

Este sería un claro ejemplo de una técnica antigua retomada para solucionar un problema moderno. Y es que para encontrar el origen de los CSS Sprites debemos mirar atrás hacia los antiguos juegos en 2D ( o los actuales juegos para móviles ), que usaban los "sprites" para las animaciones de sus personajes u otros elementos del juego. 

Como ves, los sprites no eran más que imágenes que contenían a su vez varias imágenes pequeñas, que en el caso de los videojuegos se utilizaban para recrear una animación. En nuestro caso, la solución a las múltiples peticiones para imágenes en nuestras hojas de estilo pasará por el uso de imágenes grandes que contengan a su vez varias imágenes más pequeñas. De esta forma, para mostrar diversos fondos o varios iconos, estaremos realizando una única petición al servidor, con el correspondiente ahorro en tiempo de carga y transferencia.

Implementación.

El "truco" en esta técnica está en el uso correcto del posicionamiento de backgrounds para mostrar sólo aquella parte de la imagen que nos interesa. Pongamos como ejemplo un menú, en el que queremos mostrar un icono diferente por cada opción.

Nuestro HTML podría ser algo parecido a:

y para el CSS usaríamos

    .option1, .option2, .option3 { padding-left:20px; }
    .option1 { background:url(iconos.png) 0 0 no-repeat;
    .option2 { background:url(iconos.png) 0 -30px no-repeat;
    .option3 { background:url(iconos.png) 0 -60px no-repeat;

Como verás, hemos jugado con el posicionamiento vertical de la imagen para mostrar sólo aquella parte de la misma que nos interesa, la que contiene el icono en cuestión:

A partir de aquí podemos aplicar esta técnica de trabajo a muchos otros casos, ya no sólo iconos, sino fondos de imagen, pestañas, u otros elementos gráficos de interfaz.

Es fácil hacerse una idea del ahorro conexiones que podemos conseguir: una página con 20 iconos y 3 fondos de imagen diferentes para distintos contenedores pasaría de 23 peticiones de imágenes desde las CSS a sólo 2: una imagen conteniendo todos los iconos y otra conteniendo los fondos.

Más información.

• Ejemplo práctico: La home de Yahoo
• CSS Sprites en A List Apart 

Hoy descubro a través de Vecindad Gráfica una fantástica recopilación de pinceles para Photoshop. Estos pinceles pueden ahorrarnos unas horitas de trabajo cuando nos encontremos enfrascados ilustrando un  diseño. La mayoría de ellos están preparados para trabajar a alta resolución, con lo que además podremos usarlos no sólo para trabajos web, si no también para proyectos de impresión. Os recomiendo descargarlos y echarles un vistazo, seguro que encontraréis alguno interesante.

Enlace | 100 increíbles pinceles de alta resolución para Photoshop

Aquí vamos de nuevo, arrancando el tercer y último día de las jornadas, dedicado a un workshop full day que va a ser dirigido por Tantek Çelik, sobre Microformatos.

10:36 - Tantek ha empezado haciendo una pequeña introducción hablando de los orígenes de la web semántica. Está hablando del concepto POSH. Comenta que espera que la jornada sea lo más interactiva posible, invitando a participar a todos aquellos que quieran comentar cualquier cosa durante sus explicaciones.

Describe algunos de los microformatos más elementales, empezando por rel. El atributo rel puede usarse para implementar, por ejemplo, los microformatos rel-license ( para indicar la licencia aplicable a determinado contenido ), XFN ( para indicar la relación existente entre dos personas ), rel-tag ( para indicar que determinado enlace responde a una categorización _etiqueta_ ), vote-links ( para indicar que un enlace se usa para votar / valorar determinado contenido ).

11:16 - He subido algunas fotos más al álbum de Flickr. Mientrs tanto Tantek ha hablado de la importancia de tener en cuenta la accesibilidad cuando trabajemos con microformatos. Ha comentado también acerca de las etiquetas abbr y acronym, cuyo uso correcto estaba convencido que conocía y... no!

Hasta ahora utilizaba la etiqueta acronym para marcar cualquier conjunto de iniciales que sirva para identificar un concepto ( FBI, HTML, KISS, POSH, LAMP... ), cuando en realidad sólo debe usarse para aquellos que funcionan y se leen como una palabra. Haciendo caso a los ejemplos anteriores, sólo lo serían KISS, POSH o LAMP. Por mi parte sólo usaba ABBR para abreviaciones de palabras del tipo etc., telf., dña., d., e.g., ... Haciendo caso a la especificación, FBI, HTML, WWW... deberían marcarse con la etiqueta ABBR. Nunca te acostarás sin saber una cosa más.

11:30 - Está hablando sobre el microformato hCard, utilizado para marcar perfiles de usuario ( nombre, nickname, email, dirección... ) El microformato hCard basa su estructura en el formato vCard, usado en la mayoría de software y dispositivos que trabajan con información de contactos ( agendas PDA, teléfonos, aplicaciones tipo Outlook... )

12:42 - Tras el descanso para el café, empieza retomando el tema del hCard, y recomienda a aquellos que hayan traído portátil instalar la extensión Operator para Firefox. Operator permite interactuar con aquellos elementos de una página que hagan uso de microformatos. Funciona como una barra de herramientas adicional que nos da acceso a aquellos contactos, eventos, direcciones, tags... que haya marcados en la página, ofreciendo opciones para exportar la información que contienen. Por ejemplo en el caso de contactos marcados con hCard, nos permite exportarlos a nuestro gestor de contactos ( Outlook, libreta de direcciones, la Agenda en Mac... ).

12:56 - Han repartido algunos ejercicios entre los asistentes. Se propone una práctica para marcar un perfil sencillo con nuestro nombre y nuestra web. En realidad no tiene más misterio que conocer qué nombres de clase usar y para qué. Revisad la especificación y haced vosotros mismos algunas pruebas usando Operator para comprobar que lo hacéis correctamente. Como curiosidad podéis ver algunos atajos permitidos para simplificar el marcado de nombres.

13:41 - Seguimos viendo ejemplos y realizando algunos ejercicios prácticos. Quizás lo más interesante es que está apuntando a algunas excepciones útiles para identificar o marcar casos concretos, combinando algunos de los atributos de determinada forma. Prometo una recopilación a posteriori... Ahora prefiero atender.

14:09 - Media hora más tarde de lo previsto... a comer!

-------- 

16:49 - Finally! Termina con hCard y pasa a comentar hCalendar. Pone como ejemplo a Upcoming ( algo así como Eventtos, pero en inglés y con algunas funcionalidades orientadas a red social ). Recuerda que se pueden usar cualquiera de los generadores de microformatos disponibles en la propia página de microformats.org.

Resulta interesante la idea de combinar y / o anidar diferentes microformatos para conseguir estructuras complejas. Pone como ejemplo un evento marcado con hCalendar cuyo location se marca usando hCard, indicando que se trata de un negocio.

17:59 - C'est fini. Hemos hecho un repaso de un par de microformatos algo más complejos, como son hReview y hResume, que combinan estructuras de microformatos más elementales. Como se veía venir... nada de XFN. Le atacaré ahora si se deja, o via mail.

Ala, un placer compartirlo con ustedes. Ahora, a recoger y pillar el taxi para el aeropuerto, que esta noche llego tarde y empalmo con la despedida de soltero de Raúl. Let's rock.

Empieza el segundo día de las jornadas. Parece que la espicha hizo estragos entre los participantes: la sala está medio vacía. De todas formas la primera ponente ha empezado su presentación. Se trata de George Oates, de Flickr, y va a hablarnos de "Cómo diseñar para y con la Comunidad Web". Here we go.

10:18 - Empieza explicando qué es Flickr. "Un buen lugar para compartir fotos". Da algunos números interesantes. Tienen más o menos 1.4 ¡billones! de fotos. ¿Sabíais que Flickr empezó siendo un juego online? Quizás haya algo en la Wayback Machine... De todas formas, comenta que ya en aquella versión "primitiva" de Flickr, la idea subyacente era permitir la colaboración, la idea de poder "compartir" con otros usuarios...

10: 24 - Comenta que sólo eran 5 personas cuando empezó todo, pero que el equipo creció rápidamente. Habla sobre el proceso de desarrollo y publicación de código y fixes en Flickr: realizan releases de código varias veces al dia. Defiende el concepto de Beta como un estado en el que se acepta la idea de que algunas cosas puedan fallar, pero que se encuentra en contínua mejora y evolución, los errores se solucionan sobre la marcha.

Flickr: fundamentos para su crecimiento

• Está formado por gente. Es importante tenerles en cuenta. Importancia de la gestión de la privacidad.
• Diseñar teniendo en cuenta el "blank state". Lo comentaré con detalle más tarde, hay algún link por ahí de 37signals que puede ser interesante para ampliar este concepto.
• Tener en cuenta la configuración por defecto de las opciones de privacidad tratando de tener el cuenta la mejor experiencia posible para el usuario.
• Ofrecer diferentes vías para disfrutar de la experiencia.
• Mostrar la actividad de los usuarios. Es una de las bases del sistema
• Ofrecer ayuda y soporte de forma accesible y sencilla. Habla de las normas de comportamiento de la comunidad para asegurar un ambiente de relación correcto entre usuarios. Interesante...
• Mantener un punto de vista neutral. "Un gran poder comporta una gran responsabilidad". Interesante de nuevo... no debe ser nada fácil gestionar una comunidad virtual tan inmensa como la de Flickr.

10:44 -  Habla de la API externa de Flickr. La API no deja de ser una representación virtual de Flickr de la cual cualquier desarrollador puede sacar partido para crear su propia aplicación, reinterpretando los contenidos para mostrar su propia idea. Muestra algunos ejemplos originales de aplicaciones que sacan partido de la API de Flickr. Recomienda visitar Big Huge Labs, donde se muestran decenas de desarrollos específicos que parten de la API de Flickr.

10: 49 - Aparecen las machine tags, y comenta sobre diferentes aplicaciones que sacan partido de ellas. Básicamente se trata de etiquetas complejas que permiten añadir un nivel de especificidad. LastFM por ejemplo las usa para relacionar fotografías en Flickr con eventos registrados en su site. Por ejemplo "lastfm:event=290867" nos diría que la etiqueta corresponde a LastFM, e identificaría que pertenece al evento 290867.

Habla de los riesgos de ofrecer su API en abierto, y de algunos estragos causados por desarrolladores poco cuidadosos... ( ¿ha mostrado una gráfica de cacti? )

Insiste en el respeto a la privacidad.

Los ordenadores adoran los estándares... las personas no tanto. La gestión del caos en la comunidad mediante la cooperación.  

Aplausos. 

11:14 - Mi batería se termina. Agh.

---

20:18 - Ya en el hotel, pasando las fotos del día al portátil para subirlas a Flickr. Las colgaré en el álbum que ya creé ayer, Fundamentos web 2007, y también en el grupo de Flickr de Fundamentos Web. Para las ponencias que no he podido "retransmitir", podéis esperar un par de días a que ordene las notas y las recoja en un post ( aunque de hoy creo que sólo rescataré la ponencia de Tantek Çelik sobre microformatos y las redes sociales abiertas... ) , o revisar torresburriel.com o tripix.net, donde han realizado un exhaustivo seguimiento de las mismas.

Trataré de actualizar este post con la información más relevante de las jornadas. También podéis seguir el evento a través de los exhaustivos seguimientos a los que nos tiene acostumbrados Daniel (me da que le tengo a un par de asientos).  

10:15- Acaban de terminar las presentaciones y el bla bla bla institucionales. Empieza el programa. La próxima ponencia se titual "10 años de CSS ( y los que le quedan)". Let's go.

Los principios

• Mantener el HTML independiente del dispositivo y accesible
• Hacer más fáciles de mantener los documentos, compartiendo los criterios de estilo.
• Más y mejor control del estilo
• Compartir el estilo con otros formatos SGML

La recomendación del w3c sobre CSS 1 fecha del 17 de diciembre de 1996

Originalmente sólo se plantearon 2 niveles, pero:

• Demasiadas cosas tuvieron que dejarse fuera de la especificación ( bordes redondeados, sombras, etc...)
• Algunas cosas se incluyeron en la especificación pero no se implementaron masivamente.
•  Otras cosas se especificaron o se implementaron de forma incorrecta. ( IE suckof, cof, cof... )

Se decidió revisar el nivel 2 de CSS, con lo que:

• Se solucionaron algunas ambigüedades
• Se eliminaron algunas indefiniciones
• Se aplazaron funcionalidades hasta el nivel 3
• Se empezó en 2002 y se ¿terminó? este mismo año, 2007

En general el esfuerzo ha sido exitoso: hay menos bugs de navegador y el uso de CSS ha crecido a un 72% (!)

Prioridades en el desarrollo de CSS 3

• Grid-based layouts
• Rotaciones, etc.
• Texto en vertival
• Impresión de libros
• Aritmética simple
• Fondos mejorados
• Bordes mejorados
• Sombras
• Transparencias
• Fuentes incrustadas
• Layouts para interfaces gráficas de usuario
• Presentaciones
• Comportamiento de los enlaces

 10:45 - Está poniendo algunos ejemplos de layouts complejos. Recuerdo algunas cosillas que nos avanzó el año pasado Dave Shea sobre CSS 3. Un año más tarde y seguimos aquí. No nos queda ná para conseguir eso, y que todos los navegadores lo soporten!

10:53 - La charla está acabando, llega la ronda de preguntas. Creo que haré una pausa... pensaba que la batería del portátil aguantaría un poco más, pero se hace mayor... ;-)

16:06 - Hemos terminado de comer y empieza la ponencia de Arthur Barstow, de Nokia: "Movilidad y estándares web". Los problemas de batería se suman a algunos problemas de red que hacen realmente difícil navegar o postear. Por el momento seguiré tomando notas en papel. Durante la tarde publicaré algunos resúmenes. De momento se mantiene el interés.  Buenísima la ponencia de Jeffrey Veen, de Google: "Diseñando la nueva generación de aplicaciones web". Un orador nato. :)

----

20:14 - Reflexión: tengo que cambiar de portátil. O mejor dicho: es la última vez que me llevo portátil ajeno a este tipo de eventos. MacBook ya. En fins... a falta de portátil he ido ordenando algunas ideas en papel que espero poder plasmar entre hoy ( va a ser complicado ) y mañana.  La charla de la tarde no ha estado mal, y el debate ha tenido momentos interesantes ( ¿siempre traen a uno de Microsoft para acribillarlo? ) comentando temas sobre el papel del W3C en todo esto de la web semántica, sobre la innovación, sobre cómo las definiciones evolucionan constantemente y otras yerbas. 

He colgado algunas fotos en Flickr, y podéis consultar las del resto en el grupo que hay creado bajo el nombre Fundamentos Web. Ahora voy a ir bajando que dentro de un ratín empieza la espicha. Mañana más. 

Por fin ha llegado el dia: Mañana empiezan en Gijón las jornadas de Fundamentos Web 2007.

A los que tenéis que suerte de poder asistir, espero poder saludaros en persona y tomar juntos unas sidras a la salud de los estándares web, y a los que no, informaros que realizaremos un seguimiento de las ponencias, tanto a través del blog como de  nuestro Twitter ( http://www.twitter.com/pixelovers ).

Yo voy tirando para el aeropuerto o no llegaré a tiempo... ¡Hasta mañana! 

La inclusión del botón de acceso directo a iTunes en la portada ha servido a los chicos de Signal VS Noise para hacer una pequeña reflexión acerca de los motivos que han llevado a Apple a colocar ese botoncito ahí y no en otro lugar. Me ha parecido muy acertada, así que aprovecho para compartirla con vosotros.

Como ilustra la imagen, la posición siguiendo un criterio de consistencia, la natural respecto a nuestro orden de lectura-escritura, hubiera sido la izquierda. A pesar de esto, los responsables del diseño del interface del iPhone han decidido ubicar el nuevo icono a la derecha, primando la proximidad a otra opción relacionada: el botón de iPod. Ha primado el contexto frente a la consistencia.

Por otro lado resulta interesante fijarse en qué las dos opciones posiblemente más destacadas, SMS ( en primer lugar y arriba a la izquierda ) e iTunes ( en último lugar y abajo a la derecha ), son las dos que reportan algún tipo de beneficio económico directo a la compañía ( recordad que Apple recibe un porcentaje del gasto de llamadas y SMS del terminal ). ¿Intencional o casual? Genial, en cualquier caso.

Via | Signal VS Noise