Modèles de chargement intelligents avec htmx

Dec 18, 2025 · 4 min read

Modèles de chargement intelligents avec htmx

Vous avez construit un tableau de bord. Chaque composant déclenche un hx-get au chargement. L’utilisateur voit six indicateurs de chargement tournants en attendant du contenu qui aurait pu arriver avec la page initiale. Ça vous dit quelque chose ?

Le problème n’est pas htmx—c’est de traiter chaque élément de contenu de la même manière. Les modèles de chargement d’interface intelligents nécessitent de comprendre quand charger le contenu, pas seulement comment. Cet article couvre les modèles de chargement htmx qui comptent vraiment : le chargement déclenché par la zone d’affichage, les délais échelonnés et l’amélioration progressive via hx-boost.

Points clés à retenir

Demandez-vous si le contenu doit exister avant que les utilisateurs puissent agir—si oui, rendez-le côté serveur ; si non, différez-le avec htmx
Utilisez hx-trigger="load" avec des délais échelonnés pour éviter les tempêtes de requêtes et créer des cascades visuelles
Choisissez revealed pour le défilement de page standard et intersect pour les conteneurs défilants ou le contrôle des seuils
Appliquez hx-boost pour une navigation instantanée sans modifier le code serveur ni compromettre l’amélioration progressive

Pourquoi la stratégie de chargement est importante

htmx conserve l’état sur le serveur. C’est sa force. Mais les requêtes réseau coûtent toujours du temps, et les utilisateurs remarquent quand le contenu critique arrive en retard.

La question centrale : Ce contenu doit-il exister avant que l’utilisateur puisse agir ?

Si oui, rendez-le côté serveur. Si non, htmx peut le récupérer plus tard. Ce simple filtre élimine la plupart des confusions concernant les modèles de chargement.

Chargement différé avec htmx : le déclencheur `load`

Le modèle hx-trigger="load" déclenche une requête lorsqu’un élément entre dans le DOM. Il est utile pour différer les requêtes coûteuses tout en gardant la page initiale rapide.

<section hx-get="/api/analytics" 
         hx-trigger="load delay:300ms"
         hx-swap="innerHTML">
    <div class="skeleton">Chargement des analyses...</div>
</section>

Le modificateur delay empêche les tempêtes de requêtes. Échelonnez vos délais—300ms pour le contenu de priorité moyenne, 600ms ou plus pour les sections de faible priorité. Cela répartit la charge serveur et crée une cascade visuelle naturelle.

Quand utiliser load :

Contenu en dessous de la ligne de flottaison
Données personnalisées difficiles à mettre en cache
Requêtes dépassant 200ms

Quand l’éviter :

Contenu principal de la page que les utilisateurs attendent immédiatement
Informations critiques pour le SEO
Requêtes rapides de moins de 100ms (rendez-les simplement côté serveur)

Chargement déclenché par la zone d’affichage : `revealed` vs `intersect`

htmx fournit deux déclencheurs pour le chargement basé sur la zone d’affichage. Choisir le bon dépend de votre mise en page.

Le déclencheur `revealed`

revealed se déclenche une fois lorsqu’un élément devient visible lors du défilement. Il utilise une simple vérification de visibilité par rapport à la zone d’affichage du document.

<div hx-get="/api/recommendations"
     hx-trigger="revealed"
     hx-swap="outerHTML">
    Chargement des recommandations...
</div>

Cela fonctionne bien pour le défilement de page standard—implémentations de défilement infini, images chargées en différé, ou sections de contenu que les utilisateurs pourraient ne jamais atteindre.

Le déclencheur `intersect`

intersect utilise l’API Intersection Observer et accepte un modificateur threshold. Utilisez-le lorsque vous avez besoin d’un contrôle plus fin ou lorsque le contenu se trouve à l’intérieur d’un conteneur défilant.

<div hx-get="/api/items"
     hx-trigger="intersect once threshold:0.5"
     hx-swap="innerHTML">
    <div class="placeholder"></div>
</div>

Le modificateur once empêche les requêtes répétées. Le threshold:0.5 signifie que l’élément doit être visible à 50% avant de se déclencher.

Choisissez intersect quand :

Chargement dans des conteneurs défilants (pas la zone d’affichage principale)
Vous avez besoin d’un contrôle de seuil
Vous voulez un comportement explicite de l’Intersection Observer

Choisissez revealed quand :

Défilement de document standard
Une sémantique plus simple suffit

Amélioration progressive avec `hx-boost`

hx-boost convertit les liens et formulaires standards en requêtes AJAX sans modifier votre code serveur. Le navigateur échange le contenu du <body> tout en minimisant le retraitement du <head>.

<body hx-boost="true">
    <a href="/contacts">Contacts</a>
    <a href="/settings">Paramètres</a>
    <a href="/report.pdf" hx-boost="false">Télécharger le rapport</a>
