FireFox is blocking Twitter content

To view content on tw-rl, follow these steps...

  1. Click on the shield in the address bar.
  2. Toggle the switch at the top of the panel.
Sign In →
Sign In →
start
Read Thread
Petite info, ça c’est les ressources chargĂ©es par le dev, mais il faut savoir que WordPress et certains plugins chargent du CSS et du JS, comme Contact Form 7 ou WPBakery. WordPress charge aussi nativement le CSS de Gutenberg, et le JS des emojis.
Voila ça c’est pour le contexte, on passe aux actions ! Premiùre action que je mets en place : je vire le builder WPBakery, et je rebuild les templates avec des beaux champs ACF (vive ce plugin), ça me prend facile 2h.
Le score monte Ă  plus de 40, mais on est toujours dans le rouge. Le soucis avec les builders c’est qu’il gĂ©nĂšre du code HTML lourd avec des div dans des div dans des div.. Regardez la quantitĂ© de widgets, ces ressources (CSS et JS) finissent dans par alourdir le site.
J'ai jamais vu un client aimer maintenir son site avec ce genre de truc, aprĂšs ça peut ĂȘtre pratique quand on veut monter une page rapidement (et encore..) Surtout qu’avec Gutenberg on a un systĂšme de colonnes et pleins de widgets (mais ce n'est que mon opinion).
Ensuite je fais un truc facile mais qui peut ĂȘtre long, je vire Font Awesome, Ă  quoi bon charger une librairie de plusieurs milliers d’icĂŽnes si on en utilise 20. Donc je remplace les balise <i class=”fa ...”> par le code svg qui est directement dispo sur leur doc.
Cela me prend une grosse demi heure car il faut modifier le CSS. Le score monte mais on est toujours à moins de 50 😭 Je ne me laisse pas abattre je continue.
Je dĂ©cide de regarder comment le dev a intĂ©grĂ© le site, je constate qu’il n’utilise Ă  aucun moment le JS de Bootstrap. Donc je le vire. Je vire aussi popper.js par la mĂȘme occasion, c’est une lib de 3 kb mais c'est toujours ça de gagner !
Le CSS minifiĂ© de Bootstrap 4 c’est 160kb, c’est beaucoup. Voyons si on ne peut pas l’allĂ©ger, je regarde ce que le dev a utilisĂ© : - la grille (Ă©vident) - les boutons - les formulaires Donc je vire Boostrap pour importer seulement le bootstrap-grid.min.css qui fait 60kb.
Je reconstruis le CSS des boutons et des formulaires en regardant la doc de Bootstrap. J'ai importé la grille de Bootstrap 5 pour avoir les gap sur les class row. Le score monte on passe tout juste la barre des 60, ça me prend environ 1h.
Ensuite je me dis que je pourrais virer ce bon vieux jQuery. Par chance aucun plugin frontend n’en a besoin. Par contre il y a des sliders construits avec Slick, si je vire jQuery les sliders vont pĂ©tĂ©s.
Pas grave, je vire Slick (le JS et le CSS) et j’importe Splide, une librairie de sliders qui est Lighthouse friendly. Cela ne me prend pas longtemps pour refaire les sliders, environ une grosse demi heure.
J'utilise Splide sur tous mes projets car la librairie est légÚre et qu'elle ne pose apparemment pas de problÚmes sur les autres catégories de Lighthouse (Accessibilité, Bonnes pratiques et SEO). Voici l'audit Lighthouse de la frontpage de Splide.
Je rĂ©Ă©cris le code jQuery en JS Vanilla, le dev qui a codĂ© le site n'a utilisĂ© que les sĂ©lecteurs $ et quelques fonctions, je trouve facilement l’équivalent en JS Vanilla. Je vire donc jQuery ET le JS et CSS de Slick, on arrive bientĂŽt Ă  la barre des 70 😭
Ensuite il y a du Leaflet qui est chargĂ© sur ma home page, alors qu’il n’y qu’un type de page qui en a besoin, je dĂ©cide de ne charger ces ressources que sur les pages concernĂ©es, avec ce genre de condition.
Je souhaite faire pareil pour Contact Form 7, mais il y a des formulaires sur toutes mes pages 😱 Mais si sur votre site vous avez un formulaire sur la page contact, ne chargez les ressources de CF7 que sur cette page !
Ensuite il faut savoir que les nouveaux WordPress chargent par dĂ©faut le CSS de Gutenberg, le site que j’optimise ne l’utilise pas, donc je vire. Le code Ă  mettre dans functions.php pour dequeue le CSS : https://gist.github.com/someguy9/1f51a7cb3349cc32d00f5aaa5d3b3e19#file-wp-remove-gutenberg-block-library-css-php
WordPress charge aussi nativement un fichier JS pour les émojis, ça ne sert a rien et ça dégrade les perfs, on vire aussi, vous pouvez passer par un plugin mais le plus simple et de le faire avec du code : https://kinsta.com/fr/base-de-connaissances/desactiver-emojis-wordpress/#2-dsactiver-les-emojis-dans-wordpress-avec-du-code
MĂȘme aprĂšs tout ce travail je n’arrive pas Ă  franchir la barre des 80, je reste Ă  70 environ. Je suis plutĂŽt déçu mais je ne me laisse pas abattre, je vais donc m’attaquer aux ressources qui “bloquent le rendu”, mais qu’est ce que ca veut dire au juste ?
Un peu de lecture : https://kinsta.com/fr/blog/eliminer-javascript-css-bloquant-rendu/ En gros ça veut dire que lors du parsing du HTML par la navigateur, lorsqu'il rencontre un script, il s'arrĂȘte pour l'exĂ©cuter, bloquant le reste. Lorsqu'on a des gros fichiers JS et CSS, c'est problĂ©matique.
Le navigateur ne sait pas si le code JavaScript va contenir des instructions spĂ©cifiques Ă  exĂ©cuter immĂ©diatement qui pourront avoir une consĂ©quence importante sur.. le code HTML/CSS lui-mĂȘme.
Le CSS bloque aussi le rendu, ce qui peut entrainer du FOUC (un flash de contenu non stylisé). Un trÚs bon article sur le sujet : https://dev.to/lyqht/what-the-fouc-is-happening-flash-of-unstyled-content-413j Voici une illustration pour comprendre le phénomÚne :
Il y a plusieurs choses à faire pour corriger ce problÚme de ressources bloquantes, commençons par lister les ressources qui posent problÚme : - Google reCaptcha - GTM - Google Analitycs - Google Fonts - Ainsi que mon propre fichier CSS
Commençons par Google Fonts, j'ai trouvé cet article qui explique comment les charger pour que Lighthouse soit content : https://css-tricks.com/how-to-load-fonts-in-a-way-that-fights-fout-and-makes-lighthouse-happy/#aa-the-optimal-way-to-load-fonts
J'explique le code proposé sur CSS Tricks : - rel="preconnect" permet d'indiquer au navigateur qu'il va avoir besoin des ressources que l'on passe dans le href - rel="preload" fait un preload asynchrone avec une basse priorité
- le media="print" car que le navigateur donne une basse priorité aux "print stylesheets" Le &display=swap dans l'url permet d'utiliser une police de remplacement déjà disponible sur le navigateur pour afficher du texte immédiatement tant que la police n'est pas chargée.
Ensuite j'ai voulu mettre un defer sur certains scripts, mais je me suis rendu compte que ça faisait péter certains éléments de la page (carte Leaflet), dommage. Les attributs async et defer permettent d'indiquer au navigateur comment charger le script. https://www.alsacreations.com/astuce/lire/1562-script-attribut-async-defer.html
Voila une image pour comprendre. C'est simple, avec defer le navigateur attend d'avoir parser le HTML pour exécuter le script. Source : https://flaviocopes.com/javascript-async-defer/#async-and-defer
Je me demande alors si je peux mettre un defer sur GTM. Oui on peut, on peut changer le code async=true par defer=true. Cela permet de plus avoir le warning de Lighthouse qui indique que c'est une ressource bloquante, mais j'ai fait pété les scripts qui sont injectés par GTM...
Tant pis, je vais essayer de faire avec, mais l'idéal serait de se passer de GTM. Dans mon cas il injecte beaucoup d'outils de tracking (Bing Ads, Google Ads...) je ne préfÚre pas y toucher.
Dans les ressources bloquantes c'est surtout Google reCaptcha qui fout la merde. Celui lĂ  on peut lui mettre un defer, mais le script est injectĂ© par CF7. Je trouve alors un plugin pour le faire : https://fr.wordpress.org/plugins/cf7-google-captcha-load-after-page/ Le score fait +10 facile, Ă  ce moment je suis comme ça đŸ€Ż
Mon fichier CSS est aussi considĂ©rĂ© comme bloquant, c’est normal c’est un gros fichier, il y a tout Bootstrap dedans ainsi sur mon CSS custom. Ce qu’il faut faire c’est donner au navigateur le CSS prioritaire pour le rendu (Critical CSS), en gros le CSS de la zone de flottaison.
Dans mon cas j’ai juste pris le CSS de la nav et des headers et j’ai tout mis en CSS inline dans une balise <style> dans le head. Boom +10 en perfs, je passe largement au dessus des 85, mais c’est toujours en orange, objectif atteint mais je peux passer au dessus des 90.
Comme on l'a vu un peu avant, charger en defer certains scripts comme GTM n’est pas toujours possible, vous pouvez mais ça peut casser quelque chose. Par contre on peut faire un preconnect et un dns-prefetch, j’ai grattĂ© 2 ou 3 points comme ça.
On l'a vu + haut pour Google Fonts avec le preconnect. Vous pouvez faire de mĂȘme avec GTM et GA, et d'autres services : https://blog.luke.lol/webmaster/optimize-google-analytics-google-tag-manager-via-preconnect-headers/
À ce moment je suis Ă  90+ environ, le rĂ©sultat varie un peu. Je me dis que je peux optimiser les images mais elles le sont dĂ©jĂ , le dev a fait du bon boulot. Elles sont toutes chargĂ©es avec du lazyloading et en responsive.
Elles sont aussi bien optimisées, entre 80 et 120kb pour les grandes images (>1600px de large). Pour charger des images responsives, WordPress a des fonctions pour ça : https://developer.wordpress.org/apis/handbook/responsive-images/#new-functions-and-hooks Aussi par défaut la fonction the_content() sort des images responsives.
Toujours avec les images, vous pouvez utiliser le format webp : https://developers.google.com/speed/webp C'est un format développé par Google, donc Lighthouse le recommande bien entendu. Le format permettrait d'avoir des images de 25 à 35% plus légÚre.
Je ne sais pas vraiment si ça vaut le coup mais WordPress supporte nativement ce format depuis la version 5.8 : https://make.wordpress.org/core/2021/06/07/wordpress-5-8-adds-webp-support/ Le site sur lequel j'étais avait déjà des images en webp.
Parlons du lazyloading : c'est le fait de différer le chargement d'une ressource. On peut le faire sur les images qui sont des ressources importantes, en demandant au navigateur de les charger que lorsque l'utilisateur scroll. https://developer.mozilla.org/fr/docs/Web/Performance/Lazy_loading
Pour se faire vous pouvez mettre un attribut loading="lazy" sur vos images. C'est supportĂ© par tous les navigateurs, mĂȘme Safari depuis peu il me semble. Mais si vous voulez supporter les anciens navigateurs, vous pouvez le faire en JS. Il y a pleins de librairies pour cela.
Si vous souhaitez le faire sans librairie, c'est possible avec l'API Intersection Observer : https://developer.mozilla.org/fr/docs/Web/API/Intersection_Observer_API
Toujours avec les images, il n’y avait pas tout le temps une width et une height dans le HTML. Je le fait pour toutes les images, c’est important pour Ă©viter que ça “saute” au chargement (FOUC), car les dimensions sont dans le CSS.
J'ai un warning qui me dit Ă©galement que le DOM est lourd, c’est sur ça que je vais passer environ 1h, je vais passer sur tous les templates et les templates-parts pour virer tout ce qui est inutile. Le dev qui avait fait l’intĂ© avait mis des class inutilisĂ©es par exemple.
Donc je vire tout ce qui peut l'ĂȘtre, parfois des imbrications de div inutiles, j’allĂšge aussi mon CSS en mettant la taille et la couleur de mes svg directement dans le markup HTML. Sur cette partie je pense avoir gratter 1 ou 2 points.
Voila ! C'est tout ce que j'ai fait pour amĂ©liorer les perfs, cela a eu aussi un impact positifs sur les autres metrics de Lighthouse (SEO, AccessibilitĂ©, et Bonnes pratiques). N'hĂ©sitez pas Ă  complĂ©ter ou poser des questions si besoin. Merci d'avoir lu ! ❀

My Notes:

Select to add to your #gallery:
Seb đŸ‘šâ€đŸ’»

Pro Curator

$99 /yearPay what you can