Attention au poids d'un page MOSS ! (et son optimisation)
Suite à un petit audit, quelques tests et lecture , je vais vous parler un peu aujourd'hui de la problématique des pages sous MOSS
Surtout dans un cas particulier qui est celui des page de contenu pour WCM (Web Content Management).
Quand on parle WCM, on sous entend, et avec raison, Site frontal institutionnel : un site web sur INTERNET
Et la, la notion de poids de page devient importante, pour ne pas dire primordiale
Evidemment, il ne faut pas prendre en référence les CSS et le coeur HTML des pages par défaut de SharePoint.
Pourquoi ? Simple, si nous parlons de site institutionnel, nous allons rentrer dans le gentil monde du branding internet donc de nos amis les designers/intégrateurs graphique (Salut Guy et Axel)
Et donc dans ce cas la, on peut s'attendre à des CSS et des Layouts optimisés sans trop de tableaux, n'est ce pas ?
Mais bon admettons que nous partons d'un modéle de base dans MOSS sans customisations.
Une fois la page enregistré en local via IE avec tout son contenu, on obtient :
-
Core.js: 258 KB (SharePoint core JavaScript)
-
Core.css: 121 KB (SharePoint core styles)
-
Home.htm: 99 KB (HTML of page)
-
Ie55up.js: 103 KB (more SharePoint JavaScript)
-
Init.js: 67 KB (and more SharePoint JavaScript)
-
Search.js: 26 KB (JavaScript for search)
-
WebResource.axd: 21 KB (ASP.NET special handler for Web Resources)
-
Etc… (the rest are under 20 KB)
Que peut on donc analyser (plutôt que critiquer directement !)
- L'importance de travailler ces CSS et ASPX en vue d'un site frontal SharePoint
>>> partez donc de la minimal.master de notre amie Heather : http://www.heathersolomon.com/blog/articles/BaseMasterPages.aspx
>>> n'oubliez pas "Small is Beautiful"
- Bien penser au cache du navigateur : c'est son role !
>>> ca limite les retéléchargements à chaque tour<meta name="expires" content="Wed, 7 Mar 2006 15:52:37 GMT">
<meta http-equiv="cache-control" content="max-age 10">
- Le poids conséquent du javascript : surtout du Core.js
>>> Mais c'est contournable aisement !!!!
Je m'explique, dans le cas d'un Facing Site, 80% du site est configuré en anonyme. Dés lors, le Core.Js est complétement inutile pour les accés anonymes à la différence des utilisateurs membres ou auteurs. il y a une simple modification à implémenter pour en profiter sur le mappage anonyme tout en laissant le mappage authentifié propre :
- http://www.thesug.org/blogs/patrickr/Lists/Posts/Post.aspx?List=8afc69af-f9fc-4786-816f-6419264c42da&ID=7
- http://blogs.msdn.com/ecm/archive/2007/02/21/building-a-new-page-layout-which-does-not-reference-core-js-but-downloads-it-while-the-page-is-being-viewed-thereby-optimizing-response-time.aspx
>>> on peut aussi profiter d'un chargement caché, voir nettoyer un peu plus le flux de sortie (voir dans les annexes)
- Il existe aussi du cache coté serveur qu'il ne faudrait ne pas oublier : quitte à avoir du volume, autant le gérer vite et bien, non ?
- Pour finir, n'oubliez pas non plus, la compression IIS !!!
Bref, avec de simples réflexes, le résultat devient clairement excellent et conforme à nos chers standards Web.
D'ailleurs, j'en profite pour vous rappeller le pack AKS pour l'accessibilité et la compliance de nos chers site SharePoint : WCAG 1.0 AA
http://blogs.msdn.com/sharepoint/archive/2007/11/28/announcing-the-accessibility-kit-for-sharepoint-aks-1-0.aspx
Voici quelques annexes pour vous aider (ou aller un peu plus loin)
Renaud Comte aka TheMit (WCM en avant)
Member of WygTeam
http://www.wygwam.com
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 :