This project has moved. For the latest updates, please go here.

Minimal Master page for single page application

Jul 3, 2012 at 5:44 PM

I sometimes build SharePoint pages that only rely on SharePoint Web services or similar (REST, RSS, etc.). In such cases all the default SharePoint scripts and stylesheets are completely useless and just add weight to the page.

I plan to build a minimal Master page for these specific needs, and I was wondering if anybody had done this before, and could share useful tips.

On my side, here is what I've tried:

- use the minimal Master pages published on the internet (for example on Codeplex). Those pages keep the default SharePoint scripts and are still very heavy.

- completely remove all references to the default SharePoint scripts. This is for example what I've done on my home page: . Not very clean, as this triggers error messages (not visible on my page because I cheated).

- start from a blank page: this doesn't work, as SharePoint will block .html or .aspx pages that contain scripts. The workaround would be to change SharePoint's default security settings. Again I am hoping to find a cleaner solution.

Thanks in advance for your suggestions!

Jul 3, 2012 at 6:41 PM
Edited Jul 3, 2012 at 6:41 PM

There are quite a few minimal master pages out there. Check Randy Drisgill's blog, and I think that Kyle Schaeffer and/or Heather Waterman have some, too.

The real question is what you consider minimal. You can create aspx pages that don't use any master page at all if you want to.


Jul 3, 2012 at 6:43 PM

p.s. The script and CSS files are only downloaded the first time the user hits the first page if you aren't changing them, as they are cached (and gzipped). IMO, if those files are causing performance problems, then they probably aren't the problem, but instead it's something else going on with the infrastructure.

Jul 3, 2012 at 6:53 PM

Not sure if this is exactly what you are looking for, but I will share common trick I use...

I have done this, but did not really "remove" everything from the page, but rather "hide" from the user so that I only display what I want the user to see. An example is where I often use the new item form to create an item in a list through an iframe without having the user leave the "current page".... I do this by following these steps:

  1. Using jQuery UI, create a new Dialog, and insert a (hidden) iframe that points to the newItem.aspx page.
  2. Using jQuery, "reach into" the iframe (because it is from the same domain, you can do this) and hide everything except the input form.
  3. Display the iframe to the user

Here is some sample code from an upload widget I have where it display the Edit form when a file requires "check in":

        .css("display", "none")


This hides all elements inside the <form> and adds a class to them (wasVisible) case we need to make them visible again... it then finds the form by first finding the "Title" field and then "walking up" to the web-part that holds it and moves that to the root the <form>, so that it becomes accessible to the user. I then make the <form> visible to the user.

From a user experience, they see a dialog with the New Form. I have other code to "Detect" that the use made a save and then hide the dialog again, which you implement yourself.

Hope I did not loose you here... Its not the cleanest implementation, but it works for me.


Jul 3, 2012 at 7:21 PM

Thanks for the suggestions.

Caching is not enough because the user might go directly to that page for a quick search and select. Hiding isn't enough either, and jQuery UI is also too big. The "minimal" in my case directly relates to performance, not just the visual. To make an analogy, I am looking for a Google home page rather than a Bing home page.

Marc, Randy's pages are what I was referring to, but they are still carrying the core stuff and Co. - hundreds of kb that are useless for Web services. Not using a Master page is also something I was referring to in my post (last option), but I don't know how to make it wok easily in SharePoint. Would you have an example, or additional information?

Jul 3, 2012 at 7:57 PM

What do you mean by "Caching is not enough because the user might go directly to that page for a quick search and select"? Once a user hits pretty much any SharePoint page, they have things like corev4.js cached from then on.

If you load files like jQuery and jQueryUI from a CDN, it's even less likely that they will be downloaded from your particular app.

For a simple aspx page, just go into SharePoint Designer and do a File / New. You'll get:

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "">
<%@ Page Language="C#" %>
<html dir="ltr" xmlns="">
<head runat="server">
<meta name="WebPartPageExpansion" content="full" />
<meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
<title>Untitled 1</title>
<form id="form1" runat="server">

I'm still thinking your expending effort in the wrong direction.


Jul 3, 2012 at 8:49 PM
Edited Jul 4, 2012 at 5:00 PM

Thanks Marc. When I initially tried that, I got an error "code blocks are not allowed". But I just tried again, and it seems that if I store all the scripts in a separate file and link to them it is accepted. I'll keep experimenting with it.

I hear you. It's just that sometimes you just need direct access to the content and nothing more. Something similar to the out of the box mobile pages, just a little more flexible.

[Edit] Just to clarify my sentence: "users might go directly to that page for a quick search and select": I meant that some users will only use that page (single page application) and won't navigate the site. They'll have the link as a bookmark or from an e-mail. The scenario in my case is a database of contacts or products that is maintained by a team and that other teams will consume ("filter and select"). Kind of an within the company.