La estrategia de "desplazamiento virtual" es eliminar el elemento HTML cuando está fuera de la ventana gráfica, esto mejora el rendimiento porque reduce la cantidad de elementos en el dom y reduce el tiempo para volver a pintar/refluir todo el documento.

Mostrar ninguno no reduce el tamaño del dom, solo hace que el elemento no sea visible, como visible oculto, sin ocupar el espacio visual.

Mostrar ninguno no mejora el rendimiento porque el objetivo del desplazamiento virtual es reducir la cantidad de elementos en el dom.

Haga que un elemento no muestre ninguno o elimine un elemento, active un reflujo, pero con mostrar ninguno empeora el rendimiento porque no tiene el beneficio de reducir el dom.

Sobre el rendimiento, mostrar ninguno es como visible oculto.

Google Lighthouse marca como páginas de mal rendimiento con árboles DOM que:

• Tener más de 1500 nodos en total
• Tener una profundidad superior a 32 nodos
• Tener un nodo principal con más de 60 nodos secundarios

En general, busque formas de crear nodos DOM solo cuando sea necesario y destrúyalos cuando ya no los necesite.

El único beneficio de mostrar ninguno es: no causará un repintado o reflujo cuando se cambie.

Fuente:

• https://web.dev/tamaño-dom/
• https://developers.google.com/speed/docs/insights/browser-reflow

Dos consejos para mejorar el rendimiento cuando tiene miles de elementos DOM y necesita desplazarse, interactuar, etc.

1. Intente administrar los enlaces proporcionados por los marcos front-end manualmente. Los marcos front-end pueden necesitar mucho procesamiento adicional para el enlace de datos simple que necesita. Son buenos hasta cierto número de elementos DOM. Pero si su caso es especial y excede la cantidad de elementos DOM en un caso promedio, el camino a seguir es enlazarlos manualmente considerando las circunstancias. Esto ciertamente puede eliminar cualquier retraso.

2. Almacene en búfer los elementos DOM dentro y alrededor del puerto de visualización. Si sus elementos DOM son una representación de los datos en una(s) tabla(s), obténgalos con un límite y solo represente lo que obtuvo. La acción de desplazamiento del usuario debe hacer que la búsqueda y el renderizado vayan hacia arriba o hacia abajo.

Simplemente ocultar los elementos definitivamente no va a resolver su problema de rendimiento al tener miles de elementos DOM. Aunque no puedas verlos, ocupan el árbol DOM y también la memoria. Solo el navegador no tiene que pintarlos.

Aquí hay algunos artículos:

https://codeburst.io/taming-huge-collections-of-dom-nodes-bebafdba332 https://areknawo.com/dom-performance-case-study/

La respuesta es, como casi todo, depende. Creo que tendrá que compararlo usted mismo para comprender la situación específica. Aquí se explica cómo ejecutar un punto de referencia de "suavidad", ya que la percepción de la velocidad es probablemente más importante que el rendimiento real del sistema para usted.

Como han dicho otros display:none deja el DOM en la memoria. Por lo general, el renderizado es la parte costosa, pero eso se basa en la cantidad de elementos que se deben renderizar cuando las cosas cambian. Si la operación de repintado aún tiene que verificar cada elemento, es posible que no vea un gran aumento en el rendimiento. Aquí hay algunas otras opciones a considerar.

Usar DOM virtual

Esta es la razón por la cual los marcos como React & Vue usan un DOM virtual . El objetivo es hacerse cargo del trabajo del navegador de decidir qué actualizar y solo hacer cambios más pequeños.

Agregar/eliminar elementos por completo

Podría replicar algo similar usando Intersection Observer para descubrir qué hay dentro/fuera de la ventana gráfica y, de hecho, agregar/restar del DOM en lugar de confiar solo en display:none solo, ya que el análisis de javascript es generalmente más eficiente que las pinturas grandes.

Agregar aceleración de GPU

Por otro lado, si la GPU se hace cargo de la renderización , es posible que la pintura no sea una pérdida de rendimiento, pero eso solo ocurre en algunos dispositivos. Puedes probarlo agregando transform: translate3d(0,0,0); para forzar la aceleración de la GPU.

Dar las sugerencias del navegador

También puede ver una mejora al utilizar el atributo Will-Change de CSS . Una de las entradas se basa en que el contenido está fuera de la ventana gráfica. Entonces will-change:scroll-position; sobre los elementos

CSS Content-Visibility (La vanguardia)

El grupo de trabajo de CSS en W3C tiene el módulo de contención de CSS en forma de borrador. La idea es permitir que el desarrollador le diga al navegador qué pintar y cuándo. Esto incluye contención de pintura y diseño. content-visibility:auto es una propiedad muy útil diseñada para este tipo de problema. Aquí hay más antecedentes .

Editar (abril de 2021) ahora está disponible en Chrome 85+, Edge (Chromium) 85+ y Opera 71+. Todavía estamos esperando el soporte de Firefox, pero Can I Use lo pone en una cobertura del 65%.

