Dans le cadre de site Intranet corporate de Publishing, il arrive régulièrement que l’on développe un modèle de site que l’on copie à volonté.
L’avantage évident de ce mode de fonctionnement est de simplifier le travail de conception et de design, en préparant un jeu de pages modèles que l’on devra juste compléter le moment venu.
Dans cette préparation, on ajoute dans ces pages les WebParts que l’on souhaite retrouver dans la version finale, on devra changer simplement le texte ou les liens.
Ainsi, un modèle de site pourra contenir :
- Plusieurs Layout pages avec des webparts telles que :
- Content editor WP, pour la description de la page
- WP Liste de liens en rapport avec la page en question
- WP de personne pour les responsables de cette page
- …
- …
Lorsque l’on le site pour une division, il nous faut simplement partir de ce modèle et le copier et coller au bon endroit via l’outil de Gestion de SharePoint :
Ce travail n’est pas le sujet de ce message, je vous conseille de consulter les sites de Microsoft sur ce point :
La question est plutôt de ce qui est fait une foit que l’on a créé ce nouveau sous-site en partant de ce modèle.
Il est très courant que le nombre de WebParts préparées dans ses pages d’origine soit trop élevé en rapport avec celui réellement nécessaire. On va donc naturellement les définir en “Masqué” (ou “Hidden”) dans les propriétés “Layout” de la WebPart :
On va donc pouvoir trouver dans chaque page, plusieurs de ces WebParts inutilisées mais que l’on ne veut pas supprimer, au cas où.
Tout le problème est donc dans ce paramétrage. En effèt, l’ajout de ce paramètre dans une WebPart crée le travail suivant pour le serveur SharePoint lors de la navigation au sein de cette page :
- Chargement de la page
- Chargement de toutes les WebParts (cachées ou non)
- Si la WebPart est cachée, on ajoute un Visible:none dans le bloc où cette WebPart se trouve
- On envoie tout le flux HTML à l’utilisateur
Les WebParts cachés sont des WebParts comme les autres et donc le contenu est aussi fourni dans le flux HTML. La seule différence entre les deux est l’ajout du style :
- display:none;
Dans le tableau de contenu de cette WebPart. Si on regarde la source on trouve une cellule avec le nom du type :
- id="MSOZoneCell_WebPartWPQ3" (3 étant le numéro de la WP dans la page)
Pour mon exemple précis, je trouve cela dans le flux HTML :
…..<td id="MSOZoneCell_WebPartWPQ3" vAlign="top"><table TOPLEVEL border="0" cellpadding="0" cellspacing="0" width="100%" style="display:none;width:12cm">….
Ainsi, on comprend rapidement que la méthode du “Hidden” pour des WebParts non utilisées plombent totalement les performances des pages de layouts. Les fichiers HTML générés sont donc complétés d’informations inutiles qu’il est préférable de supprimer.
Si je prends mon exemple précédent, la page HTML avec les deux WebParts cachées faisait une taille d’environ 258KB :
En supprimant ces deux WebParts (deux listes de liens vers des utilisateurs – Type Summary Links WP), on arrive à environ 247 KB :
En poursuivant ce nettoyage, je suis arrivé à une taille de 229 KB, soit une diminution de presque 10%. Mais, il faut ajouter à cela les éventuelles images ou autres contenus qui seraient dans ces WebParts.
On réduit donc de matière simple la taille du flux qui est transféré vers ses utilisateurs.
Il est donc primordial d’utiliser cette option “Hidden” avec parcimonie et de garde en mémoire que les WebParts cachées sont tout de même générées, visibles dans les sources et donc transférées aux utilisateurs.
Romelard Fabrice [MVP]
Commentaires
Enregistrer un commentaire