Next.js 9.1.7

Next.js 9 a été publié il y a six (6) mois, suivi par Next.js 9.1 il y a trois (3) mois.

Ces deux versions ont ajouté des fonctionnalités très puissantes à Next.js, sans augmenter la taille de base du runtime client.

Depuis, nous nous sommes concentrés sur l'affinage et l'amélioration du framework dans son ensemble : 9.1.1, 9.1.2, 9.1.3, 9.1.4, 9.1.5, 9.1.6, et 9.1.7.

Plongeons dans ce que ces versions ont amélioré !

• 3% - 8%+ de JavaScript côté client en moins : Nous avons optimisé la sortie des applications encore davantage, réduisant de 7,5kB les applications "hello world". Les applications plus complexes verront des économies allant jusqu'à 8% ou plus.
• Sortie CLI de build de production repensée : La sortie du build de production affiche maintenant les tailles de fichiers gzippés dans un format plus facile à comprendre.
• Nouveaux polyfills intégrés : fetch(), URL et Object.assign : Les applications peuvent utiliser l'API fetch(), URL et Object.assign dans les anciens navigateurs sans problèmes de compatibilité.
• Chargement de page optimisé : Meilleur FCP et TTI : Nous avons collaboré étroitement avec l'équipe Google Chrome pour maximiser les performances de chargement des pages. Cela se traduit par une bien meilleure expérience utilisateur.
• Support des dernières fonctionnalités JavaScript : Nous nous engageons à vous permettre d'utiliser toujours les dernières fonctionnalités JavaScript, y compris Optional Chaining, Nullish Coalescing, et d'autres fonctionnalités stables d'ES2020.
• Support de déploiement sans configuration pour les applications next export : Les applications utilisant next export peuvent maintenant être déployées sur Vercel sans configuration.
• Conformité et activation optionnelle du mode Strict de React : Tout le runtime côté client de Next.js est maintenant compatible avec le mode Strict de React. Nous avons aussi ajouté une option de configuration pour activer ce mode pour toute votre application.
• Tests automatisés contre les builds nocturnes de React : Next.js est maintenant testé automatiquement contre le canal next de React, assurant la compatibilité avec les futures versions.

Tous ces bénéfices sont non-breaking et entièrement rétrocompatibles. Pour mettre à jour, il vous suffit d'exécuter :

npm i next@latest react@latest react-dom@latest

3% - 8%+ de JavaScript côté client en moins

En collaboration avec l'équipe Google Chrome, toutes les applications Next.js bénéficieront d'une réduction de taille de 7,5kB ou plus.

Les applications basiques devraient voir une réduction de 3-4% de la taille de l'application, et les applications plus avancées pourraient voir jusqu'à 6-8% (ou plus) !

Ces économies sont en partie attribuables au remplacement de la version côté client du package url par une version basée sur l'API URL.

D'autres réductions de taille ont été accomplies en fournissant des polyfills intégrés et petits pour des packages souvent utilisés. Vous pouvez en savoir plus sur ces polyfills ici.

Enfin, nous avons optimisé notre sortie JSX, ce qui introduira des économies proportionnelles à la quantité de JSX dans votre application.

Sortie CLI de build de production repensée

La sortie CLI du build de production a été repensée pour plus de clarté. Comme Next.js est un framework d'application hybride, chaque page peut avoir des caractéristiques différentes.

La nouvelle sortie classe chaque page dans l'une des catégories suivantes :

