Y en a marre du plugin bashing !

Ça devient récurrent de taper sur WordPress sur la partie plugins. Et c’est « lent », et « c’est pas performant » et « vaut mieux le faire dans le thème ». Entre mythes et légendes, le vrai du faux d’après moi c’est ce qui suit.

🔗 Le point zéro

Est-il besoin de rappeler que le « home made » n’est pas un gage de qualité ? Apparemment oui étant donné ce qui s’est passé , excellent site par ailleurs, n’empêche que ça revient sur le tapis.

Le code parfois ça loupe, le tout est de réduire un maximum les risques d’effets de bord, incompatibilités et autres joyeuseries, les bonnes pratiques aidant pas mal l’affaire.

Dans ce cas de figure c’est assez flagrant et les commentaires n’ont pas raté l’article dans lequel s’était glissé pas mal d’oublis et d’étourderies dans un code pourtant présenté comme étant de meilleure qualité qu’avec un plugin. Mais au-delà ce débat « without a plugin », « the right way » et autres partisaneries du functions.php vs plugins — quand on est jeune on prend parti et après on comprend que rien n’est sans nuance — c’est plus les articles ultra-spécialisés performance dév qui commencent à m’agacer sérieusement.

🔗 Performance ?

Performance ? le paroxysme du troll vient avec les articles « How many », comme si au-delà d’un certain nombre ton site devenait illégal. On aura beau faire de la pédagogie — ce qui revient au final à du bon sens et des banalités comme « tout dépend de la qualité — ce débat paraît éternel, dans la lignée des Windows vs Mac vs Linux.

J’ai même eu certains clients en freelance me demandant expressément de tout faire dans le thème pour des raisons « d’optimisation » mais là ça me dérange moins de faire du conseil, quitte à répéter les mêmes choses, parce qu’au final ça fait partie du métier.

En revanche, c’est excessivement énervant de tomber sur des pseudos tests perf qui vous expliquent que ah non c’est pas bien de faire des plugins parce que ça lance des processus etc. On marche sur la tête littéralement et je vais tenter de justifier mon point de vue.

🔗 Qui dit ça ?

Qui sont ces gens et quels sont leur réseaux, enquête en eaux troubles dans les quartiers chauds de Marseille… ah non c’est autre chose lol donc je me demandais qui étaient ces gens qui établissaient des seuils sur les quantités de plugins. À votre avis s’agit-il de technocrates brussellois loin des réalités du PEUPLE ou alors de véritables pros qui osent dire tout haut une vérité qui dérange ?

🔗 Le vrai

Force est de constater que la qualité et variable, on produit tous du code de qualité variable, certains essaient de s’élever et d’autres s’en tamponnent comme de l’an 40, business is business, entre les deux une diversité de cas absolument énorme. Un écosytème est fait de ça aussi. Cette problèmatique n’est pas spécifique à WordPress mais bien à l’open source de manière générale.

🔗 Que dit Google ?

Les citations sont extraites des premiers sites que j’ai trouvé sur le sujet en mode feignasse sur Gogol :

As a general guide, we like to keep sites to under 20 plugins. A better rule of thumb is ‘less is best’

« 20 », on ne sait pas vraiment d’où ça sort, et ça tient plus de l’arbitraire qu’autre chose. Je veux bien admettre que « less is best » ou « less is more » mais l’optimisation qui consiste à refaire du code, souvent en moins bien, histoire de diminuer la quantité de plugins activés sur l’installation, c’est lunaire.

It took me years to understand that the fewer plugins we use, the better our website’s performance and load time is.

Ok donc il t’a fallu des années pour arriver à cette conclusion, pas très rassurant :P, j’aurais compris de la part de quelqu’un qui découvrirait l’univers WordPress mais après des années arriver à cette conclusion…

🔗 Techniquement parlant ?

Alors ils épiloguent, nous épiloguons et moi-même ici j’épilogue donc parlons technique un peu puisqu’il y a « dev » dans le nom de ce blog twisted

