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

> SvelteKit offre une approche différente pour un front WordPress découplé : moins de JavaScript envoyé au navigateur, un routage basé fichiers simple à comprendre.

- Auteur : Clément Hadrot
- Publié le : 2022-01-13
- Mis à jour le : 2022-01-13
- Catégorie : Headless & API
- URL : https://wpmoderne.dev.wordpress-developpement.fr/headless/sveltekit-wordpress-headless-front-leger-quelques-heures/

## L’essentiel

- Routage basé fichiers avec des fonctions load dédiées
- Rendu serveur activé par défaut, sans configuration lourde
- Bundle JavaScript sensiblement plus léger qu'avec React

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

> L'essentiel à retenir : Routage basé fichiers avec des fonctions load dédiées ; Rendu serveur activé par défaut, sans configuration lourde ; Bundle JavaScript sensiblement plus léger qu'avec React

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.