Optimiser les performances d'une application Nuxt sans complexifier le projet
Un guide pratique pour améliorer les Core Web Vitals d'une application Nuxt avec le bon rendu, des images optimisées, du cache et un chargement plus léger.
Pourquoi les performances comptent
Une application lente fait perdre des utilisateurs, mais elle fait aussi perdre en visibilité. Les performances influencent directement l'expérience utilisateur et, dans une certaine mesure, le référencement.
Quand une page met trop de temps à s'afficher, l'utilisateur n'attend pas toujours. Il ferme l'onglet, revient en arrière ou se tourne vers un concurrent. L'objectif de l'optimisation n'est donc pas d'obtenir un score artificiel : c'est de rendre l'application réellement plus agréable et plus fiable.
Les métriques à suivre en priorité sont les Core Web Vitals :
- LCP : le contenu principal doit apparaître rapidement
- INP : les interactions doivent rester fluides
- CLS : la page ne doit pas bouger de manière imprévisible
Avant d'optimiser, choisissez le bon mode de rendu
Nuxt permet de choisir le mode de rendu route par route. C'est l'un de ses plus gros avantages, car toutes les pages n'ont pas les mêmes besoins.
Quelques repères simples :
- prerender / SSG pour les pages très stables comme l'accueil ou les pages marketing
- SSR pour les pages qui doivent afficher des données fraîches dès le premier chargement
- ISR pour les pages qui peuvent être régénérées périodiquement
- SPA pour certaines zones privées ou très interactives
Le plus important est d'éviter une règle unique pour tout le site.
1. Choisir la bonne stratégie de rendu
Nuxt propose plusieurs modes selon la nature de vos pages. Définissez-les précisément avec routeRules pour ne pas rendre tout votre site plus lourd que nécessaire.
// nuxt.config.ts
export default defineNuxtConfig({
routeRules: {
'/': { prerender: true },
'/blog/**': { isr: 3600 },
'/dashboard/**': { ssr: false },
'/api/**': { cache: { maxAge: 60 } },
},
})
En pratique :
prerenderconvient très bien aux pages statiquesisrévite de reconstruire tout le site pour une simple mise à jourssr: falsepeut être utile pour une zone d'administration riche en interactions- le cache API réduit la charge serveur et accélère les réponses répétées
Cette décision initiale a souvent plus d'impact que beaucoup d'autres micro-optimisations.
2. Optimiser les images avec @nuxt/image
Les images sont l'une des premières causes de lenteur. Une image trop lourde peut ruiner un bon travail sur le reste de la page.
const image = {
src: '/photo.jpeg',
width: 400,
height: 400,
format: 'webp',
loading: 'lazy',
sizes: 'sm:100vw md:50vw lg:400px',
}
@nuxt/image apporte plusieurs bénéfices à la fois :
- génération automatique des tailles adaptées
- formats modernes comme WebP ou AVIF selon la configuration
- chargement différé des images hors écran
- réduction du poids transféré au navigateur
Le bon réflexe est simple : ne servez jamais une image plus grande que nécessaire. Une image de 2500 pixels affichée dans un bloc de 400 pixels gaspille du temps et de la bande passante.
3. Code splitting et imports dynamiques
Plus une page charge de JavaScript, plus elle met du temps à devenir interactive. Il est donc utile de charger certains composants uniquement quand ils sont réellement nécessaires.
// Ne charger un composant que quand il est visible
const HeavyChart = defineAsyncComponent(() => import('~/components/HeavyChart.vue'))
Pour les composants utilisés uniquement côté client, combinez cela avec ClientOnly :
const HeavyChart = defineAsyncComponent(() => import('~/components/HeavyChart.vue'))
const chartStrategy = {
ssr: false,
fallback: 'skeleton h-48',
}
Cette stratégie est particulièrement utile pour :
- les graphiques lourds
- les éditeurs de texte riches
- les cartes interactives
- les composants qui dépendent du navigateur
Le but est de ne pas bloquer l'affichage de la page avec du code qui n'est pas indispensable au premier rendu.
4. Caching des requêtes serveur
Si votre application appelle souvent les mêmes données, le cache peut faire une énorme différence. Inutile de recalculer ou de refetch les mêmes informations à chaque requête si elles changent rarement.
// server/api/portfolio.get.ts
export default defineCachedEventHandler(async (event) => {
return await fetchPortfolioData()
}, {
maxAge: 60 * 60,
swr: true,
getKey: () => 'portfolio',
})
Ce pattern est particulièrement intéressant pour :
- des pages de portfolio
- des listes d'articles
- des contenus qui changent peu
- des réponses d'API coûteuses à produire
Le mode stale-while-revalidate est très utile, car il permet de servir une version rapide tout en régénérant les données en arrière-plan.
Vous pouvez également cacher côté client quand cela a du sens, mais la première vraie économie de temps se fait souvent côté serveur.
5. Payload et compression
Nuxt peut aussi vous aider à réduire le poids global de la page générée. Moins vous envoyez de données inutiles, plus le chargement est rapide.
// nuxt.config.ts
export default defineNuxtConfig({
nitro: {
compressPublicAssets: true,
minify: true,
},
experimental: {
payloadExtraction: true,
},
})
Quelques bonnes pratiques utiles :
- limitez les données envoyées au client au strict nécessaire
- évitez de surcharger
useAsyncDataavec des objets trop volumineux - préférez des réponses API compactes
- supprimez les champs que l'interface n'utilise pas
Si vous envoyez moins de données, vous gagnez à la fois en temps réseau et en temps de traitement JavaScript.
6. Réduire le travail du navigateur
Optimiser Nuxt, ce n'est pas seulement réduire le poids du HTML. C'est aussi faire en sorte que le navigateur ait moins de travail à faire après le chargement.
Quelques leviers simples :
- évitez de multiplier les états locaux inutiles
- ne chargez pas de librairies lourdes pour un usage marginal
- préférez des composants simples quand un composant complexe n'apporte rien
- gardez les calculs coûteux hors du cycle de rendu si possible
Une page plus simple est souvent une page plus rapide.
7. Mesurer avec Lighthouse
Avant d'optimiser, mesurez. Sans mesure, vous risquez d'améliorer une chose invisible et de laisser le vrai problème intact.
Les indicateurs à surveiller :
- LCP : le plus grand élément visible doit arriver rapidement
- INP : la réactivité doit rester bonne
- CLS (Cumulative Layout Shift) : < 0,1
npx unlighthouse --site https://monsite.com
Vous pouvez aussi utiliser Lighthouse, les DevTools du navigateur et les logs serveur pour comprendre où part le temps.
Une méthode simple pour prioriser les optimisations
Si vous ne savez pas par où commencer, avancez dans cet ordre :
- choisir le bon mode de rendu avec
routeRules - compresser et alléger les images
- réduire le JavaScript chargé au premier affichage
- mettre en cache les réponses répétées
- mesurer à nouveau pour vérifier le gain réel
Cette méthode permet d'obtenir des résultats visibles sans disperser l'effort.
Les erreurs fréquentes
Voici les pièges les plus courants :
- tout rendre en SSR sans réfléchir
- charger des images trop lourdes
- utiliser trop de composants client-only
- oublier le cache sur des données statiques
- optimiser sans mesurer
La performance n'est pas un geste isolé. C'est une suite de petites décisions cohérentes.
Conclusion
L'optimisation d'une application Nuxt doit rester pragmatique. Commencez par le mode de rendu, allégez les images, chargez moins de JavaScript et mettez en cache ce qui peut l'être.
Si vous mesurez après chaque changement, vous saurez exactement ce qui améliore vraiment l'expérience utilisateur. C'est cette discipline qui permet d'avoir une application rapide, propre et durable.