Tâches de mise en cache, d’authentification et de mise en ligne (partie 4) / Blogs / Perficient

Cette série est mon CV d’étude Next.js, et malgré son désir d’un Next.js vanille, toutes les fonctionnalités sont applicables avec le SDK Sitecore. C’est semblable au guide J’ai récemment écrit sur GraphQL et vise à réduire la courbe d’apprentissage pour ceux qui y passent à partir d’autres piles technologiques.

• Dans partie 1 nous avons abordé certains principes fondamentaux de Next.js : les stratégies de rendu ainsi que les nuances de getStaticProps, getStaticPaths, getServerSideProps ainsi que la récupération de données.
• Dans partie 2 nous avons parlé des éléments liés à l’interface utilisateur à venir OOB avec Next.js – mises en page, styles et polices, fonctionnalités puissantes, composants d’image et de script, et bien sûr – TypeScript.
• Dans partie 3 nous avons passé en revue les nuances du routage Next.js et expliqué le middleware

Dans cet article, nous allons parler des optimisations préalables au lancement, telles que la mise en cache et la réduction de la taille du bundle, ainsi que l’authentification.

Examen en direct

• utilisez la mise en cache autant que possible (voir ci-dessous)
• assurez-vous que le serveur et la base de données se trouvent (déployé) dans la même région
• minimiser la quantité de code JavaScript
• retarder le chargement de JS lourd jusqu’à ce que vous l’utilisiez réellement
• assurez-vous que la journalisation est correctement configurée
• assurez-vous que la gestion des erreurs est correcte
• configurer 500 (erreur du serveur) et 404 (Page non trouvée) pages
• s’assurer que l’application répond aux meilleurs critères de performance
• exécutez Lighthouse pour tester les performances, les meilleures pratiques, l’accessibilité et le référencement. Utilisez un mode navigation privée pour vous assurer que les résultats ne sont pas déformés
• assurez-vous que les fonctionnalités utilisées dans votre application sont prises en charge par les navigateurs modernes
• améliorer les performances en utilisant les éléments suivants :
  • next/image et optimisation automatique des images
  • optimisation automatique des polices
  • optimisation des scripts

Mise en cache

La mise en cache réduit le temps de réponse et le nombre de requêtes vers des services externes. Next.js ajoute automatiquement les en-têtes de mise en cache aux statistiques de _next/staticy compris JS, CSS, images et autres médias.

Cache-Control: public, max-age=31536000, immutable

Pour revalider le cache d’une page précédemment rendue en balisage statique, utilisez l’option revalidate réglage dans le getStaticProps fonction.

Veuillez noter: exécution de l’application en mode développement en utilisant next dev désactive la mise en cache :

Cache-Control: no-cache, no-store, max-age=0, must-revalidate

Les en-têtes de mise en cache peuvent également être utilisés dans getServerSideProps et l’interface de routage pour les réponses dynamiques. Un exemple d’utilisation stale-while-revalidate:

// The value is considered fresh and actual for 10 seconds (s-maxage=10).
// If the request is repeated within 10 seconds, the previous cached value
// considered fresh. If the request is repeated within 59 seconds,
// cached value is considered stale, but is still used for rendering
// (stale-while-revalidate=59)
// The request is then executed in the background and the cache is filled with fresh data.
// After updating the page will display the new value
export async function getServerSideProps({ req, res }) {
   res.setHeader(
     'Cache-Control',
     'public, s-maxage=10, stale-while-revalidate=59'
   )

   return {
     props: {}
   }
}

Réduire le volume/la taille du bundle JavaScript

Pour identifier ce qui est inclus dans chaque bundle JS, vous pouvez utiliser les outils suivants :

• Coût d’importation – extension pour VSCode affichant la taille du package importé
• Phobie des paquets est un service permettant de déterminer le « coût » de l’ajout d’une nouvelle dépendance de développement à un projet (dépendance de développement)
• Phobie des paquets – un service permettant de déterminer dans quelle mesure l’ajout d’une dépendance augmentera la taille de la build
• Analyseur de bundles Webpack – Plugin Webpack permettant de visualiser le bundle sous la forme d’une arborescence interactive et évolutive

