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
—

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

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.

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.

Specifically, the problem occurs when the editor publishes an entry and saving it with the Gutenberg wordpress editor immediately causes a load on the CPU. Yes, it is true that it takes a few minutes but it shouldn’t.

The curious thing is that many claim that the newspapers theme plugins consume a lot of resources but I don’t see any solution in the photos nor does anyone refer much to it

Thanks for your comment!!

on mobile it shows the “phone viewport” layout, not the mobile template.
> https://imgur.com/undefined

Version: 11.5.1

How it looks https://imgur.com/Rw0vvHC > how it should look: https://imgur.com/Ic0mcuh

The page is under construction