Hébergement de Sanity.io : bonnes pratiques pour le déploiement et les performances d'un CMS headless

Hébergement de Sanity.io : bonnes pratiques pour le déploiement et les performances d'un CMS headless - Image principale

Sanity.io est devenu l'un des CMS headless les plus adaptés aux développeurs, offrant une collaboration en temps réel, un contenu structuré et un langage de requête puissant (GROQ). Contrairement aux CMS traditionnels, Sanity est un service backend hébergé : tu n'as pas besoin de l'installer sur ton serveur.

Comprendre l'architecture de Sanity

Sanity se compose de trois éléments :
1. Content Lake : ton contenu, hébergé par Sanity
2. Studio : l'interface d'édition basée sur React
3. Ton front-end : site web/application qui récupère le contenu via l'API

Tu héberges les composants 2 et 3. Sanity se charge du stockage du contenu et de l'infrastructure API.

Architecture de Sanity.io

Déployer Sanity Studio

# Option 1 : l'hébergement gratuit de Sanity

Courir sanity deploy et tu obtiendras une URL du type ton-projet.sanity.studio. C'est gratuit, aucune configuration n'est nécessaire, et ça fonctionne pour la plupart des cas d'utilisation.

Limites : pas de domaine personnalisé sans proxy inverse, pas de contrôle du CDN.

# Option 2 : Hébergement autonome sur un serveur dédié (VPS)

Build Studio : npm run build
À utiliser avec Nginx /dist répertoire
Nécessite au moins 2 Go de RAM, un certificat SSL ; Node.js n'est pas nécessaire après la compilation

# Option 3 :Cloudflare

Déploie automatiquement sur ces plateformes pour une diffusion mondiale via un CDN. Elles proposent toutes des formules gratuites.

Héberger ton interface utilisateur

Utilise getStaticProps avec la régénération statique incrémentielle (ISR) :

export async function getStaticProps({ params }) {
const post = await sanityClient.fetch(`*[_type == "post" && slug.current == $slug][0]`, { slug: params.slug });
return { props: { post }, revalidate: 60 };
}

Héberge-le sur Vercel (sans aucune configuration), sur un VPS auto-hébergé avec Nginx ou sur Cloudflare .

# Applications monopages React/Vue

Pour les applications avec rendu côté client, le contenu se charge après l'exécution du JavaScript. Déploie-les sur un hébergement statique (Netlify, Vercel). Ce n'est pas l'idéal pour le référencement, sauf si tu utilises le pré-rendu.

Optimisation de l'API Sanity

# Utiliser les projections GROQ

Récupère uniquement les champs nécessaires pour réduire la taille des données : // À éviter : récupère tout

const posts = await sanityClient.fetch(`*[_type == "post"]`);

// Good: Fetch specific fields

*[_type == "post"]{
title,
slug,
"authorName": author->name
}
`);

# Mise en cache côté client

Utilise SWR ou React Query pour mettre les réponses en cache et les revalider en arrière-plan, ce qui réduit le nombre d'appels API.

# Le CDN d'images de Sanity

Utilise toujours le générateur d'URL pour le redimensionnement automatique, la conversion de format et les URL adaptatives :

import imageUrlBuilder from '@sanity/image-url';
const builder = imageUrlBuilder(sanityClient);
<img src={builder.image(post.mainImage).width(800).url()} />

Webhooks pour les mises à jour de contenu

Configure les webhooks Sanity pour déclencher une revalidation de l'interface utilisateur lorsque le contenu change. Revalidation à la demande avec Next.js : // pages/api/revalidate.js

export default async function handler(req, res) {
if (req.query.secret !== process.env.REVALIDATE_SECRET) {
return res.status(401).json({ message: 'Invalid token' });
}
await res.revalidate('/blog');
return res.json({ revalidated: true });
}

Configure le webhook pour qu'il envoie une requête POST à ton point de terminaison lorsque du contenu est publié.

Contrôle des performances

Surveille l'utilisation de l'API Sanity dans le tableau de bord pour connaître le nombre de requêtes, la bande passante et les performances des requêtes. Optimise les requêtes qui prennent plus de 200 ms.

Track frontend Core Web Vitals: LCP <2.5s, FID <100ms, CLS <0.1.

Optimisation des coûts

Formule gratuite de Sanity : 100 000 requêtes API par mois, 10 Go de bande passante, 3 utilisateurs.

Pour rester dans les limites :
– Mise en cache intensive au niveau du CDN et du client
– Optimisation des images avec le CDN de Sanity
– Utilisation de webhooks à la place du polling
– Mise en place de la pagination pour les grands ensembles de données

Modèles de déploiement courants

# Modèle 1 : Jamstack avec Next.js

Studio sur Vercel/Netlify, front-end Next.js sur Vercel avec ISR, Cloudflare pour une mise en cache supplémentaire.
Idéal pour : sites marketing, blogs, documentation.

# Modèle 2 : Tableau de bord SaaS

Studio hébergé sur un VPS, interface utilisateur React SPA sur le même VPS communiquant avec l'API Sanity.
Idéal pour : outils internes, applications avec authentification.

# Modèle 3 : Site de commerce électronique à fort trafic

Hébergement gratuit chez Studio on Sanity, interface Next.js sur serveur dédié avec cache Redis, mise en cache des pages produits via CDN.
Idéal pour : les catalogues de produits générant un trafic important.

L'hébergement sur Sanity.io est très simple : il suffit de déployer des versions statiques de Studio et des interfaces utilisateur qui utilisent l'API. Pour la plupart des projets, déploie Studio sur l'hébergement gratuit de Sanity ou sur Vercel, utilise Next.js avec ISR pour l'interface utilisateur, profite du CDN d'images de Sanity et surveille l'utilisation de l'API pour rester dans les limites du forfait gratuit.

Tu as besoin d'un VPS pour héberger toi-même Sanity Studio ou Next.js ? Les offres VPS InMotion Hostingcomprennent SSD , une bande passante illimitée et un accès root. Launch Assist te facilite la configuration Nginx du SSL.

Partager cet article

Laisser une réponse

Ton adresse e-mail ne sera pas publiée. Les champs obligatoires sont marqués *