Chaque fichier dans le pages Le répertoire est alloué dans un assembly séparé pendant le next build commande. Vous pouvez utiliser l’importation dynamique pour charger paresseusement des composants et des bibliothèques.

Authentification

L’authentification est le processus d’identification d’un utilisateur, tandis que l’autorisation est le processus de détermination de ses autorisations (ou « autorité » en d’autres termes), c’est-à-dire ce à quoi l’utilisateur a accès. Next.js prend en charge plusieurs modèles d’authentification.

Modèles d’authentification

Chaque modèle d’authentification détermine le stratégie pour obtenir des données. Ensuite, vous devez sélectionner un fournisseur d’authentification qui prend en charge la stratégie sélectionnée. Il existe deux principaux modèles d’authentification :

• utiliser la génération statique pour charger l’état sur le serveur et récupérer les données utilisateur côté client
• recevoir des données utilisateur du serveur pour éviter de « vider » le contenu non authentifié (dans le sens où le changement d’état de l’application est visible pour un utilisateur)

Authentification lors de l’utilisation de la génération statique

Next.js détecte automatiquement qu’une page est statique si la page ne dispose pas de méthodes de blocage pour récupérer des données, telles que getServerSideProps. Dans ce cas, la page restitue l’état initial reçu du serveur puis demande les données de l’utilisateur côté client.

L’un des avantages de l’utilisation de ce modèle est la possibilité de fournir des pages à partir d’un CDN global et de les précharger à l’aide de next/link. Cela se traduit par une réduction du temps d’interactivité (TTI).

Regardons un exemple de page de profil utilisateur. Sur cette page, le modèle (squelette) est d’abord rendu, et après avoir exécuté une requête pour obtenir des données utilisateur, ces données sont affichées :

// pages/profile.js
import useUser from '../lib/useUser'
import Layout from './components/Layout'

export default function Profile() {
  // get user data on the client side
  const { user } = useUser({ redirectTo: '/login' })

  // loading status received from the server
  if (!user || user.isLoggedIn === false) {
    return <Layout>Loading...</Layout>
  }

 // after the request is completed, user data is
  return (
    <Layout>
      <h1>Your profile</h1>
      <pre>{JSON.stringify(user, null, 2)}</pre>
    </Layout>
  )
}

Authentification du rendu côté serveur

Si une page a un asynchrone getServerSideProps fonction, Next.js affichera cette page à chaque requête en utilisant les données de cette fonction.

export async function getServerSideProps(context) {
  return {
    props: {} // will get passed down to a component as props
  }
}

Réécrivons l’exemple ci-dessus. S’il y a une séance, le Profile composant recevra le user soutenir. Notez l’absence de modèle :

// pages/profile.js
import withSession from '../lib/session'
import Layout from '../components/Layout'

export const getServerSideProps = withSession(async (req, res) => {
   const user = req.session.get('user')

   if (!user) {
     return {
       redirect: {
         destination: '/login',
         permanent: false
       }
     }
   }

   return {
     props: {
       user
     }
   }
})

export default function Profile({ user }) {
   // display user data, no loading state required
   return (
     <Layout>
       <h1>Your profile</h1>
       <pre>{JSON.stringify(user, null, 2)}</pre>
     </Layout>
   )
}

L’avantage de cette approche est d’empêcher l’affichage de contenu non authentifié avant d’effectuer une redirection. Notez que la demande de données utilisateur dans getServerSideProps bloque le rendu jusqu’à ce que la demande soit résolue. Par conséquent, pour éviter de créer des goulots d’étranglement et d’augmenter le délai jusqu’au premier octet (TTFB), vous devez vous assurer que le service d’authentification fonctionne correctement.

Fournisseurs d’authentification

Pour l’intégration à la base de données des utilisateurs, envisagez d’utiliser l’une des solutions suivantes :

• prochaine session de fer – session sans état codée de bas niveau
• authentification suivante est un système d’authentification à part entière avec des fournisseurs intégrés (Google, Facebook, GitHub et similaires), JWT, JWE, email/mot de passe, liens magiques, etc.
• avec-passeport-et-next-connect – l’ancien bon mot de passe du nœud fonctionne également dans ce cas