El coste real de :has() y cómo medirlo

Circula una idea vaga de que :has() es lento y hay que usarlo con cuidado. Es cierta a medias y por razones equivocadas. El emparejamiento inicial casi nunca es el problema: lo caro es la invalidación, que se paga en cada mutación del DOM y la paga código que no sabe que tu selector existe. Entender dónde está el coste te permite escribir :has() sin miedo en el noventa por ciento de los casos y reconocer el diez por ciento restante antes de que aparezca en un perfil.

Por qué el motor lee al revés

Un navegador nunca resuelve la pregunta “qué elementos encajan con esta regla”. Resuelve la contraria: “qué reglas encajan con este elemento”. La diferencia es de órdenes de magnitud, porque hay decenas de miles de reglas y millones de combinaciones posibles, pero solo un elemento a la vez.

Para responderla, el motor indexa cada regla por su compuesto clave, que es el de más a la derecha, y lo guarda en cubos separados por identificador, clase, etiqueta y atributo. Cuando llega el momento de calcular el estilo de un a.enlace, el motor solo mira los cubos de a y de .enlace, y descarta todo lo demás sin leerlo. De las reglas candidatas comprueba primero el compuesto clave, y solo si encaja empieza a subir por los ancestros verificando el resto de la cadena. Un selector como body main article section p span.x es barato porque casi nunca llega a la segunda comprobación.

:has() no encaja en ese modelo. En article:has(.error), el compuesto clave es article, así que la indexación sigue funcionando. Pero verificar la condición obliga a descender por el subárbol del article, que puede tener miles de nodos. Y aún peor: en li:has(+ li.x) hay que mirar hacia delante entre los hermanos, una dirección que el algoritmo clásico nunca necesitó recorrer.

Aun así, ese coste sería asumible si solo se pagase una vez. El problema real es otro.

El coste está en la invalidación

Cuando el DOM cambia, el motor no recalcula todos los estilos: recalcula el conjunto mínimo que puede haberse visto afectado. Para eso mantiene conjuntos de invalidación precalculados a partir de las hojas de estilo, que responden a preguntas del tipo “si a un elemento se le añade la clase .error, qué descendientes suyos pueden cambiar de estilo”.

Ese mecanismo se apoya en una propiedad que fue cierta durante veinticinco años: el estilo de un elemento solo puede depender de sus ancestros y de sus hermanos anteriores. Por tanto, tocar un nodo solo puede afectar a ese nodo y a lo que cuelga de él. La invalidación siempre va hacia abajo.

:has() destruye esa propiedad. Añadir un .error en la hoja del árbol puede cambiar el estilo de su padre, de su abuelo, y de los hermanos anteriores de cualquiera de ellos. La invalidación ahora tiene que poder ir hacia arriba y hacia los lados, y hacerlo sin recorrer el documento entero en cada mutación.

La solución que hizo viable la implementación tiene dos piezas. Primero, durante el cálculo de estilos el motor marca con banderas los elementos que participan en algún :has(): si un elemento puede ser sujeto de una condición relacional, si un cambio en su subárbol puede afectar a un ancestro, si un cambio entre sus hermanos puede afectar a un hermano anterior. Segundo, indexa qué aparece dentro de los argumentos de todos los :has() de la página. Con las dos piezas, una mutación que no toca ninguna de las clases, etiquetas o atributos que figuran en algún argumento no despierta a nadie, y una que sí los toca solo hace subir la invalidación por las ramas marcadas.

flowchart TB
M[Mutacion en el DOM] --> Q{Lo que cambia aparece en algun argumento de has}
Q -- No --> Z[Invalidacion normal hacia abajo]
Q -- Si --> A[Subir por los ancestros marcados]
A --> B[Reevaluar la condicion en cada candidato]
B --> C[Recalculo de estilo de los sujetos afectados]
style Z fill:#a6e3a1,color:#11111b
style A fill:#f9e2af,color:#11111b
style C fill:#89b4fa,color:#11111b

La consecuencia práctica es la que casi nadie enuncia: el coste de un :has() es proporcional a la frecuencia con la que muta lo que hay dentro de su argumento, no a lo elegante que sea el selector ni a cuántas veces aparezca en la hoja. Una regla html:has(dialog[open]) es baratísima aunque el sujeto sea la raíz del documento, porque los diálogos se abren y se cierran unas pocas veces por sesión. Una regla .fila:has(.celda-activa) en una tabla donde el JavaScript mueve esa clase en cada mousemove es cara aunque el subárbol sea diminuto.

El combinador decide el ámbito de búsqueda

Dentro del argumento, el combinador inicial acota cuánto tiene que recorrer el motor para evaluar la condición. De más barato a más caro:

La lectura correcta de esta tabla no es “no uses el descendiente”. Es: si la relación que quieres expresar es de hijo directo, escríbelo. Muchísimo :has(.x) que se ve por ahí quería decir :has(> .x), y quien lo escribió no puso el combinador porque no hacía falta para que funcionase.

/* Recorre todo el subarbol de cada tarjeta en cada evaluacion. */
.card:has(img) { }

/* Mira solo los hijos directos. Misma intencion, coste acotado. */
.card:has(> img) { }

El sujeto importa igual de mucho, y por el mismo motivo. *:has(.error) obliga a marcar como candidato a cada elemento del documento; .formulario:has(.error) solo marca a los formularios. La diferencia no está en el emparejamiento sino en cuántos nodos llevan banderas y por tanto cuántas ramas puede subir la invalidación.

Medirlo en lugar de suponerlo

Chrome DevTools tiene una opción específica para esto en el panel de rendimiento: las estadísticas de selectores, que hay que activar en los ajustes de la grabación porque tiene coste propio. Con ella activada, cada evento de recálculo de estilo trae una tabla con el tiempo consumido por selector, el número de intentos de emparejamiento, el número de aciertos y el porcentaje de fallos que pasaron por la ruta lenta.

El flujo de trabajo es siempre el mismo. Graba la interacción sospechosa —no la carga, la interacción—, busca los eventos de recálculo de estilo en la línea de tiempo, ordena la tabla por tiempo consumido y mira si alguno de tus :has() aparece arriba. Si el número de intentos de emparejamiento es enorme y el de aciertos es minúsculo, tienes un selector que se evalúa constantemente para no hacer nada: o el sujeto es demasiado amplio, o el argumento menciona algo que muta sin parar.

Un experimento que conviene hacer una vez para calibrar la intuición: monta una lista de mil elementos, aplica li:has(> .marca) y mide el recálculo al añadir y quitar .marca de un solo elemento. Después cambia la regla a *:has(.marca) y repite. La forma del gráfico cambia, y ver esa diferencia con tus propios ojos vale más que cualquier regla memorizada.

/* Version acotada: sujeto concreto, combinador de hijo. */
li:has(> .marca) { background: color-mix(in oklch, canvas 90%, currentColor); }

/* Version que conviene medir antes de enviar a produccion. */
*:has(.marca) { outline: 1px dashed; }