Performance

Par défaut, SvelteKit fait le maximum pour rendre vos applications aussi performantes que possible :

• Du code-splitting, afin qu’uniquement le code dont vous avez besoin pour la page actuelle soit chargé
• Du préchargement d’assets, afin que les “cascades” (de fichiers requêtant d’autres fichiers) soient empêchées
• Du hashing de fichier, afin que vos assets soient mis en cache pour toujours
• De la fusion de requêtes, afin que les données récupérées par des fonctions load de serveur différentes soient groupées en une seule requête HTTP
• Du chargement parallèle, afin que les fonctions load universelles distinctes récupèrent leurs données simultanément
• De l’inlining de données, afin que les requêtes faites avec fetch lors du rendu côté serveur puissent être rejouées dans le navigateur sans générer une nouvelle requête
• De l’invalidation conservative, afin que les fonctions load ne soient ré-exécutées que lorsque nécessaire
• Du pré-rendu (configurable route par route, si besoin), afin que les pages sans données dynamiques puissent être servies instantanément
• Du préchargement de liens, afin que les besoins en données et en code pour les navigations côté client soient anticipés

Néanmoins, nous ne pouvons pas (encore) éliminer toutes les sources de ralentissement. Pour atteindre une performance optimale, vous devriez être conscient•e des astuces suivantes.

Diagnostiquer les problèmes

La site de Google PageSpeed Insights et (pour plus des analyses plus poussées) WebPageTest sont d’excellents moyens de comprendre les caractéristiques de performance d’un site déjà déployé sur internet.

Votre navigateur inclut également des outils de développement utiles pour analyser votre site, qu’il soit déployé ou qu’il tourne localement :

• Chrome - les outils de développement Lighthouse, Network, et Performance
• Edge - les outils de développement Lighthouse, Network, et Performance
• Firefox - les outils de développement Network et Performance
• Safari - améliorer la performance de votre application web

Notez que votre site tournant localement en mode dev va montrer un comportement différent que celui de votre application de production, vous devriez donc faire vos tests de performance en mode preview après avoir compilé votre application.

Instrumentation

Si vous voyez dans l’onglet Réseau de votre navigateur qu’un appel API prend beaucoup de temps et que vous souhaitez comprendre pourquoi, vous pouvez envisager d’instrumenter votre serveur avec des outils comme OpenTelemetry ou les en-têtes Server-Timing .

Optimiser les assets

Images

La réduction de la taille des fichiers d’image est souvent l’un des changements permettant d’avoir le plus d’impact sur la performance d’un site. Svelte fournit le paquet @sveltejs/enhanced-img, dont l’utilisation est détaillée dans la section images, afin de vous faciliter la tâche. De plus, Lighthouse est utile pour identifier les coupables les plus dérangeants.

Videos

Les fichiers vidéo peuvent être très lourds, ils doivent donc être traités avec soin afin qu’ils soient optimisés :

• Compressez les vidéos avec des outils comme Handbrake. Envisagez de convertir vos vidéos dans des formats adaptés au web comme .webm ou .mp4.
• Vous pouvez charger les vidéos situées en dessous de la “ligne de flottaison” (below the fold en anglais) en différé avec preload="none" (même s’il faut noter que ceci va ralentir la lecture lorsque l’utilisateur ou l’utilisatrice souhaite lancer la vidéo).
• Supprimez les pistes audio des vidéos en sourdine avec un outil comme FFmpeg.

Polices de caractères

SvelteKit précharge automatiquement les fichiers .js et .css critiques lorsque l’utilisateur ou l’utilisatrice visite une page, mais il ne précharge pas par défaut les polices, puisque ceci peut provoquer le téléchargement de fichiers non nécessaires (comme des graisses de police référencées par votre CSS mais non utilisées sur la page actuelle). Cela étant dit, précharger correctement les polices peut faire une énorme différence sur les performances ressenties de votre site. Dans votre hook handle, vous pouvez appeler la fonction resolve avec un filtre preload incluant votre police.

Vous pouvez réduire la taille de vos fichiers de police en découpant vos fichiers de police.

Réduire la taille du code

Version de Svelte

Nous recommandons d’utiliser la dernière version de Svelte. Svelte 5 est plus petit et plus rapide que Svelte 4, qui est lui-même plus petit et plus rapide que Svelte 3.

Paquets

L’outil rollup-plugin-visualizer peut être utile pour identifier quels paquets contribuent le plus à la taille de votre site. Vous pouvez également trouver des moyens de supprimer du code en inspectant manuellement la sortie de compilation (utilisez l’option build: { minify: false }) dans votre configuration Vite pour rendre les fichiers compilés lisibles, mais pensez à réactiver la minification avec de déployer votre application), ou via l’onglet Réseau des outils de développement de votre navigateur.

