Cómo acelerar el renderizado CSS

Cuando codificamos CSS, uno de los objetivos es la eficiencia del renderizado en el  navegador.  Google siempre está en una constante búsqueda de hacer más rápida la web. Mozilla también tiene varias sugerencias sobre las mejores prácticas .

optimizando_codigo_css2

Técnicas para acelerar el renderizado CSS

Evitar el “redibujo” de las imágenes

Para evitar esto, siempre se debe especificar la anchura y la altura de todas las imágenes, esta técnica permite que el navegador muestre la página incluso antes de que se descarguen las imágenes, de lo contrario el navegador requerirá un “redibujo” y volver a renderear una vez que las imágenes se descargan. Se puede especificar la anchura y la altura de todas las imágenes, ya sea en el código HTML, a travez de la etiqueta  img , o en CSS.

Los selectores generales son menos eficientes, en cambio los ID son más eficientes

Estos son selectores de acuerdo con la velocidad de renderizado:

# Sidebar {}               / * ID (la más rápida) * /
.home #slider {}           / * ID * /
.footer {}                 / * Clase * /
ul li a.arrow {}           / * Clase * /
ul {}                      / * etiqueta * /
ul li a}                   / * etiqueta */
* {}                       / * General (el más lento) * /
#content [title = 'home' ] / * General * /

Por ejemplo, este selector no es muy eficaz:

# Sidebar > li

Los IDs son los más efectivos, uno puede llegar a pensar que el navegador encontrará el ID rápidamente y dentro de él a los “li” hijos, pero no va a acelerar la velocidad de renderizado, ya que los navegadores interpretan los selectores de derecha a izquierda.

El Principio de derecha a izquierda

Es muy importante entender cómo los navegadores leen o interpretan los selectores CSS. Leen CSS de derecha a izquierda, por ejemplo, para que el selector ol> li [title = “link”] lo primero que se interpreta es [title = “link”] (también se conoce como el “selector de llave”).
También es bueno saber que, en cuanto a la interpretación de derecha a izquierda, si un selector falla, éste dejara de ser interpretado y así se utiliza menos recursos de los necesarios para mantener la interpretación. Sin embargo, siempre se debe quitar los selectores no utilizados en el código.

hojas_de_estilo_css

Colocar las reglas CSS en archivos externos y enlazarlos desde la cabecera del documento principal

Siempre se debe colocar los archivos CSS de forma externa y crear el vinculo correspondiente desde la cabecera del documento principal. Queda “casi” terminantemente prohibido la especificación de estilo en linea y creación de estilos en bloques dentro del cuerpo de un documento HTML, ya que puede tomar mucho más tiempo para que el navegador muestre e interprete el documento.

Selectores Descendentes

Los selector CSS más difíciles de interpretar son los selectores descendentes. Es terriblemente difícil de interpretar, especialmente si se encuentra dentro de una etiqueta universal. Por ejemplo, este es un ejemplo muy malo de un selector descendente:
html body nav a span {}

Usar como ventaja el CSS en Cascada

A veces, se puede lograr un muy buen resultado sin utilizar selectores adicionales. Por ejemplo, consideremos el siguiente ejemplo:
nav li a {font-size:14px}
El tamaño de la fuente “font-size”, no es necesario declararlo específicamente para el tag “a”, es mucho más eficiente:
nav {font-size:14px}

ccs3

Selectores CSS3

Los selectores CSS3 (por ejemplo : first-child ) son increíbles para ayudar en los elementos de estilo, manteniendo el código limpio y semántico. La triste realidad, sobre estos selectores, es que no se los debe utilizar, en lo absoluto, si la mayor preocupación es el rendimiento de página.

Velocidad vs Practicidad

Para conseguir la representación más eficaz para una determinada página, simplemente se puede ir por un camino, dando a cada elemento de la página una identificación única y la aplicación de un estilo con selectores de ID único. Es extremadamente no-semántico y extremadamente difícil de mantener. Incluso los sitios basados ​​en el rendimiento NO sacrifican la capacidad de mantenimiento o semántica por un archivo CSS más eficiente.

Una buena práctica es volver a revisar los archivos CSS y buscar donde se lo puede mejorar, especialmente si el público objetivo utilizara dispositivos móviles, los cuales tienen una cierta (dis)capacidad de interpretación.

Todas estas recomendaciones, requieren una cierta inversión de tiempo, pero el coste es pequeño, especialmente en comparación con las ventajas que acarrea. Y una vez que estas practicas se ponen en marcha, continúan para mejorar el rendimiento durante la vida útil del proceso de desarrollo.

Anuncios

Responder

Por favor, inicia sesión con uno de estos métodos para publicar tu comentario:

Logo de WordPress.com

Estás comentando usando tu cuenta de WordPress.com. Cerrar sesión / Cambiar )

Imagen de Twitter

Estás comentando usando tu cuenta de Twitter. Cerrar sesión / Cambiar )

Foto de Facebook

Estás comentando usando tu cuenta de Facebook. Cerrar sesión / Cambiar )

Google+ photo

Estás comentando usando tu cuenta de Google+. Cerrar sesión / Cambiar )

Conectando a %s