El botón «Guardar» en Divi Builder se ha vuelto muy lento

Hola Carlos, 

En este caso de acuerdo a lo que nos comentas el contenido se está guardando de manera apropiada, pero Divi no recibe o no comprende adecuadamente la respuesta que debería finalizar la animación de guardado.

Esto puede suceder debido a un proceso de caché, optimización de JavaScript o una solicitud AJAX que permanece abierta; sin embargo, el cambio se guarda en la base de datos al final.

Para revisarlo prueba borrar la caché de Divi en  Opciones del tema > Constructor > Avanzado > pulsa borrar o clear. Luego, limpia también la caché del navegador y de cualquier plugin de optimización o caché que uses.

De igual forma puedes probar si algo está generando conflictos activando el modo de prueba de Divi en Centro de soporte > Modo seguro. Si en este modo la ruleta se detiene correctamente, tendremos más claro que existe algún conflicto con un plugin, código personalizado o función de optimización.

Como los cambios se guardan no parece ser un problema relacionado con la longitud del contenido ni con la versión PHP, sin embargo, prueba aumentar los parámetros de tu PHP al máximo y revisa cómo va todo > https://guias.webempresa.com/preguntas-frecuentes/cambiar-la-version-php/#Modificar-parametros-PHP

Verifica esto y nos comentas cómo va todo.

Un saludo.

Hola:

Disculpa que no haya podido responder antes.

Pues he probado lo fácil: eliminar temporalmente todos los scripts —tengo varios—, desactivar uno a uno los plugins, o limpiar cachés.

Con los parámetros de PHP he preferido no meterme; el problema no es tan grave como para arriesgarme a preparar una avería.

La opción de Modo Seguro sí parecía interesante, pero me lleva al editor convencional y no me atrevo a tocar con él las páginas hechas en Divi, no sea que la líe.

Lo curioso es que a veces no se produce tal demora al guardar, aunque no he conseguido identificar la situación en la que cambia el comportamiento. A veces al borrar una caché, o desactivar un plugin, desaparece la demora, pero poco después, sin que haya cambiado la situación, la demora vuelve.

En fin, dejaremos pasar unos días a ver si consigo averiguar algo más. Por ahora, con el navegador de páginas de Divi me voy apañando cuando hay prisa. Si hay novedades volveré por aquí; si no, pasado un tiempo prudencial, cerramos el tema, que no es grave.

Saludos cordiales. 

Hola Carlos,

De acuerdo, quedamos atentos como ha ido todo.

Un saludo 😊 

no me actualiza el divi builder, y en el we panel me indica que el tema no se actualiza por licencia expirada, pero en mi plan tengo divi.

no entiendo

Hola Manuel,

Inicialmente como instalaste tu sitio con Divi, si lo hiciste mediante wepanel esta licencia se instala automáticamente, ten en cuenta que desde foro no tenemos acceso a las licencias sobre el tema.

En este caso abre un consulta en ticket y coméntales sobre el proceso de instalación para que puedan revisar tu sitio web y verificar las licencias de Divi instaladas.

Verifícalo y nos comentas cómo ha ido todo.

Un saludo 

Hola, Karen:

Aquí estamos otra vez, con el botón Guardar. Sigo con el minuto de espera hasta que se completa el proceso de grabación en Divi Builder.

Se me ocurrió hace unos días abrir DevTools de Chrome y echar un vistazo a la actividad de red. Y ahí he visto un proceso, sync-to-server, que mantiene el estado Pending hasta que se completa el guardado de la página, después de transcurrido el dichoso minuto.

Adjunto dos capturas de pantalla. La primera, correspondiente a un momento del citado minuto; la segunda, correspondiente al momento en que finaliza el proceso de guardado.

Las capturas no corresponden al durante y al después del mismo clic en Guardar; por eso hay algunos procesos que no coinciden, ya que el simple hecho de mover el puntero y cambiar de área en la pantalla envía información de red. Pero lo importante es que al iniciarse el proceso de guardado aparece siempre en primer lugar el sync-to-server en estado Pending, y al cabo de aproximadamente un minuto queda completado.

Imagino que todo esto puede daros alguna pista sobre el culpable de la demora, ya que sois vosotros los especialistas.

Por lo demás, todo sigue bien. Lo único, que de cuando en cuando cae algún cigarrillo más de la cuenta y han aumentado los sorbos de café.

