Gaming Google — Le score parfait

J'ai toujours hésité à partager mon code. Ce n'est pas que je pense que c'est inférieur à la moyenne, et je ne suis pas atteinte du syndrome de l'imposteur. C'est juste que le partage de code donne un aperçu de la folie qui règne dans mon esprit, et qui semble cruelle pour tout le monde. Permettez-moi de vous guider dans un voyage qui m'a presque mené au bord de la santé mentale. Tout a commencé avec la mise à jour Lighthouse de Google.

Pour les débutants en référencement, la mise à jour Lighthouse de Google a représenté un changement substantiel dans le classement des moteurs de recherche, en fonction des performances du site Web et du respect des meilleures pratiques. Si vous souhaitez tester votre site Web, ouvrez-le simplement dans Chrome sur un ordinateur de bureau, appuyez sur F12 pour ouvrir les outils de développement de Chrome, puis cliquez sur l'onglet « Lighthouse ». Choisissez Ordinateur de bureau ou Mobile et cliquez sur « Analyser ». Après environ une minute, vous recevrez cinq notes, chacune allant de 0 à 100, pour les performances, l'accessibilité, les meilleures pratiques, le référencement et les applications Web progressives (PWA).

Avant d'entrer dans les détails techniques, permettez-moi de me présenter. Je m'appelle Jonathan Grantham et je suis l'heureux propriétaire d'une petite entreprise SaaS B2B, Nexoid, spécialisée dans les logiciels ERP et ITSM. Le site Web dont je parle dans cet article est www.nexoid.com. N'hésitez pas à y jeter un œil, à ouvrir le code source. Vous pouvez également me suivre sur LinkedIn. Mon profil est www.linkedin.com/in/jonathongrantham/

Lors de la sortie de la mise à jour Google Chrome Lighthouse, j'ai fait ce que tout propriétaire d'entreprise consciencieux ferait : j'ai consulté mon site Web. À mon grand désarroi, les résultats étaient loin d'être satisfaisants. Avec des scores de 21/100 pour les performances, 30/100 pour l'accessibilité, 45/100 pour les meilleures pratiques, 11/100 pour le référencement et un échec pour la PWA, j'ai été choquée. J'avais personnellement créé le site Web, une architecture à page unique assez standard en utilisant React.js. Les scores ont été un coup dur.

Sans me laisser décourager par cet échec initial, j'ai lancé MS Code et j'ai commencé à résoudre les problèmes un par un, la performance étant ma première cible. Les guides fournis dans l'outil Lighthouse se sont révélés très utiles. J'ai converti toutes les images des fichiers JPEG et PNG en fichiers WebP modernes et j'ai veillé à ce que chaque balise img soit dotée d'une propriété de largeur et de longueur pour éviter les changements de mise en page. Ces modifications à elles seules ont fait passer mon score de 21/100 à 60/100. C'était une amélioration significative, mais loin d'être parfaite. La seule suggestion qui restait était de « réduire le code JavaScript inutilisé », ce qui n'était pas particulièrement utile. Le seul JavaScript présent était le framework React.js, car tout le reste avait été supprimé.

Grâce à Nexoid, AM Digital a également pu étendre les avantages d'une solution ITSM unifiée à ses opérations en contact avec les clients. Le portail client, intégré à Azure, offrait une expérience plus connectée, dynamique et fluide à leurs clients, ce qui s'est traduit par une satisfaction et un engagement accrus des clients. Le portail a permis une synchronisation en temps réel avec les données des clients, garantissant ainsi la mise à jour et l'exactitude de toutes les informations, améliorant ainsi la prestation de services et renforçant la relation client-entreprise.

Malgré mes efforts persistants pour remédier au problème, je me suis heurté à des obstacles constants. J'ai essayé de supprimer des parties de React.js, j'ai exploré le « lazy loading » et j'ai testé divers optimiseurs et compressions. Cependant, le problème provenait du fichier React.js lui-même, dont la taille était d'environ un demi-mégaoctet.

J'entends presque des développeurs web chevronnés crier : « N'utilisez pas React pour un site Web ! Il est destiné à créer des applications Web ! » J'en suis bien conscient maintenant.

Ce qui n'était au départ qu'une tâche apparemment simple de conversion de quelques images s'est transformé en une refonte complète du site Web à l'aide d'un nouveau framework. Frustrée et à bout de souffle, je me suis lancée à la recherche d'un remplaçant approprié. J'ai d'abord considéré Vue et plus tard Angular, sans doute les plus grands concurrents de React.js. Cependant, ils ont tous deux présenté le même problème.

Dans le but de simplifier les choses, j'ai décidé de me pencher sur les anciennes technologies et j'ai essayé jQuery. Pourtant, j'ai été confronté au même problème. Il est devenu parfaitement clair qu'il n'existait pas de framework d'architecture à page unique prêt à l'emploi capable d'apaiser les divinités de Google.

Il me semblait que la seule option qui me restait était de recourir à du JavaScript standard.

