Optimizando la carga de nuestro CSS3

Optimizando la carga de nuestro CSS3 en HTML5

Este artículo debe considerarse como una continuación del artículo Cómo incluir CSS3 en HTML5

Optimizando la carga de nuestro CSS3

Una de las grandes pesadillas de los desarrolladores web es la típica frase: “La web va lenta”

Pues sí, todo el mundo considera que las páginas cargan lentas… da igual que haga auténticas virguerías, ni la relación directa entre complejidad y tiempo de carga… eso da igual, todos quieren que su web sea tan rápida como lo es google… con la pequeña diferencia de que los recursos que invierte google en ese objetivo y los que el resto del mundo invierte realmente, distan un poquito entre sí… pero un poquito de nada ¿eh?

Como curiosidad, las quejas de velocidad suelen tener una relación muy extraña… cuanto menos inversión exista más quejas encontrarás. Si quieres localizar de forma rápida un proyecto que te dará ese problema sí o sí, lo tienes muy fácil: Si alguien no está dispuesto a invertir en su web más de la mitad de lo que le costó su flamante Mac, estás perdido, a él le costará cuatro perras, pero el coste real de la página será el equivalente a unos 4 flamantes Mac y lo asumirás tú. Consejo: Huye, por dios, huye.

Si has sido un insensato y no has huido… o si realmente tienes un problema con la velocidad de carga de la página, hay una serie de consejos para aumentarla.

Todos, absolutamente todos los consejos de optimización se basan en dos principios:

  • Minimizar la cantidad de bytes que el servidor envía al navegador. A menos bytes, menos información manda, por lo que antes acaba de cargar.
  • Minimizar el número de procesos necesarios para ver la web. Aquí entendamos que 1 fichero = 1 proceso. Si tu web tiene 40 imágenes, ahí tienes 40 procesos, si además tiene 4 JS y 8 CSS estamos antes 53 procesos (no olvidemos el HTML en sí). A más procesos más tiempo de carga, a menos procesos pos….

Como el tema que nos ocupa es optimizar la carga de nuestro CSS3, nos centraremos sólo en CSS3.

Minimizar al máximo el número de ficheros .css a cargar

Este problema viene muy de la mano de los CMS. Este blog funciona con WordPress y, por lo tanto, lo sufre. En WordPress es muy habitual encontrarnos que cada plugin tiene su propio CSS, así que si tienes digamos… 30 plugins, tendrás 30 ficheros CSS a cargar. Esto se aplica también a Drupal, Joomla! etc etc.

Si estamos usando un CMS, nuestro margen de maniobra es pequeño ya que es una práctica muy mala modificar los plugins y módulos de terceros, por lo tanto esos CSS seguirán ahí.

En la medida de lo posible deberemos intentar tener nuestro código CSS3 en el menor número de ficheros posible.

OJO: La finalidad de reducir el número de ficheros CSS es minimizar el número de procesos que necesitamos abrir para cargar la web, si hacemos la genialidad de tener un fichero CSS con este código:

@import url("style1.css");
@import url("style2.css");
@import url("style3.css");
@import url("style4.css");

Muy bien campeón, he ahí la idea de bombero de la semana. Sí, cuando veamos el código fuente sólo tendremos un link que llame a un fichero CSS… ajam… peeeeeeeero cuando el navegador descargue y lea ese fichero, se encontrará con una serie de import que primero deberá interpretar (y eso lleva tiempo, poco, pero lleva) para llegar a la conclusión de que debe descargar cada uno de los ficheros CSS ahí indicados, por lo que abrirá un proceso por cada uno. Ale, con la tontería no hemos ganado nada… de hecho hemos perdido, porque necesita un proceso más para cargar la web y ese proceso extra lo que hace es procesar un fichero para concluir que debe descargar y abrir otros. Resumiendo: El import no lo debes usar jamás.

Minimizar el peso de nuestros ficheros .css

A la hora de escribir nuestro CSS3 tenemos, porque hacemos las cosas bien, muchos espacios en blanco como consecuencia de indentar (tabular) correctamente el documento. Esto es muy importante para la legibilidad de nuestro documento, pero no lo es tanto a la hora de que el navegador lo interprete, porque el navegador ignora los espacios en blanco.

Es por eso que existen servicios online como css compressor que eliminan todos los espacios en blanco de nuestro CSS3 dejándolo todo en una línea. Con esto logramos ficheros CSS más livianos y, por lo tanto, menos tiempo de carga.

Por supuesto, estos ficheros CSS sólo se utilizan en el sitio en producción, la versión en desarrollo tendrá los CSS perfectamente tabulados.

Usar los splites de imagen

Una técnica muy usada son los splites. Es muy habitual utilizar imágenes de fondo en nuestros documentos HTML. Para ello utilizamos el background de CSS3. Al mismo tiempo, esos fondos pueden cambiar cuando el ratón pasa por encima de la zona (lo que se conoce como hover).

Bien, si en nuestra regla CSS utilizamos una imagen para el background y otra diferente para el background hover, tenemos dos procesos más (sí claro, cualquier imagen que se use en el CSS es un proceso más). Una solución para este problema es tener una sola imagen con la parte del background y de su hover, de forma que utilizaremos la misma imagen para ambas reglas, por lo que sólo necesitaremos un proceso y no dos.

Esto se consigue combinando el background con su posibilidad de indicar la posición X e Y en la que debe empezar a leer el background y un ancho y algo fijo de la etiqueta dónde se incluye… de forma que aunque la imagen que se carga tiene tanto el fondo como su hover, sólo se ve la parte de la imagen que corresponda a uno u otro.