Saludos cordiales.

Hola Carlos,

Gracias por las capturas y por revisar la petición desde DevTools. Sync-to-server no parece ser una petición ajena a Divi. Forma parte del propio funcionamiento de Divi  y Elegant Themes la documenta como una acción interna de sincronización con el servidor.

Por lo que describes, además, encaja bastante con lo que veníamos viendo, que son los cambios que parecen guardarse correctamente, ya que puedes comprobarlos casi inmediatamente desde otra pestaña, pero el Builder mantiene la animación hasta que esa petición sync-to-server termina aproximadamente un minuto después. Es decir, el problema parece estar más en la espera de esa comunicación que en el guardado del contenido propiamente dicho.

Como ya has probado cachés, plugins y scripts sin encontrar un patrón claro, antes de realizar más cambios sería interesante revisar esa petición concreta.

En Chrome, dentro de DevTools → Network, pulsa sobre sync-to-server mientras está pendiente y, cuando termine, indícanos o comparte una captura de estas pestañas:

• Headers: especialmente Request URL y Status Code.
• Timing: para comprobar en qué fase se consume ese minuto.
• Response o Preview: por si Divi devuelve algún aviso o error al finalizar.

Si aparece información sensible en las cabeceras, como cookies o valores de autenticación, no es necesario que la muestres.

Sobre el Modo Seguro de Divi, puedes estar tranquilo en ese aspecto: no modifica las páginas ni convierte el contenido al editor convencional. Elegant Themes indica en su documentacion que únicamente desactiva para tu usuario los plugins de terceros, el tema hijo y el código personalizado mientras realizas la prueba; los visitantes continúan viendo la web normalmente. De todas formas, como ya has realizado manualmente pruebas similares, no insistiría ahora mismo con ello.

También puedes hacer una prueba adicional entrando al Builder desde una ventana privada o desde otro navegador y guardar una modificación. Si allí sync-to-server tarda igualmente alrededor de un minuto, podremos descartar mejor algo específico del navegador o de alguna extensión instalada.

Si comprobamos que la petición permanece esperando prácticamente el mismo tiempo en todos los casos, con la URL de la petición, el código de respuesta y el Timing tendremos mucha más información para determinar si hay que revisar algo a nivel del servidor o si el comportamiento procede directamente del Builder.

Nos comentas lo que aparece y seguimos revisándolo.

Un saludo 🖐️

Hola, Argenis:

Muchas gracias por la respuesta, rápida y muy profesional, como siempre.

Me ha llevado un rato hacer los deberes que me pones. Como es tanta la información, en vez de datos concretos te pongo capturas de pantalla. Es largo, así que tómalo con calma.

Headers:

Request headers, por si acaso:

El Timing, supongo que el más relevante:

Response:

Este no parece tener nada relevante. "rendered content" tiene una línea larguísima que pasa de los treinta y pico mil caracteres, con código HTML que no creo que aporte nada de importancia.

Como DevTools de Chrome ahora es muy listo y ofrece un asistente IA, que precisamente ofrecía explicaciones sobre la demora de sync-to-server, le acepté su amable ofrecimiento. Me dijo lo siguiente:

Root Causes:

• Server-Side Latency: The server took 28.5 seconds to process the request before sending any data. This suggests a bottleneck in the WordPress/Divi PHP processing, likely due to a heavy database operation, complex layout rendering, or a slow plugin conflict.
• Payload Size & Network Speed: The content download took an additional 55.2 seconds. While the response is compressed (Brotli), the raw Divi builder JSON structure is deeply nested and verbose, leading to a long transfer time for such a large amount of serialized data.

Suggestions:

• Increase Server Resources: Ensure PHP memory_limit and max_execution_time are sufficiently high. Upgrade server hardware if CPU or I/O limits are being reached during Divi saves.
• Optimize Divi Layout: Reduce the complexity of the page. The response shows numerous nested modules, grids, and custom CSS; breaking large pages into smaller components can significantly reduce sync time.
• Check Database Health: Optimize WordPress database tables (specifically wp_options and wp_postmeta) to speed up the metadata retrieval and storage required by the Divi builder.
• Plugin Conflict Test: Temporarily disable other plugins to see if a specific one is intercepting the sync-to-server REST API call and adding overhead.

