GTMetrix a revu certains critères depuis mon dernier article sur le sujet, et donc la dernière optimisation de ce blog, le rétrogradant ainsi de 93% à 85%.
En clair, et de façon optimiste, GTMetrix nous propose de nouveaux conseils pour encore améliorer nos sites Web. Chouette !
Voyons donc comment relever cette note en suivant les nouvelles préconisations.
Chargement asynchrone des scripts
GTMetrix préconise le chargement asynchrone des scripts JavaScript, c’est-à-dire qu’ils sont téléchargés depuis le serveur en parallèle et plus les uns après les autres, tout en conservant l’ordre d’interprétation de ceux-ci.
En clair, ce principe évite d’avoir à attendre que le premier script soit chargé pour récupérer le deuxième.
Le paramètre Embed type de la page Minify de W3 Total Cache permet d’activer le chargement asynchrone et de définir la façon de procéder.
J’ai choisi ‘Non-blocking using async‘.
L’encodage
Une des nouvelles préconisations consiste à ne plus fournir l’encodage des pages Web directement dans le code HTML mais dans l’en-tête de la réponse HTTP de la page. Bien sûr, cela dépend de la façon de faire de votre thème.
Pour corriger ce point le cas échéant, il est d’abord nécessaire de supprimer la définition de l’encodage dans le fichier header.php de votre thème enfant, c’est-à-dire la ligne qui ressemble à ceci :
<meta charset="<?php bloginfo( 'charset' ); ?>" /> |
Et activer la définition de l’encodage dans l’en-tête HTTP, en ajoutant ce code au fichier functions.php :
// Définit l'encodage dans l'en-tête HTTP de toutes les pages du site function addHeaderContentType() { header("Content-type: text/html; charset=" . strtolower(get_bloginfo("charset"))); } add_action("send_headers", "addHeaderContentType"); |
Le gain : on passe de 87% à 90%
Passage de la Google font en local
Cette action n’a rien à voir avec les nouvelles préconisations, mais je profite de m’y remettre pour améliorer le point.
Mon thème utilise une police disponible sur Google Fonts qui s’appelle Oswald. Le principe de ces polices est qu’elles prennent la forme d’un fichier CSS hébergé chez Google. Et malgré le fait que le fournisseur de ce service soit à l’origine des préconisations d’optimisation pour un Web meilleur, ces dites polices ne possèdent pas de mention d’expiration ou de validation de cache. Un comble !
Ainsi pour la minifier et profiter de la connexion keep alive et du cache déjà mis en place, j’ai choisi de copier localement le code de la feuille de styles.
Pour cela, il suffit de copier le code contenu dans la feuille de styles de la police, ici http://fonts.googleapis.com/css?family=Oswald&v2,au début du fichier style.css de votre thème enfant, idéalement avant la commande @import.
Ensuite, il est nécessaire d’indiquer au thème parent de ne plus inclure la feuille de styles depuis le serveur de Google.
// Enlève le CSS de la police de Google Font pour l'inclure manuellement dans style.css function dequeueGoogleFont() { wp_dequeue_style("oswald"); wp_deregister_style("oswald"); } add_action("wp_enqueue_scripts", "dequeueGoogleFont", 20 ); |
où oswald est l’identifiant utilisé par le thème parent. A vous de trouver l’identifiant qui correspond à la police dans votre thème.
Le gain : on passe de 90% à 92%
Un dernier détail
Pour mailler manuellement les articles entre eux, j’utilise l’excellent plugin Microkid’s Related Posts.
Celui-ci n’enregistre pas sa feuille de styles avec les méthodes de WordPress, donc elle n’est pas combinée avec les autres.
En revanche, dans ses options, il est possible de ne pas utiliser la feuille de styles par défaut et de fournir ses propres classes.
J’ai donc copié le contenu de la feuille de styles de l’extension dans le fichier style.css de mon thème enfant.
Le gain : on passe de 92% à 93%
Résumé des optimisations
- Etat initial : 85%
- Scripts asynchrones : 87%
- Encodage dans l’en-tête HTTP : 90%
- Google font locale : 92%
- CSS de Microkid’s Related Posts combiné : 93%
Le mot de la fin
Avec cette nouvelle phase d’optimisation, je suis revenu au niveau de la première après avoir suivi les nouvelles préconisations de GTMetrix.
Notez que GTMetrix n’a pas seulement ajouté des préconisations. Celle concernant les sélecteurs CSS a été supprimées. Tant mieux ! Elle était difficile à mettre en oeuvre, surtout avec un CMS comme WordPress.
Parmi les conseils restants, il reste les quelques icônes à inclure dans un sprite, mais comme je l’expliquais dans le premier article, ce sont des icônes destinées à être répétées pour former un fond. Il n’est donc pas possible de les inclure dans un sprite. Peut-être que GTMetrix détectera cette subtilité un jour.
Trois autres points d’amélioration concernent la minifications, repectivement pour le CSS, l’HTML et le JavaScript et concernent quelques espaces non supprimés pendant la minification. Je vais me pencher sur les autres moteurs de minification une prochaine fois. En d’autres termes : la suite au prochain numéro !
Waouh, intéressant compte rendu. Je suis en train de me prendre le chou avec un thème enfant que Better WP Minify n’arrive pas à gérer côté CSS et j’ai toujours hésité à utiliser un plugin de cache. Je vais jeter un oeil sur W3 Total Cache et appliquer tes conseils – je suis tombé à D sur GMetrix 🙁
Et comment gérer DEUX fontes Google ? Et pourquoi ne pas remplacer dans l’encodage directement l’appel par UTF-8 ? (une requête de moins).
Bonjour Li-An,
Merci pour tes commentaires 🙂
Pour gérer deux fonts Google, il suffit de refaire la manipulation deux fois, c’est-à-dire copier le code des deux feuilles de styles qui se trouvent sur le site de Google Fonts dans le fichier CSS local.
Je ne suis pas sûr d’avoir bien compris ta deuxième question. Que veux-tu dire par là ? 🙂
David
Oui, j’ai fini par trouver 🙂
Pour le deuxième, j’avais mis dans mon header <meta charset=" » /> pour gagner une requête -en fait deux si j’en crois Gmetrix. Mais j’ai peur d’une erreur de code pour ton code de remplacement.
As tu jeté un oeil sur la méthode de cache « plus efficace que les plugins » ? http://www.geekpress.fr/wordpress/tutoriel/systeme-cache-1851/
J’avoue que je n’ose pas passer au cache de peur de voir des incompatibilités.
Pour le charset, l’important c’est que ça fonctionne et de faire comme tu le sens.
Oui, j’ai regardé le système de cache de Jonathan, j’utilise d’ailleurs l’excellent plugin qui en découle : WP Rocket. J’ai écrit deux articles sur ce plugin si ça te dit.
Pour être tout à fait clair, ce n’est pas le cache machine de l’article que tu as mentionné, l’extension WP Rocket ou tout autre système de cache qui pose le plus de souci de compatibilité, mais la minification du CSS et du JavaScript.
David
Oui, la minification sur les thèmes enfants, c’est un peu la plaie. Pour WP Rocket, je ne pense pas investir dedans – mon site ne me le permets pas – et j’attends éventuellement qu’il soit bien « mûr » – j’ai eu quelques retours assez grinçants.
Pour WP Rocket, il évolue mais est déjà très stable, pour ma part je n’ai eu que de bons échos (et je tiens à rappeler que je n’ai aucun intérêt financier 😉 )
Je comprends : j’ai regardé un peu ton blog, et j’ai l’impression que tu es plus du genre à t’amuser à optimiser un W3 Total Cache. Alors enjoy, ce plugin reste quand même très bon.
Et en poussant encore un peu, tu peux même mélanger W3 Total Cache et le cache machine de Jonathan pour avoir d’excellents résultats.
David
Essayant chaque fois de possible d’optimiser mon site, je suis fièrement à 97%/81% sur mes pages de billets et 98%/99% sur ma page d’accueil (celle-ci est quasi parfaite).
L’un des points noirs des mes pages de billets est l’appel des scripts facebook/twitter/google-plus qui ne sont pas différés. Je ne peux me résoudre à les enlever, la part social est indéniable et importante.
existe il un moyen simple de régler ce petit soucis avec, par exemple, W3 Total Cache. En plus, si l’on peut les combiner, les scripts serait dans mon système de mise en cache.. même si je perds des mises à jour, au pire si je vois un dysfonctionnement dû à une mise à jour, je relance avec les nouveaux scripts
J’ai peur que ce ne soit pas possible hélas de faire la moindre chose 🙁
@Arnaud: il n’y a pas que GMetrix dans la vie. Avec des notes bien plus basses, plus de double du poids et plus de requêtes, mon site personnel mets moins d’une seconde de plus que le votre à charger. Si vous courrez après l’optimisation, il va falloir regarder du côté de l’hébergeur…
Bonjour Li-An,
Tu regarderais quels points en particulier du côté de l’hébergeur ?
David
Bonne question. Je sais juste que mon hébergeur actuel est plus rapide que le précédent. Ça tient à beaucoup de spécificités techniques – qualité des serveurs, mémoire, technologie utilisée – pas évident à analyser pour un néophyte comme moi.
Côté serveur, on peut avoir d’excellentes performances avec un ‘petit’ serveur. Le truc c’est d’avoir un bon système de cache.
David
Bonjour Arnaud, et félicitations pour ton score 🙂
Pour les scripts des fonctionnalités sociales, c’est malheureusement compliqué de passer outre…
Il y a peut-être un solution en intégrant une version plus ‘simple’ des boutons de partage.
Je ne sais pas si tu utilises JetPack, mais ce plugin propose une version sans le nombre de likes, tweets et autres.
Ce sont ces décomptes qui nécessitent d’intégrer des iframes et autres scripts dynamiques.
Alors peut-être que le plugin que tu utilises (si ce n’est pas JetPack) propose la même chose.
En même temps, c’est toujours sympa d’avoir ce nombre… Et au niveau d’optimisation où tu es, c’est peut-être un détail 😉
Aussi, j’ai vu que tu pouvais encore gagner avec l’optimisation des images. Tu as installé WP Smush It ?
David
Plutôt que WP Smush It, je conseillerai http://www.echodesplugins.li-an.fr/plugins/ewww-image-optimizer/ – enfin si votre hébergement propose bien les bibliothèques nécessaires.
@Li-An : je sais que je pêche côté serveur. Mais comment savoir si un hébergeur est rapide ou non, sauf à l’essayer. Mon site fait bientôt 0,7 Gb (4500 photos d’environs 150 kb chacune). La bande passante est assez importante donc j’ai choisi ce qui rentre dans un ratio prix/qualité qui me convient.
On va dire que l’optimisation reste un joujou qui m’a fait m’amuser avec le code
@David : j’ai viré Jetpack -> trop de scripts à noix pour pas grand chose surtout que je l’utilisais uniquement pour la partie commentaire (j’aimais l’option facebook/twitter pour s’inscrire). je suis revenu à plus basique et je n’ai pas tant de commentaires que ça.
Beaucoup de codes sont fait par moi car trop de plugin m’énervent et ne me permettent pas de les régler comme je veux. J’ai figé mon thème et je modifie directement les fichiers.
L’optimisation des images j’y pense mais tout est réglé avec NextGen Gallery.. je ne sais pas si Smush it permet de gérer aussi ça… et j’avoue que ça me faisait peur de rajouter une couche sur les images.. surtout qu’il n’y a pas énorme à gagner.
Pour Jetpack, je me doutais 🙂
A propos de Smush It, les images sont optimisées au moment de leur ajout dans les différents formats, et elles sont stockées en version optimisées.
Il contient aussi un outil qui permet d’optimiser toutes les images qui sont déjà présentes.
Smush It est indépendant de NextGen Gallery.
J’en avais parlé dans mon premier article sur W3 Total Cache, j’avais gagné 2% pour le coup.
David
Bonjour,
Depuis qu’un version du plugin Smush It m’a fait perdre pleins d’images sur les 3 sites que je m’occupe, je le fuis comme la peste, j’ai beau lire, le bug a été réparé, rien ne dit qu’il ne reviendra autrement, je préfère utiliser un autre plugin comme EWWW Image Optimizer.
Bonjour Noaneo,
D’accord, super…
De mon côté je trouve qu’il est de plus en plus long.
Je vais donc migrer vers EWWW Image Optimizer, d’autant que Li-An me l’avait déjà conseillé.
Et aussi parce que ce plugin convertit les images localement avec Image Magick.
En tout cas, merci pour ton témoignage 🙂
David
Ah, si c’est une sorte de défi, je ne peux évidemment rien dire 🙂
Oui c’est un défi et un passe temps !
Au passage, je te remercie : j’ai installé le plugin d’optimisation d ‘image que tu m’a indiqué et lancé les tâches, puis tout renvoyé sur mon CDN interne et zouh j’ai de belles images (au passage le plugin va chercher dans les chemins classique et non dans le CDN alors que c’est indiqué dans mes chemins d’upload et de Next Gen Gallery).
ça m’a fait gagné 1% sur la page d’accueil, elle passe donc à 99% / 99%. 🙂
Pas de changement sur la page de billets mais là c’est vraiment les scripts sociaux qui me « plantent » le système.
Aujourd’hui, je sais que j’ai le site le plus rapide possible et que les lenteurs viennent avant tout du serveur (je vois 1s d’attente entre la première requête et le début…c’est 30% du temps de téléchargement de la page !).
Pour ma part, ma plus grosse optimisation a été les sprites ! J’ai ainsi divisé par 2 le nombre de requête et ce fut foudroyant !
je regarde s’il n’y a pas moyen d’avoir les scripts facebook/twitter and co en local
99 % ! Classe 🙂
Si ce n’est pas déjà fait, tu pourrais te pencher aussi sur la base de données, notamment sur les pertes.
Ce doit être le cas, comme tu as beaucoup de données.
Pour voir l’étendue, c’est plutôt simple : connecte-toi à phpMyAdmin, la perte apparaît sur la liste des tables.
Pour corriger, il suffit de sélectionner les tables et de cliquer sur ‘Réparer’.
Ensuite, tu peux soit :
– le faire manuellement, une fois par mois par exemple
– t’aider d’un plugin dont j’ai oublié le nom, qui nettoie aussi certaines données superflues comme les révisions d’articles. Li-An, as-tu le nom de ce plugin ?
– faire un script de réparation de bases lancé automatiquement dans la cron du serveur, si tu as la main.
David
Je viens de réparer les tables.. Il y avait 6 Mo de pertes. Je ne connaissais pas cette technique, ni son étendu. J’imagine que cette perte est un cumul sur les 3 ans d’histoires du site.
Je n’installerai pas de plugin.. je vérifierai ça de temps en temps moi même 😉
La base fait un peu moins de 100 Mo.. je n’ai pas un énorme site, il y a moins de 400 billets (avec par contre pas mal de texte pour chaque billet).
Je suis en train de questionner mon hébergeur sur le temps de réponse à la première requête. C’est vraiment là que je peux gagner de la réactivité, même si je ne m’attends pas à une réponse allant dans ce sens. Mais globalement, j’ai toujours eu plus de 1s d’attente depuis que j’ai commencé ma phase d’optimisation. Ce n’était pas fondamental jusque là mais maintenant c’est le point primordial.
Tiens nous au courant 🙂
David
Je suis embêté..j’ai testé sur une page HTML classique et sur un autre site chez le même hébergeur : le temps d’attente à la première requête est de respectivement 57 et 330 ms.
J’ai entre 1s et 1,5s sur mon site qui me titille.
je vais chasser les plugins non indispensableq !
Si vous avez des pistes, des idées (ou l’envie d’en faire un post plein d’intérêt 😉 ) suis preneur !
En effet, ça rejoint bien ce qu’explique Jonathan, la star du cache WordPress, sur son WP Cache Machine
J’ai une piste, on peut en parler par mail si tu veux.
David
En complément de GT Metrix, je vous invite à utiliser l’outil http://www.quadran.eu/index.php/solutions/quadran-performance-analytics qui permet de mesurer les performances et la qualité de l’expérience réellement délivrées à l’ensemble de vos utilisateurs.
Bonjour Granieron,
Intéressant…
Je ne sais pas si ce service est le tien, alors j’hésite à te demander si le site qui présente l’outil a été testé par l’outil… (en plus j’ai ma réponse, j’ai vu la ‘petite’ capture d’écran)
Comme tu m’invites à l’essayer, j’ai tout d’abord quelques questions :
– tu parles d’expérience utilisateur, l’outil teste l’ergonomie, l’accessibilité, … ou c’est simplement un testeur de performances ?
– selon l’analyse faite, l’outil propose une liste d’actions à mener ?
David