Cómo solucionar el alto consumo de recursos en WordPress

Saber cómo solucionar el alto consumo de recursos en WordPress puede ayudarnos a tener una página web más rápida y ágil. Sin embargo, el alto consumo de recursos tiene varias razones y tenemos que saber cómo atacar cada una de ellas.

Todas las aplicaciones basadas en PHP, incluyendo WordPress, consumen recursos y memoria RAM en el procesamiento de los datos contenidos en nuestra página web. Adicionalmente, cada vez que se ejecutan los scripts en las páginas enviadas a nuestros usuarios, existe un consumo de recursos. Por otro lado, mientras más tráfico, mayor es el consumo de recursos en nuestro sitio web de WordPress.

¿Cómo solucionar el alto consumo de recursos en WordPress?

En este artículo de Ayuda Hosting, veremos cuáles son las causas del alto consumo de recursos de nuestra página web en nuestro hosting y cómo solucionar este alto consumo de recursos.

¿Cuál es el funcionamiento básico de WordPress?

WordPress es una aplicación CMS o Sistema de Gestión de Contenidos, desarrollada en lenguaje de programación PHP adaptado al desarrollo web. Adicionalmente, WordPress guarda toda la información en forma de base de datos que, por lo general, está en un sistema de gestión de base de datos llamado MySQL. Esto le permite funcionar a nivel de servidor como cualquier programa basado en PHP.

Suponiendo que nuestro sitio web está desarrollado en WordPress. Y que además, no dispone de ningún caché configurado o instalado, procederemos a explicar cuál es el funcionamiento básico de WordPress, sin profundizar técnicamente.

Los siguientes, son los pasos de lo que ocurre en WordPress cuando un usuario ingresa en nuestro sitio o blog desde su navegador:

1. Nuestro visitante ingresa a la web utilizando su navegador, el cual envía una petición de acceso a nuestra página web en el servidor donde se encuentra alojada. Esto genera un impacto de leve a medio en el CPU y en la memoria RAM.
2. Utilizando PHP, nuestro servidor procesa el script PHP requerido para la generación de una página estática que muestra al visitante. Además de esto, se muestran algunos datos contenidos en la base de datos MySQL para completar la página. Esto genera un impacto alto en el CPU y en la memoria RAM.
3. Una vez generada la página, esta es enviada a nuestro visitante utilizando el protocolo HTTP o HTTPS. Esto genera un impacto bajo en el CPU y en la memoria RAM.

Como es posible observar, la mayor parte del impacto recibido por el CPU ocurre cuando se genera la página web estática en HTML. Esto ocurre cuando la página se procesa empleando PHP y la compilación interna también en PHP. Esta es la situación que causa el mayor consumo de recursos del CPU en cualquier instalación de WordPress.

Picos de tráfico o consumo continuo

En este punto tenemos que considerar dos aspectos que nos dirán cuál de ellos es el responsable del alto consumo de recursos del CPU. Esto es porque dependiendo de cuál de ellos tenga mayor peso, podemos conseguir una solución particular para el problema:

• Picos de tráfico: Son aquellos instantes cortos en el tiempo en los que recibimos una gran cantidad de visitantes al mismo tiempo. Esto produce altos consumos pero en espacios de tiempo reducidos.
• Carga o consumo continuo: En este caso, el consumo es alto y continuo, y ocurre cuando tenemos muchos visitantes en nuestra web todo el tiempo. La aplicación de técnicas que impliquen balancear este impacto no deberían afectar la funcionalidad de nuestro sitio.

Podemos aplicar técnicas que disminuyan el impacto en el consumo de recursos en un sitio web de WordPress. Sin embargo, es aplicable solo en servidores dedicados o VPS. Si nuestro sitio web está hospedado en un servidor compartido y el consumo de recursos es muy alto, esto implica que vamos a terminar restringidos. Sin embargo, si el caso es de aumentos de tráfico eventuales, es posible que no tengamos problemas.

Alto consumo de recursos ocasionado por plugins u otros elementos

El poder realizar un diagnóstico es tan solo el principio para resolver el problema de alto consumo de recursos de nuestra web de WordPress. Este consumo exagerado de recursos podría ser causado por un plugin.

Por ejemplo, supongamos que tenemos nuestro sitio alojado en un servidor VPS con 1 GB de memoria RAM. Lo más probable es que en estas condiciones nuestro sitio no será capaz de soportar la carga que generan 500 visitantes simultáneamente y a la vez ofrecer una buena usabilidad de usuario. Lo más probable es que nuestro sitio a pesar de estar optimizado, no sea estable.

Existen varias opciones que nos ayudarán a diagnosticar mediante plugins u otras herramientas cualquier problema de alto consumo de recursos del CPU en WordPress. A continuación, veamos algunas de esas herramientas que nos ayudarán a detectar el alto consumo de recursos:

