content-visibility y contain-intrinsic-size: reduce el tiempo de renderizado por 10 con dos líneas de CSS

En la carrera desenfrenada por el rendimiento web, cada milisegundo ganado en el Main Thread es una victoria. Aunque durante mucho tiempo hemos dependido de complejas librerías JavaScript para gestionar el renderizado diferido, el CSS moderno aporta una solución nativa de una eficacia temible: content-visibility.

El problema es simple: cuanto más pesada es una página DOM, más tiempo pasa el navegador calculando el layout y pintando elementos, incluso aquellos situados a 5000 píxeles por debajo de la línea de flotación. Al usar content-visibility, das la orden al navegador de saltarse el trabajo de renderizado para los elementos fuera de pantalla.

#El coste oculto del renderizado invisible

Cuando un navegador carga una página, realiza una serie de pasos críticos: la construcción del DOM, del CSSOM, luego el cálculo del estilo, el layout (la geometría) y finalmente el “paint” (el dibujo de los píxeles). En una página con miles de nodos, esta etapa puede paralizar el procesador durante varios cientos de milisegundos.

Aquí es donde interviene el concepto de containment. Históricamente, la propiedad contain permitía aislar partes del DOM para evitar que el recálculo de un pequeño componente provocara el recálculo de toda la página. content-visibility es la evolución lógica y automatizada de este concepto.

#1. content-visibility: auto, el motor de renderizado inteligente

El valor auto es el más potente. Permite al navegador determinar si un elemento está en el viewport (el área visible) o no. Si el elemento está lejos de la vista del usuario, el navegador:

• No calcula el layout de sus hijos.
• No pinta su contenido.
• Lo trata como si tuviera un “containment” estricto.

Tan pronto como el usuario hace scroll y se acerca al elemento, el navegador activa el renderizado justo a tiempo.

Implementación técnica

Así es como se aplica esta optimización en secciones de página de manera fluida, utilizando clamp() para adaptarse dinámicamente al tamaño de la pantalla sin media queries.

Copy.optimized-section {
  content-visibility     : auto;
  /* Uso de clamp para una gestión fluida del espacio reservado */
  contain-intrinsic-size : auto clamp(25rem, 60vh, 75rem);
}

/* Evitamos sobreescrituras innecesarias en secciones ya visibles */
.optimized-section:not([data-priority='high']) {
  margin-block : clamp(1rem, 5%, 3rem);
}

#2. El problema del salto de scroll: contain-intrinsic-size

El uso de content-visibility: auto por sí solo presenta un fallo importante: el navegador considera que el elemento no renderizado tiene una altura de 0px. A medida que el usuario hace scroll, el elemento se renderiza, se calcula su altura real y todo el contenido situado debajo “salta” bruscamente.

Esto es una catástrofe para el CLS (Cumulative Layout Shift), un indicador clave de Google para el SEO.

Para corregir esto, usamos contain-intrinsic-size. Esta propiedad actúa como un “placeholder” o tamaño de reserva. Indica al navegador: “Aunque no renderices este elemento, reserva este espacio”.

Sintaxis moderna y precisa

Ahora es posible utilizar auto combinado con un valor de tamaño. Si el navegador ya ha renderizado el elemento una vez, recordará su tamaño real en lugar de usar el valor estimado, haciendo que el scroll sea perfectamente fluido.

Copy.dynamic-card-container {
  content-visibility     : auto;
  /* Definimos ancho y alto intrínseco */
  contain-intrinsic-size : auto 100% auto clamp(15.625rem, 30vh, 31.25rem);
}

#3. SEO y Accesibilidad: ¿Qué impacto tiene?

Esta es la pregunta que se hacen todos los expertos en SEO: si el contenido no se renderiza, ¿puede verlo Google?

La respuesta es sí. content-visibility: auto no oculta el contenido del DOM de la misma manera que display: none. El contenido sigue siendo accesible en el árbol de renderizado para los motores de búsqueda y los lectores de pantalla. Sin embargo, como el contenido no se “pinta”, se recomienda no usarlo en elementos textuales críticos para la accesibilidad inmediata (como el menú de navegación principal).

Por qué es bueno para tu SEO

1. LCP (Largest Contentful Paint): Al liberar al procesador de tareas de renderizado inútiles, el navegador puede concentrarse en el elemento principal de la página.
2. INP (Interaction to Next Paint): Menos trabajo de renderizado significa un hilo principal más reactivo a los clics e interacciones del usuario.

#4. Estrategias avanzadas de optimización

Para maximizar el rendimiento, no debes aplicar estas propiedades a cada pequeño elemento. El truco consiste en apuntar a “chunks” o secciones lógicas de tu página.

Copymain > section:not(:first-child) {
  content-visibility     : auto;
  contain-intrinsic-size : auto 50rem;
}

En este ejemplo, dejamos la primera sección (a menudo por encima de la línea de flotación) tranquila para un renderizado inmediato, mientras optimizamos todas las secciones siguientes.

#5. Comparación: CSS vs JavaScript (Intersection Observer)

Antes de esta propiedad, utilizábamos la API IntersectionObserver para añadir o eliminar clases CSS. He aquí por qué el método nativo es superior:

• Rendimiento puro: El CSS se ejecuta a nivel del motor de renderizado, no en la máquina virtual JavaScript.
• Cero retraso: El navegador sabe exactamente cuándo empezar el renderizado para evitar destellos blancos, lo cual es muy difícil de sincronizar perfectamente en JS.
• Ligereza: Menos JS significa menos código que descargar, parsear y ejecutar.

#Conclusión: Un paso de gigante para el rendimiento web

La implementación de content-visibility y contain-intrinsic-size representa una de las optimizaciones más rentables en términos de relación “esfuerzo / beneficio”. Con solo unas pocas líneas de código, puedes transformar una página pesada y lenta en una experiencia fluida de grado de aplicación.

Es la esencia misma de la ingeniería moderna: delegar la inteligencia al navegador para concentrarse en el valor añadido de tu interfaz.

FAQ

Lionel Péramo

Experto en Rendimiento Web y Ecodiseño

Desarrollador Full Stack y creador del framework OTRA (PHP) y de la librería EcoComposer. Escribo para hacer la web más rápida e inclusiva.

Sobre mí →