Ya ves qué majo él.

En cuanto a sus sugerencias, me sorprendió la segunda porque mis páginas son bastante sencillitas (al menos eso creo; echa un vistazo si te parece, que a lo mejor son más complejas de lo que yo creo). En cualquier caso, cuando empezó a aparecer la demora de sync-to-server ya llevaba días trabajando con páginas de complejidad similar a las de ahora.

Respecto a la tercera, que sí me pareció interesante, probé una optimización de base de datos mediante el plugin WP-Optimize, pero tampoco resolvió nada.

A la cuarta sugerencia no le hice mucho caso porque el tema de los plugins ya está probado y descartado.

En algún sitio, que con tantas vueltas ya no recuerdo dónde, saltó la sugerencia de las redirecciones: me dijeron que tenía bastantes —cierto— y que era preferible ponerlas en los .htaccess y archivos de configuración de Apache (supongo que las redirecciones que se pueden hacer en wepanel trabajan a ese nivel). Ahora las estoy haciendo con el plugin Redirection.

La prueba del navegador tampoco aportó nada. Trabajé un rato en una ventana privada de Firefox, y la demora fue la misma a la hora de guardar.

En fin, así están las cosas. A ratos libres, cuando no tengas cosas más importantes que hacer, puedes jugar un rato con estos misterios, que no dejan de ser un reto para espíritus inquietos.

Saludos cordiales.

Hola Carlos,

Muchas gracias por tomarte el tiempo de hacer todas estas pruebas y compartir las capturas. Lo primero que podemos confirmar con la informacion que nos compartes es que la petición de Divi:

/wp-json/divi/v1/sync-to-server

se completa correctamente con un código 200 OK. Además, en la respuesta aparece:

"save_verification": true

Por lo que Divi está confirmando que el guardado es válido. Esto encaja con lo que comentabas desde el principio sobre los cambios que si se guardan realmente, pero el Builder tarda mucho más en dar por finalizado todo el proceso.

La captura más interesante es efectivamente la de timing. Ahí vemos que los aproximadamente 84 segundos se reparten principalmente en:

Waiting for server response: 28,51 segundos
Content download: 55,22 segundos

El envío de la petición, por el contrario, tarda únicamente unos milisegundos. Por tanto, a estas alturas no parece que el problema esté en el botón Guardar ni en que Divi no pueda escribir los cambios. La demora se está produciendo durante la respuesta de la petición REST que Divi realiza después del guardado.

Sobre lo que te comenta el asistente de Chrome, tomaría algunas de sus conclusiones como orientativas, pero no como un diagnóstico como tal. Por ejemplo, que rendered_content tenga varias decenas de miles de caracteres no debería ser suficiente para que se den 55 segundos de descarga en condiciones normales. Habría que conocer el tamaño real de la respuesta para poder atribuírselo únicamente a eso.

También descartaría por ahora el tema de las redirecciones. Esta petición obtiene directamente un 200 OK; no aparece un código 301, 302, 307, etc. ni una cabecera Location. Por tanto, no movería todas las reglas de Redirection al .htaccess solamente por este problema, especialmente teniendo en cuenta que ya probaste desactivando plugins y el comportamiento continuó.

Hay otra cosa interesante en las cabeceras que compartes:

X-Microcache: True

Esto nos dice que el dominio tiene activa la capa de Microcaché del servidor. La propia respuesta de Divi está marcada como no-store y private, por lo que esto no significa que esa petición POST esté siendo cacheada, pero podemos hacer una prueba bastante sencilla para descartarla completamente. Desde wepanel puedes desactivar temporalmente Microcaché para comprobar posibles problemas con el CMS.

Puedes hacerlo desde:

WePanel > Herramientas > Microcaché

Desactívala temporalmente para el dominio, entra nuevamente en Divi y prueba un guardado. Después puedes volver a activarla. No es necesario modificar archivos ni tocar PHP para realizar esta prueba.

También haría una última prueba muy sencilla > crea una página nueva de prueba con Divi que tenga únicamente una sección y un módulo de texto, realiza un pequeño cambio y guarda. Si el proceso que estamos validando que es sync-to-server vuelve a tardar alrededor del minuto, podemos prácticamente descartar también que la complejidad de tus páginas o el tamaño de rendered_content sean los responsables.