Scripts externes

Essayez de minimiser le nombre de script tiers s’exécutant dans votre navigateur. Par exemple, au lieu d’utiliser des outils d’analyse basés sur JavaScript, envisagez d’en utiliser des implémentations côté serveur, telles que celles proposées par de nombreuses plateformes possédant des adaptateurs SvelteKit, comme Cloudflare, Netlify, et Vercel.

Pour exécuter des scripts tiers dans un web worker (ce qui évite de bloquer le fil d’exécution principal), utilisez l’intégration SvelteKit de PartyTown.

Chargement sélectif

Le code importé avec des déclarations import statiques sera automatiquement inclus dans votre bundle avec le reste de votre page. S’il y a du code dont vous avez uniquement besoin lorsque certaines conditions sont réunies, utilisez la forme dynamique import(...) pour charger en différé vos composants de manière sélective.

Navigation

Préchargement

Vous pouvez accélérer les navigations côté client en préchargeant à l’avance le code et les données nécessaires, en utilisant les options de liens. Ceci est configuré par défaut sur l’élément <body> lorsque vous créez une nouvelle application SvelteKit.

Données non essentielles

Pour les données se chargeant lentement et non nécessaires immédiatement, l’objet renvoyé par votre fonction load peut contenir des promesses plutôt que les données elles-mêmes. Pour les fonctions load de serveur, ceci va provoquer le streaming des données après la navigation (ou après le chargement initial de la page).

Éviter les cascades

Un des plus gros problèmes de performance est ce que l’on appele une cascade, qui peut être une série de requêtes faites séquentiellement. Ceci peut se produire sur le serveur comme dans le navigateur.

• Les cascades d’assets peuvent se produire dans le navigateur lorsque que votre HTML requête du JS qui requête du CSS qui requête une image de fond et une police. SvelteKit va en grande partie vous aider à résoudre ce problème en ajoutant des balises ou des en-têtes modulepreload, mais vous devriez vérifier dans l’onglet Réseau de vos outils de développement si des ressources additionnelles ont besoin d’être préchargées. Portez une attention particulière à ce point si vous utilisez des polices de caractères web puisqu’elles doivent être gérées manuellement.
• Si une fonction load universelle fait un appel API pour récupérer l’utilisateur ou utilisatrice actuelle, puis utilise les informations de cette réponse pour récupérer une liste de choses sauvegardées, puis utilise cette réponse pour récupérer les détails de chaque chose, le navigateur va finir par faire de nombreuses requêtes les unes à la suite des autres. Ceci est fatal pour la performance, particulièrement pour les utilisateurs et utilisatrices qui se trouvent physiquement loin de votre serveur. Vous pouvez éviter ce problème en utilisant des fonctions load de serveur lorsque cela est possible.
• Les fonctions load de serveur ne sont pas non plus immunisées contre les cascades (même si celles-ci sont moins coûteuses puisqu’elles impliquent rarement des aller-retours avec une grande latence). Par exemple, si vous requêtez l’utilisateur ou utilisatrice actuelle puis utilisez ces données pour faire une deuxième requête pour obtenir une liste de choses sauvegardées, il sera typiquement plus efficace de faire une seule requête en utilisant une jointure de base de données.

Hébergement

Votre frontend devrait se trouver dans le même centre de données que votre backend pour minimiser la latence. Pour les sites n’ayant pas de backend central, plusieurs adaptateurs SvelteKit supportent le déploiement sur le réseau edge, ce qui signifie que les requêtes de chaque utilisateur ou utilisatrice seront gérées par un serveur proche de leur emplacement. Ceci peut réduire significativement les temps de chargement. Certains adaptateurs supportent même la configuration du déploiement route par route. Vous devriez également envisager servir les images depuis un CDN (qui sont généralement des réseaux edge) — les hébergeurs de plusieurs adaptateurs SvelteKit feront cela automatiquement.

Assurez-vous que votre hébergeur utiliser HTTP/2 ou plus récent. Le code splitting de Vite crée de nombreux petits fichiers pour améliorer la mise en cache, ce qui implique une excellente performance, mais cela suppose que vos fichiers puissent être chargés en parallèle avec HTTP/2.

Plus de lecture

Construire une application SvelteKit performante est en grande partie la même chose que construire n’importe quelle application web performante. Vous devriez être capable d’appliquer les conseils de n’importe quelle ressource sur les performances web comme Core Web Vitals à n’importe quelle expérience web que vous construisez.