window.requestIdleCallback(() => {
hydraterBlocRecommandations(donneesRecuesDeLApiRest);
});Cette API du navigateur, disponible nativement dans la plupart des environnements modernes, exécute la fonction qui lui est confiée uniquement pendant un temps mort du fil d’exécution principal, c’est-à-dire quand le navigateur n’a rien d’autre de plus urgent à traiter. Sur un front headless qui consomme l’API REST WordPress pour afficher plusieurs blocs de contenu sur une même page, cette technique permet de hiérarchiser explicitement ce qui mérite une hydratation immédiate de ce qui peut raisonnablement patienter.
Le scénario typique concerne une page produit qui affiche, en haut, les informations essentielles nécessaires à l’achat, et plus bas, un bloc de recommandations similaires, alimenté par un appel API distinct. Hydrater ce second bloc en même temps que le premier mobilise du temps de calcul sur le fil principal au moment précis où le visiteur s’apprête à interagir avec les éléments prioritaires de la page.
Le problème que cette technique résout
Un rendu React ou Vue classique hydrate généralement l’ensemble de ses composants dès que le JavaScript associé est chargé, sans distinction de priorité entre un bouton d’ajout au panier et un carrousel secondaire de suggestions. Cette hydratation simultanée peut retarder la réactivité des éléments réellement prioritaires, en particulier sur un appareil aux capacités limitées.
Mise en œuvre concrète
async function initialiserPage() {
const donneesEssentielles = await fetch('/wp-json/wp/v2/produit/842')
.then((reponse) => reponse.json());
hydraterBlocPrincipal(donneesEssentielles);
const declencherHydratationSecondaire = () => {
fetch('/wp-json/wp/v2/produit/842?_embed=recommandations')
.then((reponse) => reponse.json())
.then((donnees) => hydraterBlocRecommandations(donnees));
};
if ('requestIdleCallback' in window) {
window.requestIdleCallback(declencherHydratationSecondaire, { timeout: 2000 });
} else {
setTimeout(declencherHydratationSecondaire, 200);
}
}
L’option timeout mérite une attention particulière : sans elle, un navigateur constamment sollicité pourrait repousser indéfiniment l’exécution de la tâche différée. Fixer un délai maximal garantit que le bloc secondaire finit par s’hydrater même sur une page qui reste très active, au prix d’une légère perte de la priorisation recherchée.
Les limites à connaître
Un support qui reste inégal
Cette API n’est pas universellement implémentée par tous les navigateurs, ce qui impose de prévoir un repli, généralement via setTimeout, pour les environnements où elle est absente. Ce repli n’offre pas la même garantie de ne pas interférer avec le fil principal, mais reste préférable à une absence totale de gestion.
Ce que cette technique ne remplace pas
Retarder l’hydratation d’un composant JavaScript déjà présent dans le DOM diffère nettement de l’hydratation partielle par îlots, une approche architecturale distincte où certains composants ne reçoivent jamais de JavaScript côté client tant qu’ils restent purement statiques. requestIdleCallback agit à l’intérieur d’une hydratation classique déjà en place, en ordonnançant simplement son exécution dans le temps, sans changer la nature du rendu initial.
Quand cette technique apporte un bénéfice réel
- Des blocs secondaires clairement identifiables, non nécessaires à l’interaction principale de la page.
- Un appel API distinct pour la donnée du bloc secondaire, qui peut être différé sans bloquer l’affichage du contenu principal.
- Une mesure préalable confirmant que l’hydratation simultanée impacte réellement le délai avant première interaction.
Différer une tâche ne la rend pas gratuite : cela déplace simplement son coût vers un moment où le visiteur est moins susceptible de le remarquer. Encore faut-il avoir identifié le bon moment et la bonne tâche à différer.
En résumé
requestIdleCallback offre un levier simple et peu intrusif pour hiérarchiser l’hydratation d’un front headless composé de plusieurs blocs consommant l’API REST WordPress. Son bénéfice reste mesurable uniquement sur des pages où un bloc secondaire clairement identifié peut attendre sans nuire à l’expérience, et gagne à être vérifié par une mesure réelle plutôt qu’appliqué par principe à l’ensemble des composants d’une page.