Si después de estas dos pruebas continúa igual, puede ser un problema de consumo de recursos en tu servidor. Por ahora no realizaría más optimizaciones de base de datos ni cambios en las redirecciones puede llegar a ser contraproducente el comprimir de más tu base de datos. Nos comentas qué sucede al probar sin Microcaché y, si puedes, con esa página Divi prácticamente vacía.

Un saludo 🖐️ 

Hola, Argenis:

Muchas gracias también a ti por todo el informe y el tiempo dedicado al análisis de este asunto.

El botón Guardar y el minuto misterioso. Temporada 1, capítulo 3.

Vamos por partes:

— La desactivación de la Microcaché no afectó para nada al proceso de guardado. Seguimos igual.

— La creación de la nueva página sí que ha aportado alguna pista.

Desde el escritorio de WordPress creo una nueva página. Le pongo nombre y continúo con Divi, conforme al conocido mensaje

Este Diseño Está Hecho Con Divi

Allá voy. La página por defecto ya contiene una cabecera y pie de página. Añado un módulo de texto y guardo. El guardado es instantáneo.

Salgo de Divi Builder. Al salir llego a la pantalla anterior, escritorio de WordPress, donde se ofrece de nuevo Editar con el Divi Builder, pero aparece en la parte superior un mensaje algo desconcertante:

La copia de seguridad de esta entrada en tu navegador es diferente de la siguiente versión.Restaurar la copia de seguridad

Esto reemplazará el contenido actual del editor con la última versión de la copia de seguridad. Puedes usar deshacer o rehacer en el editor para recuperar el viejo contenido o volver a la versión restaurada.

Como no me queda muy claro este mensaje, por si acaso elijo Restaurar la copia de seguridad. Bien. Vuelvo a Divi y la página está tal como la dejé. No entiendo esa discrepancia entre versiones y copia de seguridad. Así que, ya en Divi, añado una simple palabra al módulo de texto y guardo. El guardado es instantáneo. Bien. Salgo de Divi y me vuelvo a encontrar con el mismo mensaje «La copia de seguridad de esta entrada en tu navegador es diferente...». Entonces me doy cuenta de que la página todavía se encuentra en estado Borrador. Así que pulso sobre el botón Publicar... y ahí se produce la demora del minuto.

Pasado el minuto vuelvo a Divi, hago un cambio mínimo y pruebo a guardar. Y ahí tenemos la demora del minuto, ya para siempre.

Entiendo, pues, que la culpa no es de Divi, al menos directamente. La primera demora se produce en un guardado fuera de Divi.

A partir de ese momento, los cambios realizados en Divi se aplican directamente a la página. Aunque el botón en el escritorio WordPress sigue ofreciendo Actualizar, no es necesario hacerlo. De hecho, cuando edito las páginas con Divi, ni me acuerdo de que ese botón existe.

La siguiente prueba que pide el cuerpo es, lógicamente, crear una página y pulsar sobre el botón Publicar sin pasar por Divi Builder. Así lo hago y, mira tú, otra vez la demora del minuto. Simplemente al Publicar. Sin hacer cambios, vuelvo a pulsar sobre el botón, que ya no es Publicar sino Actualizar, y seguimos con el minuto de demora. Abro DevTools, a la caza del sync-to-server, y tal proceso no existe. Pero sí hay uno que se queda el minuto en estado Pending: es post.php.

Naturalmente, la página creada inicialmente con Divi se puede previsualizar, pero no está visible en el sitio web hasta que se elija Publicar.

Me temo que esto cambia completamente la orientación del problema.

Saludos agradecidos por la paciencia que le estás echando.

Hola Carlos,

Pues sí, este capítulo va avanzando 😄. La última prueba que has realizado cambia bastante el enfoque y, revisando además la configuración del alojamiento, tenemos otra comprobación sencilla que merece la pena hacer antes de seguir buscando.

Vemos que actualmente la web está trabajando con PHP 8.5. Esto no significa que PHP 8.5 sea incompatible con tu WordPress: WordPress 7.0 ya ofrece soporte completo para PHP 8.5 y Divi también ha incorporado recientemente diferentes correcciones relacionadas con esta versión.

