WordPress est un CMS lent

Cet article a été initialement publié en 2014 dans WordPress est un CMS lent - 2014

Plus d’une fois, je me suis retrouvé impliqué dans le débat : WordPress est-il lent ? Eh bien, ce n'est pas vraiment un débat quand la seule réponse de ceux qui sont attachés à WordPress est qu'il existe des sites avec de nombreuses visites qui l'ont et que leurs performances sont optimales. Eux-mêmes semblent oublier que même l’algorithme de tri à bulles se comporte bien pour des échantillons excessivement volumineux s’il est « exécuté » sur un ordinateur puissant. Cependant, cela ne signifie pas qu’il s’agit nécessairement d’un algorithme efficace (en fait, ce n’est pas le cas) si l’on considère sa complexité de calcul. La même chose arrive à WordPress. Pour une même quantité d’informations, il nécessitera un hébergement bien plus puissant que les autres CMS. Non seulement cela, mais comme nous le verrons, c'est déjà un CMS lent, qu'il contienne ou non beaucoup d'informations.

Cela ne veut pas dire que WordPress est mauvais. Rien ne pourrait être plus éloigné de la vérité. Tout comme dans une voiture, la vitesse ne fait pas tout. La même chose se produit dans le monde des CMS. En fait, une grande partie de mes projets web vont avec. Cependant, chaque projet est différent et il faut donc savoir choisir les meilleurs outils de manière appropriée avec sa tête et non avec attachement.

Comme je suis une personne technique, mes arguments se baseront sur des aspects techniques. Surtout quand je comprends que WordPress est lent à cause de sa conception. J'invite tous ceux qui ne sont pas d'accord à me laisser un commentaire avec leur raisonnement.

Tout dans un seul tableau.

Lorsque nous créons un schéma de base de données pour un projet Web, la question se pose de savoir s'il faut opter pour le pratique ou l'efficace. Dans le cas de WordPress, ils ont opté pour la praticité et regroupé les posts, les posts personnalisés, les ressources et les versions dans un même tableau : wp_posts. Cette action a l’avantage de simplifier le code et les recherches (même si c’est une autre chose qui manque à WordPress comme nous le verrons dans un autre article), mais en revanche elle réduit drastiquement l’efficacité de WordPress. Quelques exemples pour comprendre :

• Si nous avons 500 posts et que chacun a quatre avis différents (l'actuel et trois autres), c'est comme si nous avions affaire à 2 000 posts.

• Si nous avons 500 produits avec Woocommerce et que chacun a une image vedette et quatre comme galerie de ce produit, c'est comme si notre CMS devait fonctionner avec 3 000 produits.

• Si nous avons un petit site Web de 35 pages et que nous y avons environ 35 éléments de menu, avec des liens externes ou internes. Notre gestionnaire de contenu fonctionnerait comme si nous avions 70 pages. Puisque chaque élément de menu compte comme s’il s’agissait d’une entrée ou d’une page dans notre CMS. Dans cet exemple, ce n'est pas grand-chose, mais je l'ai mis pour que vous puissiez voir un autre des facteurs d'influence.

• Si vous avez 500 produits et quatre langues, votre WordPress est comme s'il fonctionnait sur 2 000 produits.

• Passons maintenant à un exemple réel en guise de résumé : Si vous avez un site Web avec 500 produits et pour chacun d'eux vous avez également une image vedette, quatre images de galerie de produits et un pdf avec les informations techniques de chaque produit. . De plus, ce site dispose également d'un blog avec 200 entrées chacune avec leurs images en vedette correspondantes. De plus, si vous avez créé le site Web avec un support en trois langues et en établissant qu'il n'y a que deux avis par publication. Chaque fois que WordPress lance une requête sur votre base de données, il doit effectuer une recherche parmi plus de 5 500 éléments. Je méprise les autres comme les éléments de menu, les pages et les publications personnalisées. Conseils :

• Limiter le nombre d'avis à deux ou désactiver complètement les avis :
  

    //Limita las revisiones a dos:
    define( 'WP\_POST\_REVISIONS', 2 );
    //Desactiva totalmente las revisiones:
    //define( 'WP\_POST\_REVISIONS', false );

• Supprimez toutes les révisions de temps en temps. Vous pouvez le faire en lançant la requête SQL suivante :

    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'

• Soyez austère avec les images de votre site internet. N'ajoutez pas non plus d'images à votre CMS que vous n'allez pas utiliser.

• Évitez d'avoir une multitude de menus s'ils ne sont pas indispensables. Supprimez les entrées de menu que vous n’allez pas utiliser.

• Si vous n'avez pas d'autre choix, parce que votre client insiste, que d'utiliser WordPress pour des projets de moyenne ou grande taille, essayez de créer des tables auxiliaires et ainsi alléger au maximum la charge des wp_posts

Votre WordPress a la maladie d'Alzheimer

WordPress recherche la flexibilité à tout prix, même au détriment de la vitesse. Peut-être parce qu'au début, il ne s'agissait que d'un système de blog et que dans ce cas, une telle flexibilité ne pouvait pas causer autant de dégâts. Cependant, nous avons commencé à l'utiliser comme CMS et c'est à ce moment-là que les problèmes de performances causés par la flexibilité ont commencé.

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. WordPress 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 no les 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.

Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!