• Rendu côté serveur (Server) : la page est rendue côté serveur au runtime, ce qui signifie qu'elle utilise getInitialProps ou getServerProps (proposition)
• Optimisation statique automatique (Static) : la page a été rendue en HTML statique au moment du build, et sera servie comme un fichier statique (n'utilise pas de props initiales)
• Génération statique avec données calculées (SSG) : la page a été générée en HTML/JSON statique au moment du build, et sera servie comme des fichiers statiques (utilise getStaticProps (proposition))

De plus, la nouvelle sortie affiche la taille gzippée de chaque page — ces tailles excluent les fichiers partagés par toutes les pages (affichés séparément).

La taille de chaque page sera colorée en fonction de l'expérience utilisateur perçue :

• Moins de 130kB : Vert — votre application devrait être performante dans la plupart des conditions réseau et appareil.
• Entre 130kB et 170kB : Jaune — votre application approche un temps de chargement de 5-6 secondes sur les conditions réseau et appareil de base globales.
• Plus de 170kB : Rouge — votre application prendra probablement plus de 6 secondes à charger dans les mêmes conditions.

La nouvelle sortie CLI de production Next.js

Nous serions ravis d'avoir vos retours sur la nouvelle sortie de build.

Dans un futur proche, Next.js aura aussi des budgets de taille pour vous aider à vous assurer que les pages restent dans une certaine fourchette de taille.

Nouveaux polyfills intégrés : fetch(), URL et Object.assign

En examinant de nombreuses applications d'utilisateurs et nos exemples, nous avons constaté que la plupart expédiaient un ensemble similaire de polyfills. Dans certains cas, les applications avaient même des polyfills en double pour la même fonctionnalité.

Pour remédier à cela, nous avons collaboré avec l'équipe Google Chrome pour intégrer des polyfills pour les trois API les plus courantes que nous avons observées.

En utilisant le chargement différentiel, ces polyfills ne sont pas chargés pour 83% du trafic web mondial. Cela signifie que la majorité de vos utilisateurs ne téléchargeront pas les octets associés à ces polyfills — ils ne seront téléchargés que si nécessaire.

De plus, tous les polyfills bien connus que nous avons intégrés seront complètement éliminés de votre build de production. Cela signifie que vous ne paierez pas le prix pour une de vos dépendances qui importerait par inadvertance un polyfill pour une de ces API.

La liste des API intégrées et les polyfills qu'elles rendent obsolètes sont les suivants :

• fetch() — Remplace : whatwg-fetch et unfetch.
• URL — Remplace : le package url (API Node.js).
• Object.assign() — Remplace : object-assign, object.assign, et core-js/object/assign.

Vous devez toujours importer isomorphic-fetch ou isomorphic-unfetch si vous utilisez fetch() côté serveur.

Ce changement est complètement non-breaking, et tous les polyfills sont faits avec les versions les plus conformes aux spécifications disponibles. Le résultat est jusqu'à 18kB de JavaScript éliminé de vos bundles de production sur les navigateurs modernes.

Chargement de page optimisé : Meilleur FCP et TTI

Next.js a optimisé son implémentation de préchargement pour réduire le FCP et le TTI global.

En contournant un bug du navigateur, le CSS (quand utilisé) est maintenant correctement priorisé par rapport au JavaScript. Cela se traduit par un First Contentful Paint plus rapide, ce qui donne un site visuellement complet beaucoup plus rapide pour vos utilisateurs finaux.

De plus, nous avons optimisé notre préchargement de pages pour utiliser des requêtes réseau à priorité plus basse.

En outre, ces requêtes ne se produisent que pendant les temps d'inactivité du navigateur, ce qui donne un time-to-interactive plus rapide. C'est parce que le navigateur donnera la priorité à rendre votre application interactive plutôt qu'au préchargement optimiste.

FCP/TTI avant et après les optimisations

Support des dernières fonctionnalités JavaScript

Next.js a un pipeline de compilation avancé et hautement optimisé qui vous permet d'utiliser les dernières fonctionnalités JavaScript. Les optimisations récentes que nous avons introduites ont directement contribué à la réduction de 3-8% de la taille des applications.

Ces fonctionnalités JavaScript peuvent être utilisées sans vous soucier de la compatibilité des navigateurs, car nous compilons automatiquement votre code pour supporter tous les navigateurs (à l'exclusion des versions en fin de vie). Cela inclut les fonctionnalités ES6+, comme async/await (ES2017), Object Rest/Spread Properties (ES2018), Dynamic import() (ES2020), et plus encore !

Dans cette version, nous sommes heureux d'annoncer le support de Optional Chaining (Stage 4) et Nullish Coalescing (Stage 4).

function Page(props) {
  return (
    <p>{props?.deeply?.nested?.value}</p>
    /* ⬆ Si deeply.nested.value n'est pas disponible, rien ne sera rendu */
  );
}
 
export default Page;

Opérateur Optional chaining (?.)

function Page(props) {
  return (
    <p>{props.something ?? 'Valeur par défaut'}</p>
    /* ⬆ donne "Valeur par défaut" */
  );
}
 
export default Page;

Opérateur Nullish coalescing (??)

À l'avenir, nous prévoyons de produire des bundles encore plus optimisés via des builds automatiques module / nomodule.

Support de déploiement sans configuration pour les applications next export

La commande next export de Next.js fonctionne maintenant avec la Configuration Zéro de Vercel out-of-the-box. Avant ce changement, les utilisateurs utilisant next export devaient créer un now.json personnalisé.

Utiliser le mode export de Next.js sur Vercel est aussi simple que d'avoir le script build suivant dans package.json :

{
  "scripts": {
    "build": "next build && next export"
  }
}

Ensuite, vous pouvez déployer votre application Next.js sur Vercel avec une seule commande. Si vous n'avez pas encore installé Vercel, vous pouvez le faire en installant Vercel CLI.

now

Conformité et activation optionnelle du mode Strict de React

Le runtime complet de Next.js est maintenant conforme au mode Strict. Cela inclut des mises à jour du gestionnaire de head (<Head>), next/dynamic, et d'autres fonctionnalités principales. Cela signifie que les runtimes utilisent maintenant des hooks ou ont éliminé les lifecycles dépréciés, et utilisent la nouvelle API Context de React.

Nous avons aussi ajouté une option pratique pour vous permettre d'activer le mode Strict pour votre application.

Pour ce faire, configurez l'option suivante dans votre next.config.js :

module.exports = {
  reactStrictMode: true,
};

Si vous ou votre équipe n'êtes pas prêts à utiliser le mode Strict dans toute votre application, ce n'est pas grave ! Vous pouvez migrer progressivement page par page en utilisant <React.StrictMode>.

Bien que non requis, le mode Strict débloquera beaucoup d'optimisations à l'avenir. Pour cette raison, nous vous suggérons de vous y intéresser plus tôt que tard !

Tests automatisés contre les builds nocturnes de React

En étroite collaboration avec l'équipe React Core, nous testons maintenant Next.js contre le canal next de React toutes les 12 heures.

Ces tests aident à nous assurer que nous sommes préparés et compatibles avec les futures versions de React. La compatibilité est quelque chose que Next.js prend très au sérieux, et nous nous engageons pour la stabilité à long terme de l'API de Next.js.

Ce processus a été documenté par l'équipe React Core dans l'espoir que d'autres projets de l'écosystème React suivront.

Communauté

Nous sommes enthousiastes à propos des changements à venir qui amélioreront la taille et les performances de toutes les applications Next.js.

De plus, la communauté Next.js continue de s'étendre :

• Nous avons eu plus de 865 contributeurs indépendants.
• Sur GitHub, le projet a été star plus de 43 700 fois.
• Le répertoire d'exemples contient plus de 220 exemples.

La communauté Next.js compte maintenant plus de 13 600 membres. Rejoignez-nous !

Nous sommes reconnaissants envers notre communauté et tous les retours et contributions externes qui ont aidé à façonner cette version.