El evento tendrá lugar el próximo lunes 21 de septiembre en la ETSI de Telecomunicaciones de la Universidad Politécnica de Madrid, y dará comienzo a las 19:00. Si estás interesado en asistir, regístrate con dos sencillos clicks.

Uno de los factores por los que nuestros visitantes pueden abandonar nuestra web es el tiempo de carga de las páginas. Un tiempo de carga excesivo, aparte de producir una mala experiencia de usuario, puede hacer que nuestros visitantes se aburran mientras esperan que se renderice la página mientras navegan por nuestra web. Así que os dejo una pequeña recopilación de consejos básicos para mejorar el rendimiento de nuestras páginas, muchos de ellos ayudan también a obtener un código más SEO-friendly.

Usa páginas de tamaños moderados. Si alguna página tuya ocupa mucho tamaño, tardará mucho en descargarse. A veces es mejor dividir el contenido en varias páginas, de forma que el tamaño de cada una sea menor y cargen de forma más rápida. Lo ideal es que tus páginas no lleguen a 500KB, pero como esto es a veces dificil de conseguir, mantente por debajo de 1MB por página.

Utiliza hojas de estilo CSS. En vez de incrustar los estilos dentro del código, mantén en archivos externos todo el código que definan el estilo de los elementos de tu web. Así el código de estilos no se descarga en cada visualización de página, la página pesa menos yse aprovecha la caché del navegador. Consejo SEO.

Minimiza el número de peticiones de archivos externos. Si puedes, agrupa todos los archivos .css o los archivos .js en uno sólo. Así reduces el número de peticiones HTTP y la carga de la página se realiza más rápidamente.

No uses javascript dentro del código. Agrupa y mete el código javascript en un archivo y enlázalo. Así el visitante descarga el archivo .js en la primera visualización, y para las siguientes ya tiene ese código descargado (caché).

Enlaza los archivos javascript desde el footer, no desde el header. Los archivos .js se descargan uno detrás de otro, no de forma paralela. Si los enlazamos en el header, el navegador no puede empezar a renderizar la página hasta que no ha descargado todos los archivos. Poniendo los .js en el footer, hacemos que se descarguen cuando la página ya se ha visualizado por completo. Aunque el tiempo de carga de la página es el mismo, la sensación de velocidad es distinta, ya que dejamos el trabajo pesado de descarga para el final. Esto se puede hacer siempre que no usemos funciones javascript que sean necesarias durante la carga de la página.

Descarga en serie de archivos javascript

No uses @import en los archivos CSS. Es preferible que utilices varios enlaces “link” desde el código de la página (descarga en paralelo), que importar hojas de estilo desde otras hojas de estilo (descarga en serie).

Usa el formato correcto en tus imágenes. Juega con archivos gif, png y jpg en las imágenes que subas a la web. Usa jpg para imágenes con mucha gama de colores, como fotos, y gif o png para aquellas que necesiten transparencias o tengan una gama de colores menor.

Usa image sprites. Para imágenes comunes en el diseño del sitio o que se repitan en muchas páginas, es conveniente usar image sprites. Por ejemplo, si todas tus webs hacen X peticiones de imágenes para colocar iconos decorativos, es más eficiente combinar esas imágenes en una sola y por CSS asignar al elemento de la web que queramos el fragmento de la imagen que queremos mostrar. Las imágenes se pueden descargar en paralelo, por eso sólo debemos usar esta técnica para imágenes comunes en el template del sitio.

Descarga en paralelo de imágenes

No uses redimensionamiento de imágenes dentro del código. ¿Para qué descargar una imagen a 1024×768 si luego le vas a poner una anchura de 300px? Utiliza imágenes del tamaño real que vayan a tener a la hora de visualizarlas. Si vas a usar algún tipo de galería con thumbnails, conviene usar imágenes pequeñas en los thumbnails para que la página cargue rápidamente, y descargar las imágenes a tamaño real en background, aunque con esto implique aumentar el tamaño de la página.

Evita contenido de más dentro del código. Una cosa es tener el código bien identado, y otra es que tengamos secciones con más de 100 líneas en blanco. Si eres muy purista, puedes pasar un compactador a tus archivos .css y .js para reducir el tamaño del archivo resultante. Eso sí, mantén siempre una copia sin compactar para trabajar con ella, porque editar un archivo compactado puede ser horrible. Puedes usar aplicaciones online como CSS Compressor o CSS Formatter and Optimiser para compactar tus CSS, o Yahoo! UI Library: YUI Compressor y Online Javascript compressor para los archivos javascript.

