Here With Me

Le blog technique d'Amaury Balmer qui parle de technologies open-source, mais surtout de WordPress !

8 septembre 2013
par Amaury
46 Commentaires

Stress test de l’extension WP Rocket

1x1.trans Stress test de lextension WP RocketCe test a été réalisé sur la version 1.0 de WP Rocket, certaines critiques émises dans cet article sont désormais obsolètes.

Difficile exercice que de faire le test d’une extension WordPress, développée par des personnalités éminentes de la communauté française. (Xavier me dirait : diplomatie, diplomatie…)

Je me lance tout de même dans l’aventure…

Après avoir lu beaucoup d’articles dédiés à l’extension (dont beaucoup s’apparentent davantage à la de publi-information qu’à une véritable analyse), j’ai profité d’une promo sur Twitter pour acquérir une licence « professionnelle » et j’ai testé l’extension sur une plateforme de développement ainsi que sur 2 projets en phase de production pour me forger MON opinion.

Voici le premier article de la série stress test d’un plugin WP !

La promesse cliente

WP-Rocket est une extension pour WordPress qui a comme vocation d’améliorer les performances de votre site internet. C’est une extension « premium », vendue sous 3 licences : personnelle, business et professionnelle.

Les fonctionnalités proposées sont :

  • Mise en cache des pages
  • Préchargement du cache
  • Compression des fichiers statiques
  • Chargement différé des images
  • Optimisation pour le navigateur
  • Optimisation des images
  • Chargement différé des fichiers JavaScript

Juste que là, c’est du très classique on retrouve ni plus ni moins que tous les ingrédients de la « performance web ».

Mais la vraie promesse cliente du plugin à mes yeux, c’est « une configuration rapide ».

Dans l’univers des plugins WordPress, on trouve des centaines d’extensions ayant comme objectif d’améliorer la performance web d’un site internet, et ces extensions partagent systématiquement le même point commun : elles sont complexes et proposent des tonnes d’options. Et le pire, c’est que ces options ne sont utilisées que par une minorité de personnes.

WP Rocket, à l’image de l’extension WYSIJA, mise sur le côté simple, rapide et pédagogique de leur extension. (un principe de base de la philosophie WP : Décisions, not options)

Et de ce côté, on est très bien servi ! L’interface est extrêmement propre, les réglages de base permettent d’activer facilement les fonctionnalités principales de l’extension.

A noter qu’il ne semble pas possible de désactiver le cache statique, donc impossible de n’utiliser que les fonctionnalités de minification ou de chargement différé des images.

Analyse technique

La question que l’on peut se poser face à une extension qui promet d’améliorer la performance, c’est comment ? Quels mécanismes sont mis en place ? Les voici en détails

Cache statique

LA fonctionnalité la plus répandue pour améliorer la performance d’un site WordPress, c’est d’installer et configurer un cache statique. Le principe est simple, le premier visiteur consulte une page de votre site, le code HTML est généré dynamiquement par WP et il est stocké dans le cache pour une durée définie, les visiteurs suivants consultent alors la copie HTML.

Sur ce point, le plugin est très classique, les fichiers de cache sont stockés sur le système de fichiers (dans le dossier wp-rocket-cache), ce choix exclut « en grande majorité » les architectures multi-serveurs (rare c’est vrai). A noter, que le cache peut être différencié pour les mobiles, ceci afin de permettre l’utilisation de thème spécifique. (WP-Touch notamment)

Ma grande surprise concernant le cache statique et WP Rocket, c’est la non-utilisation  du « drop-in » advanced-cache.php. Ce fichier, que l’on trouve généralement dans le dossier wp-content pour peu que votre installation WP utilise un plugin de cache statique « traditionnel » permet de gérer la fonctionnalité de cache statique assez tôt dans l’exécution de WordPress.

Ici, point de dropin advanced-cache.php, le plugin utilise exclusivement les règles de réécritures (automatiquement ajouté dans le fichier .htaccess) pour permettre au serveur HTTP de charger les copies HTML en cache sans solliciter WordPress, ni PHP. C’est la technique la plus performante, mais elle requiert l’utilisation du serveur HTTP Apache2, cela veut dire que si votre serveur web est NGINX, ou bien Microsoft IIS, le plugin ne sollicitera jamais le cache statique généré.

Il faut donc prévoir le fait que « WP-Rocket » apporte des restrictions supplémentaires par rapport aux prérequis de WordPress. Ce qui est dommage, c’est qu’il est techniquement possible de cumuler les 2 fonctionnalités, c’est notamment ce que réalise l’extension WP-Super-Cache, elle propose de servir les fichiers directement avec le serveur HTTP, et à défaut elle utilise le dropin pour charger la copie en cache un peu plus tard dans le processus.