Esto puede ampliarse a otras situaciones como los iconos. Es muy común que los paneles de control (por ejemplo) tengan una serie de iconos para hacer más intuitiva la gestión. En vez de tener una imagen por cada icono (que podrían ser 50 iconos fácil), podemos tener sólo una con los 50 iconos y hacer que se vea únicamente el trozo del icono correspondiente vía CSS3.

Hay que tener en cuenta que utilizar spliters de imágenes es una labor costosa en tiempos de maquetación, por lo que desde el punto de vista del desarrollador sólo merece la pena la inversión de tiempo cuando realmente es necesario.

Un ejemplo de spliter se puede ver en http://www.alexmourer.com/blog-post/slow-speed-suicide-website-cant-take-abuse/ concretamente, la imagen es http://www.alexmourer.com/wp-content/uploads/2013/09/css-sprite.png

Otras técnicas avanzadas

Existen otros métodos de aumentar la velocidad de carga, pero ya entramos en temas mucho más avanzados de CSS y creo que ya sería excesivo. Si alguien tiene interés, los tiros van ya en la velocidad de interpretación y renderizado. Las reglas de CSS3 se ejecutan en un orden concreto tanto de lectura como de interpretación, conociéndolo a fondo (y con el tiempo suficiente para un correcto estudio) puedes definir las reglas de la forma más óptima y lograr sorprendentes resultados.

El dolor de la caché de nuestro CSS3 en los navegadores

Bueno, pongamos que ya tenemos nuestro CSS3 optimizadísimo, está muy bien… pero ahora llega el momento de mantenerlo, porque con el tiempo se hacen cambios en los estilos y es aquí cuando llega otro de nuestros mayores quebraderos de cabeza.

Los navegadores, en su afán por cargar las páginas más rápidas que los demás, tras acceder por primera vez a una web, guardan todos los elementos que consideran estáticos, como las imágenes, los javascript y, como no, los CSS.

Así que, cuando subes algún cambio, lo normal es que nadie los vea salvo que se recargue la caché o se acceda con el modo incógnito del navegador (que, entre otras cosas, no guarda caché). Con el paso del tiempo, los navegadores recachean la página y solucionado, pero mientras… ay mientras…

Esto es especialmente sangrante en las últimas versiones de chrome, donde es misión imposible borrar la caché… lo que es problemático cuando, por lo que sea, guarda en caché un error fatal y no hay forma de que te pille la corrección… pero bueno, esta es otra batalla.

El problema que nos ocupa se puede solucionar informando al navegador de la duración de la caché de los ficheros… sin embargo no siempre estamos en situación de poder hacer eso, así que se está generalizando otra solución.

Solucionando el problema de caché de nuestro CSS3 en los navegadores

En WordPress y en otros CMS cuando se ve el código fuente podréis encontraros con que la URL de los ficheros CSS son algo así:

http://rolandocaldas.com/wp-content/plugins/addthis/css/output.css?ver=3.7.1

Realmente el fichero es http://rolandocaldas.com/wp-content/plugins/addthis/css/output.css ¿por qué entonces el query ver=3.7.1?

Y ahí está “la magia”. Para el navegador:

http://rolandocaldas.com/wp- content/plugins/addthis/css/output.css y http://rolandocaldas.com/wp-content/plugins/addthis/css/output.css?ver=3.7.1 son dos rutas diferentes, por lo que también serán dos ficheros diferentes.

Cuando estás trabajando con una web hecha en PHP u otro lenguaje dinámico, es bastante sencillo forzar que el fichero CSS tenga un query dónde indique la versión del documento (u otro valor como, por ejemplo, la fecha de última modificación del fichero). Así, cuando hago un cambio en un fichero CSS, cambio su versión para que en la cabecera aparezca la ruta al fichero CSS con el query la nueva versión. De esta manera, el navegador pensará que es un fichero CSS3 nuevo y no el de siempre modificado, por lo que lo descargará de nuevo.

El problema de “esque es la caché” solucionado.

Vale, no siempre se puede aplicar, pero si estás en situación de hacerlo, te olvidarás de unos cuantos quebraderos de cabeza.

Aprendizaje continuo

Todo lo comentado en este artículo puede que mañana no sirva para nada… en nuestro mundo el aprendizaje continuo es una obligación y lo que hoy se hace de una manera, mañana puede cambiar radicalmente.

¿Usas alguna técnica para reducir los tiempos de carga del CSS3? ¿Y para evitar los problemas de la caché? Si es así compártelo, al menos yo estoy ansioso por encontrar nuevas y mejores formas de hacer mi trabajo!

2 pensamientos en “Optimizando la carga de nuestro CSS3

  1. yo para esto uso algo mas complicado pero efectivo, que es el uso del fichero “.htaccess”, aun me es algo complicado de entender, pero con el conocimiento basico de este fichero se pueden comprimir archivos para que los bytes enviados sean menos, y asi el cliente solo tardara en descomprimir el fichero, esto obviamente lo hace automaticamente el navegador.

    gracias por compartir, aprendi algo nuevo con tu post (Y)

  2. Pedazo de POSTS Rolando! así da gusto… Sólo un pequeño comentario son sprites no “splites”.

    Y ya puestos, tienes repetido el H1 en toda la web (quita el H1 de la cabecera “rolandocaldas.com” lo vas a notar en visitas). Te lo digo porque me extraña no ver una pila de comentarios haciendo la ola por cada post que escribes. Dale una vuelta al SEO…

    Saludos, y buen trabajo!!!

Deja un comentario