En resumen
Qué se comprueba
si el código de tu página fuerza al navegador a recalcular la disposición fuera del momento en que él lo habría hecho.
Corte
un solo valor, «con reflow». Es un sí o un no, sin grados.
Por qué importa
el navegador tiene 16,66 milisegundos por fotograma y, descontando su propio trabajo, deja unos 10 para el de tu página.
Severidad en Wakaris
Mejora. Es el hallazgo más frecuente del catálogo: aparece en el 98,4 % de las páginas analizadas (cifra interna de Wakaris).
Qué es y qué mide este hallazgo
Cada vez que el navegador pinta la pantalla recorre las mismas etapas: ejecuta el código, calcula qué reglas de estilo aplican, decide la geometría de cada elemento —esa etapa se llama disposición—, rellena los píxeles y compone las capas. Normalmente él decide cuándo hacer cada etapa y las agrupa para no repetir trabajo.
El reflow forzado rompe ese orden. Ocurre cuando el código cambia un estilo y, acto seguido, pregunta por una medida que depende de ese estilo: el ancho de un elemento, su altura, su posición. El navegador no puede contestar con el valor viejo, así que interrumpe lo que estaba haciendo, aplica los cambios pendientes y recalcula la disposición ahí mismo. La documentación de web.dev lo llama disposición síncrona forzada, y es justo el trabajo que el navegador estaba tratando de ahorrarse.
Este hallazgo salta cuando Wakaris encuentra ese patrón en tu página.
Cómo se detecta
Wakaris carga tu página y observa si durante ese proceso aparece el patrón: una escritura de estilo seguida de una lectura de geometría que obliga a recalcular en el acto. El resultado es un sí o un no, sin grados, porque el catálogo tiene un único valor, «con reflow», y una sola evidencia detrás. Es la lectura más simple del informe y, a la vez, la que más se repite.
Dos precisiones para leerla bien. La primera es que se observa una única carga y sin interactuar, así que el recálculo que aparezca al desplegar un menú o al desplazarse queda fuera de la comprobación. La segunda es que el hallazgo dice que el patrón existe, no cuánto cuesta: no distingue entre una lectura suelta, que apenas se nota, y un bucle que recalcula la disposición cincuenta veces seguidas. Para saber cuál de las dos tienes hay que mirar el código.
Por qué importa
La clave está en el presupuesto. La documentación de web.dev fija el objetivo en 16,66 milisegundos por fotograma para que la pantalla vaya fluida, y avisa de que, descontado el trabajo propio del navegador, al código de la página le quedan unos 10. En el caso que esa misma página documenta, una disposición forzada dentro de un bucle consumía más de 28 milisegundos por fotograma: casi el doble del presupuesto entero.
Lo que se nota cuando ese presupuesto se agota no es una cifra, es una sensación. La página aparece pero no responde al primer clic, el desplazamiento va a tirones y las animaciones saltan. Y el coste se paga en el aparato de quien visita, no en tu servidor: un móvil de gama media tarda bastante más que el ordenador donde se programó la web.
Está clasificado como Mejora y no como Crítico, y con motivo: casi todas las páginas lo tienen y casi ninguna se cae por ello.
Causas comunes
El patrón casi nunca se escribe a propósito. Llega por tres vías.
La primera es el bucle que alterna lectura y escritura. Recorrer una lista de elementos, leer el ancho de uno y aplicárselo al siguiente obliga al navegador a recalcular en cada vuelta, porque los estilos han cambiado desde la lectura anterior.
La segunda son las animaciones hechas con propiedades que tocan la geometría. Animar el ancho, el alto o la posición obliga a rehacer la disposición en cada fotograma, mientras que las propiedades que solo recomponen capas se la saltan entera.
La tercera, y la más habitual en una web que nadie ha escrito desde cero, es el código de terceros: un carrusel, un igualador de alturas, un componente que mide su contenedor para colocarse. Cada uno hace su lectura y su escritura sin saber lo que hacen los demás, y el efecto se acumula. Por eso el hallazgo aparece también en páginas cuidadas.
Cómo solucionarlo
Empieza por acotar el terreno: Wakaris te confirma que el patrón está en esa página, y a partir de ahí el trabajo es de código.
La regla que resuelve la mayoría de los casos es agrupar. Haz todas las lecturas primero y todas las escrituras después. Sacar la medida fuera del bucle y reutilizarla convierte cincuenta recálculos en uno solo, sin cambiar nada de lo que se ve.
Para las animaciones, sustituye las propiedades que mueven la geometría por las que solo recomponen capas: desplazar y escalar con transformaciones, o variar la opacidad, evita la etapa de disposición completa.
Y si una zona de la página es independiente del resto, díselo al navegador. La contención de CSS permite declarar que la disposición interna de un bloque no afecta a lo de fuera, así que un cambio dentro no obliga a revisar el documento entero. Su variante para contenido fuera de pantalla evita renderizar lo que todavía no se ve, y eso adelanta la primera carga.
Comparación de un bucle que lee y escribe alternando frente al mismo bucle con la lectura sacada fuera
Brief para generar la imagen
Ilustración editorial para una guía técnica de Wakaris. Tema: Comparación de un bucle que lee y escribe alternando frente al mismo bucle con la lectura sacada fuera. Estilo: fondo blanco con lavado suave lima→verde pálido (#F8F7D6 → #E2F2DC), acento en degradado verde→lima (#8ED390 → #DCD86F), tinta casi negra (#12150B), formas de pastilla y esquinas redondeadas, sombras difusas, aspecto limpio y esquemático, sin fotografía. Formato: 16:9, 1440 píxeles de ancho. Sin texto legible: cualquier rótulo, código o cifra se representa con barras grises de relleno. El significado lo lleva el pie de foto, no la imagen. Sin logotipos reales ni marcas de terceros. Sin personas reconocibles. Etiquetas: coste, renderizado, comparación, bucle, lee, escribe, alternando, frente
Pregúntale a tu IA
Si quieres profundizar en tu caso concreto, copia uno de estos dos prompts y pégalo en la IA que uses. Elige según tu situación.
Ya tengo el hallazgo medido con Wakaris y quiero solucionarlo
Actúa como un auditor técnico web profesional y prudente. Tu objetivo es ayudarme a entender un hallazgo concreto sobre mi web y decidir qué hacer con él, sin inventarte nada. Contexto: he obtenido este hallazgo con Wakaris, una herramienta que analiza una web en 9 áreas (rendimiento, SEO, seguridad, social, mercado, IA, experiencia, accesibilidad y legal) y explica cada problema de forma que lo entienda cada perfil de un equipo. El hallazgo es: Coste de renderizado. Mi página obliga al navegador a recalcular la disposición de los elementos fuera de tiempo, porque el código cambia un estilo y acto seguido pide una medida que depende de ese estilo. Referencia: es un sí o un no, sin grados; el hallazgo salta con que el patrón aparezca una vez. Pega aquí el resultado de Wakaris: en qué página te ha salido y qué más te marca el informe en el área de rendimiento. Si no lo tienes, dímelo y te diré cómo obtenerlo antes de seguir. Reglas que debes seguir en todo momento: 1. No asumas nada sobre mi web. Todo dato que uses tiene que venir de lo que yo te confirme o de lo que Wakaris haya medido. Si no lo sabes, pregúntamelo antes de afirmarlo. 2. Antes de darme conclusiones, hazme SIEMPRE estas preguntas, juntas y en lenguaje sencillo, para saber si este hallazgo me afecta de verdad y por dónde: a) ¿En qué plataforma está tu web? (WordPress, Shopify, web a medida, otra) b) ¿La página tiene carrusel, galería, menús que se despliegan o bloques que se igualan de altura entre sí? c) ¿Hay animaciones propias, y sabes si mueven tamaño y posición o solo desvanecidos y desplazamientos? d) ¿Cuánto código de terceros lleva puesto la página: chats, mapas, reseñas, widgets de redes? e) ¿Notas que la página vaya a tirones al desplazarte o que tarde en responder al primer clic, o va fina? f) ¿Tienes acceso al código fuente y a las plantillas, o solo al panel de administración? g) Si hay que tocar código, ¿lo harías tú, un técnico interno o una agencia? 3. Toda afirmación o recomendación tiene que ir argumentada respecto a MI contexto, no en general. Si me recomiendas algo, explícame por qué aplica a mi caso. 4. Marca siempre tu nivel de certeza. Si algo es una hipótesis porque no lo puedes medir, dilo: tú no ves mi web, razonas sobre lo que yo te cuento. 5. Ten en cuenta que este hallazgo aparece en casi todas las webs y no siempre duele igual: ayúdame a estimar si en mi caso es un detalle o un problema real, en vez de darlo por grave de entrada. 6. No me propongas cambios técnicos irreversibles o de riesgo (tocar plantillas o componentes en producción, desactivar plugins de golpe) sin avisarme antes del riesgo y de que conviene una copia de seguridad o un entorno de prueba. 7. Si necesitas un dato que solo se obtiene midiendo la web (confirmar el hallazgo, la página concreta, o si el arreglo funcionó), dímelo y recomiéndame volver a pasar la página por Wakaris: eso se mide, no se adivina. 8. La decisión final es mía, no tuya. Tu papel es ayudarme a entender y a preparar la acción, no decidir por mí. 9. Si el arreglo excede lo que puedo hacer yo, o lo va a ejecutar un equipo, ayúdame a dejar el problema listo para traspasarlo: qué es, dónde está, por qué importa y qué habría que hacer, en un formato accionable para esa persona. Fuente de este hallazgo: https://www.wakaris.com/es/guias/rendimiento/coste-de-renderizado Para medirlo o volver a medirlo: https://www.wakaris.com/ Empieza presentándote brevemente en tu rol y haciéndome el primer bloque de preguntas.
Aún no lo he medido y quiero comprobar si mi web tiene este problema
Actúa como un auditor técnico web profesional y prudente. Estoy investigando si mi web tiene un problema concreto y quiero que me ayudes a averiguarlo con honestidad, sin darlo por hecho. Contexto: he llegado a esto a través de Wakaris, una herramienta que analiza una web en 9 áreas (rendimiento, SEO, seguridad, social, mercado, IA, experiencia, accesibilidad y legal) y explica cada problema de forma que lo entienda cada perfil de un equipo. El problema que quiero investigar es: Coste de renderizado. Es cuando el código de una página obliga al navegador a recalcular la disposición de los elementos fuera de tiempo, en mitad de su trabajo, lo que consume parte del presupuesto de cada fotograma. Referencia: es un sí o un no, sin grados. Todavía NO sé si mi web lo tiene: quiero averiguarlo. Reglas que debes seguir en todo momento: 1. Lo primero y más importante: esto se detecta observando cómo se comporta la página al cargarse, y tú no puedes cargar mi web desde esta conversación. Déjame claro desde el principio que no vas a poder darme un "sí lo tienes" o "no lo tienes" definitivo, solo una hipótesis a partir de lo que yo te cuente. 2. No asumas nada. Antes de darme ninguna valoración, hazme SIEMPRE estas preguntas, juntas y en lenguaje sencillo, para estimar si es probable que lo tenga: a) ¿Tu web va a tirones al desplazarte, o se queda unos instantes sin responder justo después de aparecer? b) ¿Tiene carrusel, galería, contadores animados o bloques que se igualan de altura entre sí? c) ¿Cuántos componentes de terceros lleva: chats, mapas, reseñas, widgets de redes? d) ¿Se hizo con una plantilla comprada, con un constructor visual o a medida? e) ¿La sensación de lentitud la notas más en móvil que en escritorio? 3. Con mis respuestas, dame una estimación clara de si es PROBABLE o POCO PROBABLE que lo tenga y por qué vía, argumentada según lo que te he dicho y marcada explícitamente como hipótesis, no como diagnóstico. 4. Sé honesto con la frecuencia: este patrón es muy común, así que decirme que es probable aporta poco. Lo útil es ayudarme a estimar si en mi caso llega a notarse. 5. Dime de forma directa que la única manera de saberlo de verdad es comprobarlo, y que puedo hacerlo gratis y sin crear cuenta pasando mi web por Wakaris, que me dirá si el patrón está en esa página y de paso el estado de las otras áreas. 6. Si te pregunto cómo comprobarlo a mano, no me lo ocultes, pero recuérdame que Wakaris lo hace más rápido, sobre la página real y con información adicional que a mano no obtengo. 7. Si al comprobarlo resulta que sí lo tengo, dime que el siguiente paso es entender cómo me afecta y cómo solucionarlo en mi caso concreto. 8. La conclusión y la decisión son mías, no tuyas. Tú me ayudas a orientarme. Fuente de este hallazgo: https://www.wakaris.com/es/guias/rendimiento/coste-de-renderizado Para medirlo: https://www.wakaris.com/ Empieza presentándote brevemente en tu rol, dejando claro el punto 1, y haciéndome el bloque de preguntas.
Preguntas frecuentes
¿Qué es exactamente un reflow forzado? +
Es un recálculo de la disposición que el navegador tiene que hacer antes de tiempo. Sucede cuando el código modifica un estilo y a continuación pide una medida que depende de él, como el ancho o la posición. El navegador no puede dar el valor antiguo y recalcula en el acto.
Si aparece en el 98,4 % de las páginas, ¿tengo que hacer algo? +
No con urgencia. Por eso Wakaris lo clasifica como Mejora y no como Crítico. Conviene mirarlo cuando la página ya va justa de rendimiento o cuando notes tirones al desplazarte: ahí el arreglo suele ser barato y se nota. Si la página va fina, puede esperar.
¿Se nota el reflow forzado a simple vista? +
A veces sí y a veces no, y esa es la trampa. Una lectura suelta no la percibe nadie. Un bucle que recalcula decenas de veces se traduce en desplazamiento a tirones, animaciones que saltan y unos instantes en que la página no responde al primer clic.
¿Es lo mismo que el contenido que se mueve al cargar? +
No. Ese otro hallazgo mide que los elementos cambien de sitio delante de tus ojos, y se ve. El coste de renderizado mide trabajo interno del navegador: la página puede quedarse perfectamente quieta y estar recalculando su geometría muchas veces por segundo.
Fuentes citadas
- web.devAvoid large, complex layouts and layout thrashing, web.dev: la definición de disposición síncrona forzada, el bucle que la provoca, el caso de más de 28 milisegundos por fotograma y la regla de agrupar lecturas y escrituras.
- web.devRendering performance, web.dev: las cinco etapas del pintado, los 16,66 milisegundos por fotograma con unos 10 disponibles para el código propio, y qué propiedades disparan la disposición frente a las que solo componen.
- developer.mozilla.orgReflow, MDN: el reflujo como recálculo de posición y geometría, seguido del repintado.
- developer.mozilla.orgUsing CSS containment, MDN: la contención limita el recálculo al subárbol declarado, y la variante para contenido fuera de pantalla evita renderizarlo hasta que hace falta.
Actualizado: 8 de septiembre de 2026.
Este artículo forma parte de Wakaris, que analiza tu web en 9 áreas y explica cada hallazgo de forma que lo entienda cada perfil de tu equipo.