LazyLoad

La technique LazyLoad permet de différer le chargement des images, pour résumé, seules les images affichées réellement sur l’écran de vos internautes sont téléchargées. Les images présentes en base de page ne seront téléchargées que si l’utilisateur scroll dans son navigateur et affiche cette partie du site.

La fonctionnalité agit uniquement sur le contenu des articles/pages, les widgets, les images à la une et les avatars. A noter que le code JS nécessaire pour cette fonctionnalité est ajouté automatiquement dans le code HTML de votre page afin d’éviter de charger une ressource supplémentaire.

Concaténation & Minification des JS/CSS

La concaténation et la minification des ressources JavaScript et des feuilles de style CSS permettent de diminuer le nombre de requêtes HTTP nécessaires à l’affichage d’une page internet. Le plugin fait appel à la librairie PHP « minify », également utilisé par le plugin WP-Minify/BWP-Minify.

C’est donc une valeur sûre en terme de technologie, par contre on ne peut être que déçu que ce script ne génère pas de vrais fichiers CSS/JS comme peut notamment le faire AssetsMinify ou W3 Total Cache.

Les requêtes vers les ressources JS/CSS font systématiquement appel à une ressource PHP, moins performante et qui peut s’avérer problématique  lors de la mise en place d’un CDN notamment.

Compression, expiration des ressources statiques

Le plugin affine largement la configuration du serveur web HTTP Apache2 (via le fichier .htaccess) en redéfinissant les propriétés de mise en cache, de compression des ressources statiques, etc. Cela permet notamment de spécifier que les ressources JS/CSS doivent être mises en cache par les navigateurs pour une durée définie, et non rafraichies à chaque visite de la page.

Les règles ajoutées sont très répandues sur la toile, on peut notamment les retrouver dans le starter-kit de référence HTML5 Boilerplate.

Divers

Enfin, je passe très rapidement sur les autres fonctionnalités de l’extension que je considère comme mineure ou comme trop « avancée » :

  • Cookie de 3 minutes pour les personnes ayant posté un commentaire
  • JavaScript avec l’attribut « deferred » + utilisation du script LABjs
  • Suppression des numéros de version dans les ressources JS/CSS, notamment s’il s’agit du numéro de version de WP
  • Spécification systématique des dimensions des images

La spécificité du projet et de l’extension : Le préchargement

Une fonctionnalité intéressante du projet, c’est le préchargement du cache. Au lieu de laisser vos visiteurs patienter lors de la génération des copies HTML et leur mise en cache, le plugin sollicite un robot qui parcourt pour vous les pages les plus visitées de votre site pour précharger le cache.

Notez que ce n’est pas une fonctionnalité exclusive à ce projet, le plugin WP Super Cache propose déjà la même chose. (le côté complexe et mystique en plus)

La différence, c’est que le robot n’est pas intégré au plugin, le robot fonctionne depuis les serveurs de WP-Rocket et ce choix technique est contestable à mes yeux pour plusieurs points :

  • Confidentialité, un robot de cette nature fournit indirectement des données concernant l’activité d’un site internet
  • Confidentialité, la présence du robot indique aux auteurs l’existence d’un site
  • Restriction d’utilisation, notamment dans la cadre d’un site intranet, sans domaine public
  • Restriction d’utilisation, notamment si le site est protégé par une authentification

Alors effectivement, dans la cadre d’un site personnel, d’un site de TPE/PME, ça peut sembler assez anodin. Mais en entreprise, ma cible préférée pour WP, c’est clairement un mode de fonctionnement rédhibitoire. Par ailleurs, la fonctionnalité n’est pas désactivable…

Dans le même thème, l’obligation de déclarer chaque site utilisant le plugin via le site officiel est quelque chose d’assez contraignant. Sur ce point, le mode de fonctionnement de la licence GravityForms est bien plus pratique.

Benchmark : Avant/Après ?

Pour être tout à fait honnête, j’avais initialement prévu d’afficher les notes GTmetrix avant et après.Mais je suis revenu sur ma décision car l’impact de l’extension sur les performances d’un site WordPress dépend d’un trop grand nombre de paramètres, notamment :

  • L’hébergement, le plugin peut très bien fonctionner chez un prestataire A, et avoir un effet quasiment nul chez un prestataire B, notamment s’il manque des modules Apache2…
  • Le projet, le thème et les extensions utilisés, le plugin fonctionne parfaitement avec une installation fraiche, mais il peut générer des conflits JS important sur les thèmes premiums ou les projets « complexes »…

