Articulo publicado el
Por Frank Esteban Isdray Junco
content-visibility en CSS: mejora el renderizado sin JavaScript
Guia practica para diferir el coste de layout y pintura en paginas largas sin romper la accesibilidad
En una pagina larga, no todo el contenido necesita calcularse, pintarse y componerse desde el primer render. Una landing con muchas secciones, un listado editorial, una pagina de documentacion o un catalogo con bloques repetidos pueden cargar decenas de elementos que estan fuera del viewport inicial. Aunque el usuario todavia no los vea, el navegador puede dedicar tiempo a calcular su layout y pintura.
La propiedad CSS content-visibility permite indicar al navegador que puede saltarse parte de ese trabajo hasta que el contenido sea relevante para el usuario. Bien usada, es una mejora sencilla para paginas con mucho contenido bajo el primer pantallazo. Mal usada, puede provocar saltos de layout, mediciones inesperadas o una falsa sensacion de optimizacion.
Que problema resuelve content-visibility
Cuando el navegador renderiza una pagina, no solo descarga HTML, CSS y JavaScript. Tambien construye arboles internos, calcula estilos, resuelve layout, pinta pixeles y compone capas. En paginas largas, una parte importante de ese trabajo puede corresponder a secciones que aun no son visibles.
content-visibility permite controlar si el contenido interno de un elemento se renderiza. Segun la documentacion de MDN, el valor auto permite que el navegador omita trabajo de renderizado, incluido layout y pintura, hasta que sea necesario.
La idea no es reemplazar lazy loading, virtualizacion o una buena arquitectura de componentes. Es una herramienta adicional de CSS para reducir trabajo inicial cuando el contenido ya esta en el DOM, pero no necesita renderizarse inmediatamente.
Valores principales
La propiedad tiene tres valores de uso practico:
.section {
content-visibility: visible;
}
visible es el valor por defecto. El navegador renderiza el contenido normalmente.
.section {
content-visibility: hidden;
}
hidden oculta el contenido del elemento y salta su renderizado. A diferencia de display: none, puede conservar parte del estado de renderizado, pero no debe usarse como reemplazo automatico para todos los patrones de mostrar y ocultar contenido.
.section {
content-visibility: auto;
}
auto es el valor mas interesante para rendimiento. El navegador puede aplicar containment y diferir el renderizado de contenido que no es relevante en ese momento. Cuando el elemento se aproxima al viewport o pasa a ser necesario, el navegador vuelve a renderizarlo.
Patron base para paginas largas
Un patron razonable es aplicar content-visibility: auto a bloques completos y relativamente independientes: secciones de una landing, grupos de tarjetas, bloques de articulos o paneles de una pagina de documentacion.
<main class="article-page">
<section class="content-section">
<h2>Introduccion</h2>
<p>Contenido visible cerca del inicio.</p>
</section>
<section class="content-section">
<h2>Casos de uso</h2>
<p>Contenido que probablemente aparecera mas abajo.</p>
</section>
<section class="content-section">
<h2>Ejemplos</h2>
<p>Otro bloque independiente de contenido.</p>
</section>
</main>
.content-section {
content-visibility: auto;
contain-intrinsic-size: auto 640px;
}
La segunda linea es importante. contain-intrinsic-size da al navegador una estimacion de tamano mientras el contenido esta omitido. Sin esa reserva, el bloque podria colapsar o generar saltos visuales cuando el navegador tenga que calcular su altura real.
Por que contain-intrinsic-size importa
content-visibility: auto funciona mejor cuando el navegador puede reservar espacio aproximado para el contenido que todavia no ha renderizado. Si no hay una dimension intrinseca de referencia, el layout puede quedar inestable hasta que el bloque entre en una zona relevante.
.card-list {
content-visibility: auto;
contain-intrinsic-size: auto 520px;
}
El valor auto 520px indica que el navegador puede recordar el tamano real cuando el contenido ya se ha renderizado, usando 520px como estimacion inicial. No necesitas acertar al pixel, pero si conviene elegir un valor cercano al alto habitual del bloque.
En una pagina editorial, cada seccion puede tener alturas distintas:
.hero-followup {
content-visibility: auto;
contain-intrinsic-size: auto 420px;
}
.feature-grid {
content-visibility: auto;
contain-intrinsic-size: auto 760px;
}
.faq-block {
content-visibility: auto;
contain-intrinsic-size: auto 360px;
}
Este enfoque evita tratar toda la pagina como si tuviera una unica altura media. Cuanto mejor sea la estimacion, menor sera el riesgo de cambios bruscos al hacer scroll.
Donde usarlo
content-visibility: auto suele encajar bien en:
- Secciones largas que aparecen por debajo del primer viewport.
- Listados editoriales con grupos de contenido independientes.
- Bloques de documentacion con ejemplos, tablas o snippets extensos.
- Dashboards con paneles que no estan visibles al cargar.
- Paginas de producto con modulos secundarios como FAQ, reviews o recomendaciones.
El punto clave es la independencia. Un bloque candidato no deberia depender de que sus hijos afecten el layout externo de forma imprevisible. Si un componente necesita medirse desde JavaScript antes de aparecer, o si su altura determina una interaccion critica inmediata, conviene evaluarlo con mas cuidado.
Donde no conviene aplicarlo
No es buena idea aplicar content-visibility: auto indiscriminadamente a cada tarjeta, boton o elemento pequeno. El objetivo es reducir trabajo significativo, no llenar el CSS de optimizaciones de bajo impacto.
Evitalo especialmente en:
- Elementos visibles en el primer pantallazo.
- Componentes muy pequenos donde el coste de renderizado es irrelevante.
- Bloques cuya altura cambia constantemente por interaccion inmediata.
- Contenido que se mide con JavaScript antes de que el usuario lo vea.
- Elementos que participan en animaciones complejas de entrada desde el primer render.
Tambien debes tener cuidado con APIs que fuerzan calculos de layout. Si tu codigo consulta medidas de un subtree omitido, el navegador puede verse obligado a resolver parte del trabajo que estabas intentando diferir.
Accesibilidad y busqueda en pagina
Una ventaja importante de content-visibility: auto frente a ocultar contenido manualmente es que el contenido fuera de pantalla sigue estando en el DOM y en el arbol de accesibilidad. MDN indica que el contenido offscreen con content-visibility: auto permanece disponible para tecnologias de asistencia.
Eso no significa que puedas ignorar la semantica. Si dentro de una seccion tienes contenido que debe estar realmente oculto, sigue usando patrones adecuados como hidden, display: none, aria-hidden cuando corresponda, o controles semanticos como details y summary.
La regla practica es sencilla: content-visibility: auto sirve para diferir renderizado, no para expresar estado de interfaz. Si el usuario ha cerrado un panel, abierto un modal o filtrado una lista, representa ese estado con la semantica correcta.
Relacion con lazy loading y virtualizacion
content-visibility no descarga menos datos por si sola. Si tienes imagenes pesadas, sigue usando loading="lazy" cuando sea apropiado. Si tienes listas de miles de filas, probablemente necesites virtualizacion. Si el problema principal es JavaScript bloqueante, tendras que dividir bundles, revisar hidratacion o reducir trabajo en el hilo principal.
La propiedad encaja en otra capa: renderizado CSS de contenido ya presente. Es util cuando la pagina necesita tener el contenido disponible, pero no todo debe pintarse desde el inicio.
Una combinacion comun puede ser:
<section class="related-posts">
<h2>Articulos relacionados</h2>
<article>
<img src="/imagenes/css-layout.webp" alt="Vista previa del articulo" loading="lazy" />
<h3>Patrones de layout moderno</h3>
</article>
</section>
.related-posts {
content-visibility: auto;
contain-intrinsic-size: auto 480px;
}
El atributo loading="lazy" ayuda con la carga de la imagen. content-visibility ayuda con el coste de renderizar el bloque.
Como validarlo en un proyecto real
No deberias aplicar esta propiedad y asumir que todo ha mejorado. Mide antes y despues.
Puedes empezar con una prueba controlada:
- Identifica una pagina larga con varias secciones bajo el primer viewport.
- Aplica
content-visibility: autosolo a bloques grandes e independientes. - Define
contain-intrinsic-sizecon una estimacion razonable por tipo de bloque. - Revisa si aparecen saltos de layout al hacer scroll.
- Mide el resultado con el panel Performance de DevTools y Lighthouse.
Fijate especialmente en trabajo de layout y pintura durante la carga inicial. Si la pagina ya era ligera, puede que el beneficio sea pequeno. Si la pagina contiene muchas secciones complejas, tablas, tarjetas o contenido enriquecido, el impacto puede ser mas visible.
Buenas practicas
- Empieza por secciones grandes, no por microcomponentes.
- Acompana
content-visibility: autoconcontain-intrinsic-size. - Usa estimaciones de altura distintas para bloques con estructuras diferentes.
- No lo apliques al contenido principal visible al cargar.
- Comprueba accesibilidad, foco de teclado y busqueda en pagina.
- Mide con DevTools antes de extenderlo a mas pantallas.
Tambien conviene documentar el patron en el sistema de diseño o en la guia interna del proyecto. Asi el equipo entiende que no es una decoracion CSS, sino una decision de rendimiento con condiciones concretas.
Ejemplo final
Este ejemplo resume un patron aplicable a una pagina de blog, documentacion o marketing con muchas secciones:
.page-section {
content-visibility: auto;
contain-intrinsic-size: auto 600px;
}
.page-section:first-of-type {
content-visibility: visible;
contain-intrinsic-size: none;
}
La primera seccion se renderiza siempre porque forma parte de la experiencia inicial. Las secciones siguientes pueden diferir trabajo hasta que sean relevantes. Es una mejora progresiva: si el navegador soporta la propiedad, puede optimizar; si el impacto no compensa, el codigo sigue siendo facil de retirar.
Conclusiones
content-visibility es una herramienta muy practica para mejorar el rendimiento percibido de paginas largas sin introducir JavaScript ni cambiar la arquitectura completa. Su mejor uso esta en bloques grandes, independientes y fuera del primer viewport, siempre junto a una reserva de espacio con contain-intrinsic-size.
No sustituye a lazy loading, virtualizacion ni a una auditoria seria del JavaScript, pero cubre un hueco importante: reducir trabajo de renderizado que el usuario todavia no necesita. Como casi toda optimizacion frontend, funciona mejor cuando se aplica con criterio, se mide y se revisa en dispositivos reales.
