La performance comme choix de conception et enjeu SEO

Pour le site d'Eva, je voulais que le texte et les images s'affichent sans charger une application entière dans le navigateur. C'est pour ça que j'ai traité la performance dès les choix de structure et d'hébergement.

Je suis Jim. Après la stack technique et le CMS, ce sixième article du making-of explique les choix qui servent le chargement et la lecture. Je pars des pages à afficher et du travail demandé au navigateur.

Ce que je cherche à améliorer

Une page peut charger lentement, bouger pendant l'affichage ou répondre avec retard quand on clique. Ce sont des problèmes différents. Réduire le poids d'une image ne corrige pas forcément un bouton qui se décale ou un script qui bloque une interaction.

Google décrit trois Core Web Vitals : le LCP pour le chargement, le CLS pour la stabilité visuelle et l'INP pour la réactivité. Ils interviennent dans ses systèmes de classement, sans garantir une bonne position. Je les utilise comme repères pour le confort de visite, pas comme un calcul de trafic futur.

Sur le site d'Eva, les portraits et les textes doivent rester lisibles sur téléphone. Les animations doivent accompagner la page sans retarder son contenu. C'est ce besoin qui guide les choix suivants.

Du HTML pour afficher le contenu

Dans la configuration retenue, Astro génère les pages en HTML au build. Le contenu existe donc dans la réponse envoyée au navigateur. Il n'a pas besoin d'être entièrement reconstruit par une application JavaScript côté visiteuse.

C'est le principe de l'architecture en îlots d'Astro : le contenu peut rester statique et les éléments interactifs charger leur propre JavaScript.

Le site d'Eva en utilise peu : une lune dorée en fond, des animations au défilement et un formulaire de newsletter. Le reste repose sur le HTML et le CSS. Cela réduit le travail demandé au navigateur. Restent les images et les polices à charger, deux sujets à traiter dans la même conception.

Préparer les photos à la bonne taille

Les photos font partie du site : le portrait d'Eva, les visuels des accompagnements et l'atmosphère des pages. Je voulais les conserver sans envoyer systématiquement le fichier source au navigateur.

Le traitement passe par astro:assets, avec des images redimensionnées et une sortie AVIF configurée au build. La documentation d'Astro décrit les formats et les transformations disponibles. L'AVIF n'est pas une conversion automatique de toute image par défaut : il faut configurer le rendu et utiliser les images dans le circuit prévu.

Lorsqu'Eva remplace une photo par l'interface du site, l'objectif est que ce circuit prépare la version à afficher. Elle n'a pas à exporter elle-même chaque variante. Il reste à contrôler la qualité du résultat et la taille choisie pour la page.

L'hébergement et la distribution

Le site est hébergé sur Cloudflare Pages. Sa distribution s'appuie sur le réseau de Cloudflare, ce qui permet de servir les ressources depuis plusieurs points plutôt que de dépendre d'un serveur d'origine unique pour chaque visite. La documentation de Pages présente ce fonctionnement.

Cela ne permet pas de promettre le même délai à tout le monde. Le réseau de la visiteuse, le cache et les ressources demandées comptent aussi. Je préfère vérifier le chargement sur la page que déduire sa vitesse du nom de l'hébergeur.

Rendre le site lisible pour les moteurs

En parallèle de la performance, j'ai prévu trois éléments techniques :

Un sitemap, généré au build à partir des routes retenues. Il aide à signaler les URL, mais ne prouve pas qu'elles sont toutes indexées.
Un robots.txt, pour indiquer les consignes d'exploration. Sa présence ne dispense pas de relire les règles quand le site évolue.
Un JSON-LD Person, qui décrit Eva et relie son identité à ses profils et références, comme Instagram, son podcast ou un article de presse.

Je traite ces éléments à côté du chargement : ils servent à décrire le site et à guider son exploration. Google précise notamment qu'un sitemap aide à découvrir les URL sans garantir leur exploration ou leur indexation.

Ce qu'il reste à mesurer

Ces choix doivent ensuite être vérifiés sur les pages rendues et dans les conditions de visite. Les images, les polices et les scripts peuvent encore peser sur le chargement, même quand la structure est légère.

La performance soutient la lecture. Pour vérifier les textes eux-mêmes, la suite revient sur la page Human Design et son travail de structure.

Le recul sur l'ensemble du chantier se trouve dans le bilan du passage de Wix au sur-mesure.