CSS
Analiza costos de style, layout y paint, y usa containment, content-visibility y optimizaciones de composición sin sacrificar correctitud ni accesibilidad.
El rendimiento CSS depende de cuánto trabajo provoca una actualización en style calculation, layout, paint y compositing.
cambio de estado
↓
style
↓
layout cuando cambia geometría
↓
paint cuando cambian píxeles
↓
composite cuando cambian capas<link rel="stylesheet" href="/styles.css">Una stylesheet necesaria bloquea renderizado para evitar pintar contenido con estilos incompletos.
Mejora mediante:
Fragmentar en demasiados archivos también tiene costo.
Una gran stylesheet aumenta transferencia, parsing y memoria. Herramientas de build pueden eliminar utilities no detectadas, pero clases construidas dinámicamente pueden desaparecer por error.
Prueba el artefacto de producción.
Los motores modernos optimizan selección. Evita obsesionarte con div > span frente a .label sin medir.
Los problemas reales suelen ser:
:has() sobre árboles muy dinámicos y extensos.CSS no provoca por sí solo el patrón; JavaScript que alterna lecturas y escrituras puede forzar layouts síncronos:
item.style.width = '200px';
const height = item.offsetHeight;Agrupa writes y reads o utiliza APIs de observación.
.widget {
contain: layout paint;
}Tipos principales:
sizeinline-sizelayoutstylepaintShorthands como strict y content combinan varios.
Containment promete que ciertos cambios no afectan fuera. Una promesa incorrecta puede cambiar sizing o recortar contenido.
.widget {
contain: size;
contain-intrinsic-size: 20rem 30rem;
}El elemento deja de usar su contenido para sizing externo y necesita una dimensión o intrinsic placeholder apropiado.
.section {
content-visibility: auto;
contain-intrinsic-block-size: auto 40rem;
}Permite omitir rendering de contenido fuera de pantalla mientras conserva una estimación de tamaño.
El contenido continúa en DOM y puede participar en búsqueda, accesibilidad y navegación según reglas del navegador; prueba focus y fragment navigation.
Sin estimación, saltos de layout pueden aparecer cuando el contenido entra al área renderizada.
contain-intrinsic-size: auto 600px;auto puede recordar tamaño tras renderizar y usar un fallback inicial.
.card:hover {
will-change: transform;
}No debería aplicarse solo durante hover porque el navegador necesita anticipación. Tampoco debe quedar en cientos de elementos.
Úsalo temporalmente antes de una animación conocida y retíralo después cuando sea viable.
will-change puede crear stacking context o consumir memoria.
Transform y opacity suelen evitar layout y paint del contenido, pero:
Evita animar continuamente:
Mide frames, paint y GPU memory en hardware real.
Cambiar un token en :root puede invalidar estilos de muchos descendientes. Para estado local, define la property en el subtree más pequeño posible.
Muchos query containers no son automáticamente un problema, pero añaden containment y reevaluación contextual. No declares container-type globalmente en cada div.
CSS de fuentes afecta rendimiento mediante:
El objetivo no es ocultar texto, sino mostrar contenido estable pronto.
Mide:
Un Lighthouse score no explica por sí solo la causa.
.project-list {
content-visibility: auto;
contain-intrinsic-block-size: auto 50rem;
}Aporta en listas largas debajo del fold; no lo apliques al hero o contenido LCP.
¿Por qué will-change: transform en cientos de cards puede empeorar rendimiento?
Porque puede promover muchas capas, consumir memoria y aumentar trabajo de composición aunque la mayoría nunca se anime.
Debugging, @supports y compatibilidad crea una estrategia para encontrar y contener fallos.