Nuxt : choisir entre Lazy et ClientOnly sans déplacer le problème

Dans une application Nuxt, un composant peut être coûteux pour deux raisons différentes : il est inutile au premier affichage, ou il dépend d’un environnement disponible uniquement dans le navigateur. Lazy et ClientOnly peuvent alors sembler interchangeables. Ils ne répondent pourtant pas au même problème.

Le préfixe Lazy agit sur le moment où un composant est chargé. ClientOnly agit sur le contexte dans lequel il est rendu. La décision ne consiste donc pas à choisir l’option la plus « performante » en général, mais à identifier ce que l’on cherche à éviter : du JavaScript chargé trop tôt, un rendu serveur impossible, un contenu absent du HTML initial ou une complexité inutile.

Première bifurcation : que cherchez-vous à retarder ?

Commencez par décrire le symptôme observé, sans nommer immédiatement la directive ou le composant. Trois situations reviennent souvent :

• Le composant est rarement utilisé ou apparaît après une action de l’utilisateur : la question porte d’abord sur son chargement.
• Le composant utilise une API du navigateur, une librairie graphique ou une information locale indisponible côté serveur : la question porte d’abord sur son rendu.
• Le composant contient une information importante dès l’arrivée sur la page : il faut préserver son contenu initial avant de chercher à l’optimiser.

Cette première qualification évite de traiter un problème de compatibilité comme un problème de poids, ou inversement.

Si le composant peut attendre, examinez Lazy

Le préfixe Lazy, utilisé devant un composant comme <LazyMonComposant />, sert à indiquer que ce composant peut être chargé plus tard. Cette approche convient à un élément secondaire : panneau de filtres fermé par défaut, fenêtre modale, bloc de statistiques situé plus bas dans la page ou fonctionnalité ouverte après un clic.

La bonne question est : « l’utilisateur a-t-il besoin de ce composant avant cette interaction ? » Si la réponse est non, retarder son chargement peut réduire le travail demandé au premier affichage. Cela ne rend pas automatiquement le composant plus léger, et ne dispense pas de vérifier son comportement lorsqu’il apparaît.

Avant de retenir cette option, documentez quatre points :

1. L’action qui déclenche l’affichage du composant.
2. Le délai acceptable entre cette action et la disponibilité du composant.
3. Le comportement prévu pendant l’attente.
4. La manière de vérifier que le chargement différé n’a pas cassé le parcours.

Un composant chargé tardivement doit donc avoir un état d’attente compréhensible et un scénario de test associé. Une optimisation qui transforme un clic simple en écran vide n’est pas un gain exploitable.

Si le composant dépend du navigateur, examinez ClientOnly

ClientOnly correspond à une autre situation : le composant ne doit être rendu que dans le navigateur. C’est pertinent lorsqu’il s’appuie sur des objets ou des capacités absents de l’environnement serveur, par exemple une mesure de fenêtre, une interaction directe avec le document ou une librairie qui suppose la présence du navigateur.

Cette décision a une conséquence éditoriale et fonctionnelle : le contenu placé dans cette zone n’est pas disponible de la même manière dans le rendu initial. Il faut donc éviter d’y enfermer une information essentielle à la compréhension de la page, un titre, une description de produit ou un contenu que l’utilisateur doit voir immédiatement.

ClientOnly ne signifie pas « charger plus tard parce que le composant est lourd ». Il signifie « ne pas tenter de rendre ce composant côté serveur ». Si le composant n’a aucun problème avec le rendu serveur mais reste secondaire, Lazy répond probablement mieux à la question.

L’arbre de décision à utiliser avant de modifier le code

Question	Réponse	Orientation
Le composant est-il nécessaire dès le premier affichage ?	Non	Évaluer Lazy et prévoir un état d’attente.
Le composant dépend-il d’une API ou d’un état propre au navigateur ?	Oui	Évaluer ClientOnly et prévoir un contenu de remplacement.
Le contenu est-il important pour comprendre la page ou agir immédiatement ?	Oui	Éviter de le masquer par défaut ; revoir le découpage du composant.
Les deux problèmes existent-ils en même temps ?	Oui	Combiner avec prudence, puis tester le rendu initial et l’interaction.

La combinaison de Lazy et ClientOnly peut avoir du sens lorsqu’un composant est à la fois secondaire et dépendant du navigateur. Elle ajoute toutefois deux conditions à vérifier : le composant ne doit pas être attendu dans le rendu initial, et son apparition doit rester compréhensible après l’action de l’utilisateur. Dans une PME, cette combinaison mérite une décision écrite, car elle modifie à la fois le chargement et le parcours de rendu.

Le critère décisif : préserver la promesse de la page

Une page de présentation, une fiche de service ou un écran d’accueil n’a pas la même tolérance qu’un tableau de bord ouvert après authentification. Dans le premier cas, le contenu principal doit rester immédiatement lisible. Dans le second, un module interactif ou analytique peut être différé si l’utilisateur a d’abord besoin d’un état général.

Pour les pages publiques, examinez notamment :

• le contenu visible sans interaction ;
• les textes nécessaires à la compréhension de l’offre ;
• les éléments qui structurent la navigation ;
• le comportement de la page lorsque JavaScript n’est pas encore disponible ;
• la cohérence entre le contenu initial et le contenu après hydratation.

Pour un espace métier, ajoutez les critères d’exploitation : délai acceptable après une action, message affiché en cas d’échec, possibilité de reprendre l’opération et capacité du support à expliquer le comportement.

Les livrables à demander avant de valider l’optimisation

Le choix entre Lazy et ClientOnly ne devrait pas rester dans une modification isolée du code. Demandez une courte note de décision contenant le composant concerné, le problème initial, l’option retenue, les conséquences attendues et les limites connues. Ajoutez un scénario de vérification avec le rendu initial, l’action qui déclenche le composant et le comportement en cas d’erreur.

La recette de non-régression avant production peut fournir un cadre utile pour vérifier que l’optimisation n’a pas modifié un parcours métier ou une fonction déjà attendue.

Si le composant utilise aussi des données, des identités ou un service externe, consignez la responsabilité de chaque élément : qui fournit les données, qui gère l’état d’attente, qui surveille l’erreur et qui décide d’un retour arrière. Cette discipline rejoint les principes d’un document de décision d’architecture exploitable, sans transformer chaque ajustement en dossier volumineux.

La décision à retenir

Choisissez Lazy lorsque le composant peut attendre et que le sujet principal est le moment de son chargement. Choisissez ClientOnly lorsque le sujet principal est l’impossibilité ou l’inutilité d’un rendu côté serveur. N’utilisez aucune des deux options pour masquer un contenu essentiel ou pour compenser un composant mal découpé.

La meilleure optimisation est celle qui relie une cause observable, un comportement attendu et une preuve de vérification. Dans Nuxt, cette méthode permet de gagner en maîtrise sans confondre chargement différé, rendu côté client et simple déplacement du problème.