Monday, 4 February 2008

Creating a Standards Compliant MOSS 2007 WCM Public Internet Website With Low Page Weight

The standards compliant and small page size MOSS 2007 websites keep rolling out -
Some of you may wonder how in heck are people making MOSS 2007 render these sites with such small page weight, that are compliant?
We're currently developing a Federal Government website that is required to be XHTML Compliant and we ( have spent heaps of time investigating various ways to reduce page size and unnessesary rendering.
A public WCM website rarely needs to make use of web parts so you don't need most of what is in the HTML of a standard MOSS master page such as that 200kb+ Core.JS! Why make everyone who browses to a site download 200kb .JS file that they don't need or use! That's just dumb.
You can simply wrap and hide most MOSS CSS and JS references using a custom panel control so they don't render when the user is anonymous, a SPSecurityTrimmedControl can also be used for this purpose. You still need all of that SharePoint JS and CSS if the user is authenticated and authoring, so the Site Actions, PET and Field Controls render and function correctly, but all that heavy JS and CSS is not required for the anonymous user.
The Master Page and Page Layouts are developed from a minimal.master (that has been further minimalised) and starts off completely empty and FULLY compliant, then start adding field controls and custom controls. All controls make use of the MOSS object model to get data from Page Fields for content specific to the page and Site Lists which provide an easy way for content authors to configure common elements across all pages in the site, like header and footer links. Ensure each custom control added renders its html nicely and doesn't break compliance in the page! You can also do some funky .NET code in Master Pages and Page Layouts to further strip out HTML on rendering to have extra control to ensure compliance for the anonymous user.
Think about page 'Modes' to help make it easy when developing, the anonymous user just needs a simple html page, where as someone running the site and authoring content needs all the SharePoint stuff to work. You can check the page mode programatically and also make use of Edit Mode Panels to control rendering in edit mode and display mode.

1. Edit Mode and Authenticated
In Edit mode authors need to be able to interact with field controls on the page to change content on the page. You also need the Site Actions menu, PET, and the SharePoint JS and CSS to be in the page for the author to do their job. You can forrget now about making Edit Mode XHTML compliant, but that's okay because the public won't ever see edit mode, only the web authors will, and this page doesn't need to be compliant, it needs to primarily be functional to facilitate entering content and configuring the page, so feel free to use whatever html you want to. Page size will also be massive with core.js but that's okay
2. Display Mode and Authenticated When the author checks-in the page after editing or they browse through the site authenticated they aren't presented with field controls, but with a page that looks fairly similar to what the anonymous users will see, with important exceptions, the Welcome Sign-In, Site Actions menu, PET and the SharePoint JS and CSS must be in the page for the author to do their job. Depending on security, this mode will see present the current edited page that is pending approval, so authors can trigger page workflows by clicking the PET buttons to approve pages.
3. Display Mode and Anonymous
Must be compliant, with nice html and small page size. You don't need any of that SharePoint JS or CSS, and the anonymous user defanetly aint gonna be clicking the site actions menu, PET or entering content because they won't be there! This should render as close to the HTML/CSS Design provided by the Designer (which should probably be compliant!) If you are still having problems with compliance, you can also kick in some further in-line custom .NET code in the Master Page to further manipulate the HTML rendered by overriding the Page.Render method.

So you basically need to build three seperate and independant web interfaces, by developing with page modes in mind it frees you to do what is required for that specific page mode, I have previously been frustrated with MOSS WCM Development and trying to produce clean html while still, at the same time make all the SharePoint controls function correctly, by thinking about page mode you can free yourself of the dirty rendering that OOTB SharePoint web controls when in anonymous mode and get rid of dependencies on MASSIVE un-needed JS and CSS that fatten the page size. If you are building a public internet web site, then page size should be small with simple html, css and js so that its FAST, because no one likes a SLOW website!
A problem with this approach outlined is it involves extensive development work on custom .NET controls, you need to build a lot more yourself, because guess what! The OOTB search center needs that SharePoint JS for buttons and stuff to work :( and all the Search controls are Web Parts, So you need to build a Custom Search Center site yourself that uses custom page layouts with no web parts.
I'm a big fan of going fully custom, because in the real world requirements for a standards compliant public Internet website aren't met by MSFTs cookie-cutter approach to MOSS web controls, and page rendering, you can save time when developing with custom controls because trying to configure and mess with sharepoint web controls and web parts will waste a lot more time than coding simple controls that use the object model to get Page Field data and Site List data, and then render what you want them to (for me anyways) BE CAREFUL!!! custom code means you can potentially code something nasty that will hammer sql or the cpu, be sure to dispose of objects properly. If you write custom controls you need to take responsibility for their efficiency and what they do to server resources. Also remember to enabled BLOB cache to further improve performance and try and investigate application caching when custom controls take long to do their work to get the data they need to render.
Lists can help improve productivity compared to classic ASP.NET development against a database data layer, I love lists because of all the cool free stuff that comes with them, but that development time saved is quickly eaten up by a lot of the other time wasting aspects of MOSS 2007 development such as deployment. Win Some Lose Some.

Some Code
How do you tell if you are in edit or display mode?
Get SPContext.Current.FormContext.FormMode and check this against the Microsoft.SharePoint.WebControls.SPControlMode enumeration.
How do you tell if the user is authenticated?
For an example see the RegisterCoreWhenAuthenticatedControl here

More Linkage
Excellent and Inspirational Blog Posts on MOSS 2007 Compliant websites, with heaps of steps I followed!
Blog Post on using custom HTTP-Filter to clean HTML output to reduce page size and possibly enforce compliance,guid,968b0588-f306-467b-be51-54f7a8f2079d.aspx
see sections Get the Space Out – Reducing Page Size Over the Internet Pipe JavaScript Weight Reduction – The Client Browser
How to Optimize a SharePoint Server 2007 Web Content Management Site for Performance
Definetly something to look out for AKS Accessibility Kit for SharePoint -

1 comment:

michhes said...

Love your work Sezai! I'm retroactively fixing all the performance issues on and looking to ditch all the junk anonymous users get from MOSS(why?!?).

-Michael H

PS. Watch out for Exires [sic] headers!!