WordPress es un CMS lento

Este post ya fue publicado inicialmente en 2014 en WordPress es un CMS lento - 2014

Más de una vez me he encontrado envuelto en el debate: ¿ es WordPress lento ?. Bueno, no es tanto debate cuando la única respuesta por parte de aquellos apegados a WordPress es que hay sitios con muchas visitas que lo tienen y su rendimiento es óptimo. Estos mismos parece que se olvidan que hasta el algoritmo de ordenación de burbuja se comporta bien para muestras excesivamente grandes si se "ejecuta" en un equipo potente. Sin embargo, eso no quiere decir que sea un algoritmo eficiente necesariamente (de hecho, no lo es) si atendemos a su complejidad computacional. A WordPress le pasa lo mismo. A igualdad cantidad de información, requerirá un hosting mucho más potente que otros CMS. No sólo eso, sino como veremos, ya de por si es un CMS lento tenga o no tenga mucha información.

Esto no quiere decir que WordPress sea malo. Nada más lejos de la realidad. Igual que en un coche, la velocidad no lo es todo. En el mundo de los CMS pasa lo mismo. De hecho, gran parte de mis proyectos webs son con él. Sin embargo, cada proyecto es un mundo y, por tanto, hay que saber escoger las mejores herramientas adecuadamente con la cabeza y no con el apego.

Como soy una persona técnica, mis argumentos estarán basados en aspectos técnicos. Sobre todo cuando entiendo que WordPress es lento debido a su diseño. Invito a todos aquellos que no estén de acuerdo que me pongan un comentario con sus razonamientos.

Todo en una tabla.

Cuando estamos realizando un esquema de base de datos para un proyecto web, surge la duda si ir por lo práctico o por lo eficiente. En el caso de WordPress tiraron por lo práctico y agruparon tanto los posts, como custom posts, como recursos y versiones en una misma tabla: wp_posts. Esta acción tiene la ventaja de simplificar el código y las búsquedas (aunque esto sea otra cosa de la que cojea WordPress como ya veremos en otra entrada), pero como contraparte reduce drásticamente la eficiencia de WordPress. Algunos ejemplos para que se entienda:

• Si tenemos 500 posts y cada uno tiene cuatro revisiones diferentes(la actual y tres más), es como si tuviéramos tratando con 2.000 posts.

• Si tenemos 500 productos con Woocommerce y cada uno tiene una imagen destacada y cuatro como galería de ese producto, es como si nuestro CMS tuviera que trabajar con 3.000 productos.

• Si tenemos un sitio web pequeño con 35 páginas y en él tenemos unos 35 elementos de menús,ya sea, con enlaces externos o internos. Nuestro gestor de contenidos trabajaría como si tuviéramos 70 páginas. Ya que cada elemento de menú cuenta como si fuera una entrada o una página en nuestro CMS. En este ejemplo eso no es mucho, pero lo pongo para que se vea otro de los factores que influye.

• Si tienes 500 productos y cuatro idiomas, tu WordPress es como si trabajara 2.000 productos.

• Ahora vamos a un ejemplo real a modo de resumen: Si tienes un sitio web con 500 productos y por cada uno de ellos también tienes una imagen destacada, cuatro imágenes de galería de producto y un pdf con información técnica de cada producto. Además, ese sitio también tiene blog con 200 entradas cada cual con sus correspondientes imágenes destacadas. Además, si has hecho el web con soporte a tres idiomas y estableciendo para que sólo haya dos revisiones por post. WordPress cada vez que lanza una consulta contra tu base de datos, ha de buscar entre más de 5.500 elementos. Desprecio otros como elementos de menú, páginas y custom posts. Consejos:

• Limita el número de revisiones a dos o desactiva las revisiones completamente:
  

    //Limita las revisiones a dos:
    define( 'WP_POST_REVISIONS', 2 );
    //Desactiva totalmente las revisiones:
    //define( 'WP_POST_REVISIONS', false );

• Borra todas las revisiones de vez en cuando. Puedes hacerlo lanzando la siguiente consulta sql:

    DELETE a,b,c FROM wp_posts a
    LEFT JOIN wp_term_relationships b ON (a.ID = b.object_id)
    LEFT JOIN wp_postmeta c ON (a.ID = c.post_id)
    WHERE a.post_type = 'revision'

• Se austero con las imágenes en tu sitio web. Tampoco añadas a tu CMS imágenes que no vayas a utilizar.

• Evita tener multitud de menús si no son imprescindible. Elimina entradas de menús que no vayas a usar.

• Si no te queda otra, porque así lo insiste tu cliente, que usar WordPress para proyectos medianos o grandes, trata de crear tablas auxiliares y así aligerar en lo posible la carga de wp_posts

Tu WordPress tiene alzheimer

WordPress busca la flexibilidad a cualquier precio, aunque sea a costa de velocidad. Quizás, porque en los principios sólo iba a ser un sistema de blogs y para ese caso tanta flexibilidad no podría causar tanto daño. Sin embargo, empezamos a usarlo como CMS y ahí empezaron los problemas de rendimiento ocasionados por la flexibilidad.

