Here With Me

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

10 novembre 2014
par Amaury
4 Commentaires

Et paf ! Une nouvelle version de Simple Tags…

Profitant de quelques heures de temps libre, j’ai publié la version 2.4 de mon plugin Simple Tags.

Au programme du changelog :

  • Test OK vs WP 4.0.x
  • Fix Yahoo terms suggestion (use new API)
  • Fix conflict with ShareThis plugin
  • Add option for autolink title attribute
  • Add current state for « click tags » feature (opacity changed if tags is already selected)
  • Fix order by tag cloud
  • Implement dataTXT provider for suggest terms feature (from Github contribution SpazioDati/master)
  • Implement Tag4Site provider for suggest terms feature (from Sergey Zobin)
  • Fix shortcode usage with &
  • Add support of category name into tag cloud function

Bon il n’y a clairement rien d’extraordinaire, quelques providers en plus pour la suggestion automatique de termes, quelques corrections de bug.. Bref du grand classique !

Pour ma part, j’ai longtemps cru que je n’allais jamais plus publier de nouvelles versions de ce plugin tant les retours des usagers sont extrêmement variés en positif comme en négatif. Et puis j’ai reçu 2 pull request de 2 développeurs différents pour ajouter des fonctionnalités au plugin… alors j’ai décidé de publier une nouvelle version !

En critique récurrente, je note des utilisateurs se plaignant du manque de nouvelles versions, voir du manque de support de l’auteur du plugin… J’ai donc profité de cette mise à jour pour notifier 3 informations aux utilisateurs de ce plugin :

  1. Je ne propose aucun support pour cette extension open-source
  2. Je ne réalise aucun support sur le forum de WP.org
  3. J’accepte les reports de bugs sur le tracker de Github si ces derniers sont détaillés (code à l’appui/message d’erreur).

Quand on y en pense, ce n’est pas facile tout les jours de proposer une extension open-source à la communauté…

8 septembre 2013
par Amaury
50 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
12 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.