• PingDom Tools: Esta herramienta nos permite comprobar la velocidad de carga de las páginas de nuestro sitio y verificar qué elementos tardan más en cargar desde nuestro servidor. Así podremos saber qué es lo que hace más lenta la carga de nuestras páginas. A manera de ejemplo, podemos observar en la siguiente imagen como el javascript de Piwik hace más lenta la carga de la web:

• GTMetrix: Esta herramienta, al igual que la anterior, nos permite conocer cuáles son los elementos que más tiempo tardan en cargar de nuestro sitio web. De la misma forma que PingDom Tools, carga los scripts, permitiéndonos tener una visión más precisa del problema. Además, nos muestra toda la información técnica relacionada con el problema de manera más amplia que PingDom Tools.

• Deshabilitar plugins uno por uno: La mayoría de los problemas que podemos encontrar en nuestra página web de WordPress, son ocasionados por los plugins. Es por esto, que lo primero que haremos para detectar si el problema lo ocasiona un plugin es desactivarlos todos uno por uno. Lo haremos agregándole una letra a los nombres de las carpetas utilizando un cliente FTP. Lo haremos utilizando un cliente FTP porque en algunas ocasiones se imposibilita hacerlo desde el administrador de WordPress.
• Comprobar los Widgets: En algunas ocasiones, los widgets ralentizan la carga de las páginas, más aún si les hemos incluido códigos PHP. Utilizando cualquier plugin similar a Widget Cache es posible cachear los plugins en el disco.

Existen otras maneras de diagnosticar los problemas de carga de nuestro sitio de WordPress. Sin embargo, muchas de ellas exigen conocimientos técnicos más avanzados para su aplicación.

Uso de OPCode de PHP en WordPress 

Para comprender cómo funciona un cache OPCode de PHP se requiere saber cómo trabaja un compilador de PHP justo cuando los visitantes acceden a nuestro sitio de WordPress y estos realizan una petición que genere una página web en nuestro sitio.

Un cache OPCode simplemente cachea los scripts de PHP, que ya han sido procesados, para presentar lo que podemos obtener con ellos posteriormente. Es una manera de ahorrar recursos, debido a que, cuando se ejecuta un script PHP, no se realiza todo el proceso de compilación. Por esta razón, los resultados se presentan con mayor velocidad.

Existen otros sistemas de cache OPCode para PHP. Unos más empleados que otros y los más empleados resultan más efectivos. Existen otros sistemas más efectivos de OPCode para PHP como: Zend OPCache, eAcccelerator, APC o XCache. Estos sistemas solo se podrán instalar en servidores VPS o servidores dedicados. Si nuestro servidor es del tipo compartido, debemos contratar este servicio con nuestro proveedor de hosting.

Cache de objetos en WordPress

El cache de objetivos solo podrá implementarse en servidores del tipo VPS o dedicados. Este podrá ser configurado en nuestro sitio web de WordPress.

Con este sistema de cache de objetivos podremos almacenar, en la memoria RAM o en nuestro disco, los códigos de los elementos que forman nuestra página web. Podremos guardar los códigos de los videos, imágenes y todos aquellos elementos que se cargan desde nuestro servidor, al momento de abrirse una página de nuestro sitio web de WordPress.

También, podremos reducir el I/O de nuestros discos duros y simultáneamente reducir los tiempos de respuesta de las peticiones de nuestros visitantes.

Este sistema es fundamental para sitios web grandes. Sin embargo, no olvidemos que mientras más elementos tengamos cacheados, más memoria RAM exigirá nuestro sitio web.

Podemos encontrar diferentes sistemas de cache de objetos que podremos emplear para el almacenamiento de objetos cacheados en nuestro servidor. Entre ellos se encuentran: APC, XCache, Redis o Memcached.

Si deseamos tener un sistema de cache de objetos en nuestro WordPress podemos instalar algunos de los siguientes plugins: W3 Total Cache, Cachify o WP-FFPC. Con estas aplicaciones podemos realizar consultas en la base de datos de los almacenamientos del cache de la memoria.

Cache de los widgets en WordPress

En algunas ocasiones es posible determinar que el mayor consumo de recursos proviene de los widgets. Sin embargo, no es posible siempre prescindir de algunos de ellos muy útiles para nosotros.

Una solución para disminuir el excesivo consumo de recursos causado por los widgets es implementando un sistema de refrescamiento del cache de los widgets. Esto podemos ajustarlo a cada 5 minutos, dependiendo de la demanda. Como consecuencia de esta solución, podremos obtener un aumento de I/O Wait del 10 por ciento y una baja de la carga del procesador del 90 por ciento.

Cache de la base de datos en WordPress