Il m’est arrivé de devoir présenter WordPress à des personnes pas du tout convaincues voir carrément hostiles et donc avec un succès variable en ce qui m’a concerné, l’expérience aidant, je soulève les bons points tout en restant lucide et honnête sur mon outil. Dans ce cas de figure, il s’agit d’être précis donc soyons-le ici.

L’idée c’est : comment je vais pouvoir prouver que WordPress n’est pas un boulet ? Ma réponse c’est tout simplement de la même façon que je prouve qu’il est sécurisé.

Va-t-il y arriver ? rolleyes

En matière de sécurité comme en matière de performance la clé c’est la maintenance. WordPress est excessivement bien maintenu par des dizaines de milliers de développeuses et développeurs à travers le monde entier et une équipe de core dév pour chapoter le tout.

Deuxième argument fort à mon sens : les sujets performance et sécurité sont condamnés à l’éternité. L’évolution est constante parce que les menaces et besoins sont en constante évolution. À l’image aussi des développeurs de cette communauté, je n’ai jamais vu personne refusant des remarques voire carrément des pull requests sur leur plugin pour améliorer la performance ou corriger une faille de sécurité. Si cela vous est arrivé c’est que vous êtes tombés sur les rares « klet pey, trous du cul de merde »(je suis pas vulgaire, je cite dikkenek tongue ) et j’en suis désolé pour vous.

De base, WordPress possède des tags conditionnels pour un chargement conditionnel de scripts et styles c’est tout à fait prévu, également dans les widgets on retrouve la même logique alors pas d’excuse ^^.

Au final c’est donc bien une question de connaissance de l’outil, et, j’ajouterais, de rigueur. Pour les développeurs de plugin c’est exactement la même chose : la clé c’est la maintenance, la pratique. La veille et la progression doivent être constantes sinon il faut faire autre chose.

3ème et dernier argument : certains sites sont des bouses immondes d’un point de vue performance et pourtant derrière y a parfois du Drupal et d’autres ressources dites « plus dév », là pareil ça ne me viendrait pas à l’idée de dire :

moins de modules, moins de problèmes

Dans ces cas-là on a même envie de dire quel gâchis, tout ça pour ça. Il n’y aurait aucun véritable sens à comparer Drupal à WordPress et pourtant certains le font. Mais quand bien-même « Drupal beats WordPress » dans le désert, la nuit par -15 dégré, au final, si c’est Jacky qui a fait le site, ou si ça roule en Twingo, ça va ramer pareil.

🔗 La fièvre du fait maison

Attention à cette maladie de dév. À vouloir tout faire soi-même, tout coder à la main, histoire de montrer à la terre entière qu’on sait faire, on finit par se fatiguer, perdre du temps sur des gadgets qui ont déjà été fait et refait, en mieux, on apporte rien, et ce n’est pas honnête à mon sens d’aller vendre ça au client.

Besoin d’un module de partage sur les réseaux sociaux ? je vous le code ce matin dans le thème

Donc tu vas mettre des heures entières à faire ça sous prétexte qu’il faut pas utiliser de plugins ? Franchement pas de temps à perdre là-dessus, mieux vaut se concentrer sur une vraie demande spécifique type « besoin de connecter mon WordPress à une API ou un CRM ».

🔗 Last but not least

La logique de WordPress c’est les plugins. L’API plugins a.k.a les hooks, c’est l’unes des plus belles trouvailles de cette communauté. Les hooks sont fait pour « pluguer » des codes, étendre WordPress, étendre => extensions.

#cqfd mrgreen

🔗 Conclusion

La clé de la performance c’est la bonne association des ressources externes et internes au projet, les bonnes pratiques de code dans le thème et les plugins maison, MAIS aussi la bonne infrastructure quand les besoins sont importants, le cache… Rien ne peut se résumer à une formule toute faite ou à un chiffre dans nos métiers c’est même probablement un contresens.