Performances (mesurées)

Des chiffres réels, pas une intuition — mesurés sur ce déploiement. Le plancher d'interactivité de bext (le JS qu'un client paie pour rendre un îlot interactif) est de l'ordre du kilo-octet, et zéro avant interaction en mode paresseux.

JS d'interactivité, compressé (gzip)

Ce qu'un client télécharge pour rendre un compteur interactif. Le runtime de reprise (~3 Ko) est mis en cache une seule fois pour tous les îlots et toutes les pages ; chaque îlot supplémentaire n'ajoute que ~0,6 Ko — ou rien jusqu'à l'interaction.

React + ReactDOM45 KB

SolidStart (solid-js)7 KB

bext — island + shared rt3.5 KB

bext — each extra island0

bext — lazy, before interaction0

Astuce

C'est le plancher du framework, pas le total d'un site. Un site chargé (y compris ce gabarit de démo, avec sa coloration syntaxique et ses éditeurs intégrés) expédie son propre « chrome » en plus. L'argument n'est pas que chaque page bext est minuscule — c'est que le framework ne vous impose pas un socle lourd : la base est ~13× plus légère que les ~45 Ko de React (et chaque îlot supplémentaire ~75×), et nulle avant interaction.

Tête-à-tête : la même app dans cinq frameworks (mesuré)

Nous avons construit la même app — grille de 24 produits rendue côté serveur + compteur, bascule de thème et filtre de recherche, le tout vérifié dans un vrai navigateur — dans les cinq frameworks, puis forcé chacun à rendre à neuf à chaque requête (aucun cache, aucun pré-rendu ; prouvé par un horodatage qui change à chaque requête). Builds et serveurs de production sur activ-2 ; RPS/TTFB via oha -c 50.

Framework	JS client (gzip)	TTFB	RPS (non caché)	p99	Build
bext (PRISM)	5,6 Ko	6,0 ms	4 742	71 ms	~4 Ko*
Astro	0,33 Ko	12,3 ms	3 807	20 ms	432 Ko
Remix	101 Ko	12,2 ms	1 011	75 ms	335 Ko
Qwik	35 Ko	42,6 ms	938	73 ms	249 Ko
Next.js	145 Ko	21,1 ms	575	141 ms	5,2 Mo

Astuce

Même non caché, bext rend le plus vite (le force-dynamic de Next l'a fait chuter de 2 945 à 575 RPS : il servait du statique pré-rendu, pas du rendu). Avec son cache ISR intégré — une ligne de config, pas un CDN — la même route sert 282 776 RPS à 0,13 ms de TTFB. Le 4 742 non caché est le pire cas de bext, et il gagne quand même. * bext n'a pas de build lourd : compilation à la demande.

Time to First Byte

Rendu Rust + cache ISR. La page de reprise complète part en ~18 ms (octet et total confondus sur le réseau local), sur trois requêtes chaudes.

~18 ms

Méthode (reproductible)

reproduce.shShell

# interactivity floor — gzipped bytes a client actually pays
curl -s https://demo.bext.dev/islands/ResumableCounter.js | gzip -c | wc -c   # 589
curl -s https://demo.bext.dev/islands/__resume-runtime.js  | gzip -c | wc -c   # 2970 (cached once)

# TTFB (Rust + ISR cache) — three warm samples
for i in 1 2 3; do curl -s -o /dev/null \
  -w '%{time_starttransfer}s\n' https://demo.bext.dev/examples/resumability; done
#  → 0.018s  0.020s  0.019s

# full harness (TTFB + JS bytes + request count per page)
node harnesses/browser/bench.mjs