PRNext 0.1.22-alpha : bien plus de performances

PRNext 0.1.22-alpha est disponible sur npm. Sur notre tableau de développement de mille lignes, le débit médian Flight est multiplié par 7,7, le débit SSR par 3,97 et le payload Flight décodé diminue de 72,1 %. Les mesures comparent le même tableau avec l’optimisation désactivée puis activée.

Le changement est automatique pour les composants de présentation compatibles. Aucun « use presentation » à ajouter : PRNext transmet une structure réutilisable et les valeurs affichées, en conservant les calculs sur le serveur et le HTML complet. Pour en profiter, mettez à jour PRNext et reconstruisez votre application.

Jusqu’à 7,7× le débit Flight sur notre tableau de test

La campagne de développement sur la source 270ae481 compare exactement le même tableau, avec l’optimisation désactivée puis activée. Sur mille lignes, le débit médian SSR passe de 48,611 à 192,765 requêtes par seconde, soit environ 3,97 fois. Flight passe de 80,472 à 619,413, soit environ 7,70 fois. Le p95 passe respectivement de 100,52 à 28,78 ms et de 61,65 à 8,806 ms.

Le HTML du tableau est identique. Flight décodé passe de 266 672 à 74 353 octets, soit 72,1 % de moins. Avec gzip, la baisse est de 36,1 %. Le JavaScript navigateur encodé augmente de 606 octets et demande deux requêtes supplémentaires.

Ces mesures locales utilisent Windows x64, Node 24.22.1, deux workers et quatre connexions sur un PC partagé de 12 processeurs logiques et 32 Gio. La campagne comprend aussi un scénario SSR de 100 lignes. Trois paires alternées, avec une seconde de chauffe et trois secondes mesurées par fenêtre, totalisent 18 fenêtres et 21 523 réponses validées sans erreur. Les deux variantes utilisent le même binaire natif 0.1.21 reconstruit. Ce sont des mesures du code de développement, pas des archives npm finales ni un comparatif Next.js. La mémoire varie selon le scénario et le gain navigateur reste inconclusif. SQL, logique métier et travail DOM ne deviennent pas sept fois plus rapides.

Transmettre la structure une fois

Flight transporte le résultat des React Server Components vers le navigateur. Lorsque beaucoup de lignes partagent la même structure, la représentation détaillée de chaque élément peut coûter davantage que les données affichées. PRNext reconnaît certains composants synchrones et purs, compile leur balisage statique et utilise une référence client React officielle avec des emplacements compacts. Le protocole et le décodeur Flight de React restent ceux de la version prise en charge.

Le navigateur reçoit un petit module de présentation. Il y a donc toujours du JavaScript à télécharger et à exécuter. Le HTML est entièrement rendu côté serveur, y compris avant le chargement de ce module. Une petite liste ou une valeur incompatible peut conserver la représentation ordinaire sans remplacer sa racine DOM uniquement à cause du changement de format.

Les tableaux de données, les annuaires et les longues listes de cartes de présentation peuvent répéter beaucoup de balisage. En séparant cette structure des valeurs affichées, PRNext réduit le travail nécessaire pour décrire l’interface dans Flight. Le serveur continue d’exécuter les calculs et les autorisations de votre application ; les gains dépendent de la quantité de présentation compatible à transmettre.

Les calculs privés restent sur le serveur

Sur le chemin compact, une expression comme row.revenue-row.privateCost est évaluée sur le serveur. Le navigateur reçoit le résultat affiché, pas les deux opérandes ni l’expression originale. Il en va de même pour les conditions qui choisissent un texte. Les champs inutilisés ne deviennent pas automatiquement des props navigateur.

Cette transformation ne crée aucun cache de pages entre comptes et ne remplace aucune autorisation. Les données que votre application affiche doivent toujours être autorisées. Imports, hooks, effets, composants personnalisés, contrôles interactifs, HTML brut et attributs non vérifiés restent sur le chemin ordinaire.

Un périmètre volontairement précis

Le chemin automatique concerne les builds de production Node avec App Router. Développement, Pages, Edge et sortie HTML seule gardent leur fonctionnement actuel. Les pipelines webpack ou JSX personnalisés restent ordinaires lorsque leur compatibilité ne peut pas être établie, y compris lorsqu’un plugin installe ces hooks. Ne retirez pas un plugin utile pour augmenter le nombre de composants éligibles.

Le fichier .prnext/presentation-report.json explique les décisions du compilateur. Il ne mesure pas la proportion de requêtes réellement compactées. La qualification distingue une charge compacte éligible d’un SaaS PostgreSQL authentifié avec son pipeline de traduction, et conserve le repli de ce dernier. Un diagnostic de vingt minutes reste distinct de la campagne d’endurance de deux heures.

Mettre à jour et vérifier son application

Conservez le code, le lockfile, la configuration et le déploiement précédent pour revenir en arrière. Installez la version, reconstruisez l’application et redémarrez ses workers avec des paquets framework et natifs de même version. Remplacer les fichiers sous un processus actif ne met pas à jour son code chargé.

Pour comparer votre application, définissez presentationComponents: false dans prnext.config.mjs et reconstruisez les deux variantes. Vérifiez hydratation, navigation, changements de compte, formulaires et annulation des streams, ainsi qu’un onglet resté ouvert pendant un déploiement et un rollback. Les mutations périmées doivent être refusées sans répétition automatique. PRNext reste une alpha à compatibilité Next.js partielle : le résultat à retenir est celui de votre application.

Terminal
npm install @thomas.f/prnext@0.1.22-alpha
npx --no-install prnext check --production --json
npx --no-install prnext build

Implémentation et périmètre

Guide de mise à jour

Retour au blog