Hébergement statique SvelteKit

SvelteKit peut prérendre chaque page au build et écrire le résultat sous forme de fichiers simples avec @sveltejs/adapter-static. Lobsite héberge ces fichiers. Buildez avec l’adaptateur statique, lancez npx lobsite, et le site est en ligne à une adresse *.lobsite.app en HTTPS. Cette page porte sur les sites entièrement prérendus. Les routes serveur et les form actions exigent un hébergeur qui exécute SvelteKit sur un serveur.

Comment ça marche

1. Passez à l’adaptateur statique et prérendez chaque page (voir ci-dessous), puis lancez npm run build. Le site arrive dans build/.
2. Lancez npx lobsite dans le projet. Il déploie build/, pas static/ ni .svelte-kit/. Le premier déploiement ne demande pas de compte et dure 6 heures.
3. Gardez-le grâce au lien de récupération, dans un compte gratuit. Ensuite, npm run build && npx lobsite met à jour la même adresse.

adapter-static et prérendu

// svelte.config.js
import adapter from "@sveltejs/adapter-static";

export default {
  kit: { adapter: adapter() },
};

// src/routes/+layout.js
export const prerender = true;

• prerender = true dans le layout racine fait rendre chaque page au build. Si une page ne peut pas être prérendue, le build échoue et vous dit laquelle : rien de cassé n’est déployé.
• fallback: "200.html" sert aux pages qui ne peuvent pas être prérendues : SvelteKit écrit une coquille 200.html, et Lobsite la sert pour tout chemin qui n’est pas un fichier, si bien que ces pages s’affichent dans le navigateur. Les pages prérendues restent meilleures pour les moteurs de recherche et le premier chargement.
• trailingSlash peut garder sa valeur par défaut : /about est écrit en about.html et servi à /about.

Ce qui s’exécute au build, et ce qui ne peut pas

Les fonctions load, y compris celles de +page.server.js, s’exécutent pendant le build quand une page est prérendue : les données venant de fichiers ou d’API sont intégrées au HTML. Les routes dynamiques sont trouvées en suivant les liens de vos pages ; listez celles qui ne sont pas liées dans prerender.entries. Ce qui ne peut pas fonctionner sans serveur : les form actions, les endpoints +server.js autres que les GET prérendus, les hooks exécutés à chaque requête et la lecture des cookies. Pour un formulaire de contact, envoyez-le vers /_lobsite/forms/contact plutôt que vers une form action ; voir formulaires.

Hébergeurs SvelteKit comparés

Si votre application rend des pages à la demande, utilisez un adaptateur pour un hébergeur qui l’exécute. Si chaque page peut être prérendue, comme pour les sites vitrines, les blogs et la documentation, Lobsite l’héberge en une commande et n’envoie que les fichiers modifiés par chaque build.

Questions fréquentes

Quel adaptateur SvelteKit utiliser pour Lobsite ?

@sveltejs/adapter-static, avec chaque page prérendue. adapter-auto et les adaptateurs de plateforme buildent pour des serveurs et des fonctions, que Lobsite n’exécute pas.

Une SPA SvelteKit avec page de repli peut-elle tourner ici ?

Oui. Définissez adapter({ fallback: "200.html" }) : Lobsite sert 200.html avec un statut 200 pour tout chemin qui n’est pas un fichier, et le routeur de SvelteKit affiche la page dans le navigateur. Les pages prérendues sont toujours servies telles quelles.

Pourquoi mon build SvelteKit a-t-il échoué avec une erreur de prérendu ?

Une page n’a pas pu être rendue au build, souvent parce qu’elle lit url.searchParams, des cookies ou une form action. Déplacez ce travail dans le navigateur, ou dans une fonction load qui n’utilise que des données disponibles au build.

Les transitions de page de SvelteKit fonctionnent-elles encore après le prérendu ?

Oui. Les pages prérendues chargent le client de SvelteKit, qui prend en charge la navigation après la première page : les liens changent donc de page sans rechargement complet.