Rendu côté serveur avec Preact

Si vous avez déjà créé des applications avec React et Vite, vous comprenez déjà le rendu côté client. Le navigateur télécharge un bundle JavaScript, l’exécute et construit le DOM. Cela fonctionne, mais les utilisateurs disposant d’une connexion lente se retrouvent face à un écran vide pendant le chargement de ce bundle. Le rendu côté serveur avec Preact résout ce problème en envoyant du HTML prêt à être affiché depuis le serveur. L’empreinte runtime réduite de Preact rend ce compromis particulièrement intéressant pour les applications axées sur la performance.

Cet article explique le fonctionnement du SSR avec Preact, l’outillage impliqué, et comment l’hydratation relie le HTML rendu côté serveur à une application interactive et vivante.

Qu’est-ce que le SSR avec Preact et pourquoi est-ce important ?

Avec le SSR, votre arbre de composants est rendu en une chaîne HTML sur le serveur avant que le navigateur ne reçoive quoi que ce soit. L’utilisateur voit le contenu immédiatement. Le JavaScript se charge en arrière-plan et attache ensuite l’interactivité.

Les bénéfices pratiques sont concrets :

• Temps de chargement perçu plus rapide — le contenu visible arrive avec la réponse HTTP initiale.
• Meilleur SEO — les robots d’indexation lisent un HTML complet sans avoir à exécuter de JavaScript.
• Résilience — les pages restent lisibles même si le JS côté client échoue ou est lent.

Preact est particulièrement bien adapté au SSR car son runtime de petite taille ajoute une surcharge minimale.

L’outil central : preact-render-to-string

Le SSR avec Preact repose sur preact-render-to-string, un package distinct qui prend en charge le rendu côté serveur.

npm install preact-render-to-string

Rendu synchrone

Pour les composants sans dépendances asynchrones, renderToString convertit votre arbre de composants en HTML en une seule passe :

import { renderToString } from 'preact-render-to-string';

const App = () => <h1>Hello from the server</h1>;
const html = renderToString(<App />);
// → <h1>Hello from the server</h1>

Rendu asynchrone

Lorsque les composants effectuent des appels de données ou utilisent Suspense avec des chunks chargés en lazy, utilisez renderToStringAsync à la place. Cette fonction attend que les promesses et les opérations de rendu asynchrones se terminent avant de retourner la chaîne HTML finale.

import { renderToStringAsync } from 'preact-render-to-string';

const html = await renderToStringAsync(<App />);

Streaming

Pour les pages volumineuses, les APIs de streaming permettent d’envoyer le HTML au navigateur par morceaux au fur et à mesure du rendu de chaque section. renderToPipeableStream cible les streams Node.js, tandis que renderToReadableStream cible les environnements utilisant l’API Web Streams, notamment des plateformes comme Cloudflare Workers, Deno et Bun. Le streaming améliore le Time to First Byte (TTFB) sans attendre la fin du rendu complet.

Hydratation Preact : connecter le HTML à l’interactivité

Envoyer du HTML statique ne représente que la moitié du travail. Pour rendre la page interactive, Preact doit hydrater le DOM existant — attacher les écouteurs d’événements et l’état sans tout re-rendre depuis zéro.

import { hydrate } from 'preact';
import { App } from './app.js';

hydrate(<App />, document.getElementById('root'));

Utilisez hydrate plutôt que render lorsque le DOM a déjà été produit par le serveur. Utiliser render aurait pour effet d’écarter le HTML serveur et de le reconstruire, ce qui annulerait tout l’intérêt de la démarche.

Les incohérences d’hydratation surviennent lorsque le HTML rendu côté serveur ne correspond pas à ce que le client rendrait. Les causes courantes incluent l’affichage de timestamps, d’identifiants aléatoires, ou la lecture de window pendant la passe serveur. Gardez la logique des composants cohérente entre serveur et client pour les éviter.

SSR avec Preact et Vite : la configuration moderne

Pour les nouveaux projets, un workflow basé sur Vite constitue le choix pratique par défaut. Le guide SSR de Vite documente le pattern à double build : un build ciblant le point d’entrée serveur et un autre pour le bundle client. Preact s’intègre parfaitement avec @preact/preset-vite, qui gère le JSX, les alias et la configuration spécifique à Preact.

Pour les équipes souhaitant un point de départ plus structuré, preact-iso fournit des utilitaires légers de routing et de prerendering conçus spécifiquement pour les projets Preact Vite.

Ce qu’il faut garder à l’esprit

Le SSR avec Preact partage des fondements conceptuels avec le SSR React, mais n’est pas identique sur tous les détails d’implémentation. Certaines APIs SSR spécifiques à React n’ont pas d’équivalent direct, et l’écosystème autour de Preact est plus restreint — un compromis raisonnable face aux gains en taille et en performance.

Le pattern qui fonctionne de manière fiable : récupérez vos données avant le rendu, passez-les en props, effectuez le rendu en chaîne sur le serveur, hydratez côté client. Commencez par là, puis ajoutez le streaming ou des patterns de rendu plus avancés lorsque cela se justifie.

Conclusion

Le SSR avec Preact offre une voie légère et axée sur la performance pour des applications rendues côté serveur, sans la surcharge d’un framework plus volumineux. En combinant preact-render-to-string pour la passe serveur, hydrate pour l’activation côté client et Vite pour le pipeline de build, vous obtenez une configuration rapide à mettre en production et facile à appréhender. Commencez par le flux basique render-et-hydratation, gardez vos sorties serveur et client alignées, et n’envisagez le streaming que lorsque l’échelle de votre application le justifie.

FAQ

Gain Debugging Superpowers

Unleash the power of session replay to reproduce bugs, track slowdowns and uncover frustrations in your app. Get complete visibility into your frontend with OpenReplay — the most advanced open-source session replay tool for developers. Check our GitHub repo and join the thousands of developers in our community.