À la Recherche d'un Héros Vrai

Après consolidation de l’affichage de l’article, nous poursuivons la conversation entre contenu, conception et mise en œuvre des fonctionnalités. En particulier, l’article sur le Mont Fyffe (mt-fyffe) pourrait bénéficier d’une image d’hero. Cela doit être contenu-driven - c’est-à-dire spécifié dans les fichiers mdx.

Il existe des options toutefois. Devrions-nous faire cela comme un frontmatter (dans la partie hyphène-hyphène-hyphène au début du fichier hero: ../path/to/image) ou dans le corps de l’article (en rendant un composant Hero <Hero src="…" />)?

Une considération qui informe la décision est que, pour l’instant, le modèle d’article impose la structure de présentation des informations du frontmatter comme suit (pseudocode) :

<!-- [slug].astro -->
<article>
  <header>
    <h1>{post.data.title}</h1>
    <p>{post.data.date}</p>
    <p>{post.data.tags}</p>
  </header>
  <Content />
</article>

Cela signifie que nous ne pouvons pas rendre quoi que ce soit du corps de l’article avant le header, ce qui signifie que nous ne pourrions pas rendre un composant Hero avant le titre, même si nous voulions initialement aller avec cette option.

Cette inflexibilité pose la question “pourquoi utiliser du frontmatter au tout début?”. Pourquoi pas simplement laisser les articles décider ce qui va où en important des composants directement dans le corps de l’article et avoir le modèle juste render <Content />? D’un autre côté, cela aurait certainement permis d’avoir des incohérences entre les articles à se produire. Je décide de rester consistant. Frontmatter, c’est ça.

En plus de quelques réajustements attendus du layout, l’importation d’images dans le frontmatter nécessite une mise en place rapide de Astro’s native <Image /> et <Picture /> composants pour des images optimisées.

Optimisation des Images avec Astro

J’ai défini la largeur maximale sur le conteneur d’images à 1200px et j’ai remarqué que l’image d’hero prend un moment pour charger. Un rapide scan des docs d’Astro me donne le message en tête :

“Utilisez les composants <Image /> et <Picture /> natifs d’Astro pour des images optimisées”

…mais ce n’est pas tout à fait aussi simple que cela.

Cela fonctionne de manière suivante : ces composants fournissent une API de props unifiée pour contrôler la résolution de deux problèmes :

La génération de fichiers d’image appropriés (par exemple, sur le disque) prêts à être servus statiquement par un serveur web.
La détermination du fichier d’image minimum requis en fonction d’une fenêtre de navigateur de taille donnée chargement la page (en ajoutant des propriétés HTML correspondantes à l’élément img).

Essayons cela avec quelques exemples.

Tout d’abord, spécifier une largeur statique comme <Image width=”200” /> fera que Astro :

réduira l’image source originale à 200px de large et la rendra prête à servir à une taille spécifique d’URL
définira la propriété src de sortie img sur cette URL.

Pour la responsivité (c’est-à-dire lorsque la largeur de l’image affichée dépend de la taille du viewport du navigateur) vous pouvez <Image widths={[800,1200,1600]} sizes=”90vw” /> qui fera que Astro :

génère trois fichiers d’image à 800, 1200 et 1600 pixels de large et les rendra prêts à servir à des URLs spécifiques
ajoute une propriété srcset avec trois entrées sur l’élément img de sortie avec les URLs des images générées
transmet la propriété sizes fournie pour que le navigateur détermine quel fichier d’image charger en fonction de la taille du viewport.

En fin de compte, cela est certainement une abstraction agréable pour éviter de générer des images et de configurer leurs URLs mais vous devez toujours comprendre les concepts d’images responsives (c’est-à-dire srcset & sizes propriétés, dpi etc.) et utiliser l’API d’Astro appropriément pour obtenir “des images optimisées” dans les cas responsifs.

J’ai collé des largeurs et des tailles suffisantes sur le Hero image network size a diminué de 5 fois, ce qui a entraîné une expérience de chargement améliorée.

Les héros dans les articles. Yay !