Como lo mencionamos anteriormente, WordPress almacena toda su información en forma de base de datos MySQL. Esto genera un uso constante de la base de datos, lo que ocasiona un alto consumo de recursos continuamente. Todo esto, en función de alimentar de información al visitante cada vez que ingresa a nuestro sitio web de WordPress.

Podemos permitir que solo queden guardados en cache una cantidad limitada de consultas compartidas entre la memoria y el cache del disco. Esto podemos hacerlo empleando un plugin o configurando el Query Cache en MySQL.

En el caso de configurar MySQL del servidor, tenemos que especificar el tamaño del Query Cache de acuerdo con la memoria RAM disponible. Esto, porque es allí donde se guardarán las consultas cacheadas.

También, podemos guardar el cache de las consultas en sistemas de cache de objetos como APC, Memcached y XCache. Esto podemos hacerlo empleando el plugin W3 Total Cache.

Si además, estamos en un hosting compartido y queremos guardar las consultas de la base de datos en un cache en el disco, podemos emplear el plugin DB Cache Reloaded Fix.

Cache de páginas estáticas en WordPress

Las páginas estáticas de WordPress siempre se han podido cachear. Por lo general, esto lo hacemos fácilmente con plugins como WP SuperCache o W3 Total Cache almacenando las páginas estáticas cacheadas en el disco.

Sin embargo, cuando se trata de sitios web con elevados consumos de recursos, se produce un aumento del el I/O Wait del servidor y una reducción del rendimiento general, cuando se leen y escriben grandes volúmenes de estos archivos estáticos en el disco duro. Esto trae como consecuencia, una disminución del rendimiento general y un retardo en las peticiones en nuestro sitio web de WordPress.

Para el caso del alto consumo de recursos causado por páginas estáticas, podemos encontrar muchos plugins que nos ayuden a tener buena estabilidad con una buena demanda de visitas a nuestro sitio web.

Por otro parte, no podemos dejar de mencionar uno de lo mejores plugins del momento para caché en WordPress: LiteSpeed Cache. Para más detalles, puedes echarle un vistazo a su guía de configuración.

Sistemas CloudFlare y CDN

Podemos decir que existen por lo menos dos sistemas de red de distribución de contenidos (CDN) que, aunque son diferentes entre sí, funcionan perfectamente cuando se trata de estabilizar del consumo de los recursos de nuestro sitio web. Estos son: CloudFlare y Amazon CloudFront

Implementar un sistema CDN es una manera de mantener estable el consumo de recursos, cuando se reducen las peticiones a nuestro servidor. Con este sistema el servidor se exime de servir archivos estáticos y le deja esa tarea al CDN.

Sistema de proxy inverso con Nginx o Varnish

Aunque Apache es un servidor muy estable y flexible cuando es exigido, tiene una fuerte debilidad y es su alto consumo de recursos cuando sirve archivos estáticos.

Por lo anterior, si deseamos aprovechar la flexibilidad de Apache, sus módulos, y al mismo tiempo ahorrar recursos, podemos implementar el sistema de proxy inverso o reverse proxy. Esto podemos hacerlo empleando Nginx o Varnish.

La técnica consiste en colocar Nginx o Varnish entre el visitante y el servidor Apache de nuestra web. De esta manera el tráfico es obligado a pasar por el proxy inverso sirviendo la página de una manera menos perfeccionada y empleando menos cantidad de recursos.

Test de velocidad de carga de WordPress

La velocidad de carga de WordPress puede ser probada empleando varias herramientas. Hasta podemos experimentar en qué forma nuestro sitio maneja una situación crítica. Podemos simular una elevada carga de usuarios que llegue a causar complicaciones en la estabilidad del sitio y hasta interrupciones de servicio.

Sitios para probar la velocidad de carga de WordPress:

• GTMetrix: http://gtmetrix.com/
• PingDom Tools: https://tools.pingdom.com/

Sitios para probar la estabilidad de carga de WordPress:

• Load Impact (de pago): https://loadimpact.com/
• Apache Benchmark (incluido en Apache) https://httpd.apache.org/docs/2.4/programs/ab.html
• Loader.io (de pago con alternativa gratuita) https://loader.io/

Para finalizar

Uno de los gestores de contenido más escalables es WordPress. Es uno de los CMS más compatibles con cualquiera de los sistemas más avanzados de balanceo de carga o de cache en la web.

Además, es uno de los gestores de contenido que funcionan a la perfección en sitios web de mucho tráfico. Basta con conocer cómo funciona esta plataforma para aprovechar al máximo la capacidad y obtener los mejores resultados del servidor.

Esperamos que este artículo sobre cómo solucionar el alto consumo de recursos en WordPress, les haya resultado útil. Más información sobre este y otros temas en Ayuda Hosting.