SharePoint : Retour d’usage sur la désactivation du ViewState dans un site de Publishing
Dans mon précédent article, j’avais évoqué le lancement d’une série sur les optimisations possibles pour améliorer les perfomances d’un site SharePoint de type Publishing (Portal Intranet Corporate) :
Après quelques jours de test, voici un bilan sur le résultat de cette modification.
Tout d’abord, l’usage du ViewState en ASP.NET permet d’éviter des rechargements intempestifs de toute la page lors de la modification de certaines parties de cette page. Le cas classique est le formulaire avec des listes déroulantes en cascade.
Dans le cas spécifique du menu de SharePoint (Objet SharePoint:AspMenu), le chargement de ce composant et donc de l’ensemble des liens peut être séparé en deux cas précis :
- Site de Publishing Internet public
- Site de Publishing Intranet ou Extranet
En effet, le comportement de ce menu lors de son chargement est de tester les permissions pour l’utilisateur connecté. Ainsi pour chaque lien à ajouter dans le menu, une vérification est effectuée afin de savoir si l’utilisateur courant a le droit de voir ou non la page destination de ce lien.
Ceci est totalement compréhensible, car un “Content Manager” a souvent bien plus de liens qu’un simple “Reader”.
De ce fait, lors du chargement des composants du menu, SharePoint va effectuer le test des droits qu’il stockera ensuite dans ce ViewState (activé par défaut). Ainsi, lors de la navigation dans certains composants de la page (cas du remplissage d’un formulaire) qui ne nécessite pas de rafraichissement complet, ce ViewState sera utilisé pour éviter d’éffectuer ce test à nouveau.
Pour conclure, dans le premier cas (site Internet), le ViewState du Menu doit être désactivé, mais globalement il ne faut pas utiliser le modèle de publishing pour ce type de site (les pages de Layouts avec des WebParts ne servent à rien pour un site public). Il est même préférable de faire développer une page light par son équipe de designer utilisant des Users Controls plutôt que des WebParts.
Dans le second cas (site Intranet ou Extranet), cela dépendra de votre contenu dans les pages.
Mon conseil est de créer deux versions de la même Master Page (une avec et une sans ViewState) et de faire un test sur une semaine chacune de ces Master Pages par ses utilisateurs (voir directement sur la production).
Vous aurez ainsi un bilan concrèt et le retour de la perception des utilisateurs sur ce changement.
Nous verrons d’autres axes d’amélioration bientôt.
Romelard Fabrice [MVP]
Ce post vous a plu ? Ajoutez le dans vos favoris pour ne pas perdre de temps à le retrouver le jour où vous en aurez besoin :
