SvelteKit et WordPress headless : un front léger en quelques heures

Après plusieurs projets React et Vue en headless, un client m’a demandé d’évaluer SvelteKit pour un site vitrine à fort trafic mobile, où chaque kilo-octet de JavaScript comptait pour le temps de chargement. SvelteKit compile les composants à la construction plutôt que d’embarquer un framework runtime complet dans le navigateur, ce qui se traduit concrètement par un bundle JavaScript nettement plus léger qu’un équivalent React ou Vue pour une page comparable.

Cet article détaille la mise en place d’un front SvelteKit consommant l’API REST WordPress : structure des routes, récupération des données, rendu serveur. Il ne compare pas les performances chiffrées avec Next.js ou Nuxt, un exercice qui mériterait son propre protocole de mesure plutôt qu’une comparaison rapide en fin d’article.

Initialiser le projet

npm create svelte@latest mon-front-wp
cd mon-front-wp
npm install
npm run dev

Le générateur propose plusieurs options à la création (TypeScript, ESLint, tests) : pour un projet headless consommant une API externe, je recommande d’activer TypeScript dès le départ, la structure des réponses WordPress bénéficiant grandement d’un typage explicite des champs attendus.

Routage basé fichiers

SvelteKit organise les routes selon l’arborescence du dossier src/routes, avec une convention proche de celle de Next.js mais des noms de fichiers différents : un dossier [slug] représente un segment dynamique, et chaque route peut avoir un fichier +page.svelte pour l’affichage et un fichier +page.js (ou +page.server.js) pour le chargement des données.

src/routes/
├── +page.svelte              (page d'accueil)
├── +page.js
└── article/
    └── [slug]/
        ├── +page.svelte
        └── +page.js

Charger les données avec la fonction load

Chaque route peut exporter une fonction load, exécutée avant le rendu du composant, côté serveur si le fichier se nomme +page.server.js, ou potentiellement aussi côté client sinon :

// src/routes/article/[slug]/+page.server.js
export async function load({ params, fetch }) {
  const reponse = await fetch(
    `https://exemple.fr/wp-json/wp/v2/posts?slug=${params.slug}&_embed`
  );

  if (!reponse.ok) {
    throw new Error(`Erreur API : ${reponse.status}`);
  }

  const articles = await reponse.json();

  if (articles.length === 0) {
    throw error(404, 'Article introuvable');
  }

  return { article: articles[0] };
}

Le composant +page.svelte associé reçoit ces données via la prop data, sans avoir à gérer d’état de chargement côté client puisque le rendu serveur a déjà résolu la requête avant l’envoi du HTML :

<script>
  export let data;
</script>

<article>
  <h1>{data.article.title.rendered}</h1>
  {@html data.article.content.rendered}
</article>

La directive {@html} est l’équivalent Svelte de dangerouslySetInnerHTML en React : elle insère le HTML brut sans échappement, indispensable pour afficher le contenu Gutenberg déjà rendu par WordPress, mais à réserver strictement à des sources de confiance comme votre propre API WordPress.

Prérendu pour les pages statiques

Pour les pages dont le contenu change rarement (pages institutionnelles, articles anciens), SvelteKit permet de forcer un prérendu au moment du build plutôt qu’un rendu à la demande à chaque requête :

// src/routes/a-propos/+page.js
export const prerender = true;

export async function load({ fetch }) {
  const reponse = await fetch('https://exemple.fr/wp-json/wp/v2/pages?slug=a-propos');
  const pages = await reponse.json();
  return { page: pages[0] };
}

Déploiement selon l’adaptateur choisi

SvelteKit s’appuie sur un système d’adaptateurs pour cibler différentes plateformes de déploiement (Node.js, Vercel, Netlify, ou export purement statique) :

npm install -D @sveltejs/adapter-vercel

// svelte.config.js
import adapter from '@sveltejs/adapter-vercel';

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

Ce que j’ai observé en production

Métrique	Observation sur ce projet
JavaScript envoyé pour la page d’accueil	≈ 40 Ko compressé, contre plus de 90 Ko sur un projet Next.js comparable non optimisé
Temps de mise en place initiale	Comparable à Next.js pour une équipe déjà familière du routage basé fichiers
Écosystème de composants tiers	Nettement plus restreint que React, à vérifier avant de s’engager sur un besoin spécifique

Le principal frein que j’ai rencontré n’est pas technique mais humain : la majorité des développeurs front que je croise connaissent React, peu Svelte. Le choix de SvelteKit engage donc autant une décision d’équipe qu’une décision technique.

En résumé

SvelteKit permet de construire un front WordPress headless léger et performant en quelques heures, grâce à un routage basé fichiers clair et un rendu serveur activé sans configuration complexe. Le principal compromis reste l’écosystème de composants tiers, plus restreint que celui de React, à évaluer selon les besoins spécifiques du projet avant de trancher.