Accéder au contenu principal

SharePoint : Attention aux WebParts cachées dans les pages

 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 :

image

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 :

image

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 :

Untitled4

En supprimant ces deux WebParts (deux listes de liens vers des utilisateurs – Type Summary Links WP), on arrive à environ 247 KB :

Untitled5

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

Posts les plus consultés de ce blog

Série de vidéos sur le montage d'une serre horticole ACD

 Episode 1: Préparation du terrain Episode 2: Montage de la serre en elle même Episode 3: Finalisation avec le montage électrique alimentant la serre Bon visionnage Fab

Présentation des outils utiles pour l'entretien de ses haies vives

Afin de gérer les haies vives, il est nécessaire d'avoir recourt à un matériel adapté. Les solutions à batteries sont bien adaptées pour un usage personnel avec des dimensions raisonnables. Ainsi dans mon cas précis, j'utilise les outils suivants de la Gamme Ryobi 18V ONE+ électroportatif: Petit taille-haies simple mais efficace -  RYOBI OHT1855R Un modèle plus puissant qui fonctionne très bien -  RYOBI RY18HTX60A Pour les parties hautes de vos haies, voici un outil très utile -  RYOBI OPT1845 Enfin lorsque vous devez élaguer certains arbres ou certaines partie hautes de vos haies, ce dernier outil est très utile -  RYOBI OPP1820 Ces outils font parti maintenant de mon arsenal de base pour maintenir notre maison chaque saison de taille. Fab

Série de Videos sur Home Assistant intégrant la production Photovoltaïque

 Un certain nombre de vidéos sont en ligne pour intégrer sa production photovoltaïque dans Home Assistant en partant de la base. Installation de Home Assistant: On peut ensuite intégrer les composant des Micro-Onduleurs Enphase, mais aussi les batteries Enphase: Ou encore le composant de contrôle Ecojoko: Ce qui permet alors de faire des comparaisons entre les valeurs capturées: Des videos seront encore publiés dans les prochaines semaines sur différents aspects de cette solution. Fab