Comment aborder les optimisations techniques les plus difficiles avec ses partenaires

Au-delà des optimisations standards, qui ne nécessitent que l’ajout programmatique d’une balise ou l’intégration de contenu à des endroits stratégiques, d’autres actions plus compliquées permettent un gain de performances significatif mais s’exposent à des niveaux d’échec également plus élevés. Gros plan sur ces cas particuliers et méthode pour en tirer le meilleur.

Tiens, voilà la documentation

Lors de création de tickets Jira/Redmine ou de demande d’action technique générale à une équipe de développeurs, il est malheureusement fréquent qu’un SEO décrive succinctement de quoi il s’agit, ses attentes, puis termine par partager un lien vers une page de documentation Google de 47 pages. Bonne lecture !

Ce n’est pas forcément dramatique pour les « petites » optimisations, mais c’est proche d’une garantie d’échec pour les travaux compliqués. Dans la plupart des cas, les devs sont des intégrateurs minutieux qui ont une capacité à trouver des solutions, mais celle-ci est (et doit être) limitée pour tirer profit au mieux de leur savoir-faire.

Le SEO est ici celui avec la vision stratégique et doit gérer ce projet avec les ressources humaines disponibles. Pas simplement trasmettre une liste d’informations à l’équipe en leur souhaitant bonne chance. En ce sens, des aptitudes de management sont utiles pour arriver aux résultats attendus.

Critical CSS ?

Le Critical CSS est un bon exemple. Parvenir à faire en sorte que le CSS critique soit vraiment utile sur un gros site reste probablement l’une des actions les plus compliquées à coordonner, et ce pour plusieurs raisons :

• Le Total Blocking Time augmente de manière drastique dans 90% des cas, pour cause de duplication ou de lignes de code chargées tôt sans être critiques
• Ce code non requis est souvent le fruit d’outils type générateurs de CSS critique qui ne donnent pas de résultats fiables
• Faire manuellement le tri de ce qui est critique et de ce qui ne l’est pas est fiable mais très (trop ?) chronophage
• Parvenir à cibler et adapter le CSS critique en fonction des types de page n’est pas aisé

Il s’ensuit en général une période de frustration et un abandon, faute de résultats suffisants. Pourtant, parvenir à optimiser le chargement de son CSS de la sorte peut faire une différence massive si c’est mis en place correctement. Dilemme.

Reconnaissance de la difficulté

La solution pour parvenir à passer outre ces problèmes et éviter l’abandon consiste en deux éléments :

• Reconnaître que l’action proposée est difficile et en faire part aux équipes partenaires
• Partager le poids de cette difficulté avec dévelopeurs et designers, et se mettre d’accord pour que chacun se mette en quête de solutions

Cela signifie que l’on sort d’un projet standard où le SEO apporte une solution et les partenaires l’intègrent. On passe alors à une collaboration où chacun apporte sa pierre à l’édifice et a pour mission de faire en sorte que le résultat soit positif. Le tout est de parvenir à justifier l’effort pour les autres équipes en parvenant à le lier d’une manière ou d’une autre à leurs objectifs généraux.

Cela peut ressembler par exemple à cela :

• Le référenceur définit les objectifs, sélectionne les fichiers à optimiser et extrait les lignes à charger tôt
• Le designer vérifie que cela n’interfère pas avec l’affichage et offre des solutions supplémentaires pour augmenter l’impact de l’optimisation des fichiers choisis
• Les développeurs se chargent d’analyser les risques de duplication et les fichiers CSS dont le chargement sera repoussé, afin de réduire au maximum le TBT

Puis les tests commencent, avec des allers et retours entre les différents acteurs jusqu’à ce qu’une issue positive soit trouvée.

Bien que non garanti, un dénouement heureux est bien plus probable maintenant que chacun a un intérêt particulier dans le projet.