Statische SvelteKit-hosting

SvelteKit kan met @sveltejs/adapter-static elke pagina tijdens de build vooraf renderen en het resultaat als gewone bestanden schrijven. Lobsite host die bestanden. Bouw met de statische adapter, voer npx lobsite uit, en de site staat live op een *.lobsite.app-adres met HTTPS. Deze pagina gaat over volledig vooraf gerenderde sites. Serverroutes en form actions hebben een host nodig die SvelteKit op een server draait.

Zo werkt het

1. Stap over op de statische adapter en render elke pagina vooraf (zie hieronder), voer dan npm run build uit. De site komt in build/ terecht.
2. Voer npx lobsite uit in het project. Het deployt build/, niet static/ of .svelte-kit/. De eerste deploy heeft geen account nodig en duurt 6 uur.
3. Houd hem met de claimlink, in een gratis account. Daarna werkt npm run build && npx lobsite hetzelfde adres bij.

adapter-static en prerendering

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

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

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

• prerender = true in de root-layout laat elke pagina tijdens de build renderen. Kan een pagina niet vooraf worden gerenderd, dan mislukt de build en zegt hij welke, zodat er niets kapots wordt gedeployd.
• fallback: "200.html" is voor pagina's die niet vooraf kunnen worden gerenderd: SvelteKit schrijft een 200.html-shell, en Lobsite serveert die voor elk pad dat geen bestand is, zodat die pagina's in de browser renderen. Vooraf gerenderde pagina's blijven beter voor zoekmachines en de eerste keer laden.
• trailingSlash kan op de standaardwaarde blijven: /about wordt geschreven als about.html en geserveerd op /about.

Wat tijdens de build draait, en wat niet kan

load-functies, ook die in +page.server.js, draaien tijdens de build als een pagina vooraf wordt gerenderd, dus data uit bestanden of API's wordt in de HTML gebakken. Dynamische routes worden gevonden door de links op je pagina's te volgen; zet routes waar niets naar linkt in prerender.entries. Wat zonder server niet kan werken: form actions, +server.js-endpoints behalve vooraf gerenderde GET-endpoints, hooks die per verzoek draaien, en cookies lezen. Post een contactformulier naar /_lobsite/forms/contact in plaats van naar een form action; zie formulieren.

SvelteKit-hosts vergeleken

Rendert je app pagina's op verzoek, gebruik dan een adapter voor een host die hem draait. Kan elke pagina vooraf worden gerenderd, zoals bij marketingsites, blogs en documentatie, dan host Lobsite hem met één opdracht en uploadt alleen de bestanden die elke build heeft veranderd.

Veelgestelde vragen

Welke SvelteKit-adapter moet ik voor Lobsite gebruiken?

@sveltejs/adapter-static, met elke pagina vooraf gerenderd. adapter-auto en de platformadapters bouwen voor servers en functions, die Lobsite niet draait.

Kan een SvelteKit-SPA met fallbackpagina hier draaien?

Ja. Stel adapter({ fallback: "200.html" }) in: Lobsite serveert 200.html met status 200 voor elk pad dat geen bestand is, en de router van SvelteKit rendert de pagina in de browser. Vooraf gerenderde pagina's worden nog steeds geserveerd zoals ze zijn.

Waarom mislukte mijn SvelteKit-build met een prerender-fout?

Een pagina kon tijdens de build niet renderen, vaak omdat hij url.searchParams, cookies of een form action leest. Verplaats dat werk naar de browser, of naar een load-functie die alleen data gebruikt die tijdens de build beschikbaar is.

Werken de paginaovergangen van SvelteKit nog na prerendering?

Ja. De vooraf gerenderde pagina's laden de client van SvelteKit, die na de eerste pagina de navigatie overneemt, dus links wisselen nog steeds van pagina zonder volledige herlaadbeurt.