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, mais est particulièrement coûteux lorsque cela implique des données devant parcourir de longues distances ou naviguant sur des réseaux plus lents, comme une personne sur mobile requêtant un serveur distant.

Dans le navigateur, des cascades peuvent se produire lorsque votre HTML déclenche une chaîne de requêtes telle que requêter du JavaScript qui va requêter du CSS qui va requêter une image de fond et une police. SvelteKit résout grandement ce genre de problèmes pour vous en ajoutant des balises ou des en-têtes modulepreload, mais vous devriez observer l’onglet Réseau de vos outils développeur pour vérifier si des ressources additionnelles ont besoin d’être préchargées.

• Faites particulièrement attention à ce point si vous utilisez des polices web puisqu’elles ont besoin d’être gérées manuellement.
• L’activation du mode SPA va provoquer ce genre de cascades. Avec le mode SPA, une page vide est générée, et cette page va ensuite récupérer le code JavaScript, qui va s’exécuter et rendre la page. Ceci induit des aller-retours réseau supplémentaires avant qu’un seul pixel ne puisse être affiché.

Des cascades peuvent également se produire lors d’appels vers le backend faits soit depuis le navigateur soit depuis le serveur. Par ex. si une fonction load universelle fait un appel API pour récupérer l’utilisateur courant, puis utilise les informations de la réponse pour récupérer une liste d’éléments sauvegardés, puis utilise cette réponse pour récupérer les détails de chaque élément, au final le navigateur va effectuer plusieurs requêtes en séquence. Ce type de scénario est destructeur pour les performances, particulièrement pour les personnes étant physiquement éloignées de votre backend.

• Évitez ce problème en utilisant une fonction load de serveur pour faire des requêtes vers des services backend depuis le serveur plutôt que depuis le client. Notez cependant que les fonctions load de serveur ne sont pas immunisées contre les cascades (même si ces cascades y sont moins coûteuses puisqu’impliquant rarement des aller-retours à grande latence). Par exemple, si vous requêtez une base de données pour récupérer l’utilisateur courant puis utilisez cette donnée pour faire une deuxième requête pour une liste d’éléments enregistrés, il sera généralement plus performant de créer une seule requête de base de données contenant une jointure.

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.