Déjame decirte una mala noticia: tu gestor de contenidos tiene alzheimer. Se le olvida todo de una petición a otra. Tendrás que repetirle en cada una de ellas los customs posts, los sidebars, o los menús que vas a usar. No te queda otra porque a él se le olvida. Es por ello, que si quieres añadir una entrada al menú del panel, por ejemplo, se lo tendrás que decir cada vez que se vaya a mostrar. Sí, da una enorme flexibilidad pero obliga a PHP y al CMS a procesar lo mismo una vez y otra vez, dando lugar a una perdida de eficiencia. Lo mismo le pasa a los plugins y es por ello que muchos plugins pueden ralentizar sobremanera tu sitio web. No por el sistema de plugins en sí ( que es magnifico como está pensado y programado ), sino por la obligación de los plugins de decir lo mismo una y otra vez y, por tanto, la necesidad de WordPress de recorrerlos completamente en cada petición.

Un CMS enfocado al rendimiento lo hubiera hecho de otra manera. Por ejemplo, haciendo que durante la activación del tema éste dijera que sidebars, custom posts o cualquier otro elemento necesita. Este CMS lo registraría y se ajustaría adecuadamente de manera interna. Y lo mismo para los plugins. Pero, como digo anteriormente, un proceder así restaría mucha flexibilidad al CMS, algo que a WordPress no le interesa.

Consejos:

• Limita el número de plugins

• Escoge temas minimalistas o que sólo tengan lo que necesites

• Te recomendarán que uses un plugin de caché, yo no. Úsalo sólo en el caso que tu sitio web vaya extremadamente lento y siempre con pinzas. Hablaré de ello en otra entrada (edit: ya está disponible: No uses plugins de caché con WordPress , aunque básicamente es porque cortarás todo el funcionamiento interno de WordPress basado en hooks. Es decir, forzarás a trabajar a WordPress de una manera, que como hemos visto, no es la que han decidido para él.

Todo siempre a tu disposición

WordPress, como casi todo el mundo sabe, empezó como un sistema de blogs que se basaba en otro sistema anterior. No estaba pensado para proyectos grandes es por eso que su diseño tendió a lo simple. No clases, sólo funciones. Como cualquier aspecto de diseño, eso no tiene que ser algo necesariamente malo (sino que se lo digan a los que usan escritorios realizados con GTK), a no ser que busques la flexibilidad. Entonces, es cuando empiezan los dolores de cabeza.

Si vienes del mundo PHP, seguramente te sorprendas que con WordPress no has tenido ni que hacer requires, ni includes ni usar namespace. Es algo sencillo de entender, el motivo es que WordPress siempre carga todo su arsenal de librerías. Sí, siempre, las uses o no. Si lo sumamos a que tiene alzheimer, uff. Líneas de código que se tienen que leer si o si en cada petición. Un pasote. Pero, claro, piensa que es por la flexibilidad. Puedes usar una función del core sin tener que hacer un include a un fichero que puede que el día de mañana tenga otro nombre o esté en otro path.

A partir de PHP 5.6 hay soporte completo de namespace de funciones. Quizás esa sea una solución para WordPress. Pero en ese caso tendrán que tomar la difícil decisión de crear incompatibilidad hacia atrás. No sé lo que harán.

Nada puedes hacer para mejorar esto, ya que es parte del diseño de WordPress. Tan sólo te queda hacer tu parte, es decir, que tu código no siga esa línea. Si te decides a hacerlo, aquí mis consejos:

• Crea funciones anónimas para los "actions" y que no sean más que un include a ficheros externos dónde tengas tu código. Así, si esa acción no llega nunca a lanzarse tampoco PHP tendrá que parsear todo el código. Ejemplo:

    add\_action('admin_init', function() {
        include(__DIR__."/zonas/panel/init.php");
    });

    add\_action('admin_menu', function() {
        include(__DIR__."/zonas/panel/menu.php");
    });

• Para widgets, shortcodes y filtros, usa clases con namespace. Además, que estás clases se instancien mediante autocarga.

    //Recomendable usar mejor: spl_autoload_register() 

    function __autoload($classname) {
        $file = str_replace('', DIRECTORY_SEPARATOR, $classname);

        include_once(BASE_PATH.$file.'.php');
    }

    add_shortcode( 'block', array('misshortcodesBlock', 'load') );
    //...mis otros shortcodes, filtros y widgets, ....

Como resumen, hemos visto que WordPress tiene como principios de diseño a la simplicidad y flexibilidad, pero de una forma que le resta eficiencia. Hay que pensar que ninguna herramienta de desarrollo es buena para todo. Si alguien te lo presenta así es porque te está engañando o te vende una navaja suiza que no sirve para nada. WordPress cojea en su velocidad, pero para sitios webs escaparates es algo que no hay que darle mayor importancia. Para sitios en los que el negocio es la web se debería de plantear otras alternativas. Lo mismo para sitios con bastante tráfico. Si aún así queremos WordPress por su facilidad de uso y flexibilidad hemos de saber que habremos de compensarlo con un buen alojamiento, mucho cuidado con la selección de plugins y un tema de calidad y ajustado a nuestras necesidades.