Optimiser les appels de page dans les pages du site de publication moderne et classique SharePoint

Les sites de publication modernes et classiques SharePoint contiennent des liens qui chargent des données à partir de (ou effectuent des appels à) des fonctionnalités SharePoint et des CDN. Plus le nombre d’appels effectués par une page est grand, plus la page prend de temps à charger. Il s’agit de la latence perçue par l’utilisateur final ou EUPL.

Cet article vous permet de comprendre comment déterminer le nombre et l’impact des appels vers des points de terminaison externes à partir de vos pages de sites de publications modernes et classiques et comment limiter leur effet sur la latence perçue par l’utilisateur final.

Remarque

Pour plus d’informations sur les performances dans les portails modernes SharePoint, voir Performances dans l’expérience SharePoint moderne.

Utiliser l’outil Diagnostic de page pour SharePoint pour analyser les appels de page

L’outil Diagnostics de page pour SharePoint est une extension de navigateur pour les nouveaux navigateurs Microsoft Edge (https://www.microsoft.com/edge) et Chrome qui analyse à la fois le portail moderne SharePoint et les pages du site de publication classique. L’outil fournit un rapport pour chaque page analysée montrant comment la page se comporte par rapport à un ensemble défini de critères de performance. Pour installer et en savoir plus sur l’outil Diagnostics de page pour SharePoint, consultez Utiliser l’outil Diagnostics de page pour SharePoint.

Remarque

L’outil Diagnostics de page fonctionne uniquement pour SharePoint et ne peut pas être utilisé sur une page système SharePoint.

Lorsque vous analysez une page de site SharePoint avec l’outil Diagnostic de page pour SharePoint, vous pouvez voir des informations sur les appels externes dans les résultats Requêtes à SharePoint dans le volet Tests de diagnostic. La ligne s’affiche en vert si la page du site contient moins que le nombre d’appels de référence, et en rouge si la page dépasse le nombre d’appels de référence. Le nombre de référence est différent pour les pages modernes et classiques car les pages de sites classiques utilisent HTTP1.1 et les pages modernes utilisent HTTP2.0 :

• Les pages de sites modernes ne doivent pas contenir plus de 25 appels
• Les pages de publication classiques ne doivent pas contenir plus de 6 appels

Les résultats possibles sont les suivants :

• Attention requise (rouge) : la page dépasse le nombre d’appels de référence
• Aucune action requise (vert) : la page contient moins d’appels que le nombre d’appels de référence

Si le résultat Requêtes à SharePoint apparaît dans la section Attention requise, vous pouvez cliquer sur le résultat pour obtenir des détails, notamment le nombre total d’appels sur la page et une liste d’URL.

Résoudre les problèmes de performances liés à un trop grand nombre d’appels sur une page

Si une page contient trop d’appels, vous pouvez utiliser la liste des URL dans les résultats Demandes à SharePoint pour déterminer s’il existe des appels répétés, des appels qui doivent être traités par lots ou des appels qui retournent des données qui doivent être mises en cache.

Le traitement par lots des appels REST permet de réduire la dégradation des performances. Pour plus d’informations sur le traitement par lots d’appels d’API, consultez Effectuer des requêtes de lot avec les API REST.

L’utilisation d’un cache pour stocker les résultats d’un appel d’API peut améliorer les performances d’une demande d’urgence en permettant au client d’utiliser les données mises en cache au lieu d’effectuer un appel supplémentaire pour chaque chargement de page suivant. Il existe de multiples façons d'aborder cette solution en fonction des besoins de l'entreprise. En règle générale, si les données sont identiques pour tous les utilisateurs, l’utilisation d’un service de mise en cache de niveau intermédiaire comme Cache Azure Redis constitue une option idéale pour réduire considérablement le trafic d’API sur un site, car les utilisateurs demandent les données du service de mise en cache plutôt que directement à partir de SPO. Les seuls appels SPO nécessaires sont pour actualiser le cache du niveau intermédiaire. Si les données fluctuent en fonction de chaque utilisateur individuel, il peut être préférable d’implémenter un cache côté client, tel que LocalStorage ou même un cookie. Cela a pour but de réduire encore les volumes d’appels en éliminant les demandes subséquentes effectuées par le même utilisateur pour la durée du cache, mais sera moins efficace qu’un service de mise en cache dédié. PnP vous permet d’utiliser LocalStorage en ne nécessitant que peu de développement supplémentaire.

Avant d’apporter des révisions de page pour résoudre les problèmes de performances, notez le temps de chargement des pages dans les résultats de l’analyse. Exécutez à nouveau l’outil après votre révision pour déterminer si le nouveau résultat est inclus dans la norme de référence et vérifier le nouveau temps de chargement des pages pour voir s’il y a eu une amélioration.

Remarque

Le temps de chargement des pages peut varier en fonction de nombreux facteurs tels que la charge réseau, l’heure de la journée et d’autres conditions transitoires. Vous devez tester le temps de chargement des pages plusieurs fois avant et après avoir apporté des modifications pour vous aider à faire la moyenne des résultats.

Voir aussi

Optimiser les performances de SharePoint

Optimisation des performances Office 365

Performances offertes par l’expérience moderne de SharePoint

Réseaux de distribution de contenu

Utiliser le réseau de distribution de contenu (CDN) Office 365 avec SharePoint