Evita enlazar contenido de otros dominios. Incluir información que esté alojada en otro dominio implica que la carga de nuestra página dependerá del estado del servidor de destino y de su tiempo de respuesta. Por ejemplo, en mi sidebar yo cargo mis dos últimos comentarios en Twitter, y cuando su sistema está muy saturado, la carga de mi web se ralentiza. Si haces algo de este estilo, no lo pongas en el header, ponlo en el sidebar derecho o footer. Así si tarda en cargar ese contenido, el header y la parte central de la web ya estará renderizado y el “atasco” se notará menos.

Nunca uses frames. No tiene nada que ver con el rendimiento, pero conviene que no uses frames por muchos otros motivos. Los frames era como se diseñaban las webs en 1995. Consejo SEO.

Por último, asegurate de que todo lo que has hecho funcione. Haz pruebas y mide los tiempos de carga, para descubrir dónde se pueden producir cuellos de botella o ver qué partes puedes modificar para aumentar el rendimiento. Yo uso la extensión Firebug para Firefox junto con YSlow, pero existen muchas otras herremientas de medición online.

Aclaración: por si te da por revisar el código de mi blog, todavía no está optimizado. Como con WordPress se pueden utilizar muchos puglins, cada uno lleva sus propios archivos .js, .css o imágenes. Todavía estoy trabajando en su optimización, lo que requiere en muchos casos que tenga que modificar el propio código de los plugins.

ftp://ftp.webdeloscreativos.es/clientes/nombre-de-mi-cliente/

Como me leí un libro de “Hacking para dummies“, se me ocurrió la feliz idea de escribir dirección pero eliminando de ella el nombre del cliente para el que trabajaba. Ahí estaba: toda la lista de clientes de la empresa de creatividad ante mis ojos. Mi curiosidad me llevó a entrar en algunos directorios (Movistar, Repsol…) a ver qué había. Y lo que me encontré fue el diseño de webs que estaban en fase de diseño o de creatividad.

¿Qué hubiera pasado si encuentro información sobre la futura estrategia en la red de la competencia? ¿Y si hubiese sido al revés? Mi competencia se habría enterado de la web que tenía en desarrollo, y podría haberse preparado para copiarme o para contrarrestar el lanzamiento de mi web. Y todo el trabajo y coste en lanzar un producto innovador y rompedor se podría haber ido al garete.

Con la abundancia de servicios que hay hoy en día en internet, que te copien una idea y la pongan en producción antes que tú puede tirar abajo tu proyecto sin haberlo sacado siquiera de la caja. Así que por favor, proteged las ideas y los desarrollos de vuestros clientes (y usad contraseñas en vuestros FTPs).

Don’t use @import

En resumen, desaconseja el uso de @import porque los archivos que se importan se hacen de forma secuencial, mientras que con link se hace de forma paralela.

pageTracker._setCookieTimeout(“604800″);

El valor del parámetro de la función _setCookieTimeout() es el periodo de caducidad de la cookie, expresado en segundos. Para el ejemplo que os pongo, 604800 segundos corresponden a 7 días (7x24x3600), que es precisamente el valor que tengo configurado en este blog y en algún otro site que administro.

¿Cómo puedo comprobar el valor de una cookie?

En Firefox, pulsamos Herramientas -> Opciones -> pestaña Privacidad -> Mostrar cookies. En el campo Buscar podemos escribir la URL o la cookie por la que queremos filtrar el listado que aparece en la parte inferior.

La cookie __utmz tiene el siguiente formato:

__utmz=XXX.YYY.V.C.utmccn=|utmcsr=| utmcmd=|utmctr=

donde:
XXX = es el hash único de tu domino web
YYY = hora unix o “timestamp” en que se creó la cookie
V = cuantas visitas ha realizado desde que se creó la cookie
S = número fuentes de origen distintas desde la que el usuario ha llegado a la web

La cookie cuenta una visita nueva por sesión, que por defecto expira cada 30 minutos de inactividad o cuando se cierra el navegador. Si la visita actual tiene origen distinto de tráfico directo, es decir, tiene como origen un referral o un buscador, la cookie existente se sobrescribirá con la nueva fuente de origen. No ocurre lo mismo si la visita actual tiene tráfico directo y la cookie existente tiene otro origen distinto.

Lo veremos mejor con un ejemplo. Un usuario visita la web tres veces y en este orden: desde un enlace de otra página (referral), mediante tráfico directo y por último desde un buscador. La cookie __utmz tendrá un valor XXX.YYY.3.2, que indicará que es la tercera vez que visitamos la web pero sólo hemos usado dos fuentes de tráfico. El acceso directo a la web, introduciento la dirección directamente en el navegador, lo ha contado como si fuera un referral.

¿Se puede considerar que Google con la configuración por defecto nos indica correctamente estadísticas sobre nuestros usuarios fidelizados? Yo creo que no.

Artículos relacionados:

• Google Analytics vs XiTi: cómo miden el origen de las visitas
• Google Analytics… ¿resulta que no es el único patito feo?