Combien de kilo-octets de JavaScript faut-il vraiment pour afficher un champ de recherche ? Sur un site éditorial construit avec Astro et alimenté par WordPress en headless, la réponse retenue a été : uniquement ceux nécessaires à ce composant précis, et rien de plus sur le reste des pages.
Astro repose sur une architecture d’îlots (Islands Architecture) : chaque page est rendue en HTML statique par défaut, et seuls les composants explicitement marqués comme interactifs reçoivent du JavaScript côté client. Pour une fonctionnalité de recherche instantanée alimentée par Algolia, ce modèle est particulièrement adapté : le reste du site (articles, pages, menus) n’a aucune raison d’embarquer la bibliothèque InstantSearch.js.
Étape 1 : isoler le composant de recherche
Le composant de recherche a été écrit en React, dans un fichier dédié, sans dépendance vers le reste du système de mise en page du site :
// src/components/RechercheAlgolia.jsx
import { InstantSearch, SearchBox, Hits } from 'react-instantsearch';
import { liteClient as algoliasearch } from 'algoliasearch/lite';
const client = algoliasearch('APP_ID', 'CLE_PUBLIQUE_RECHERCHE');
export default function RechercheAlgolia() {
return (
<InstantSearch searchClient={client} indexName="articles_prod">
<SearchBox placeholder="Rechercher un article…" />
<Hits hitComponent={ResultatArticle} />
</InstantSearch>
);
}
function ResultatArticle({ hit }) {
return (
<article>
<a href={`/articles/${hit.slug}`}>{hit.title}</a>
</article>
);
}
Ce composant React n’est utilisé nulle part ailleurs dans le site : les autres pages restent écrites en composants .astro purs, sans aucun framework côté client.
Étape 2 : contrôler précisément l’hydratation
C’est dans le fichier de page Astro que se joue la décision d’hydratation, via les directives client:*. Pour ce projet, client:visible a été retenu plutôt que client:load, afin de ne charger le JavaScript du composant que lorsqu’il entre réellement dans le viewport de l’utilisateur :
---
import RechercheAlgolia from '../components/RechercheAlgolia.jsx';
import Layout from '../layouts/Layout.astro';
---
<Layout title="Rechercher">
<h1>Recherche</h1>
<RechercheAlgolia client:visible />
</Layout>
Sur une page où le champ de recherche se trouve en bas de page (par exemple dans un pied de page présent sur tout le site), cette directive évite de charger inutilement React et InstantSearch.js sur des pages où l’utilisateur ne fait jamais défiler jusqu’à cette zone.
Étape 3 : synchroniser l’index avec le contenu WordPress
L’index Algolia est alimenté par un script exécuté à chaque webhook de publication reçu depuis WordPress, transformant chaque article en un enregistrement plat exploitable par InstantSearch :
{
"objectID": "482",
"slug": "astro-islands-algolia-recherche-interactive-statique",
"title": "Astro Islands et Algolia : une recherche interactive dans un site statique",
"excerpt": "N'hydrater qu'un seul îlot de recherche...",
"categorie": "headless"
}
Cette synchronisation reste totalement indépendante du rendu Astro : que le site soit généré en statique (SSG) ou en rendu à la demande, l’index Algolia vit sa propre vie, alimentée uniquement par les événements de publication WordPress.
Ce qui distingue cette approche d’un widget de recherche classique
- Aucune bibliothèque JavaScript n’est chargée sur les pages qui n’affichent pas la recherche
- Le composant peut être remplacé ou mis à jour sans reconstruire l’intégralité du site statique
- La recherche reste réactive côté client, avec filtrage instantané, sans rechargement de page
Un point de vigilance : le contenu affiché avant hydratation
Avant que le composant ne soit hydraté, Astro affiche son rendu serveur initial (une boîte de recherche vide, sans résultats). Un texte de substitution explicite, du type « Chargement de la recherche… », évite une impression de champ cassé pour les utilisateurs qui interagissent avec la page avant la fin du chargement du bundle JavaScript de l’îlot.
Notre verdict
L’architecture en îlots d’Astro convient particulièrement bien à une recherche Algolia sur un site par ailleurs statique : elle évite l’écueil classique d’un framework JavaScript complet chargé sur toutes les pages pour la seule fonctionnalité de recherche. Le compromis à assumer reste le léger délai d’hydratation visible avant que le champ ne devienne réellement interactif, largement acceptable pour un usage de recherche non critique.