Ma série d'expériences a commencé avec une page HTML basique sans JavaScript. Ensuite, j'ai essayé une page HTML avec un div dont le contenu pouvait être remplacé. Je me suis vite rendu compte que le fait d'apporter plusieurs modifications simultanées à la page via JavaScript entraînait des pénalités de la part de Lighthouse. La solution consistait à manipuler le contenu de la balise body sous forme de chaîne, puis à le réintégrer, ne créant ainsi qu'une seule modification visible du DOM.

J'avais maintenant une page HTML minimaliste avec une balise body vide, complétée par une petite fonction de chargement dans la balise head. Cette fonction a inspecté l'URL et exécuté une requête HTML GET pour récupérer le fichier texte correspondant contenant le code HTML du corps de la page. On pourrait penser que c'est une solution appropriée. Malheureusement, cela n'a pas abouti lorsque j'ai tenté de charger dynamiquement la fonctionnalité JavaScript.

Contrairement aux autres balises, si vous ajoutez une balise de script avec une simple alerte (« yes this fired ») dans le corps de la chaîne, elle ne s'exécutera pas. Bien que cela ne soit pas idéal, une solution de contournement consistait à analyser la chaîne de caractères, à identifier tous les contenus des balises de script et à les placer dans une fonction d'évaluation JavaScript. L'approche s'est révélée assez efficace, mais elle a échoué en ce qui concerne les espaces de noms, et la console du développeur a été inondée d'avertissements inesthétiques. La solution consistait à extraire les balises de script du code HTML et à les ajouter en tant qu'élément de script après le rendu du DOM. Google n'a pas pénalisé cette action pour une raison quelconque.

Des progrès étaient réalisés et je disposais d'une solution basique d'architecture à page unique. Mais pas si vite. Alors que Google indexe efficacement les pages d'architecture de page unique (pour ce faire, il l'ouvre dans un navigateur, autorise l'exécution de tout le code JavaScript, puis scanne le DOM), Bing, Yahoo et les autres principaux moteurs de recherche utilisent une méthode similaire et plus simple. Cependant, la plupart des autres plateformes comme Facebook, Reddit, LinkedIn et WhatsApp ne récupèrent que le fichier HTML, c'est-à-dire un petit fichier HTML dont le corps est vide. Ma solution n'était pas viable. Je devais maintenant reproduire ce concept pour chaque page du site Web et inclure le JavaScript pour passer en mode architecture de page unique lorsqu'un utilisateur cliquait sur un lien.

J'avais besoin d'un outil capable de générer du code HTML pour chaque page, en fonction de ma solution. Je me suis rendu compte que j'avais la ressource parfaite à ma disposition : mon propre système ERP, Nexoid. J'ai créé un modèle Nexoid comprenant un site Web et des objets de données de page Web. L'enregistrement du site Web a facilité la création d'un modèle de page Web générique, tandis que les enregistrements de page Web contenaient le contenu de chaque page individuelle. La dernière pièce du puzzle était une fonction ou un script de flux de travail capable de lire l'enregistrement du site Web et tous les enregistrements de pages Web connexes pour générer les fichiers HTML. Au bout de quelques jours, il était opérationnel. J'avais créé un système de gestion de contenu (CMS) de base. À ce stade, le développement d'un CMS n'est pas trop complexe ; le véritable défi se pose lors de l'intégration d'autres flux de travail, approbations, localisations, aperçus, etc.

L'une des principales exigences du nouveau site Web était la localisation ; nous avions pour objectif de le lancer en 11 langues. En tant que société informatique, je me suis naturellement tournée vers les solutions technologiques. Plutôt que de faire appel à un traducteur pour chaque page, j'ai opté pour AWS Translate. Les traducteurs basés sur l'IA sont bons, mais ils ne sont pas parfaits et les erreurs sont suffisamment visibles pour révéler une origine non humaine. Un membre du personnel francophone a évalué la traduction de l'IA et lui a attribué la note de 6/10, la décrivant comme « un français compréhensible, mais pas correct ».

Cependant, nous sommes tombés sur une astuce précieuse. Nous avons découvert qu'en introduisant d'abord le texte en anglais via ChatGPT, en lui demandant de « mettre de l'ordre », puis en le collant, il reformule le texte d'une manière qui reste en anglais mais qui est beaucoup plus compatible avec les modèles linguistiques. L'utilisation de l'anglais reformulé par ChatGPT comme base de traduction améliore considérablement la qualité de la traduction, en l'élevant à 9, voire à un parfait 10 sur 10.

Ayant développé une base technologique solide pour la création du site Web, je faisais des progrès. Cependant, un nouveau défi est apparu lorsque nous avons commencé à créer des pages plus complexes. Selon les nouvelles directives de Lighthouse, il est devenu nécessaire de regrouper tous les éléments JavaScript, CSS et HTML dans un seul fichier. Cela s'appliquait également aux versions Single Page Architecture.

Nous avons eu recours à l'insertion de tous les fichiers JavaScript et CSS sous forme de balises intégrées. Une stratégie similaire était requise pour la version Single Page Architecture. Nous avons créé un fichier JSON contenant tous les scripts, styles et code HTML.

