Statische SvelteKit-Website mit adapter-static hosten

Q: Welchen SvelteKit-Adapter sollte ich für Lobsite verwenden?

@sveltejs/adapter-static, mit jeder Seite vorgerendert. adapter-auto und die Plattform-Adapter bauen für Server und Functions, die Lobsite nicht ausführt.

Q: Läuft hier eine SvelteKit-SPA mit Fallback-Seite?

Ja. Setze adapter({ fallback: "200.html" }): Lobsite liefert 200.html mit Status 200 für jeden Pfad aus, der keine Datei ist, und der Router von SvelteKit rendert die Seite im Browser. Vorgerenderte Seiten werden weiterhin so ausgeliefert, wie sie sind.

Q: Warum ist mein SvelteKit-Build mit einem Prerender-Fehler gescheitert?

Eine Seite konnte beim Build nicht rendern, oft weil sie url.searchParams, Cookies oder eine Form Action liest. Verlagere diese Arbeit in den Browser oder in eine load-Funktion, die nur Daten nutzt, die beim Build verfügbar sind.

SvelteKit kann mit @sveltejs/adapter-static jede Seite beim Build vorrendern und das Ergebnis als schlichte Dateien schreiben. Lobsite hostet diese Dateien. Bau mit dem statischen Adapter, führe npx lobsite aus, und die Website ist unter einer *.lobsite.app-Adresse mit HTTPS live. Diese Seite behandelt vollständig vorgerenderte Websites. Server-Routen und Form Actions brauchen einen Hoster, der SvelteKit auf einem Server ausführt.

So funktioniert es

Wechsle zum statischen Adapter und rendere jede Seite vor (siehe unten), dann führe npm run build aus. Die Website landet in build/.
Führe npx lobsite aus im Projekt. Es deployt build/, nicht static/ oder .svelte-kit/. Das erste Deploy braucht kein Konto und hält 6 Stunden.
Behalte sie mit dem Übernahme-Link, in einem kostenlosen Konto. Danach aktualisiert npm run build && npx lobsite dieselbe Adresse.

adapter-static und Vorrendern

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

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

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

prerender = true im Root-Layout lässt jede Seite beim Build rendern. Kann eine Seite nicht vorgerendert werden, scheitert der Build und nennt sie, damit nichts Kaputtes deployt wird.
fallback: "200.html" ist für Seiten, die sich nicht vorrendern lassen: SvelteKit schreibt eine 200.html-Hülle, und Lobsite liefert sie für jeden Pfad aus, der keine Datei ist, sodass diese Seiten im Browser rendern. Vorgerenderte Seiten sind trotzdem besser für Suchmaschinen und den ersten Ladevorgang.
trailingSlash kann beim Standard bleiben: /about wird als about.html geschrieben und unter /about ausgeliefert.

Was beim Build läuft und was nicht geht

load-Funktionen, auch die in +page.server.js, laufen beim Build, wenn eine Seite vorgerendert wird; Daten aus Dateien oder APIs werden also ins HTML eingebacken. Dynamische Routen werden gefunden, indem den Links deiner Seiten gefolgt wird; trag nicht verlinkte in prerender.entries ein. Ohne Server geht nicht: Form Actions, +server.js-Endpunkte außer vorgerenderten GET-Endpunkten, Hooks, die pro Anfrage laufen, und das Lesen von Cookies. Für ein Kontaktformular sende an /_lobsite/forms/contact statt an eine Form Action; siehe Formulare.

Nur geänderte Dateien werden hochgeladen

Dateien werden nach ihrem Hash gespeichert. Ein erneutes Deploy einer unveränderten Website lädt 0 Bytes hoch.

Jedes Deploy bekommt eine URL

Vorschau ansehen, bevor es live geht. Mit einem Klick zurückrollen, samt Weiterleitungen.

HTTPS überall

Jede Website bekommt ab dem ersten Deploy eine *.lobsite.app-Adresse mit HTTPS.

Formulare, die einfach funktionieren

Lass ein Formular auf /_lobsite/forms/contact zeigen. Spamfilter inklusive.

Konfiguration in einer Datei

Weiterleitungen, Header und Formulare stehen in lobsite.toml und reisen mit jedem Deploy mit.

Limits, die du nachlesen kannst

Jedes Limit ist veröffentlicht, und jeder Fehler sagt dir, was als Nächstes zu tun ist.

SvelteKit-Hoster im Vergleich

	Lobsite	Vercel	Netlify	Cloudflare Pages
Vorgerenderte Websites (`adapter-static`)	Ja	Ja	Ja	Ja
Server-Rendering, Form Actions	Nein	Ja	Ja	Ja
Baut auf dem Server	Nein: du deployst `build/`	Ja	Ja	Ja
Konto vor dem ersten Deploy	Nein: 6 Stunden live, dann kostenlos behalten	Ja	Ja	Ja
Formulare ohne Backend	Ja, sobald die Website in einem Konto ist	Nein	Ja	Nein
Eigene Domain	Ja, kostenlos	Ja	Ja	Ja

Rendert deine App Seiten auf Anfrage, nimm einen Adapter für einen Hoster, der sie ausführt. Lässt sich jede Seite vorrendern, wie bei Marketing-Websites, Blogs und Doku, hostet Lobsite sie mit einem Befehl und lädt nur die Dateien hoch, die sich mit jedem Build geändert haben.

Häufige Fragen

Welchen SvelteKit-Adapter sollte ich für Lobsite verwenden?

@sveltejs/adapter-static, mit jeder Seite vorgerendert. adapter-auto und die Plattform-Adapter bauen für Server und Functions, die Lobsite nicht ausführt.

Läuft hier eine SvelteKit-SPA mit Fallback-Seite?

Ja. Setze adapter({ fallback: "200.html" }): Lobsite liefert 200.html mit Status 200 für jeden Pfad aus, der keine Datei ist, und der Router von SvelteKit rendert die Seite im Browser. Vorgerenderte Seiten werden weiterhin so ausgeliefert, wie sie sind.

Warum ist mein SvelteKit-Build mit einem Prerender-Fehler gescheitert?

Eine Seite konnte beim Build nicht rendern, oft weil sie url.searchParams, Cookies oder eine Form Action liest. Verlagere diese Arbeit in den Browser oder in eine load-Funktion, die nur Daten nutzt, die beim Build verfügbar sind.

Funktionieren Seitenübergänge von SvelteKit nach dem Vorrendern noch?

Ja. Die vorgerenderten Seiten laden den Client von SvelteKit, der nach der ersten Seite die Navigation übernimmt; Links wechseln die Seite also weiterhin ohne komplettes Neuladen.

Statisches SvelteKit-Hosting