Personnellement, j’ai rencontré des problèmes de minification sur les 2 sites de production que j’ai testé, et une fois les problèmes résolus (ou plutôt contourné) j’ai constaté une baisse de la notation GTmetrix, malgré une amélioration de l’impression de fluidité…

Mais tout cela n’est guère étonnant car ces projets n’ont pas été bâtis autour de cette extension, il n’est donc pas anormal de rencontrer des conflits de cette nature…

En conclusion de ce chapitre, je pense que le benchmark comparatif de la performance des plugins de cache est possible, mais il ne reflète absolument pas le niveau de performance que vous allez pouvoir obtenir sur votre installation.

Par expérience, selon les projets et les plugins utilisés, j’obtiens parfois de meilleurs résultats avec Hyper-Cache, et parfois c’est WP-Super-Cache qui fait des merveilles…

Faut-il passer son chemin ?

C’est une question très compliquée et la réponse varie selon moi d’après votre niveau technique et l’environnement technique de votre projet.

On peut déjà éliminer WP-Rocket dans les situations suivantes :

  • Utilisation d’un serveur web exotique NGINX, Cherokee, Microsoft IIS
  • Utilisation d’un reverse-proxy avec Varnish ou autre (bien que compatible)
  • Architecture multi-serveur, car le cache aura davantage sa place dans un cache objet (cf Batcache)
  • Projet d’intranet

Dans ce type d’environnement, vous n’utiliserez pas 100% des fonctionnalités de WP-Rocket et d’autres solutions sont à considérer à mon avis.

Ensuite…

Si vous êtes fauchés/radins/amateurs des logiciels libres et que vous êtes un bidouilleur :
ou
Si vous êtes un professionnel/développeur WP :

Passez votre chemin, et installez le jeu d’extensions suivant

  • LazyLoad
  • WP Super Cache ou HyperCache
  • BWP Minify
  • + fichier HTACCESS optimisé en s’inspirant des règles de HTML5 Boilerplate

Vous obtiendrez un périmètre fonctionnel très proche de WP-Rocket, des plugins interchangeables et un niveau de performances comparable.

Si vous n’aviez rien compris à cet article, que vous n’êtes pas un bidouilleur ou que vous n’avez tout simplement pas de temps à investir dans la performance web :

Vous devriez probablement ouvrir un blog sur WordPress.com ou à défaut prendre une licence WP-Rocket car, et c’est ma conclusion, WP-Rocket ce n’est pas simplement une extension de plus à installer, c’est également un service de support (gratuit le temps de la licence – 1 an) pour vous assister à la bonne mise en place de la solution.

Pour avoir fait un tour rapide dans le forum de support, on constate qu’une extension de cette nature génère beaucoup de discussion, car chaque installation est unique et les bugs rencontrés sont à gérer au cas par cas.

Et donc même si je ne partage pas l’ensemble des choix techniques réalisés, et que je préfère une solution composée de différentes extensions, je tiens juste à tirer mon chapeau pour le travail de support que réalise les auteurs de cette belle et prometteuse extension.

Ma wishlist