Lighthouse a identifié le problème suivant comme étant la taille des ressources ; les fichiers de page HTML et JSON étaient excessivement volumineux. J'ai résolu ce problème en utilisant « minify », une bibliothèque Node.js spécialement conçue pour compresser les fichiers HTML, CSS et JavaScript. Cette solution a permis de réduire la taille du fichier texte de plus de 40 %. De plus, minify offrait l'avantage supplémentaire de l'obfuscation, rendant le code brut plus difficile à lire et améliorant la sécurité.

Examinons le sujet de l'hébergement. Traditionnellement, un système de gestion de contenu (CMS) fonctionne via un serveur d'applications qui gère la requête HTML de l'utilisateur. Il interprète la demande de page à partir de l'URL, localise les ressources correspondantes dans une base de données, extrait l'enregistrement de la base de données (éventuellement avec d'autres), traite les informations pour assembler la page et la fournit enfin à l'utilisateur final sous forme de document HTML plat. Cette description concerne principalement la requête HTML initiale lorsqu'un utilisateur visite un nouveau site Web, bien que je connaisse AJAX et d'autres technologies similaires.

Cependant, ce modèle classique présente certains inconvénients dans le contexte du nouveau monde Lighthouse. Tout d'abord, le va-et-vient entre le serveur d'application et le serveur de base de données, ainsi que la compilation des pages, introduisent des retards. Deuxièmement, dans leur forme la plus simple, un serveur d'applications et un serveur de base de données ne sont physiquement disponibles qu'à un seul endroit. Cette configuration est excellente si vous vous trouvez dans le même bâtiment ou dans la même ville, mais elle est nettement moins efficace si vous essayez d'accéder au site depuis l'autre bout du monde. Par exemple, la latence de ping moyenne entre l'Australie et le Royaume-Uni est d'environ 250 millisecondes.

Notre solution à ces défis implique l'utilisation d'AWS S3 pour héberger les fichiers statiques générés par le script de publication mentionné précédemment, et d'AWS CloudFront pour la distribution de contenu à l'échelle mondiale. Au moment de la rédaction de cet article, AWS CloudFront distribuait du contenu dans plus de 90 villes dans 47 pays. Pour une personne de Melbourne, en Australie, accédant à un site Web britannique, AWS CloudFront a réduit la latence de ping de 250 millisecondes à seulement 13 millisecondes (il s'agit du décalage horaire entre Melbourne et les serveurs Edge AWS à Sydney).

Nous arrivons maintenant à la composante Progressive Web Application (PWA) du test Lighthouse, à laquelle je n'avais pas accordé beaucoup d'attention auparavant. Pour ceux qui ne le connaissent pas, une PWA implique un service worker JavaScript qui gère le site Web en tant qu'application Web. Si c'est un peu complexe, considérez-le de cette façon : il s'agit essentiellement d'un outil de téléchargement et de mise en cache automatique. Lorsqu'un utilisateur visite votre site Web, l'objectif est de rendre ses demandes ultérieures aussi rapides et fluides que possible. Le service worker PWA vous permet de télécharger déjà les ressources suivantes sur la machine locale de l'utilisateur, ce qui évite d'avoir à effectuer une autre requête GET sur Internet.

Au moment de la rédaction de cet article, le site Web de Nexoid est relativement petit, ne contenant que 19 pages. Cependant, ces 19 pages sont traduites dans 11 langues différentes, soit un total de 209 pages. Au départ, j'ai essayé de télécharger chaque ressource dans le service worker, ce qui représentait environ 5 Mo. Cette taille était trop grande pour un chargement initial, et Lighthouse m'a pénalisé pour cela. J'ai choisi de ne télécharger que les fichiers JSON de la page en anglais, qui incluent tous les CSS, HTML et JavaScript nécessaires pour afficher chaque page.

La structure finale est la suivante : un compartiment S3 héberge les fichiers HTML compilés, nommés sans l'extension .html. Par exemple, www.nexoid.com/en représente le code HTML de la page d'accueil en anglais, www.nexoid.com/de correspond au code HTML de la page d'accueil en allemand, et www.nexoid.com/en/platform fait référence au code HTML de la plateforme anglaise, etc. En outre, certains fichiers JSON contiennent les parties du corps et de la tête qui changent lorsque vous naviguez entre les pages, tels que https://www.nexoid.com/en.json, https://www.nexoid.com/de.json et https://www.nexoid.com/en/platform.json, entre autres.

En conclusion, comprendre Lighthouse a posé un défi de taille. Je suis sceptique quant à la capacité des produits CMS traditionnels et prêts à l'emploi de résoudre efficacement cette tâche. À la lumière de mon expérience avec des plateformes telles que WordPress et Drupal, j'ai du mal à croire qu'elles puissent être optimisées pour obtenir un score Lighthouse parfait. Dans l'ensemble, je pense que l'effort en vaut la peine, et Google a raison de mettre davantage l'accent sur les performances. Cependant, ce changement est et continuera d'être un problème considérable pour les concepteurs de sites Web et les agences.

Si vous souhaitez en savoir plus sur Lighthouse ou si vous souhaitez discuter des produits et services de Nexoid, n'hésitez pas à nous contacter. Vous pouvez nous contacter via LinkedIn ou via la page « Contactez-nous » de notre site Web.