Descripción:
Estimado equipo de soporte de Newspaper,
Nos gustaría reportar algunos problemas recurrentes con el tema y sus plugins asociados:
Rendimiento de la CPU: Hemos experimentado picos de uso de CPU debido a la carga de contenido pesado, especialmente imágenes y consultas de base de datos. A pesar de la implementación de WP Rocket y Redis, el problema persiste.
TagDiv Composer: El plugin TagDiv Composer está causando una carga significativa en la CPU y el servidor, afectando el rendimiento general del sitio. A veces, la interfaz se vuelve lenta y no responde con la fluidez esperada.
Problemas con el Editor Gutenberg: El uso de Gutenberg junto con el tema Newspaper genera picos elevados de CPU, especialmente cuando se editan publicaciones con contenido multimedia pesado.
Optimización de la base de datos: A pesar de las optimizaciones realizadas (caché de objetos, optimización de imágenes, etc.), seguimos enfrentando problemas con la base de datos, especialmente cuando se manejan grandes volúmenes de publicaciones y medios.
Solicitamos asistencia para:
Identificar posibles configuraciones adicionales para mejorar el rendimiento en conjunto con TagDiv Composer y Gutenberg.
Optimizar el rendimiento general sin comprometer la funcionalidad o la carga de contenido histórico.
Gracias de antemano por su ayuda.
Hi,
Please check if the wp rocket plugin is set as in our guide also using Redis will help a lot. Another cache that can be used the the cache from flex blocks elements – https://forum.tagdiv.com/use-flex-blocks-cache-option/ this should reduce the CPU, also you can use a plugin to monitories the elements and plugins that are consuming and when are consuming the resources.
Thank you!
Espero que se encuentren bien. Me gustaría exponer detalladamente las pruebas de rendimiento y la configuración de los plugins de optimización realizadas en el sitio http://www.itvpatagonia.com, con el fin de ofrecerles un contexto más claro sobre las conclusiones técnicas a las que hemos llegado respecto al rendimiento del theme Newspaper y el uso del plugin tagDiv Composer.
1. Plugins de Optimización Instalados
En el sitio web de http://www.itvpatagonia.com, hemos instalado y configurado los siguientes plugins de optimización para mejorar el rendimiento y la carga de las páginas:
WP Rocket: Configurado para la optimización de caché, precarga de caché, compresión de archivos estáticos, optimización de bases de datos, y optimización de scripts JavaScript y CSS.
Cloudflare: Usado como CDN y servicio de mitigación de ataques DDoS, con reglas específicas para excluir el backend de la caché y optimizar la entrega de contenido estático.
Redis: Configurado para optimizar la caché de objetos en el servidor, lo que ha ayudado a reducir los tiempos de respuesta de las consultas a la base de datos.
tagDiv Cloud Library: Plugin proporcionado por Newspaper para acceder a plantillas prediseñadas y optimizar el uso de recursos de la web.
Smush Pro: Usado para la optimización de imágenes, comprimiendo y redimensionando las imágenes para mejorar la velocidad de carga.
EWWW Image Optimizer: Complemento para optimizar aún más las imágenes y garantizar que estén en los formatos más ligeros posibles (incluyendo WebP).
2. Pruebas de Rendimiento y Revisión
A lo largo de este tiempo, hemos realizado diversas pruebas de rendimiento con herramientas como GTmetrix y Google PageSpeed Insights, así como evaluaciones internas utilizando New Relic y Query Monitor, para examinar el impacto de los plugins y la estructura del sitio.
Pruebas clave realizadas:
Rendimiento de carga: Con un volumen de alrededor de 10,000 publicaciones, observamos que la carga del sitio se ve afectada negativamente, especialmente al trabajar con tagDiv Composer y Newspaper.
Uso de CPU y memoria: Durante la carga masiva de contenido y la generación de nuevas páginas, experimentamos picos de uso de CPU, que no se lograron reducir completamente incluso después de optimizar todos los plugins de rendimiento mencionados.
Tiempo de respuesta del servidor: El tiempo de respuesta del servidor también se incrementa significativamente cuando el número de publicaciones excede las 10,000, independientemente de la optimización de caché y otros ajustes.
Problemas con tagDiv Composer: El plugin tagDiv Composer muestra un rendimiento inconsistente y no se comporta de manera óptima cuando se trabaja con grandes volúmenes de contenido. Esto afecta directamente la experiencia del usuario y la administración del sitio.
3. Conclusión Técnica
A pesar de la implementación y configuración de los mejores plugins de optimización disponibles, hemos llegado a la conclusión de que el tema Newspaper y su plugin tagDiv Composer no son capaces de funcionar de manera óptima con un volumen de contenido superior a 10,000 publicaciones. Este comportamiento se mantiene consistente a pesar de las múltiples configuraciones y ajustes en los plugins de rendimiento y cache.
Por tanto, la consulta técnica original no estaba relacionada con recomendaciones generales sobre qué plugins de optimización utilizar o qué tipo de hosting es el mejor. Ya hemos realizado todas las pruebas posibles en este sentido, y estamos en busca de una solución más profunda y técnica que considere los problemas de rendimiento inherentes al uso de Newspaper en sitios con grandes volúmenes de contenido.
Agradecería que, en lugar de proporcionar recomendaciones genéricas, pudiéramos recibir una revisión técnica detallada o incluso una actualización o mejora en los plugins/funcionalidades de Newspaper y tagDiv Composer que puedan garantizar el rendimiento adecuado en este tipo de sitios.
Quedo atento a su pronta respuesta.
hola compañeros, nosotros estamos en nuestra web en una configuración muy parecida a la vuestra, también con muchas mas de 10000 publicaciones, también somos un medio de comunicación, tenemos un servidor sobredimensionado para intentar mitigar el impacto del tema sobre el rendimiento. Algo que a nosotros, creemos, nos ha servido, ha sido configurar nuestro plugin de cache, “wp super cache”, en modo “experto” para que sea nginx quien atienda las peticiones de cache, para liberar a php un poco de carga, también optimizar la “OPcache” que estaba rozando el limite máximo, de todas formas, seguimos experimentando picos de carga en momentos aleatorios y a horas que no hay visitas, no somos los únicos por este foro con este problema concreto…
Hello,
In addition to using caching, Cloudflare, and Redis, I’d also recommend enabling caching for the Flex Block. This feature can make a noticeable difference by significantly reducing the number of server requests, especially on content-heavy pages.
It’s also good to keep in mind that, like any visual page builder, tagDiv Composer requires more resources while editing. This is perfectly normal. Real-time builders perform many background processes—adding, removing, and modifying elements, all of which generate multiple live requests. On websites with large databases (for example, those with a high volume of articles), using filters on blocks can slow things down a bit, as each block applies its own query to retrieve specific content.
This behavior is common across most live builders, not just tagDiv Composer. The system is working hard to provide instant feedback, which naturally increases resource usage.
What you can do:
A good next step would be to monitor resource usage and identify which pages or specific elements are using the most server resources. Often, features like AJAX filters or “most popular articles” widgets can be more demanding, since they constantly query the database for up-to-date information.
Identifying and optimizing these high-impact areas can help keep your site fast and responsive both for your visitors and during editing sessions.
Thanks again
Asunto: Problemas persistentes con carga AJAX – Caché en bloques no fue efectivo
Estimado equipo de soporte de tagDiv,
Gracias por su respuesta anterior. Después de probar la solución recomendada de activar el caché para los bloques Flex, lamento informar que no produjo mejoras significativas en el rendimiento del servidor.
Actualmente operamos un sitio de noticias de alto tráfico con más de 10.000 publicaciones, y nuestra infraestructura incluye:
VPS optimo
Nginx, PHP 8.1 (FPM), Redis como caché de objetos
WP Rocket (totalmente optimizado), Cloudflare activo, y la última versión del theme Newspaper
No usamos WooCommerce ni funciones de suscripción – es un sitio exclusivamente de publicaciones
A pesar de tener todas las capas de caché activas y optimizadas, seguimos observando un alto consumo de CPU incluso en momentos sin visitas. Tras una revisión más profunda, la causa principal parece ser el uso de AJAX, especialmente:
admin-ajax.php?action=as_async_request_queue_runner
tareas en segundo plano generadas por el theme/plugins (probablemente vía Action Scheduler)
llamadas generales a admin-ajax generadas por el theme y el constructor
En este contexto, no es viable desactivar funcionalidades críticas o plugins simplemente para reducir la carga del servidor, especialmente considerando que muchas llamadas AJAX provienen de la estructura misma del theme (incluyendo tagDiv Composer y bloques dinámicos).
Necesitamos una solución técnica concreta y viable para reducir la sobrecarga de AJAX sin sacrificar funciones esenciales.
Agradeceríamos su orientación sobre lo siguiente:
¿Existe algún mecanismo interno o actualización en desarrollo para minimizar las consultas AJAX en segundo plano?
¿Es posible configurar tagDiv Composer o componentes del theme para reducir su dependencia de admin-ajax en entornos productivos?
¿Tienen prácticas recomendadas o configuraciones avanzadas específicamente para sitios con gran volumen de contenido que utilicen Newspaper?
Esperamos su orientación experta, ya que esta situación está afectando el rendimiento y la escalabilidad de nuestro sitio en producción.
Hi,
Based on the logs you’ve shared, it appears that the as_async_request_queue_runner action is being triggered frequently, leading to high CPU usage. This action is part of the Action Scheduler library, which is used by many plugins to manage asynchronous and scheduled tasks.
High CPU usage from this action is uncommon unless a large number of tasks are being generated. This could be caused by a plugin or theme creating excessive tasks, or by tasks not being properly cleared after execution.
To further investigate, consider using a plugin like WP Crontrol to inspect scheduled tasks (crons) for any unusual patterns. Additionally, you can check the Action Scheduler’s admin interface by going to Tools > Scheduled Actions to see if there are a large number of pending or failed actions.
There would be some ways to reduce the number of queries, if you will consider them.
For one of the queries (sql_calc_found_rows):
Reduce the number of ajax usage on the website, as those are the ones that will make requests to load more posts.
So ajax features like ajax pagination – https://i.imgur.com/EfKi0za.png – https://i.imgur.com/sMeot5s.png – https://i.imgur.com/vrJq3BC.png
The ajax menus – https://i.imgur.com/n0K9hCN.png
Also the header live search makes requests when it is used – https://i.imgur.com/1ZvDwZx.png This can be deactivated when using a cloud header template. We added an option specially for it, as it can cause increased load on large websites.
The mega-menu pagination – https://i.imgur.com/T8kYzu4.png This can be deactivated when using cloud header templates, an option for this was also added for the same reasons mostly.
You can disable the ajax view count from here -> https://i.imgur.com/BIwbscU.png
Gracias por los tips, pero no es la idea desactivar todo para que la Plantilla no consuma tanto recurdo de un Hosting o VPS. El problema de News Paper es que tiene un alto consumo de CPU cuando el administrador entra al editor Gutenberg. En algún momento de la edición del post llega a 60% o más cuando guarda el Post y ese problema es 100% del editor gutenberg con tagdv. Leí que hay un plugin Tagdv que sireve para cache pero no lo encontré en el Pack de la plantilla que se descarga de la página. Luego de Muchas pruebas en News Paper creo que no es la plantilla en en el FronEnd es más su plugin tagdv y Gutenmber que consumen mucho recurso a partir de las 5.000 publicaciones
Hi,
Can you please make a test and see if using the classic editor (install the plugin classic editor) the problem is still persisting.
I just tested on my dev and for me is working ok with both, classic editor and the new Gutenberg editor from wordpress (not the extra plugin)
Thank you!
Estimado equipo de soporte de Newspaper:
Les escribo para manifestar nuestro toal descontento con la calidad de atención que hemos recibido hasta ahora. Llevamos varios días reportando problemas de rendimiento y compatibilidad de la plantilla con bases de datos de gran volumen, y la única “solución” que obtenemos de ustedes son parches a medias, respuestas tardías y explicaciones genéricas que no resuelven nada de raíz.
Para que conste:
Hemos seguido cada instrucción que nos han enviado (ajustes de PHP-FPM, optimizaciones de MySQL, configuración de WP Rocket, Redis, Cloudflare, etc.). Ninguna de esas recomendaciones ha detenido los picos de CPU ni ha solucionado la incompatibilidad de Newspaper con >10.000 publicaciones.
Hemos documentado con datos concretos el comportamiento de la plantilla durante los picos de carga (líneas de log, tiempos de respuesta, consultas lentas con SQL_CALC_FOUND_ROWS, pruebas de WP Crontrol y Action Scheduler). Sin embargo, sus respuestas no han ido más allá de “revise sus plugins” o “desactive este o aquel módulo”, cuando el problema radica en el núcleo de Newspaper y en cómo gestiona las consultas y la memoria para grandes volúmenes de contenido.
Pagamos por un servicio de soporte premium, y lo mínimo que se espera es que respondan en plazos razonables (no semanas después) y que propongan un diagnóstico definitivo, no parches temporales que rompen el sitio en cada actualización.
Les exigimos lo siguiente:
Revisión integral del código de la plantilla: Identifiquen y corrijan los cuellos de botella en las consultas SQL y en el manejo de bloques con Composer y Gutenberg. Dejen de sugerir “optimaciones genéricas” que ya hemos descartado mil veces.
Propuesta de solución concreta y probada para entornos con bases de datos de más de 10.000 entradas. Queremos código o configuraciones específicas que demuestren fehacientemente que el tema funciona sin saturar la CPU.
Compromiso de tiempos de respuesta: Si envíamos un ticket o solicitamos asistencia, exigimos una respuesta en menos de 48 horas hábiles.
Transparencia en los parches: Si la solución requiere cambios en la plantilla (funciones, consultas, hooks), entreguen un parche detallado y documentado. Nada de “vuelva a instalar Newspaper” ni “elimine plugins conflictivos” cuando ya hemos probado todo lo posible en nuestro entorno.
Es inaceptable que paguemos por un producto que colapsa bajo un uso razonable y que el soporte tarde tanto en ofrecer algo distinto a soluciones parches que no corrigen nada.
Quedamos atentos a su pronta y concreta respuesta.
Atentamente,
Juan
VPS 8 núcleos / 24 GB RAM | PHP 8.1.2-FPM | MySQL optimizado | Redis activo | Cloudflare activo
—
Me uno a la peticion, estoy en la misma situacion y no hay una solucion definitiva al problema
Hi jasm90,
I’m truly sorry you’re feeling this way, and I completely understand your frustration, especially knowing that you’re one of the few customers who actively support us and have a valid subscription. It’s disheartening to see you disappointed, and I want to sincerely apologize for any inconvenience caused.
We know you’re not like others who come to us with long-expired support and still expect help, and we genuinely appreciate your ongoing trust. That’s why it pains us even more when we’re not able to resolve things as quickly or easily as we’d like.
The issues you’re facing are, unfortunately, quite complex. When it comes to problems that require deeper investigation, like code reviews or custom implementation these are beyond what the support team is equipped to handle directly. We wish we could do more on the spot, but these kinds of tasks need involvement from a developer, and we’re not able to allocate that instantly.
Regarding forum responses, we aim to reply within 24 hours during the work week (Monday to Friday). Support requests made Friday evening or over the weekend are typically addressed first thing Monday morning.
For your current situation, what I can do and I genuinely hope this helps—is reach out to one of our developers and ask if they can take a look at your site when they have a bit of free time. Please note that this might take up to a week.
If you’re okay with that, here’s what we’ll need from you:
– A full backup of your website and database
– Temporary access to your WordPress admin (wp-admin) and cPanel
– Please email this information to contact@tagdiv.com and make sure to include a link to this forum topic so we can identify your case and assign it properly.
Once again, I truly regret the trouble you’ve experienced, and I appreciate your patience and understanding more than I can say.
