WordPress ist ein langsames CMS

Version anglaise de mon ancien article WordPress es un CMS lento - 2014

Plus d'une fois, je me suis retrouvé au milieu du débat : WordPress est-il lent ? Eh bien, ce n’est pas vraiment un débat lorsque la seule réponse de ceux qui sont attachés à WordPress est qu’il existe des sites très visités qui l’utilisent et que leurs performances sont optimales. Ces personnes semblent oublier que même l'algorithme de tri à bulles Bubble Sort fonctionne bien pour des échantillons excessivement volumineux s'il est "exécuté" sur une machine puissante. Cependant, cela ne signifie pas qu’il s’agit nécessairement d’un algorithme efficace (ce n’est pas le cas, en fait) si l’on considère sa complexité de calcul. La même chose se produit avec WordPress. A quantité égale d’informations, il nécessitera un hébergement bien plus puissant que les autres CMS. Non seulement cela, mais comme nous le verrons, WordPress est intrinsèquement 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. Il en va de même pour le monde des CMS. En fait, bon nombre de mes projets Web sont construits avec. Cependant, chaque projet est différent et vous devez donc choisir les meilleurs outils avec sagesse et non par attachement.

Comme je suis une personne technique, mes arguments seront basés sur des aspects techniques. Surtout quand je comprends que WordPress est lent à cause de sa conception. J'invite toute personne en désaccord à laisser un commentaire avec son raisonnement.

Tableau tout-en-un

Lors de la conception d'un schéma de base de données pour un projet Web, la question se pose de savoir s'il faut privilégier l'aspect pratique ou l'efficacité. Dans le cas de WordPress, ils ont choisi l’aspect pratique et regroupé les publications, les publications personnalisées, les ressources et les versions dans un seul tableau : wp_posts. Cette action a l’avantage de simplifier le code et les recherches (bien que ce soit un autre problème avec lequel WordPress se débat, comme nous le verrons dans un autre article), mais en revanche, elle réduit considérablement l’efficacité de WordPress. Quelques exemples pour que cela soit plus clair :