Vale la pena echarle un vistazo, ya que las demostraciones que vi marcaron una gran diferencia en el rendimiento y las puntuaciones de Lighthouse.

La propiedad "display: none" de un elemento elimina ese elemento del flujo del documento.

La redefinición dinámica de la propiedad de visualización de ese elemento de ninguna a otra, y viceversa, forzará nuevamente el cambio en el flujo del documento.

Cada vez que se requiere un nuevo cálculo de todos los elementos bajo la cascada de flujo para una nueva representación.

Así que sí, una propiedad "display: none" aplicada a un elemento dimensional y de flujo libre o relativamente posicionado distinto de cero, será una operación costosa y, por lo tanto, empeorará el rendimiento .

Este no será el caso para, digamos position: absolute o de otro modo, los elementos eliminados forman el flujo de documento natural y libre cuya propiedad de visualización se puede establecer en ninguno y viceversa sin activar el reflujo en el cuerpo del documento.

Ahora, en su caso específico [vea el gráfico editado] a medida que se mueve/desplaza hacia abajo, llevar la 'pantalla: bloque' de vuelta al siguiente div no causará un reflujo al resto de la parte superior del documento. Por lo tanto, es seguro hacerlos visibles sobre la marcha. Por lo tanto, no afectará el rendimiento de la página. También display: none de los elementos de la cola a medida que se mueve hacia arriba, ya que esto liberará más memoria de visualización. Y por lo tanto puede mejorar el rendimiento. ¡Lo cual nunca es el caso cuando se agregan o eliminan elementos de y dentro de la parte superior de la secuencia HTML!

Para agregar a las respuestas ya publicadas.

Los puntos clave de mis pruebas:

• establecer un elemento para display: none; disminuye el uso de ram
• los elementos que no se muestran no se ven afectados por los cambios de diseño y, por lo tanto, no tienen (o tienen muy poco) costo de rendimiento en este sentido
• Firefox es mucho mejor manejando muchos elementos (~x50)

También intente minimizar los cambios de diseño.

Aquí está mi configuración de prueba:

 <!DOCTYPE html> <html lang="en"> <head> <meta charset="UTF-8"> <meta name="viewport" content="width=device-width, initial-scale=1.0"> <title>Document</title> <style> body { margin: 0; } .testEl { width: 100%; height: 10px; } </style> </head> <body> <main id="main"></main> </body> <script> // firefox Max // const elementCount = 12200000; // chrome Max const elementCount = 231000; const main = document.getElementById("main"); const onlyShowFirst1000 = true; let _content = "" for (let i = 0; i < elementCount; i++) { _content += `<div class="testEl" style="background-color: hsl(${(Math.random() * 360)|0}, 100%, 50%); display: ${!onlyShowFirst1000 || i < 1000 ? "block" : "none"}"></div>`; } main.innerHTML = _content; const addOneEnd = () => { const newEl = document.createElement("div"); newEl.classList.add("testEl"); newEl.style.backgroundColor = `hsl(${(Math.random() * 360)|0}, 100%, 50%)` requestAnimationFrame(() => { main.appendChild(newEl); }) }; const addOneBeginning = () => { const newEl = document.createElement("div"); newEl.classList.add("testEl"); newEl.style.backgroundColor = `hsl(${(Math.random() * 360)|0}, 100%, 50%)` requestAnimationFrame(() => { main.insertBefore(newEl, main.firstChild); }) }; const loop = (front = true) => { front ? addOneBeginning() : addOneEnd(); setTimeout(() => loop(front), 100); }; </script> </html>

Creo muchos elementos y tengo la opción de mostrar solo los primeros 1000 usando el indicador onlyShowFirst1000 . al mostrar todos los elementos, firefox permitió hasta ~12200000 elementos (usando 10 gb de mi RAM) y Chrome hasta ~231000.

Uso de memoria (en 231000 elementos):

 +----------+----------+-------------+ | false | true | reduction % | +---------+----------+----------+-------------+ | Chrome | 415,764k | 243,096k | 42% | +---------+----------+----------+-------------+ | Firefox | 169.9MB | 105.7MB | 38% | +---------+----------+----------+-------------+

Cambiar la propiedad de visualización de un elemento a o desde ninguno hace que el área se vuelva a pintar, pero el área de su elemento generalmente será relativamente pequeña, por lo tanto, el costo de rendimiento también será pequeño. Pero dependiendo de su diseño, el cambio de visualización también podría causar un cambio de diseño que podría ser bastante costoso ya que haría que una gran parte de su página se volviera a pintar.

En el futuro (p. ej., Chrome 85), también podrá utilizar la propiedad content-visibility para indicarle al navegador qué elementos no deben renderizarse.

Además, configura el navegador para que muestre repintados usando las herramientas de desarrollo, para Chrome, abra la pestaña de renderizado y marque "Paint flashing".