Representación eficiente de CSS | Programar Plus

Es cierto que no pienso en esta idea muy a menudo… ¿Qué tan eficiente es el CSS que escribimos, en términos de qué tan rápido puede procesarlo el navegador?

Esto es definitivamente algo que preocupa a los proveedores de navegadores (cuanto más rápido se carguen las páginas, más felices estarán las personas usando sus productos). Mozilla tiene un artículo sobre mejores prácticas. Google también está siempre en una cruzada para hacer que la web sea más rápida. También tienen un artículo al respecto.

Analicemos algunas de las grandes ideas que presentan y luego discutamos los aspectos prácticos de todo ello.

De derecha a izquierda

Una de las cosas importantes que debe comprender acerca de cómo los navegadores leen sus selectores de CSS es que los leen de De derecha a izquierda. Eso quiere decir que en el selector ul > li a[title=”home”] lo primero que se interpreta es un[title=”home”]. Esta primera parte también se conoce como el “selector clave” en el sentido de que, en última instancia, es el elemento que se selecciona.

Las identificaciones son las más eficientes, las universales son las menos

Hay cuatro tipos de selectores clave: ID, clase, etiqueta y universal. Es ese mismo orden en lo eficientes que son.

#main-navigation {   }      /* ID (Fastest) */
body.home #page-wrap {   }  /* ID */
.main-navigation {   }      /* Class */
ul li a.current {   }       /* Class *
ul {   }                    /* Tag */
ul li a {  }                /* Tag */
* {   }                     /* Universal (Slowest) */
#content [title="home"]     /* Universal */

Cuando combinamos esta idea de derecha a izquierda y la idea del selector de teclas, podemos ver que este selector no es muy eficiente:

#main-nav > li {   }  /* Slower than it might seem */

A pesar de que parece extrañamente contrario a la intuición… Dado que las identificaciones son tan eficientes, pensaríamos que el navegador podría encontrar esa identificación rápidamente y luego encontrar a los niños li rápidamente. Pero en realidad, el selector de etiquetas li relativamente lento se ejecuta primero.

No etiquetar-calificar

Nunca hagas esto:

ul#main-navigation {  }

Las identificaciones son únicas, por lo que no necesitan un nombre de etiqueta que las acompañe. Hacerlo hace que el selector sea menos eficiente.

Tampoco lo hagas con nombres de clase, si puedes evitarlo. Las clases no son únicas, por lo que teóricamente podría tener un nombre de clase que haga algo que podría ser útil en múltiples elementos diferentes. Y si desea que el estilo sea diferente según el elemento, es posible que deba calificar con etiquetas (por ejemplo, li.first), pero eso es bastante raro, por lo que, en general, no lo haga.

Los selectores de descendientes son los peores.

David Hyatt:

El selector descendiente es el selector más caro en CSS. Es terriblemente caro, especialmente si el selector está en la categoría Tag o Universal.

En otras palabras, un selector como este es un desastre de eficiencia:

html body ul li a {  }

Un selector que falla es más eficiente que la misma combinación de selectores

No estoy seguro de si podemos aprender mucho de esto, porque si tienes un montón de selectores en tu CSS que no coinciden con nada, eso es, uhm, bastante extraño. Pero es interesante notar que en la interpretación de derecha a izquierda de un selector, tan pronto como falla una coincidencia, deja de intentarlo y, por lo tanto, gasta menos energía que si necesitara seguir interpretando.

Considere por qué está escribiendo el selector

Considera esto:

#main-navigation li a { font-family: Georgia, Serif; }

Cascadas de familias de fuentes, por lo que es posible que no necesite un selector que sea tan específico para empezar (si todo lo que está haciendo es cambiar la fuente). Esto puede ser igual de efectivo y mucho más eficiente:

#main-navigation { font-family: Georgia, Serif; }

CSS3 y Eficiencia

Tipo de noticias tristes de David Hyatt:

La triste verdad sobre los selectores CSS3 es que realmente no deberían usarse si te preocupa el rendimiento de la página.

Vale la pena leer todo el comentario.

Los selectores de CSS3 (p. ej., :nth-child) son increíblemente impresionantes para ayudarnos a identificar los elementos que queremos mientras mantenemos nuestro marcado limpio y semántico. Pero el hecho es que estos sofisticados selectores requieren más recursos del navegador para su uso.

Entonces, ¿cuál es el trato, en realidad no deberíamos usarlos? Pensemos un poco en los aspectos prácticos…

aspectos prácticos

¿Ese artículo de Mozilla al que vinculé en la parte superior? Literalmente 10 años. Hecho: las computadoras eran mucho más lentas hace 10 años. Tengo la sensación de que estas cosas eran más importantes en ese entonces. Hace diez años estaba a punto de cumplir 21 y creo que ni siquiera sabía qué era CSS, así que no voy a ponerte toda la vieja escuela contigo… pero tengo la sensación de que no hablamos de esta eficiencia de renderizado. muchas cosas es porque ya no es un problema tan grande.

Así es como me siento al respecto: las mejores prácticas que cubrimos anteriormente tienen sentido sin importar qué. También podrías seguirlos, porque de todos modos no limitan tus habilidades con CSS. Pero no tienes que ser tan dogmático al respecto. Si se encuentra en la posición en la que necesita obtener hasta la última gota de rendimiento de un sitio y nunca ha considerado estas cosas antes, puede valer la pena revisar sus hojas de estilo para ver dónde puede hacerlo mejor. Si no ve mucha lentitud de renderizado en su sitio, entonces no se preocupe, solo tenga en cuenta el futuro.

Súper velocidad, Cero practicidad

Entonces sabemos que las identificaciones son los selectores más eficientes. Si quisiera hacer que la página de renderizado fuera lo más eficiente posible, literalmente le daría a cada elemento de la página una ID única y luego aplicaría estilos con selectores de ID únicos. Eso sería súper rápido, y también súper ridículo. Probablemente sería extremadamente no semántico y extremadamente difícil de mantener. No ve este enfoque incluso en sitios basados ​​en el rendimiento extremo. Creo que la lección aquí es no sacrificar la semántica o la mantenibilidad por un CSS eficiente.

Gracias a Jason Beaudoin por enviarme un correo electrónico sobre la idea. Si alguien sabe más sobre este tema, o si tiene consejos adicionales que usa en este mismo sentido, ¡vamos a escucharlo!

Solo como una nota rápida, también me gustaría mencionar que dado que los selectores de estilo CSS también se usan en muchas bibliotecas de JavaScript, estos mismos conceptos también se aplican. Los selectores de ID serán los más rápidos, mientras que los complicados selectores de descendientes calificados serán más lentos.

(Visited 3 times, 1 visits today)