• Si nous avons 500 articles, et chacun a quatre révisions différentes (l'actuelle et trois autres), c'est comme si nous avions affaire à 2 000 articles.

• Si nous avons 500 produits avec WooCommerce, et que chacun a une image vedette et quatre dans une galerie de produits, c'est comme si notre CMS devait gérer 3 000 produits.

• Si nous avons un petit site Web avec 35 pages et 35 éléments de menu, qu'il s'agisse de liens externes ou internes, notre gestionnaire de contenu fonctionnerait comme s'il y avait 70 pages puisque chaque élément de menu compte comme une entrée ou une page dans notre CMS . Cela peut sembler peu dans cet exemple, mais cela montre un autre facteur influençant les performances.

• Si vous avez 500 produits en quatre langues, votre WordPress agira comme s'il traitait 2 000 produits.

• Maintenant, passons à un exemple concret en résumé : si vous avez un site Web avec 500 produits, chacun avec une image en vedette, quatre images de galerie de produits et un PDF avec des informations techniques, et le site également a un blog avec 200 entrées, chacune avec leurs images respectives. Si votre site prend également en charge trois langues et est configuré pour autoriser seulement deux révisions par publication, WordPress doit rechercher plus de 5 500 éléments à chaque fois qu'il interroge votre base de données. J'ignore d'autres facteurs tels que les éléments de menu, les pages et les publications personnalisées. Conseil :

• Limitez le nombre de révisions à deux ou désactivez-les complètement :
  

// Limit revisions to two:
define('WP_POST_REVISIONS', 2);
// Completely disable revisions:
// define('WP_POST_REVISIONS', false);

• Supprimez toutes les révisions de temps en temps. Vous pouvez le faire en exécutant 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 économe avec les images de votre site Web. N'ajoutez pas d'images à votre CMS que vous n'utiliserez pas.

• Évitez d'avoir plusieurs menus à moins qu'ils ne soient essentiels. Supprimez les entrées de menu que vous n'avez pas l'intention d'utiliser.

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

Votre WordPress est atteint de la maladie d'Alzheimer

WordPress recherche la flexibilité à tout prix, même au détriment de la vitesse. Peut-être parce qu’à ses débuts, il ne s’agissait que d’un système de blogs, et dans ce cas, une telle flexibilité ne causerait pas beaucoup de dégâts. Cependant, lorsque nous avons commencé à l'utiliser comme CMS, des problèmes de performances causés par cette flexibilité ont commencé à surgir.

Let me give you some bad news: your content manager has Alzheimer’s. It forgets everything from one request to another. You will have to repeat each time which custom posts, sidebars, or menus you are going to use. There is no other choice because it forgets. That's why, for example, if you want to add an entry to the admin menu, you will have to tell it every time it is to be displayed. Yes, it offers enormous flexibility, but it forces PHP and the CMS to process the same thing repeatedly, resulting in a loss of efficiency. The same thing happens with plugins, which is why many plugins can significantly slow down your website. It’s not because of the plugin system itself (which is magnificently designed and programmed) but because plugins have to declare the same information repeatedly, forcing WordPress to go through them entirely with every request.

A performance-focused CMS would have done it differently. For example, by having the theme declare during activation what sidebars, custom posts, or other elements it needs. WordPress would register this information and adjust internally. The same could be applied to plugins. But, as mentioned earlier, such an approach would significantly reduce the CMS's flexibility, which is not desirable.

Tips:

• Limit the number of plugins.

• Choose minimalist themes that only have what you need.

• You might be advised to use a cache plugin; I don't. Only use one if your website is extremely slow and do so with caution. I will discuss this in another post (edit: now available: Don’t Use Cache Plugins with WordPress, but basically, it’s because you will disable all of WordPress’s internal workings based on hooks. That is, you will force WordPress to work in a way that is not intended.

Everything Always Available

As almost everyone knows, WordPress started as a blogging system based on a previous system. It wasn't designed for large projects, which is why its design leaned toward simplicity. No classes, just functions. As with any design aspect, this doesn’t have to be a bad thing (just ask those using desktops built with GTK) unless you are looking for flexibility. Then, the headaches begin.

If you come from the PHP world, you might be surprised that with WordPress, you don’t have to use "require," "include," or "namespace." This is easy to understand: WordPress always loads its entire arsenal of libraries. Yes, always, whether you use them or not. When you combine this with its memory issues, well... that's a lot of code to read with every request. But, of course, this is all for flexibility. You can use a core function without having to include a file that might change names or paths tomorrow.

Since PHP 5.6, there is full support for function namespaces. Maybe this is a solution for WordPress. But in that case, they will have to make the difficult decision of breaking backward compatibility. I don't know what they will do.

There’s nothing you can do to improve this, as it’s part of WordPress’s design. All you can do is your part: make sure your code doesn't follow this path. If you decide to do so, here are my tips:

• Create anonymous functions for "actions" that are nothing more than includes to external files where you keep your code. This way, if the action never triggers, PHP won’t have to parse all the code. Example:

add_action('admin_init', function() {
    include(__DIR__ . "/zones/panel/init.php");
});

add_action('admin_menu', function() {
    include(__DIR__ . "/zones/panel/menu.php");
});

• For widgets, shortcodes, and filters, use classes with namespaces. Also, make sure these classes are instantiated using autoloading.

// It's better to use: spl_autoload_register()

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

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

add_shortcode('block', array('misshortcodesBlock', 'load'));
//... my other shortcodes, filters, and widgets...

In summary, we have seen that WordPress's design principles are simplicity and flexibility, but in a way that sacrifices efficiency. It is essential to understand that no development tool is good for everything. If someone presents it that way, they are either misleading you or selling you a Swiss army knife that is good for nothing.

WordPress struggles with speed, but for showcase websites, this is not something to worry about. However, for websites where the business relies on the web, or for sites with a lot of traffic, alternative options should be considered. Still, if we choose WordPress for its ease of use and flexibility, we must compensate by investing in good hosting, being very careful with the selection of plugins, and using a high-quality theme tailored to our needs.

Das obige ist der detaillierte Inhalt vonWordPress ist ein langsames CMS. Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!