Sin embargo, WordPress no funciona únicamente con el núcleo; intervienen también el tema, plugins y cualquier código personalizado. Por ese motivo, creo que merece la pena hacer una prueba temporal con PHP 8.3, que nos proporcionará un entorno algo más maduro para comparar.

Desde WePanel cambia temporalmente la versión PHP del dominio de 8.5 a 8.3, espera unos minutos y realiza exactamente esta prueba:

• Crea una página nueva desde WordPress sin entrar en Divi.
• Pulsa Publicar.
• Comprueba cuánto tarda.
• Una vez publicada, haz un pequeño cambio y pulsa Actualizar.

No necesitas dejar PHP 8.3 definitivamente; lo que nos interesa es únicamente comparar el comportamiento.

Además, por los datos de configuración que vemos, no modificaría los límites de PHP. Actualmente tienes:

• memory_limit = 512M
• max_execution_time = 300
• max_input_time = 300
• max_input_vars = 10000

Son valores suficientemente amplios para esta prueba, por lo que no parece que el retraso venga de falta de memoria o de un tiempo máximo de ejecución demasiado reducido. Aquí pueden ocurrir dos cosas:

Si con PHP 8.3 desaparece el minuto de espera, habremos encontrado una pista bastante importante. En ese caso no sería necesario seguir buscando en Divi, cachés o redirecciones; habría que localizar qué componente de la instalación está teniendo un comportamiento anómalo bajo PHP 8.5.

Si con PHP 8.3 tarda exactamente lo mismo, podemos descartar prácticamente también la versión de PHP y continuar con la pista de alguna acción que WordPress ejecuta al publicar o actualizar contenido.

Antes de volver a PHP 8.5, revisaría también si dentro de la carpeta de la web aparece un archivo error_log. Haz una publicación de prueba y comprueba inmediatamente después si se han añadido errores o avisos nuevos. No es necesario que publiques todo el archivo; si aparecen entradas coincidiendo con la hora exacta del guardado, compártenos solamente esas últimas líneas.

Después de esta prueba, si todo sigue igual, continuaría con estas comprobaciones tambien:

• Desactivar temporalmente Magic Cache + WE-Varnish-Cache, si los tienes activos, y probar.
• Probar Actualizar la página publicada con el Modo Seguro de Divi activado (esto, más allá de desactivar plugins, también pausa scripts y códigos que interfieran en el funcionamiento).

A ver qué nos depara el capítulo 4 😄

Un saludo 🖐️

Hola, Argenis:

El botón Guardar y el minuto misterioso. Temporada 1, capítulo 4.

Pues algo está cambiando.

Paso el PHP a versión 8.3. Espero bastantes minutos mientras aprovecho para algunas tareas domésticas.

Creo la página nueva, con una simple línea y sin pasar por Divi.

Guardo. Tarda un rato, no cronometro pero la sensación es que el tiempo ha sido algo inferior.

Añado una línea. Antes de guardar tengo la curiosidad de previsualizar. Se abre nueva pestaña y la página tarda algo en mostrarse, más o menos el mismo tiempo que en el primer guardado.

Añado otra línea, pero antes de guardar tomo la precaución de abrir DevTools. Vuelve a tardar más o menos el mismo tiempo, post.php vuelve a aparecer Pending, pero ahora ya tenemos el tiempo exacto que tarda: 33,32 segundos. Así pues, el tiempo de grabación se ha reducido a la mitad.

Ahora tengo la curiosidad de ver qué pasa si toco la página con Divi Builder. Tarda un rato en cargar, me imagino que por ser la primera vez, y quizá porque no le gusta que otros le modifiquen la página a sus espaldas, quitándole protagonismo.

Por fin se abre Divi Builder. Ahí está la página. Sin cambiar nada, clic en Guardar. Y vuelve a aparecer nuestro viejo conocido sync-to-server. Ahora el Pending se toma su tiempo, nada menos que 1,4 minutos. Decepción.

Vamos a ver el error_log.

No ha registrado nada. La última entrada es del 10 de agosto. Por curiosidad, la última línea es:

[10-Aug-2026 10:15:53 UTC] PHP Warning: unserialize(): Extra data starting at offset 4349 of 4363 bytes in /home2/martin18/public_html/martinezbande.es/wp-content/themes/Divi/core/components/cache/File.php on line 79

Hay bastantes líneas similares para este día, en torno a 40. Días atrás aparecen de cuando en cuando otras similares pero me imagino que son problemas puntuales, no parece nada sistemático.

