SvelteKit

Qu'est-ce que SvelteKit ?

SvelteKit est un framework pour créer des applications web avec Svelte. Svelte gère les composants d'interface, et SvelteKit ajoute ce dont une application complète a besoin : routage par fichiers, chargement de données, points d'accès serveur et gestion des formulaires. Les pages peuvent être rendues sur le serveur, dans le navigateur ou au moment du build, au choix pour chaque route. Il joue pour Svelte le rôle que Next.js joue pour React et Nuxt pour Vue.

Le développement s'appuie sur Vite : les changements de code apparaissent dans le navigateur grâce au remplacement de modules à chaud (HMR).

Comment fonctionnent le routing et le chargement des données

Les routes viennent de l'arborescence de dossiers sous src/routes. Les fichiers qui commencent par + définissent le comportement d'une route :

• +page.svelte est la page elle-même. Elle est rendue sur le serveur à la première requête, puis dans le navigateur lors des navigations suivantes.
• +page.js exporte une fonction load exécutée sur le serveur au premier rendu et dans le navigateur lors d'une navigation côté client.
• +page.server.js a un load exécuté uniquement sur le serveur : il peut donc accéder à une base de données ou à des variables d'environnement privées. Il peut aussi exporter des form actions.
• +layout.svelte encadre les pages enfants avec une interface commune, comme la navigation.
• +server.js crée un point d'accès d'API en exportant des gestionnaires nommés d'après les méthodes HTTP, comme GET et POST.

Un dossier entre crochets comme src/routes/blog/[slug] correspond à un segment dynamique, disponible sous params.slug dans load.

Options de rendu

Trois options de page contrôlent le rendu d'une route. ssr est activée par défaut : les pages sont d'abord rendues sur le serveur (rendu côté serveur). csr l'est aussi, et le HTML du serveur devient interactif dans le navigateur, une étape appelée hydratation. prerender construit une route en HTML statique au build, c'est la génération de sites statiques. Avec ssr à false dans le layout racine, l'application devient une application monopage (SPA), et avec csr à false, aucun JavaScript n'est envoyé au client.

Vous pouvez les combiner dans une même application : prérendre les pages marketing, rendre un tableau de bord sur le serveur et garder un outil uniquement côté client.

Adapters : déployez où vous voulez

Un adapter convertit l'application construite en quelque chose qu'un hébergeur peut exécuter. La documentation de SvelteKit liste des adapters officiels pour les serveurs Node (adapter-node), la sortie entièrement statique (adapter-static), Vercel, Netlify, Cloudflare Workers et Pages, et Bun. Choisissez celui qui correspond à l'endroit où l'application tournera, et rappelez-vous qu'un adapter entièrement statique ne fonctionne que si toutes les routes peuvent être prérendues.

Form actions

Les form actions permettent à un fichier +page.server.js de traiter les envois de <form> sur le serveur. Elles utilisent POST et fonctionnent sans JavaScript côté client. Avec use:enhance, le formulaire est envoyé par fetch sans rechargement de page, avec le même code serveur. Pour des API JSON ou d'autres requêtes qui ne sont pas des formulaires, utilisez plutôt un point d'accès +server.js.

Erreurs courantes

• Mettre des secrets dans un load universel (+page.js). Il s'exécute aussi dans le navigateur : l'accès aux bases de données et les variables privées vont dans +page.server.js.
• Prérendre une page qui a des form actions. D'après la documentation, ces pages ne peuvent pas être prérendues.
• Choisir l'adapter statique pour une application dont des routes dynamiques ne peuvent pas être prérendues.
• Laisser trailingSlash sur 'ignore'. /x et /x/ deviennent deux URL distinctes, ce qui nuit au SEO selon la documentation. La valeur par défaut est 'never'.

SvelteKit, tests de charge et surveillance

Les routes rendues sur le serveur font un vrai travail à chaque requête : fonctions load, appels à la base de données et rendu HTML. C'est là qu'il faut regarder quand le trafic augmente. Lancez un test de charge sur les routes importantes, comme la page d'accueil, une page riche en données et vos points d'accès +server.js, et suivez le temps de réponse et les erreurs à mesure que les utilisateurs virtuels augmentent. L'article (en anglais) How to load test single-page applications traite le côté lourd du navigateur.

Après la mise en ligne, la surveillance d'API contrôle vos points d'accès selon un calendrier, et la surveillance de la vitesse des pages suit les Core Web Vitals pour qu'une version lente se remarque vite.

Questions fréquentes sur SvelteKit

Quelle différence entre Svelte et SvelteKit ?

Svelte est le framework de composants pour l'interface. SvelteKit est le framework d'application qui l'entoure et ajoute routage, chargement de données, rendu serveur, points d'accès et adapters de déploiement.

SvelteKit utilise-t-il le rendu côté serveur ?

Oui, par défaut. Les pages sont rendues sur le serveur à la première requête, puis deviennent interactives dans le navigateur. Vous pouvez le désactiver par route ou pour toute l'application.

SvelteKit peut-il générer un site statique ?

Oui. Prérendez les routes et utilisez l'adapter statique. Cela ne marche que si toutes les routes peuvent être prérendues : les pages qui dépendent de données au moment de la requête ou de form actions demandent un autre adapter.

Où déployer une application SvelteKit ?

Partout où un adapter officiel ou communautaire existe. Les officiels couvrent les serveurs Node, l'hébergement statique, Vercel, Netlify, Cloudflare et Bun.

Quelle différence entre SvelteKit, Next.js et Nuxt ?

L'idée est la même : un framework full-stack avec routage et rendu serveur. La différence tient à la bibliothèque d'interface sous-jacente, Svelte plutôt que React ou Vue.