¿Qué pasó con la regla “Usar selectores eficaces de CSS”?

Hubo una recomendación de Google PageSpeed ​​que pedía a los desarrolladores web Usar selectores eficaces de CSS :

Evitar los selectores de teclas ineficientes que coinciden con un gran número de elementos puede acelerar el rendimiento de la página.

Detalles

A medida que el navegador analiza HTML, construye un árbol de documento interno que representa todos los elementos que se mostrarán. A continuación, combina los elementos con los estilos especificados en varias hojas de estilo, de acuerdo con las reglas estándar de cascada, herencia y ordenamiento de CSS. En la implementación de Mozilla (y probablemente también en otras), para cada elemento, el motor de CSS busca reglas de estilo para encontrar una coincidencia. El motor evalúa cada regla de derecha a izquierda, comenzando desde el selector situado más a la derecha (llamado “clave”) y moviéndose a través de cada selector hasta que encuentra una coincidencia o descarta la regla. (El “selector” es el elemento de documento al que debe aplicarse la regla).

De acuerdo con este sistema, cuantas menos reglas tenga el motor para evaluar, mejor. […]. Después de eso, para las páginas que contienen grandes cantidades de elementos y / o un gran número de reglas CSS, la optimización de las definiciones de las reglas también puede mejorar el rendimiento. La clave para optimizar las reglas radica en definir reglas que sean lo más específicas posible y que eviten la redundancia innecesaria, para permitir que el motor de estilo encuentre rápidamente las coincidencias sin perder tiempo evaluando las reglas que no se aplican.

Esta recomendación se ha eliminado de las reglas actuales de Page Speed ​​Insights . Ahora me pregunto por qué se eliminó esta regla. ¿Los navegadores se volvieron eficientes en la coincidencia de las reglas de CSS mientras tanto? ¿Y esta recomendación ya es válida?

En febrero de 2011, el desarrollador de Webkit Antti Koivisto realizó varias mejoras en el rendimiento del selector de CSS en Webkit.

Antti Koivisto enseñó CSS ​​Style Selector para omitir selectores de hermanos y una clasificación más rápida, lo que aporta algunas mejoras menores, tras lo cual obtuvo dos parches más: uno que permite el filtro de identificador de ancestros para la construcción de árboles, reduciendo a la mitad el tiempo restante carga de página típica, y una ruta rápida para selectores simples que aceleran el emparejamiento hasta otro 50% en algunos sitios web.

¡El rendimiento del selector de CSS ha cambiado! (Para mejor) por Nicole Sullivan pasa por estas mejoras en mayor detalle. En resumen –

De acuerdo con Antti, los combinadores adyacentes directos e indirectos aún pueden ser lentos, sin embargo, los filtros ancestrales y los hashes de las reglas pueden reducir el impacto, ya que esos selectores raramente se igualarán. También dice que todavía hay mucho espacio para webkit para optimizar pseudo clases y elementos, pero independientemente de que sean mucho más rápidos que intentar hacer lo mismo con las manipulaciones de JavaScript y DOM. De hecho, aunque todavía hay margen de mejora, dice:

“Utilizado con moderación, prácticamente todo funcionará bien desde la perspectiva de la coincidencia de estilos”.

Si bien los navegadores son mucho más rápidos al hacer coincidir los selectores de CSS, vale la pena reiterar que los selectores de CSS deberían optimizarse (por ejemplo, mantenerse lo más “planos” posible) para reducir el tamaño de los archivos y evitar problemas de especificidad.

Aquí hay un artículo completo (que está fechado a principios de 2014)

Cito a Benjamin Poulain , un ingeniero de WebKit que tuvo mucho que decir sobre la prueba de rendimiento de los selectores de CSS:

~ 10% del tiempo se usa en el rasterizador. ~ 21% del tiempo se gasta en el primer diseño. ~ 48% del tiempo se gasta en el analizador sintáctico y en la creación del árbol DOM ~ 8% se gasta en resolución de estilo ~ 5% se gasta en recostackr el estilo: esto es lo que deberíamos probar y lo que debería tomarse la mayor parte del tiempo. (El tiempo restante se extiende a muchas funciones pequeñas)

Y él continúa:

“Estoy totalmente de acuerdo en que es inútil optimizar los selectores por adelantado, pero por razones completamente diferentes:

Es prácticamente imposible predecir el impacto final en el rendimiento de un selector dado simplemente examinando los selectores. En el motor, los selectores se reordenan, dividen, recogen y comstackn. Para conocer el rendimiento final de un determinado selector, debería saber en qué bloque se ha recostackdo el selector, cómo se comstack y, finalmente, cómo se ve el árbol DOM.

Todo eso es muy diferente entre los distintos motores, lo que hace que todo el proceso sea aún menos predecible.

El segundo argumento que tengo contra los desarrolladores web que optimizan los selectores es que probablemente empeorarán las cosas. La cantidad de información errónea sobre los selectores es mayor que la información correcta entre navegadores. La posibilidad de que alguien haga lo correcto es bastante baja.

En la práctica, las personas descubren problemas de rendimiento con CSS y comienzan a eliminar las reglas una a una hasta que el problema desaparezca. Creo que es la forma correcta de hacerlo, es fácil y conducirá a un resultado correcto “.

Hay enfoques, como BEM por ejemplo, que modela CSS lo más plana posible, para minimizar la dependencia de la jerarquía DOM y desacoplar componentes web para que puedan “moverse” a través del DOM y funcionar independientemente.

Tal vez porque hacer CSS para CMSes o frameworks es más común ahora y es difícil evitar el uso de selectores CSS generales. Esto para limitar la complejidad de la hoja de estilos.

Además, los navegadores modernos son realmente rápidos en la renderización de CSS. Incluso con grandes hojas de estilo en IE9, no parecía que el renderizado fuera lento. (Debo admitir que probé en una buena computadora. Tal vez haya puntos de referencia por ahí).

De todos modos, creo que debes escribir CSS muy ineficiente para ralentizar Chrome o Firefox …

Hay una publicación de 2 años sobre el rendimiento @ ¿Qué selectores o reglas de CSS pueden afectar de manera significativa el diseño de la interfaz de usuario / el rendimiento de representación en el mundo real?

Me gusta su conclusión única: cualquier cosa dentro de los límites de “sí, este CSS tiene sentido” está bien.