O sea, que error_log no ha registrado hoy nada que haya merecido una anotación en sus registros.

Siguiente paso. Buf, qué miedo esto del modo seguro de Divi. Atrevámonos...

Bueno, en modo seguro se vuelve al editor clásico. No veo el contenido de la página, solo el logo de Divi, pero como anda por ahí el botón de Actualizar, clic y guardado inmediato. Como desde esa pantalla, sin volver a Divi > Centro de soporte, puedo desactivar el modo seguro, procedo, respiro aliviado.

Por si acaso vuelvo a Divi > Centro de soporte y veo que, efectivamente, el modo seguro de ha desactivado. Bien, volvemos a la normalidad.

Ahora entro a editar con Divi la página de prueba. Hago unos cambios mínimos y Guardar. Tarda solo unos segundos.

Entre el entusiasmo y la desconfianza, abro una de las páginas más complejas que tengo. Por si acaso no hago cambios, pulso sobre Guardar y, oh sorpresa, guarda en unos segundos.

Conteniendo la emoción, abro otra página compleja. Sin realizar cambios, clic en Guardar. Grabación casi instantánea. ¿Qué ha pasado? Ni idea. El hecho de guardar sin haber realizado cambios no parece ser la razón de la desaparición de la demora, porque antes, aunque no hubiera cambios, el simple hecho de Guardar ya conllevaba esta demora.

Pruebo a Guardar otra vez, pero con DevTools a la vista. La misma rapidez. Ahora sync-to-server tarda 4,2 segundos.

Vuelvo a una página que dejé ayer pendiente de un detalle. Modifico y guardo. Ahora, sync-to-server, 34 segundos.

Ya no sé que pensar. Le doy un respiro mientras dedico otro rato a tareas domésticas.

Vuelvo. Abro otra página que también tenía pendiente de una modificación mínima. Guardo. Ahora sync-to-server, 14,59 segundos.

¿Que ha pasado?

Buena pregunta. ¿Será que PHP 8.3 está ya trabajando con normalidad? ¿Será que un paso por modo seguro le ha llevado a limpiar algo y eso se traduce en un mejor rendimiento? ¿Será que, al ser hoy festivo aquí, la Virgen de la Asunción nos ha iluminado?

Vamos a darnos unos días con el sistema tal como queda ahora, con PHP 8.3 y un sync-to-server redimido parcialmente de sus pecados. A ver si esto es solo flor de un día o se mantiene en el tiempo.

Volveré en unos días con el capítulo 5. A ver si para entonces los protagonistas se han reconciliado, se casan, tenemos final feliz y podemos terminar la temporada 1.

Como siempre, mi agradecimiento por todas vuestras atenciones. Y paciencia. Es un lujo teneros ahí.

Hola Carlos,

Por lo que comentas, parece que hemos confirmado dos cosas importantes:

La primera es que PHP 8.3 mejora claramente el comportamiento general frente a PHP 8.5, al menos en las pruebas de publicación/actualización normales. post.php pasó de rondar aproximadamente el minuto a unos 33 segundos. No es todavía un tiempo ideal, pero sí es una diferencia suficientemente grande como para pensar que PHP 8.5 estaba influyendo de alguna manera en la instalación.

La segunda pista, y quizá la más interesante, es lo que ocurrió después de activar y desactivar el Modo Seguro de Divi. A partir de ahí varios guardados que antes tardaban cerca de un minuto pasaron a realizarse en unos pocos segundos, con sync-to-server llegando incluso a 4,2 segundos.

El Modo Seguro no modifica el contenido de las páginas, pero sí carga Divi temporalmente sin plugins de terceros, tema hijo ni código personalizado. Es posible que al entrar y salir de ese modo se haya regenerado alguna caché interna o algún estado temporal de Divi.

De hecho, en el error_log aparece esta advertencia relacionada precisamente con la caché de Divi:

PHP Warning: unserialize(): Extra data...
/wp-content/themes/Divi/core/components/cache/File.php

Por ahora, viendo la mejora que has obtenido, estoy contigo en dejarlo así unos días; entonces quedamos atentos y esperamos que sea el punto de solución del problema. A ver si el capítulo 5 acaba en boda 😄

Un saludo 🖐️