</body>

C’est le chargement progressif dans sa forme la plus simple. La navigation semble plus rapide car les scripts et les styles ne se rechargent pas. L’historique et le comportement du bouton retour fonctionnent normalement. Si JavaScript échoue, les liens fonctionnent toujours comme une navigation standard.

Remplacez par hx-boost="false" pour les téléchargements de fichiers ou les liens externes qui ne doivent pas être interceptés.

Contrôler les conditions de concurrence avec `hx-sync`

Plusieurs déclencheurs peuvent créer des conditions de concurrence. hx-sync coordonne les requêtes sur des éléments liés.

<input hx-get="/search"
       hx-trigger="keyup changed delay:200ms"
       hx-sync="closest form:replace">

La stratégie replace annule les requêtes en cours lorsqu’une nouvelle démarre. D’autres stratégies incluent queue et drop. Utilisez ceci lorsque la saisie rapide de l’utilisateur pourrait déclencher des requêtes qui se chevauchent.

Préserver le contenu déjà chargé

Lorsque htmx échange du contenu, il remplace la cible par défaut. Utilisez hx-preserve sur les éléments qui ne doivent pas se recharger—lecteurs vidéo, champs de formulaire avec des données utilisateur, ou composants avec un état interne.

<video id="player" hx-preserve="true">...</video>

L’élément persiste à travers les échanges tant que son id correspond.

Le cadre de décision

Avant d’ajouter hx-trigger="load" à quoi que ce soit, demandez-vous :

Est-ce critique pour comprendre la page ? → Rendu côté serveur
La requête prend-elle plus de 200ms ? → Chargement différé
Est-ce en dessous de la ligne de flottaison ? → Utilisez revealed ou intersect
Est-ce personnalisé ? → Chargement différé (la mise en cache n’aidera pas)

Commencez avec du contenu rendu côté serveur. Ajoutez des modèles de performance htmx uniquement là où ils résolvent de vrais problèmes—requêtes lentes, données personnalisées, ou contenu dont les utilisateurs pourraient ne pas avoir besoin.

Conclusion

Le meilleur modèle de chargement est souvent l’absence de modèle de chargement. Rendez ce qui compte, différez ce qui ne compte pas, et laissez le serveur garder le contrôle. En appliquant le cadre de décision—rendu côté serveur du contenu critique, chargement différé des requêtes lentes, et utilisation de déclencheurs de zone d’affichage pour les sections en dessous de la ligne de flottaison—vous évitez le piège des indicateurs de chargement tournants et livrez des interfaces qui semblent immédiates.

FAQ

Le déclencheur revealed utilise une simple vérification de visibilité par rapport à la zone d'affichage du document et se déclenche une fois lorsqu'un élément devient visible lors du défilement. Le déclencheur intersect utilise l'API Intersection Observer, vous donnant un contrôle de seuil et un comportement approprié à l'intérieur des conteneurs défilants. Utilisez revealed pour le défilement de page standard et intersect lorsque vous avez besoin d'un contrôle plus fin.

Non. Le chargement différé ajoute des allers-retours réseau qui peuvent rendre le contenu critique lent. Ne différez que le contenu dont les utilisateurs n'ont pas besoin immédiatement, qui prend plus de 200ms à interroger, qui se trouve en dessous de la ligne de flottaison, ou qui contient des données personnalisées qui ne peuvent pas être mises en cache. Les requêtes rapides de moins de 100ms doivent être rendues côté serveur.

Utilisez hx-sync pour coordonner les requêtes sur des éléments liés. La stratégie replace annule les requêtes en cours lorsqu'une nouvelle démarre. Vous pouvez également utiliser queue pour traiter les requêtes dans l'ordre ou drop pour ignorer les nouvelles requêtes pendant qu'une est en attente. Ceci est particulièrement utile pour les champs de recherche avec des déclencheurs keyup.

Non. Lorsque hx-boost intercepte la navigation, htmx met correctement à jour l'historique du navigateur. Les boutons retour et avancer fonctionnent comme prévu. Si JavaScript échoue complètement, les liens boostés reviennent à la navigation standard puisqu'il s'agit de balises d'ancrage régulières avec des attributs href valides.

Gain Debugging Superpowers

Unleash the power of session replay to reproduce bugs, track slowdowns and uncover frustrations in your app. Get complete visibility into your frontend with OpenReplay — the most advanced open-source session replay tool for developers. Check our GitHub repo and join the thousands of developers in our community.

Points clés à retenir

Pourquoi la stratégie de chargement est importante

Chargement différé avec htmx : le déclencheur load

Chargement déclenché par la zone d’affichage : revealed vs intersect

Le déclencheur revealed

Le déclencheur intersect

Amélioration progressive avec hx-boost

Contrôler les conditions de concurrence avec hx-sync