Assez courte :

  • Support de advanced-cache.php
  • Documentation élargie au serveur HTTP Nginx
  • Robot de préchargement, en local ou à distance (au choix)
  • Amélioration du moteur de minification
    • Notamment le filtre d’exclusion, qui exclut bien le JS de la minification mais qui le déplace tout de même dans l’entête de la page :(
    • Utilisation de AssetsMinify ?
  • Suppression du contrôle de licence en mode GravityForms (utilisé pour les MAJ)
About   Twenty Thirteen

9 mars 2013
par Amaury
11 Commentaires

Ce à quoi pourrait ressembler WordPress 3.6

Ça travaille dur dans la communauté pour améliorer encore et toujours notre CMS préféré ! J’ai évoqué les nouveautés de la version 3.6 dans un précédent billet, mais depuis certaines fonctionnalités ont été reportées (workflow de publication), et d’autres modifications ont été annoncées.

C’est notamment le cas de l’apparence de WordPress, aussi bien coté public avec un nouveau thème « Twenty Thirteen » que la console d’administration avec peut-être un restylage.

Twenty Thirteen est un thème orienté blog, avec l’accent mis sur les posts formats.

1x1.trans Ce à quoi pourrait ressembler WordPress 3.6

 

Concernant la console d’administration, un projet d’évolution est disponible sous la forme d’une extension nommée MP6. À ce stade, rien ne garantit que cette évolution de l’interface soit intégrée dans le projet, c’est une extension « laboratoire ». Tous les détails sur le blog make UI.

1x1.trans Ce à quoi pourrait ressembler WordPress 3.6 1x1.trans Ce à quoi pourrait ressembler WordPress 3.6 1x1.trans Ce à quoi pourrait ressembler WordPress 3.6

8 janvier 2013
par Amaury
2 Commentaires

Premières orientations pour WordPress 3.6

Je trouve que la plateforme Make WordPress commence vraiment à bien fonctionner !

Cette plateforme de blogs, utilisant le thème collaboratif P2, donne une vraie visibilité pour les évolutions de chaque thématique du projet dont le core, l’UI, les plugins, les thèmes, l’internationalisation, l’accessibilité, etc.

Et c’est grâce à cette plateforme, que je peux vous énoncer la liste des chantiers envisagés  pour cette prochaine version :

  1. Refonte de l’interface des formats d’articles
  2. Refonte des fonctionnalités de sauvegarde automatique et verrouillage lors de l’édition des contenus
  3. Refonte du workflow de publication
  4. Refonte de l’interface des révisions
  5. Refonte de l’interface des menus

Autrement dit, pas de nouveauté majeure, mais simplement la modernisation des fonctionnalités existantes du CMS. Cela est une très bonne chose concernant le workflow de publication dont l’API existante n’est pas forcément très fonctionnelle.

Si vous voulez contribuer à WordPress, n’attendez plus ;)

14 décembre 2012
par Amaury
76 Commentaires

WordPress 3.5 : Plus de JavaScript dans la console d’administration

Si vous faites partie de ces personnes pressées d’avoir fait la mise à jour vers WordPress 3.5, il se peut que le JavaScript ne fonctionne plus dans la console d’administration.

Les symptômes sont les suivants :

  • Les menus déroulants ne fonctionnent plus
  • Les fonctionnalités de glisser/déposer non plus
  • Impossible d’ajouter un média
  • Etc.

Le problème est actuellement étudié par l’équipe de développement, cf ce ticket, mais il existe une solution simple, c’est de tout simplement désactiver la concaténation des JavaScript dans le back-office.

Pour y parvenir, il faut ajouter la ligne suivante dans votre fichier de configuration :

define('CONCATENATE_SCRIPTS', false);

Comme indiqué dans la page du codex détaillant les possibilités du fichier wp-config.php.

Une origine du problème pourrait également être un fichier .htaccess trop restrictif, je vous conseille de lire cet article si vous utilisez le firewall Jeff Starr’s .htaccess ou le plugin BulletProof Security.

14 septembre 2012
par Amaury
17 Commentaires

Tester rapidement et efficacement un hébergement pour WordPress : phpwpinfo()

À chaque nouveau projet à BeAPI c’est la même chose, on conçoit un nouveau site, on le développe, on le teste, et puis vient le moment fatidique où il faut le mettre en ligne.

Généralement, nos clients travaillent avec un prestataire « infogérant » ou leur DSI et c’est là que les complications arrivent.

Il faut dans un premier temps fournir les prérequis nécessaires à WordPress, et ensuite il faut vérifier que ces prestataires aient bien faire leur job.(chose qui arrive assez rarement !)

Il faut alors parcourir de façon méthodique le PHPinfo() et les variables MySQL afin de s’assurer que tout est correctement configuré !

Pour ma part, je vérifie plus de 50 points différents qui touchent les sujets suivants :

  • Configuration Apache
  • Modules Apache
  • Configuration PHP
  • Extensions PHP
  • Configuration de MySQL
  • Envoi d’emails

Ayant constaté le côté méthodique et répétitif de la chose, j’ai décidé de faire un script PHP dédié à ces tests. Il s’appelle donc phpwpinfo, c’est open-source et sur Github.

1x1.trans Tester rapidement et efficacement un hébergement pour WordPress : phpwpinfo()

Aperçu de phpwpinfo

Le test couvre beaucoup plus de points que les 2 prérequis de base de WordPress (Version 5.2 de PHP et 5.0 de MySQL)

Il permet globalement de s’assurer que WordPress va bien tourner, en ayant mis toutes les chances de son côté, en ce qui concerne les optimisations PHP, MySQL et HTTP.

C’est un projet libre, je ne pense pas avoir couvert tous les tests possibles, c’est pourquoi j’attends avec impatience les premiers « pull request » dans Github afin de parfaire l’outil.

Bon test !